In Defense of Scala: Part 2
In Defense of Scala: Part 2
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
I got a pretty sizable response to my previous post on Scala. Instead of answering each and every public & private comment and feedback – I’ve decided to pull them into a separate post below:
Scala doesn’t need defending!
100% agree. Scala doesn’t any defending from anyone, it was simply a (catchy) title of my post in response to a critical post about Scala. After all, it’s the most prominent language in JVM eco-system behind Java.
I’m productive with Haskell and you are misguided about it
If you are productive with Haskell as I’m with Scala, getting paid doing it and working on a real commercial project – you are very rare individual… And I mean it. They are very few of you on this planet, quite literally. Send me your resume – we’ll probably hire you on the spot.
I’m a committer for Spray.io. What’s wrong with it?
After one day of reading “documentation”, looking at examples, etc. I still couldn’t figure out all details on writing my own REST routing rules and directives with Spray’s routing “DSL”. HTTP APIs are mediocre at best too. That’s what wrong…
Writing a simple HTTP sever and REST processor is a high school project these days (quite literally if you attend decent high schools in Pleasanton, Fremont or Cupertino in Bay Area, for example). The only challenging part that is concurrency was “outsourced” to Akka. It should not be so convoluted…
After the first post I actually looked at the source code for routing and directives specifically. Judge for yourself – but, IMHO, this is hopelessly complex and hardly usable for such a trivial use case as REST routing. It just gives a pretty bad wrap to a whole “functional” approach. APIs should be simple and usable first before they are functional and composable.
Scala is not simple at all – Clojure is!
Scala is simple, but not trivial. It’s sophisticated, but not complex. It also has unfortunately a long list of edge cases in type system and number of surprising warts (just ask Paul Phillips).
I’ve never written anything in Clojure – but I can read the code (and read the book about it). So my knowledge here completely theoretical (and thus superficial).
Clojure is a modernized Lisp – but I’m not in 70s anymore and Scala feels all that much modern to me without obsolete notation, counting brackets, and seemingly desire to be different just for the sake to be different.
Dynamic typing of Clojure is a deal breaker for me anyways.
The reason I started with Scala is Scalaz. You are simply wrong about it…
Many did so as well – most of them dropped Scala. You are one of the few who liked it and stuck around. Most likely you came from Haskell background (see above). If you use Scalaz beyond simple syntactic sugar (we do too) and can prove your point in real life use case — send me your resume…
Scala is a mess. Even Paul Phillips quit Typesafe…
Good point. Paul’s departure was stinging for anyone who knew his work… Scala is not perfect, far from it. But I do believe Paul’s reaction (here, for example) is a bit over the top. I always liked that Scala implicitly (pun intended) prefers practicality over the academic purity – but that’s the topic for much larger discussion.
You can probably surmise most of the Scala idiosyncrasies into three category:
- Martin Odersky’s preferences on core language design & principles
- A need to interoperate with Java (JVM)
- Scala collection design
First is subjective. But we got to remember that a) Martin got most of the things right, and b) it’s impossible to get everything right for everyone in something as involved as a programming language.
Inter-operatation with Java is the difference between an obscurity and acceptance. It’s ugly, and it made Scala a lot less elegant around edges – but it gave it a ticket to adoption that it would have never had without decent (if not excellent) Java inter-operability.
And as far as collection – I agree with Paul’s comments, for example, almost 100%. It’s sad that even on the 2nd attempt the Scala collections is a bloody mess. It’s somewhat good example of type level programming and a bad example in overall software design. I’ve said it many time: people that spend most of their time in academia should stay away from designing complex commercial software… it almost never works.
There’s a big and profound difference between tinkering for your own academic thesis – and designing something that will be commercially used by others.
Scala type system is a complex mess.
See above re: Java inter-op. Most (if not all) perceived complexity is around dealing with Java interop (existential types, etc.). It’s not an excuse but rather an explanation of why type system looks non-trivial.
After almost 5 years I still maintain that Scala type system is simple and elegant for absolute majority of use cases. Edge cases are different – but have you seen edge cases in other type systems of comparable sophistication?!?
SBT is just better Maven and interactive compiler.
We use IDEA. We use Maven. Compilation is fast enough (lately). Never needed SBT. We have over 1M LOC in Scala… We don’t develop software in text editors and command lines either… it’s 2014, you know
Published at DZone with permission of Nikita Ivanov , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.