joostdevries

I just can't imagine going back to Java. The cumbersome object definitions. The endless type declarations. The lack of case classes (algebraic types). The lack of pattern matching. The lack of named arguments. The difficulty in creating immutable objects. Even implicits; they can be overused but in my mind they're just a better way of dealing with contextual information than stateful objects like ThreadLocal.

That's true. But it's my impression that the terminology used in Haskell in discussing types of functions is different enough to require some study. A Haskell to Scala translation of terminology would be what I'd have to devise for myself.

I'm going through their FP in Scala book right now. So I'm focusing on pure Scala for the moment. But I'll be definitely learning enough Haskell to be able to read papers and such. Since most of the literature on how to do FP come with examples in Haskell.

I was wondering about the persistent negativity about Scala since it runs counter to my own very positive experiences with Scala and Play. For me it hits just the sweet spot between monadic goodness and getting stuff done in the JVM eco system.

For Scala 2.11 I'm excited about the focus on performance of map and flatmap in List. Those are my bread and butter at the moment. It's amazing how intuïtive that becomes once you use it everyday for dealing with futures, collections etc and you forget about the mathematical monad etc underpinnings for a moment.

I hope that splitting xml parsing off into a module will reinvigorate xml support that's highly performant and easy to use. Of course json is all the hotness. But there's a lot of xml services out there to be used. So that's a core tool for a lot of applications.

I can't wait to try out the compiler/sbt speed improvements in sbt 13.2. I seem to recall that there are talks on unifying the compilation of sbt and the IDE. That's something I look forward to since I tend to use the ~ continuous run/test/compile options of sbt and then having another compilation going on at the same time within my IDE seems wasteful.

I do hope that the Eclipse Scala IDE gets enough love and will continue to improve. A lot of companies in the Java space got used to free IDEs. (I know that's penny wise) So having a good free IDE is a strong enabler for grass roots Scala adoption.

Together with the super support for JS MVC applications that's coming up in Play 2.3 I'm looking forward to putting this to use.

Cool: apparently it works with Heroko buildpacks. So I can deploy Play framework apps as well with the Heroku buildpack for Play.

I found out that a build I was doing was utilising http://imgur.com/U70Rcrz. I don't see that very often. Personally I find that kind of parallel processing CS magic impressive. Similarly I like the possibility of processing data as it arrives in a non blocking fashion in pipes-and-filters chains of computation. Another thing I like are having arbitrary numbers of stateless possibly short lived servers. Like you see at PaaS's like Heroku. Easy load balancing, easy recovery. These are all things that become possible by employing other programming paradigms than the classical thread based, blocking, stateful ones.

And it's not confined to one tech stack either; .net, javascript, java, scala, ...

To me it's just good computer science for when you want to be near real time, scale horizontally and utilise your hardware resources and be able to handle failure.

"Useful for getting stuff done" is a point that Erik Meijer literally has made. F.i. you find him explaining his point of view on side effects and imperative programming here. And how he progressed from "fundamentalist" functional programming to "the real world is imperative & embrace side effects". http://youtu.be/a-RAltgH8tw?t=11m1s

You can't say that Erik Meijer doesn't know Haskell. :-)

I think I read that phrase from you before on nyc. I think it's a misleading catchprase.

For me and I think most other Scala devs Scala is a statically typed FP-OO language. So Haskell doesn't do it justice because Haskells insistence on purity makes it impractical for me in getting stuff done. And Java doesn't do it justice because Java is held back by its history. "Superset of" makes it sounds like a weakness and overwrought. In my experience it offers a sweat spot of the best features of static FP and OO.

So what about your mention of Lisp and Javascript? Unless you're deep in some framework you don't need to know about the support for macros and structural typing. I've ignored those two so far because I haven't needed them (yet?). And I haven't felt they were in my way.

So where you say "a superset of Haskell, Lisp, Javascript and Java" I say "the sweet spot of the best features of static FP and OO for the real world. Leveraging the JVM ecosystem".

Programming languages are very much a matter of de gustibus. So I respect the writers experiences. But I have a slightly different perspective.

