A Month With Scala(w2lessons.com)
w2lessons.com
A Month With Scala
http://www.w2lessons.com/2011/12/month-with-scala.html
8 comments
A good post, recommending the use of Scala. I do agree with his point about the differences between scala collections and java ones. Interfacing with java libs which return java collections often requires conversions to scala collections before I can use the full power of scala. That said I'd still pick Scala any day of the week. The Scala book he references is surprisingly good, I bought it recently.
the conversions thing is true, but providing a wrapper class and an implicit utilizing scala.collection.JavaConverters makes that an issue you should only have to solve once.
"First off let’s talk about why I chose Scala in the first place. After spending a good deal of my last year entrenched in JavaScript and appreciating its functional nature, brevity and flexibility, writing Java code became a tremendous chore for me. At the same time, our developers have grown accustomed to, and appreciative of the wide array of quality frameworks and tools available for Java, so a drastic departure was out of the question. This left us with two viable options: Clojure, and Scala."
Yes, a dynamically typed, functional lang like Javascript can be quite liberating after working predominantly in Java. But is the replacement of anonymous inner classes and traditional loops with closures really that important? And moving to Scala does not constitute a "drastic departure?" Really?
"Simply put, this is the main reason for my departure from Java. I fell in love with having Functions as first class members in JavaScript and it pained me to work without them in Java. Coupled with other functional niceties like currying, partially applied functions, etc. it improves code re-use and drastically accelerates development."
Really. Drastically accelerates development. Sounds suspiciously like he found himself a Silver Bullet. And of course all of the little hiccups along the way that come with moving to a new(ish), less mature platform don't slow down development at all.
"While the Scala compiler invoked through a builder like Maven, or the command line provides workarounds for this, IDE’s such as Eclipse and NetBeans don’t fare as well. Although the Eclipse Scala plugin is supposed to support Joint Compilation out of the box, this has not been my experience thus far. As long as your not married to Eclipse, I’ve heard IntelliJ and Buildr are the best IDE’s for Scala development so you may want to opt for one those if going the Scala route."
Good thing actually compiling is not a frequent and crucial behavior in the development process otherwise these little quirks might really slow things down.
"In my case, I use Java for Servlets and REST via Jersey with the service and data access layers provided by Scala. This way Scala never has to call Java."
LOL. You know, because Hibernate or JdbcTemplate are just too gnarly to deal with. We need the brevity of Scala here! And a functional model for our service layer! Really, maybe if the guy was doing some highly concurrent app and was making the argument that Scala's Actor model greatly simplified things, that might be a plausible justification. But for some service and dao classes? Seriously? How do people justify these decisions with a straight face?
Yes, a dynamically typed, functional lang like Javascript can be quite liberating after working predominantly in Java. But is the replacement of anonymous inner classes and traditional loops with closures really that important? And moving to Scala does not constitute a "drastic departure?" Really?
"Simply put, this is the main reason for my departure from Java. I fell in love with having Functions as first class members in JavaScript and it pained me to work without them in Java. Coupled with other functional niceties like currying, partially applied functions, etc. it improves code re-use and drastically accelerates development."
Really. Drastically accelerates development. Sounds suspiciously like he found himself a Silver Bullet. And of course all of the little hiccups along the way that come with moving to a new(ish), less mature platform don't slow down development at all.
"While the Scala compiler invoked through a builder like Maven, or the command line provides workarounds for this, IDE’s such as Eclipse and NetBeans don’t fare as well. Although the Eclipse Scala plugin is supposed to support Joint Compilation out of the box, this has not been my experience thus far. As long as your not married to Eclipse, I’ve heard IntelliJ and Buildr are the best IDE’s for Scala development so you may want to opt for one those if going the Scala route."
Good thing actually compiling is not a frequent and crucial behavior in the development process otherwise these little quirks might really slow things down.
"In my case, I use Java for Servlets and REST via Jersey with the service and data access layers provided by Scala. This way Scala never has to call Java."
LOL. You know, because Hibernate or JdbcTemplate are just too gnarly to deal with. We need the brevity of Scala here! And a functional model for our service layer! Really, maybe if the guy was doing some highly concurrent app and was making the argument that Scala's Actor model greatly simplified things, that might be a plausible justification. But for some service and dao classes? Seriously? How do people justify these decisions with a straight face?
I'm not that familiar with Scala, but I have done some significant Clojure work, and I can assure you, the difference between inner classes and closures is significant. Having used C# for many years, it's notable that people started to use closures vastly more after Microsoft improved the syntax.
And yes, Hibernate really is that gnarly. Imlementing a rest/Jason interface in Clojure is vastly easier, never mind simpler.
And yes, Hibernate really is that gnarly. Imlementing a rest/Jason interface in Clojure is vastly easier, never mind simpler.
So what I do not understand, if the goal is to stay with java and leverage their background, but wanting something less laborious to code. Then why not try Groovy? Seems to me anyone now wants to do Scala just to put it on their resumes.
Less laborious but us java devs are not really a scripting language audience.
"Then why not try Groovy?"
Or Xtend, or Kotlin or Ceylon (though the second two haven't yet been widely released).
Or Xtend, or Kotlin or Ceylon (though the second two haven't yet been widely released).
"By most measures, Scala is not a simple language to learn. While there are lots of languages that are large in scope and features, most can be learned over time. Scala fall short by requiring you to learn at least 75% before you can do anything meaningful. When I first started out with some basic scripting this didn’t appear to be the case, however; once I tackled a real project, I realized how limited my knowledge really was. For those that think you’ll coast by because you’re a Java expert, think again. My Java knowledge is extensive and the parallels between the language are few and far between."
part of me wonders if this is inevitable, and a good thing. many problems don't require expert tools and expert teams. joe blo can write a blog on appengine, and you can throw a bunch of college hire "consultants" on many business apps and be successful. Competence is relative. As problems get more complex (see Why Is Payroll Hard[1]) you need more expert teams and more expert tools, your average enterprise java team of people who work 9-5, have a nice family and a powerboat hobby (but perfectly competent, by most standards!), can no longer successfully manage the complexity. Maybe they can't grasp scala, maybe they just aren't interested in grasping scala. But there is a set of problems which you need experts to solve, and experts want sharper tools. like git, a macbook, and not-java.
I think Scala might end up like Javascript -- it has good parts, and it has bad parts. but in the hands of experts, allows us to accomplish things which are otherwise out of reach. this hits home for me personally -- i can create elegant functional solutions to problems that I just struggle to tame with traditional java-OOP[2].
[1] http://c2.com/cgi/wiki?WhyIsPayrollHard [2] which is, you know, how people get turned on to FP in the first place. "you don't find it, it finds you"