Scala – 1 Star – Would Not Program Again

And the fact that its completely optional means that its easy to get it out of the way when its not possible to express some constructs with it.

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)

For example, Lisp has a simple syntax, but most people would consider infix math notation easier, although more complex.

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".