Let me first say where I'm coming from. I like: a static typing. b support for FP and OO c targeted for JVM.

Compile times It is my experience that compile times are not that bad if you use the support by SBT for continuous compile-deploy-test. Have a look at Typesafe Activator to get a feel what they're moving towards.

Libraries and community I do agree that some frameworks, like Spray f.i., tend to overdo the concise DSL aspect. This seems to be especially prevalent with Scala developers coming from the academic world of monads. Or with a strong tendency to show of how clever they are to the detriment of usability. Scalaz had a strong similar tendency. I have noticed that frameworks like SBT and Scalaz are de-emphasising unpronouncable ungoogleable unintuitive operators. So far I have hope that the Scalaz community will veer away from this. To a certain degree every language community develops a culture about good vs bad code. Twitters Effective Scala guidelines are a wonderful contribution.

Magic syntax I've been using the Play framework for webapplications. And in my experience that is largely a pragmatic tool where I can just get things done. My main criticism would be that sometimes new features seem to be not very well tested. F.i. multi project support did not really work for quite a few versions. That shouldn't take up much time. I hope they address that.

Type inference Coming from Java I like Scalas type inference. Although the compiler feedback can sometimes still be challenging. There has been great work in compiler messages giving advice on how to fix mistakes. F.i. the well known mistake of forgetting the = between a function declaration and implementation. But there are still hairy situations. If you've ever had the infinite recursion type error (being addressed in newer version of the language) you know what I mean. Or using the json parser combinators in the Play framework with classes with one attribute f.i.

Other issues he mentions: - build tools. This has significantly improved since Typesafe started. I'd say that before that Scala wasn't suitable for non academic use. There are still improvements to be made like speed, usability of SBT, maturity of the Eclipse based Scala IDE... - repetition of case classes. I have no idea what is meant with that. I think that writing a model of your domain in scala is a truy joy compared to java. And pattern matching and standard marshalling/unmarshalling to json etc is great. - the language being inaccessible and experimental. This is not my experience at all. Like any language it takes learning. But if you're looking for a language that supports both FP and OO I find it very coherent and well thought out. I'd say beautiful even. For me the coursera courses on FP with Scala and Reactive programming with Scala have been the critical power boosts in becoming proficient enough to make the transition from hobby interest language to professional everyday tool. - 'if you want true strong type systems use Haskell'. To me the 'impurity' of FP in Scala is it's strong suit. On the one hand for getting stuff done and on the other for using the vast ecosystem of JVM libraries and frameworks. Also I think that the writer will encounter quite a few inscrutable operators and overwrought type systems (like his complaint about Spray) in the world of Haskell.

To finish up I'd like to state what I like about Scala: - FP in the real world of web applications and mutable state. Accessibility to colleagues who come from OO & Java - Well thought out coherent language. Especially in combination with the Coursera courses I have just become a better programmer and system engineer. - Good interoperability with Java frameworks etc - good support for horizontal scaling, near realtime processing, non-blocking processing etc ie reactive programming.

Some things I have mixed feelings about: - reinventing the whole Java stack. It is true that f.i. non-blocking support has a pervasive 'disruptive' influence. But for me there's great value in mature well know libraries, server, frameworks that just work. - sometimes there are very common use cases that need quite a bit of research. F.i. it's not easy to find out what the 'canonical' way of processing xml is. - stability and documentation

MMDV (=My Mileage Did Vary)

btw JS dependencies are available as maven deps now as well. Pretty handy http://www.webjars.org/

Play 2.0+ is based on SBT as build system. SBT uses ivy and maven repos as source for dependency lookup. Maven repo's often show the SBT mantra form of a maven dependency. F.i. click on the sbt tab here http://mvnrepository.com/artifact/org.eclipse.mylyn.github/o... If you don't want to add your dependency to a maven repo you can define a sub-project. SBT projects are aggregated recursively of other sbt projects.

My pet peeve is that SBT suffers from ungoogleable scalaz like operators like %% instead of %. And that the Scala IDE doesn't provide any help like code completion, marking compilation errors e.d. in creating your project/Build.scala Those two facts make sbt a big hurdle in adoption I noticed.