tag:blogger.com,1999:blog-741750605858169835.post1538548989460063492..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Scala feels like EJB 2, and other thoughtsStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger146125tag:blogger.com,1999:blog-741750605858169835.post-55376691060316322752015-02-24T19:38:59.993+00:002015-02-24T19:38:59.993+00:00> (0/:l)(_+_)
> Thats practically the very ...> (0/:l)(_+_)<br />> Thats practically the very definition of line noise. (And I've not even shown any scalaz examples, or similar unicode <br /><br />I actually like this terse style, it's part and parcel what draws me to Scala. I don't understand why other devs have a problem with this approach and seem to feel that a heavily verbose alternative is better. For me it is quite the opposite: the more verbiage, the harder it is to follow.<br /><br />And with respect to the "unicode wierdness" link you posted, there is nothing wrong with that either. We're not talking about abusing operator overloads, he is implementing very mature 19th century De Morgan's laws consistently. <br /><br />Is this unicode wierdness or is this your lack of familiarity with De Morgan's laws?<br /><br />Programming should reflect mathematics not resist it. Mathematics has been the most successful in describing the nature of things than any other language. It is the most efficient, the most simple, the most concise language for describing the nature of things. It is the universal language, and first contact with extra-terrestrials would only be achieved via mathematics. <br /><br />To resist mathematics is to regress. And as such I find your criticism of Michid's union types implementation disappointing.Knurdhttps://www.blogger.com/profile/05570170609420849934noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-19533144936407479682015-02-24T19:14:10.181+00:002015-02-24T19:14:10.181+00:00I hear you.
I am a Scala newbie as well, and befo...I hear you.<br /><br />I am a Scala newbie as well, and before Scala I was a complete FP virgin. But I feel it took me no more than 2 hours to ramp-up and become productive FP in Scala whereas many of my peers struggle to grasp the language and FP in general. What I notice is that when I step-in to assist, they keep polluting their approach in Scala with imperative styles and it always seems to be the source of confusion.<br /><br />If you try to force Scala into your Java paradigm of course you're going to hate it.<br /><br />One thing that may have helped me is that over the past five years I developed a keen interest in mathematics and in-particular vector calculus as a hobby apart from my career. Applying that mindset to learning FP may have eased the learning curve. Another thing that helped me was reading-up on Alonso Church.<br />Knurdhttps://www.blogger.com/profile/05570170609420849934noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-65816435585273072892015-02-24T19:01:20.150+00:002015-02-24T19:01:20.150+00:00So what you're saying is that Scala is freedom...So what you're saying is that Scala is freedom but not freedom from responsibility? The argument that a language should force all programmers to write code in exactly the same fashion is absurd. It is a hail-back to 1984; what I mean by that is Apple's 1984 commercial designed to undermine the monotony of the way people solved problems in that era. It would be like regressing back to those days before the Apple revolution.<br /><br />That is fundamentally insane!<br /><br />If we cannot trust each other to write code responsibly, we cannot trust each other to do anything responsibly. So then say hello to your new fascist dictators, and if you don't like it then off to room 101 with ye.<br /><br />For every time this criticism is leveled against Scala I demand the acknowledgement that JavaScript is worse, otherwise I consider the argument invalid.Knurdhttps://www.blogger.com/profile/05570170609420849934noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-47318552600597605572013-07-11T03:34:21.637+01:002013-07-11T03:34:21.637+01:00"The Scala community is not tolerant of disse..."The Scala community is not tolerant of dissent":<br /><br />Well, the comments herein provide some fair evidence towards this. <br /><br />Scala is going through a phase of being new kid on the block, trying to setup for an advanced future. That's very tough, with challenges to get right across spectrum of areas. It's reasonable, nay *great*, to ask challenging questions. Many of the 'answers' here are fanboy/flame 101. The OP should be thanked for writing and reasoning to the extent he did. The onus is on the community to answer - which, properly done, should probably take 10 times more reasoned content... Anyone? Please?<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-62551624858171322102013-07-11T02:47:10.402+01:002013-07-11T02:47:10.402+01:00Did you mean FUD?Did you mean FUD?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-58843280107355863952013-07-11T02:03:15.108+01:002013-07-11T02:03:15.108+01:00Hmmm... I'm no apologist for the OP, but this...Hmmm... I'm no apologist for the OP, but this response addresses is unhelpful. It acknowledges and addresses none of the points made. It's lazy to serve arrogance, rudeness and blanket black-and-white opinion, where only explanatory content could help the Scala cause. This seems to me textbook reinforcement of the OP's point about some in the community. <br /><br />Maybe the OP has some degree of misinformation and biases and is not getting an objective picture out? But it's legit to have concerns and raise questions, seeking answers. He deserves the assumption that he's objectively trying to understand the strengths and weaknesses and is not an entrenched Scala 'hater'.<br /><br />One of the most important, if not the most important, traits in achieving success in any grand and complex team endeavour is the ability and willingness to objectively self assess, critique and address weaknesses. Another is the ability to communicate well the available features, nuances, approaches and best practices to help all on the journey and grow numbers and capability. Think about it. The subject matter raised, does have the potential to negatively impact. He cross-references cases where this has happened elsewhere. This is not trivial stuff, that can be swept under the carpet.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-5095628404764745562013-07-11T01:22:09.394+01:002013-07-11T01:22:09.394+01:00Two years later and inbound from Google, one must ...Two years later and inbound from Google, one must wonder how this approach is working out for you. From my perspective, this is exactly the kind of snark that lowers the dialogue, and it persists today, not to mention how out of place throwing PHP into a discussion of static languages is.<br /><br />"Message queues can be replaced by SMTP and POP, or just a DB table to hold the job list."<br /><br />No, no and thrice no. For posterity's sake. No one in their right mind would would give up the fault tolerance and sanity checks afforded by solutions like AMQP on RabbitMQ just to cut a corner and fly by fire-and-forget SMTP, especially when virtually every language has an an option available at this point and the development overhead is virtually nil. Solutions like SQS make implementation trivial. Where using such a pay-for service is impractical, celery backed by MongoDB can give you virtually the same fault tenacity and entirely for free. What you're suggesting here is a trade for no gain.<br /><br />For a guy who throws the invective term "stupid" around so much (and about entire language specs at that!) one could have a choice term for what the stack you advocate. Maybe you could do for some of the insight those "perfectionists" you chagrin so much could offer. Keep an open mind, perhaps?<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86859023661995448962012-10-14T21:03:04.014+01:002012-10-14T21:03:04.014+01:00Yes I'm a Scala newbie, I only discovered it l...Yes I'm a Scala newbie, I only discovered it less than five months ago and I'm struggling to see what is complicated about:<br />val coll2 = List(1, 2, 3) ++ Set(3, 4, 5)<br />//result: List[Int] = List(1, 2, 3, 3, 4, 5)<br />Set(1, 2 ,3) ++ List(3, 4, 5)<br />//result = Set[Int] = Set(5, 1, 2, 3, 4)<br />That strikes me as the height of simplicity. I think the signature above is to enable something slightly more generic like:<br />List[Car](FordEscort, Porsche911] ++ Set[Truck](MercedesAxor, VolvoFH)<br />gives result: List[Vehicle](FordEscort, Porsche911, MercedesAxor, VolvoFH)<br />But again what could be simpler to use than that?Richhttps://www.blogger.com/profile/11553465908249956699noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-73071437351839300352012-06-24T19:00:50.754+01:002012-06-24T19:00:50.754+01:00> It looks like Scala is ultimately attempting ...> It looks like Scala is ultimately attempting to give us the benefits of Haskell on the JVM.<br /><br />Actually it would more be Frege which aims to do that.Anonymoushttps://www.blogger.com/profile/11382268504770604242noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-9185092386170395122012-06-07T03:23:17.411+01:002012-06-07T03:23:17.411+01:00There's an element of truth in most of Stephen...There's an element of truth in most of Stephen's points, and I think, despite OP's obvious bias against the language, it's still a valuable critique.<br /><br />Modules - would be nice, but it doesn't make much sense at the moment to develop such a system with project Jigsaw on the horizon.<br /><br />Concurrency - compiler checks for immutability would also be nice, but it's really not a big deal in practice.<br /><br />Community - the vast majority of members are very helpful, intelligent, and friendly in my experience. Since Scala has roots in academia it's only to be expected that some people are concerned with exploring the limits of what's possible. So you don't understand cutting-edge research-level topics - is that surprising? Should people not discuss them? <br /><br />OP comments "This sometimes leads Scala aficionados to castigate those that don't understand as lazy or poor quality developers, as being second class citizens". I am fairly certain that this refers to the outbursts of just one individual, who has made great contributions but perhaps has difficulty dealing with people. It's unfair to make out that this is representative of a whole community since I've never seen such a sentiment expressed by anyone else.<br /><br />Why not instead say something closer to the truth, e.g. "Scala aficionados are passionate about their language and are always eager to show you the ropes. Sometimes their explanations will fly over your head, but if there's something you don't understand, they're more than happy to explain." Don't focus needlessly on the negative. Personally, I've learnt almost everything I know about the language from the fantastic community.<br /><br />I've run out of time to address the other points. :)Luigi Plingenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-54847623433561866522012-03-16T00:11:34.540+00:002012-03-16T00:11:34.540+00:00Everyone has issues with any language they use, an...Everyone has issues with any language they use, and even Scala aficionados have issues with certain aspects of Scala. But I've lost a lot of respect for the author for expressing his ideas in this manner. My objections have been covered by other people in other comments so I won't repeat them.<br /><br />But I encourage anyone to try Scala out and come to your own conclusion. Even if you decide that Scala is not the right language for you I think you can still gain a lot from learning it. I can honestly say that my Java code has gotten better from learning Scala.Jason Wheelerhttps://www.blogger.com/profile/03003397883655075830noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-78456153131191383862012-03-13T14:16:32.948+00:002012-03-13T14:16:32.948+00:00Is this Richard Richards speaking?Is this Richard Richards speaking?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-62578751454829860232012-03-02T12:15:10.718+00:002012-03-02T12:15:10.718+00:00Complexity
I agree in principle that we want to e...Complexity<br /><br />I agree in principle that we want to eliminate complexity that doesn't fulfill the 80/20 rule (Paretto Principle).<br /><br />I'm aware of the <a href="http://grahamhackingscala.blogspot.com/2011/12/will-typesafe-address-scala-criticisms.html" rel="nofollow">Yammer</a> and Steve Yeggie criticisms.<br /><br />I empathize with the allegation that Scala is a "write-only" language, given for example <a href="http://goldwetrust.up-with.com/t112p165-computers#4420" rel="nofollow">9 ways to write a method function</a>. I am <a href="http://goldwetrust.up-with.com/t112p180-computers#4460" rel="nofollow">pondering ideas</a> that may or may not succeed in reducing complexity, yet retain the robust static typing that I claim is necessary to have true modularity. Even the extra (as compared to Java) binary compatibility complexity of Scala is <a href="http://www.scala-lang.org/node/9346" rel="nofollow">somewhat due</a> to the conflation of interface and implementation, also the multiplicitous syntax <a href="http://www.slideshare.net/mircodotta/managing-binary-compatibility-in-scala" rel="nofollow">enabled by</a> type inferencing.<br /><br />As I <a href="http://copute.com/docs/" rel="nofollow">explore modularity</a>, afaics so far I could not (without boilerplate inefficiency, code rot, and semantic non-determinism rot) implement the necessary paradigms without the robust type system, including implicits, higher-kinds, etc.. I am exploring that perhaps it will be possible to hide this complexity in a language that is custom-tailored to do some key features. If successful, it might still indicate that the power of Scala was necessary to implement such a compiler efficiently.<br /><br />So far, <a href="http://stackoverflow.com/questions/1722726/is-the-scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist/7397388#7397388" rel="nofollow">I am undecided</a> if the use of implicits in the standard library was the correct way to go.<br /><br />I think none of us have a complete enough picture of how to get a handle on the complexity of the exponentially exploding world of software, and whether the power of a Scala type system is necessary, or what could be simplified. There are going to be some growing pains as the Comp Sci world figures this out.<br /><br />Let's keep in mind for example that neither Java nor Haskell can do <a href="http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html#c264394583444826559" rel="nofollow">diamond multiple inheritance</a>, which causes major problems for modularity.<br /><br />There is no free lunch. There is much experimentation going on to find the key advantages that are going to replace Java, because we are overdue on the decade cycle of having a new mainstream language.<br /><br />We have to ask ourselves, what is the key feature that will drive the next language? For Java, it was garbage collection and the VM.<br /><br />Apparently the shift to dynamically-typed languages <a href="http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html" rel="nofollow">has abated</a> (see chart near bottom) and is either stagnate or reversing.shelbyhttps://www.blogger.com/profile/04192118408905938326noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-75397118519526196482012-03-02T09:42:45.633+00:002012-03-02T09:42:45.633+00:00Concurrency
Scala has the 'val' to declar...Concurrency<br /><br />Scala has the 'val' to declare immutability. It is lacking the ability to declare functions (and methods) as 'pure'.<br /><br /><a href="http://copute.com/docs/Event.html#Modeling_Change" rel="nofollow">No real world program</a> will have entirely immutable data. In addition to immutability, concurrency also requires <a href="http://en.wikipedia.org/wiki/Thread_safety#Concurrent_programming" rel="nofollow">atomicity</a> and <a href="Propogation%20Indeterminancy" rel="nofollow">acyclical propogation</a> of data flow, which can never be guaranteed in open, distributed systems.<br /><br />In short, concurrency will always be non-deterministic and exhibit random semantics (i.e. bugs a/k/a <a href="http://awelonblue.wordpress.com/2012/02/16/declarative-state/#comment-271" rel="nofollow">semantic noise</a>) in the open, distributed scenario. There is no theoretical way for a compiler to prevent it, due to the Halting theorem (inability to trace all potential code paths) for Turing-complete machines. See my links above for more on that.<br /><br />Perhaps Scala could benefit from the ability to declare functions as 'pure'. My impression is the author is too harsh by not recognizing the existence of 'val' and by implying that immutability is a concurrency panacea.shelbyhttps://www.blogger.com/profile/04192118408905938326noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42934200554265954332012-03-02T07:56:56.809+00:002012-03-02T07:56:56.809+00:00Modularity
Afaics, the discussion about ML module...Modularity<br /><br />Afaics, the discussion about <a href="http://lambda-the-ultimate.org/node/2808" rel="nofollow">ML modules versus Scala</a> is research about the most composable paradigm for the separation of interface from implementation. That is not central to the allegation that Scala is bad because it is alleged to not have modularity.<br /><br />Modularity (i.e. <a href="http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html?showComment=1311534787150#c2109159097718758997" rel="nofollow">separate compilation</a>, <a href="http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)" rel="nofollow">SOLID</a> principles, <a href="http://copute.com/dev/docs/Copute/ref/Complete%20solutions%20to%20the%20%93Expression%20Problem.htm" rel="nofollow">Expression Problem</a>, <a href="http://copute.com/docs/Event.html#Theory" rel="nofollow">declarative programming</a>, etc.) is fundamentally about separating interface from implementation (and sufficiently expressive typing for denotational semantics). If an interface changes, give it a new name-- afaics versioning hell would disappear. A key point is separating implementation (changes) from the abstract interface declarations (which should change more infrequently). Afaics, there is no need for a special orthogonal syntax for versioning, just change the name of the interface (append a version number).<br /><br />The ability to compile implementation separately from interface, is what matters in terms of those asking to be able to compile 'modules' and not classes. The pertinent issue is not that the unit of 'class' is too low-level, rather it is that 'class' shouldn't be first-class, i.e. one should never be able to reference and operate on a class (input and operate on an interface instead). Afaics, the modularity paradigm of the critics is apparently wrong, thus they want something which isn't modularity.<br /><br />Afaics, Scala suffers no more than any other language (e.g. all of the popular languages) that allow mixing implementation in an interface declaration and/or that allow referencing a non-interface as a first-class type. My current thinking (subject to change with experience) is I would choose to separate a Scala 'trait' into 'interface' and 'mixin', where the former is an abstract signature and is first-class, and the latter is implementation and not first-class.<br /><br />The loading of modules dynamically is mostly an orthogonal issue. Google "Java classloaders". Afaics, the main point for modularity is dependency injection employing interfaces, since implementation wouldn't be first-class and thus couldn't be referenced in my proposal. Afaics, this can be emulated in Scala manually (not enforced by the compiler), but can't be emulated in languages (most of them) which don't have mixins and sufficiently powerful typing.<br /><br />Afaics, <a rel="nofollow">Fantom destroys modularity by throwing away typing</a>:<br /><br /><a rel="nofollow">http://fantom.org/sidewalk/topic/675#c11391</a><br /><br />Reflection and dynamic typing is not modularity. Perhaps your experience is greater than mine, but afaics wide-scale modularity doesn't exist without powerful typing.<br /><br />I am very interested in counter examples to my points.shelbyhttps://www.blogger.com/profile/04192118408905938326noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6534625846005573962012-03-01T05:06:34.001+00:002012-03-01T05:06:34.001+00:00Wow... I'm late to the party.
As someone who...Wow... I'm late to the party. <br />As someone who has programmed professionally in many languages (but in the last 16 years primarily Java) and in multiple distributed paradigms (RPC, Sockets, CORBA, EJB 1/2/3, SOAP, ReST... god i'm old...) I see what Stephen is saying. He's not making a technical comparison of Scala to EJB2, he's using the analogy of the distaste of EJB 2 by the Java community at the time to a distaste he has and sees with using Scala as a general use programming language.<br /><br />All of the posts contrasting Scala to EJB that I just read (I got tired of reading the replies) are correct. But again I believe Stephen wasn't trying to compare the two as technologies but it was an analogy of how EJB 2 did a lot but it's inherit complexity for even the simplest things made it unpopular. If you think about it, if you are pointing out the differences between Scala and EJB you are picking apart all of the differences between a computer language like Scala and a specification. He wasn't trying to say Scala is like EJB he's talking about the negative aspects that both brought/bring to many users. If you are focusing on how is comparison of the two technologies differ then you are simply not seeing the forrest for the trees... I think he's just saying: "This inherit complexity, lack of testing, rich but computationally-explosive type/collection mechanism provides the same distaste for using Scala (to him and others) that EJB 2 did for those of us programming in server-side Java at the time."<br /><br />For the record, 2 years ago I was a team lead on a project and approved the use of Scala to augment our Groovy and Grails implementation for it's concurrency. It was more efficient for us to use Scala to multi-thread our request processing than doing it in Java. It wasn't that we couldn't do it in Java, but that we had been looking at Scala off-and-on for a while and felt this one particular need would be more efficiently soled in Scala. <br /><br />I'm not anti-Scala but I TOTALLY get what Stephen is saying, I just agree at a lesser extent. Scala has it's place, it just doesn't feel to me that it's place is to replace Java for the meat-and-potatoes programming, even though it is technically capable.Dustyhttps://www.blogger.com/profile/06739403240645807469noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-70917219939085938022012-02-16T23:01:34.223+00:002012-02-16T23:01:34.223+00:00> "FP is a different programming paradigm ...> "FP is a different programming paradigm and not for non-lambda ultimate types" <br /><br />... and then ...<br /><br />> "Making the syntax simple does not solve problems."<br /><br />Heard of Lisp, FP noob? Sounds like you haven't made it out of CS 101 yet yourself.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-16007566801506827902012-02-15T09:31:05.819+00:002012-02-15T09:31:05.819+00:00I 100% agree with the author.
Scala is too complex...I 100% agree with the author.<br />Scala is too complex even for experienced developer who had never worked with functional languages. And there are 90+% of such people.<br />But imagine that I need to introduce junior dev into big Scala project. I simply feel a big FAIL here.Zzznoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-9865129786095702012-02-03T19:33:43.062+00:002012-02-03T19:33:43.062+00:00I do not fully agree to the points about the compl...I do not fully agree to the points about the complexity - you like other non-Java languages, but at some point you appreciate that Java kept things simple. They kept things so simple that Java codebases are infested by boilerplate accessors which people have to avoid to get to the real code.<br /><br />Just a brief point about the community harshness:<br />> So, it appears this is not just a functional programming community thing.<br />Clojure is (IIRC) dynamically (not statically) typed, and I believe that makes a big difference. This attitude seems present in the Scala, but much less than in the Haskell community.<br /><br />The reality is that "hard-core functional programming" in strongly typed languages like Haskell has a really steep learning curve but also amazing benefits - in essence, it's mathematics (category theory in particular). Unlike in OOP, abstractions can be much more general, and much more generally applicable. However, the process of abstraction _is_ somewhat hard - and it just takes time to get it. Moreover, I've seldom seen that coding style in untyped languages, and I strongly suspect that it's because it wouldn't work well.<br /><br />However, Scala does not require you to get to that point. You can program in a simpler style. If that's your choice, I guess you want to stay away from Scalaz - also because they seem to target experienced Haskell programmers anyway since they have little documentation.Anonymoushttps://www.blogger.com/profile/04485097839438234853noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42971677278538451432012-01-30T06:45:58.852+00:002012-01-30T06:45:58.852+00:00> Now I realise the scala landscape is made of ...> Now I realise the scala landscape is made of both kinds of people, some of them very helpful. Best to ignore the parts where some wonder why others find scala difficult to learn.<br /><br />This is a helpful comment and important to keep in mind. Sadly, the "everybody else is an unworthy idiot" will push many people away. From where I sit, it is striking how much less defensive and hostile the Clojure community is for example. So, it appears this is not just a functional programming community thing.Justinhttps://www.blogger.com/profile/10357987798044677430noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-57479499076349010832012-01-30T06:40:11.036+00:002012-01-30T06:40:11.036+00:00There is a difference.
What you describe is my fa...There is a difference.<br /><br />What you describe is my favourite kind of engineering environment. That kind of informed, challenging, and passionate community creates a playground for the mind. A critical element though is the the social convention to "attack the idea and not the person". In addition, it is not just about debating other people's sacred cows but about being excited when somebody questions your own.<br /><br />The environment you describe is much as the scientific community should work. Dissenting ideas are either an opportunity to advance your own understanding or a chance to display your intellectual prowess (depending on if the dissent proves well founded or not). Unfortunately, personal attacks and self-evident truths are a big part of the arguments that I have seen Scala fans wage.<br /><br />> The Scala community is not tolerant of dissent<br /><br />In fact, it is much worse. Many Scala fans will not even tolerate the peaceful promotion of competing technologies. As an outsider, it feels as though the Scala community is very frustrated that the rest of will simply not shut-up and drink the Kool Aid and is getting impatient waiting.Justinhttps://www.blogger.com/profile/10357987798044677430noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-61100008020403144412011-12-19T21:48:29.322+00:002011-12-19T21:48:29.322+00:00Much theory here. Started to read *the* Scala book...Much theory here. Started to read *the* Scala book a few days ago and put my hands on the keyboard. Regarding my 10+ years Java background, I'm very impressed with Scala.<br />I studied computer science and got in contact with ML and Lisp. Never thought functional aspects would go mainstream. But looking at Scala and it's elegance it seems so much natural to me!<br />I love what I've seen so far and would recommend everyone to give it a try.Daniel Dietrich's Bloghttps://www.blogger.com/profile/02492628698632995681noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-60714269768455558772011-12-06T17:58:21.760+00:002011-12-06T17:58:21.760+00:00As a Java web developer, I delivered 4 projects an...As a Java web developer, I delivered 4 projects and failed at 2. As a PHP web developer, I delivered 30+ projects and never failed. Using Java EE and studying its specs, I believe that Java people and promoters were stupid perfectionists. PHP may be quick and dirty, but delivers. And it does so without any huge corporate powertrain behind. In rare cases where you need more than PHP, one can use C++ or Java as a standalone console application - there is no need for containers, servlets, EJB, object mapping, JMS, etc. Integration can be done with pipes or webservices. Message queues can be replaced by SMTP and POP, or just a DB table to hold the job list. There is no need for threads - just spawn another process. Connection pooling can be replaced by process pooling.<br /><br />What makes things simple in this architecture is the absence of so many layers and complex, integrated APIs. You basically receive the request and respond to it. Caching is on your own. Talk to the database the way you like. 90% of your code is automatically stateless and sandboxed, and there is no need to complex setup or slow loading. Now compare it to Java EE - to respond to a simple request first you need to load a huge container into memory, and that reads lots of configurations. After some warmup (because almost everything is lazy-loaded, due to slow loading), your request can be handled reasonably fast. Then there is servlet, JNDI, context, connection pool, object mapping, EJB, JVM, etc, plus application server "features" like clustering and high availability - all of which must be correctly configured. 2% is your code, 98% is code from someone else that needs to be integrated. If something goes wrong (or goes slow, as often happens), there 98% of chance that it will be on some layer. Then somebody will tell "you didn't code using the recommended patterns". So you must add more boilerplate to make it work.<br /><br />Fortunately I work mostly at in-house development, so I don't need to listen to stupid IT manager requirements such as "80% of solution must run on JVM", "must run on ABC Application Server", etc. Hence, I really don't care about Scala in the Java EE world. I think Scala doesn't solve the urgent problems in Java EE. The language can allow smaller programs, but while these programs run or require a fat set of layers under it, loaded, configured and warmed-up, a better language won't help.<br /><br />When comparing Scala to Java language itself (forgetting Java EE), then to me Scala documentation and promoters resemble some stupid perfectionism or at least some excessive optimism. I particularly don't like Scala syntax, but this might be biased from years of C/C++, Java and PHP. Kotlin and Gosu seem to be more reasonable replacements than Scala if you need too many algorithmic programming (that PHP can't handle). It's a shame that JetBrains decided to invent Kotlin instead of uniting to Gosu - the motivation behind Kotlin and Gosu is 90% the same, but still that yielded quite different languages.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-25596035243329957752011-12-05T08:02:53.344+00:002011-12-05T08:02:53.344+00:00I agree to all of what Stephen outlined in his pos...I agree to all of what Stephen outlined in his post. I am a seasoned Java programmer and started experimenting with Scala recently. I was just curious about other languages in the JVM and Scala seemed promising. The moment i saw operator overloading, it reminded me of C++. Isnt there a good reason why Java avoided it?<br /><br />Its expressive for the seasoned programmer but intimidates the average Joe. I read about 13 chapters of the Martin Odersky Scala book. The type system is way complex and the feature set is bigger than C++. Read again, "bigger than C++". Thats a red flag.<br /><br />I still liked it or i should say i was bored with Java. I went on to create a web application using Scala. The frameworks are immature and the most popular framework in Scala Lift is for programmers from a different world. <br /><br />I told myself i would use Java frameworks and write Scala code. It didnt scale. I couldnt use Scala's features fully and i have to make use of conversions to make Scala play well with Java frameworks.<br /><br />Each Scala library kinda has its own DSL, you know with operator overloading and custom constructs etc. This makes the code hard to read. If you are writing mission critical applications, you would end up using multiple frameworks and the learning curve is huge.<br /><br />Scala scares me. I would rather use Java's imperfect type system than learning the Scala's cumbersome and complex system.Aravindanhttp://www.aravindanr.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-3040665594802681412011-11-30T21:50:42.941+00:002011-11-30T21:50:42.941+00:00I just can state from personal experience that the...I just can state from personal experience that the type system isn't "getting in the way" all too often. Most of the time it's a helpful guide to catch errors early.<br /><br />And in those circumstances where I don't want to fuss with overly complicated types (mostly recursive structures which can be unpleasant to type) I just cast the fuss away. It's always an option.<br /><br />With the collection library it's the same: there is nothing wrong in using it without having all the gory details of its type signatures in mind all the time. If I am getting it wrong the compiler will tell me. Most of the time I don't even care - I put my statements in the REPL (the scala "interpreter" shell) and test if I got something right (not aiming at the types but the intended functionality).<br /><br />In summary (and I am no PhD developer) I am a lot faster with scala than I am with Java, C# (disregarding GUI development) or Perl. It hit's a sweet spot combining the sloppyness of scripting with the rigor of type safety.<br /><br />But I agree in two points:<br /><br />-1-<br />If someone want's to show you that you are a dumb coder not worth your salt that person can do so with scala. The language allows arcane things which are not easily understood with java / OO background.<br /><br />-2-<br />I think there are some scalaist which are very explicit about their point of view and vilify people which do not share their mind set.<br /><br />I just chose to disregard both.<br /><br />So scala fits my bill - which does not imply that it has to fit yours, which it obviously doesn't.<br /><br />GreetingsAnonymousnoreply@blogger.com