Performance Zone is brought to you in partnership with:

Nikita Ivanov is a founder and CEO if GridGain Systems – developer of one of the most innovative real time big data platform in the world. I have almost 20 years of experience in software development, a vision and pragmatic view of where development technology is going, and high quality standards in software engineering and entrepreneurship. Nikita is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

In Defense of Scala: Part 2

02.07.2014
| 7513 views |
  • submit to reddit

 

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, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Peter Huber replied on Fri, 2014/02/07 - 7:16am

 I'm one of those who say "Scala!?!? Can I rather go assembler, please?". Coming from over a decade of Java-Experience, Javascript, some experience in Lisp, C, C++ and R, I found Scala pretty unintuitive. And I was confronted with Spray Rest-Routing...Spaghetti Code! And finally I gave up and now I'm waiting for JDK 8 lambdas and defender methods which actually open a small door to multiple inheritance. And I think this new Java features will give Scala an even harder time. Finally we see that the saying "Eventually all programming languages converge to Lisp" is not completely untrue ;-)

However, after my unsuccesful attempt to become a Scalarian, I read alot of blogs and think about Scala alot. I found a crucial point - Scala has on major topic, it's type system but how is this a solution and by the way for what burning problem in the it industrie?

I review a lot of projects and I find problems, but it's never like I can say "Aha! Here is your big mistake in your type system. Please use more contravariance". It's rather different things that get projects into dangerous seas...Adding to this point - how can billions of C or Java LoC be written correctly when they lake a precise type system? Uhu, the X11 C Event Union...My thesis: Good type system is only secondary factor to project success. I mean secondary in the sence of "there has to be one, that provides basic support to the programmer but it's not in the focus if you chose a language for a project".

But what are then primary factors for a succesful language? I'm not quite sure. What made Java such a big success compared to  C++? I think it's simplicity, at least it was for me. Java took C++ preserved the object orientation and took the language BACK at least one level, thus made it simpler to read, simpler to understand. Who has counted how often you can use the keyword "const" in a C++ Method declaration, and next, who can tell what each const essentialy means ;-) Java philosophie: Make it simple, don't have n ways to do things. But you are right, yes...even Java has it's dark spots and true, I'm simplifying here...

Okay, simplicity was just only one example for what I think make a langauge succesful in project context. I think if we take the time to check out what are the burning problems in programming/projects we have today (standish group report), rather than what is a nice feature for academic discussions, we could be able to identify features that really usefull in terms of actually bring down or avoid errors and increase project success. And I think it would be fun to look what other languages could probably contribute, like for instance R or Octave...

Cheers,

Peter

Pierre-yves Saumont replied on Fri, 2014/02/14 - 9:28am

"If you are productive with Haskell as I’m with Scala, getting paid doing it and working on areal 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."

What make you think they would ever want to work for you? And BTW, getting paid to develop software does not prove in anyway that you are doing it right.

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

Okay. So you don't understand it. This does not mean there is a problem with it. (Although I agree there might be a problem elsewhere.)

"You are one of the few who liked it [Scalaz] 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…"

Whether you understand it or not, you are using Scalaz. Simply because you are using Akka, and Akka is using Scalaz. (and Spray BTW!). If you can prove your point about "colossal snobbism of Scalaz", please do. But for this, you must first understand it. Then you must explain us why it is not done right. Or better, you should explain this to the people who wrote it. That would probably be an interesting debate. So please, do.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.