

In Defense of Scala. Response to “I Don’t Like Scala” - javinpaul
http://blog.gridgainsystems.com/in-defense-of-scala-response-to-i-dont-like-scala/

======
tikhonj
It's funny how he can dismiss Haskell as "hopeless academic idealism" and
accuse dynamic language of "intellectual laziness" in one breath. Haskell is
_different_ from most languages, but that doesn't make it hopeless or academic
_a priori_. Saying that is itself intellectually lazy, bordering on
intellectually dishonest. But it is a good way to save yourself the effort of
learning something new!

Besides this, Scala has way too much Java in it to really be "algebraically
elegant" or even simple! Scala is a compromise. It has the legacy of Java
compatibility dragging it down. That's one of the main reasons it's caught on,
but it's also the reason it isn't actually particularly simple or elegant.
It's one of the most _complex_ (but not necessarily difficult) languages in
common use.

It is nowhere near as elegant or simple as OCaml or Haskell as they can afford
to be much closer to the λ-calculus. Which is also why they can afford such
incredible things like tail call elimination and type inference!

Also, while Scala _is_ a multiparadigm language, it _is not_ the best of both
worlds. In embracing Java and OO, it throws away many of the advantages of
functional programming. In fact, any non-trivial functional programming
quickly becomes unbearable. Especially compared to Haskell.

Edward Kmett wrote a nice Reddit post[1] about how Scala falls short from a
functional standpoint. This is from an entirely practical commercial
standpoint based on his experiences at S&P Capital IQ. Here is what he had to
say about functional programming in Scala: "If scala was the only language I
had to think in, I'd think functional programming was a bad idea that didn't
scale, too." A pretty strong image!

Their story is interesting: they took a Java project to Scala. It was an
incredible improvement. Then Scala became a pain on its own, so they designed
their own functional language for the JVM[2] and moved to that. It was the
same sort of incredible improvement. The same thing that happened to Java
happened to Scala!

Ermine, their new programming language, is basically like the core of Haskell
adopted to the JVM along with some interesting new features. One thing that
really stood out for me is that they have customizable type error messages:
they can have type errors that are domain-specific! That by itself probably
has a fair amount of value.

[1]:
[http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_...](http://www.reddit.com/r/haskell/comments/1pjjy5/odersky_the_trouble_with_types_strange_loop_2013/cd3bgcu)

[2]: [https://github.com/ermine-language/ermine](https://github.com/ermine-
language/ermine)

~~~
virtualwhys
Edward Kmett is a Haskell evangelist (not to mention absurdly productive
engineer) so it's natural for him to point out the inconsistencies in Scala,
inconsistencies that the average programmer will never even realize exist.

He ends his semi-rant with a concession: there's a lot of good in Scala, and
that's absolutely true, there is _so much good_ in Scala that only when you
leave it's confines do you realize, shit, I miss:

    
    
       immutability
       lazy vals
       case classes
       pattern matching
       named parameters
       implicits
       import aliases
       partial functions
       Option, Either (wish latter was biased)
       map/flatMap/fold & collections FP friends
    

and on and fucking on, how can you not love Scala? o_O

Ok, compile times and IDE support leave something to be desired, but things
have improved by leaps and bounds in the past 3 years, and more goodness to
come with Scala 2.11 in (hopefully) March.

~~~
asdasf
>Edward Kmett is a Haskell evangelist

Really? Could you point me to some of his evangelizing? Or did you mean "he
uses haskell and is quite happy with it"? Because that isn't the same thing.

>inconsistencies that the average programmer will never even realize exist.

Do you honestly believe that?
[http://www.youtube.com/watch?v=TS1lpKBMkgg](http://www.youtube.com/watch?v=TS1lpKBMkgg)

>Scala that only when you leave it's confines do you realize, shit, I miss

But the very point Edward makes is that you don't give up those things when
you leave scala. You only give up those things if you leave scala for
something worse. You could leave for something better, keep all those things,
and get tons of important things that you also won't realize you are missing
until you get used to them and then try to live without them.

~~~
virtualwhys
There's nothing wrong with language evangelism, if you love the language you
work in you'll evangelize it without even thinking about it.

Kmett has, I believe, taken on a larger role in Haskell, perhaps officially
with FP Complete. At any rate he does mention in one his videos (maybe on
www.haskellcast.com) that he is coding less now due to his new obligations,
which includes [completely from fallible memory] promoting [read:
evangelizing] the language.

>inconsistencies that the average programmer will never even realize exist.

Referring to a presentation by Paul Phillips, an absolute Scala giant, and
equating that with what the average Scala programmer encounters in their daily
work does not negate my argument...in the slightest.

When you leave Scala and remain on the JVM there is no better statically typed
alternative, IMHO. When you leave the JVM, then yes, you can dive into Haskell
and experience (compared to Scala) longer compile times, yelp o_O, poor to
non-existent (IDE) tooling (just type :t in the REPL to see the inferred type,
AKA beginner's joy), lack of an enterprise ecosystem, and yes, purity in all
its glory, with a superior type system and quite a friendly community of
mostly brilliant minds.

In the end I'd say there's some degree of PITA everywhere, even in Haskell.
Just getting my feet wet, maybe I'll learn to love it, but for now, to get
shit done in the real world, it's Scala and the JVM.

~~~
asdasf
>There's nothing wrong with language evangelism

He says, after suggesting you can't trust what someone says because they are
an evangelist.

>Kmett has, I believe, taken on a larger role in Haskell, perhaps officially
with FP Complete

FP complete is an independent company and has no official involvement in GHC
or any other haskell implementation. Edward is not involved with FP complete.
Edward is involved in the haskell community and the scala community. In
neither case is he anything like an evangelist (which would make no sense
anyways, you can't convert the converted). It seems odd that you are so
adamant about inventing a fictional promotional context for him after claiming
there's nothing wrong with that.

>Referring to a presentation by Paul Phillips, an absolute Scala giant, and
equating that with what the average Scala programmer encounters in their daily
work does not negate my argument...in the slightest.

Perhaps you should actually take the time to listen to it. A significant part
of what he was saying was "this stuff matters". Just because the person doing
the presentation knows scala very well, does not mean the problems he points
out do not effect people who know scala less well.

>When you leave Scala and remain on the JVM there is no better statically
typed alternative, IMHO

I am not sure how that is relevant. I don't care about the JVM.

>Just getting my feet wet, maybe I'll learn to love it, but for now, to get
shit done in the real world, it's Scala and the JVM.

Or this. Do you remember the part where I tried to convince you to use
haskell? Neither do I.

~~~
virtualwhys
> He says, after suggesting you can't trust what someone says because they are
> an evangelist.

What the hell are you talking about? I provided a counterpoint to Kmett's
detailing all that is wrong with Scala, by providing some of the good. Kmett
is a living legend, I'm not questioning the guy's integrity; he went off in
that reddit thread based on his [deep] experience of the language, which is
entirely non-average.

re: Paul Phillips, he's knows Scala probably better than anyone else on the
planet; yes, the soundness of the compiler affects everyone, but those who are
most bitten and bothered by it are library authors (read: advanced users), not
end users who remain, for the most part, unaware of whatever issues may lie
under the hood.

> Or this. Do you remember the part where I tried to convince you to use
> haskell? Neither do I.

Other than Haskell, given the context of the thread, which language might you
be referring to as the better alternative to Scala?

> You could leave for something better, keep all those things, and get tons of
> important things that you also won't realize you are missing until you get
> used to them and then try to live without them.

That sounds great! I am curious about leaving Scala for something better --
please name this better alternative that is presumably not Haskell.

~~~
raiph
Hi virtualwhys

> I am curious about leaving Scala for something better -- please name this
> better alternative that is presumably not Haskell.

With apologies if you think this is too OT and/or if you are uninterested in
immature languages/ecosystems, let me mention Rakudo and its increasingly
capable JVM backend.

Today's Rakudo Star release (Star means "batteries included") is expected to
be the last to ship without Rakudo's JVM backend. Almost certainly there'll be
a February Rakudo Star release and it is expected to support the JVM backend
out of the box.

I would be happy to say more about why I think P6 is going to become relevant
again one day, perhaps this year, to folk at least interested in Scala.

------
kasey_junk
"For sane type-level programming look at latest Scala collections"

Is this a joke? The Scala collections library are terrible. They are
inconsistent, hard to reason about, suffer from scope creep, and have terrible
performance characteristics.

~~~
octo_t
Every time I've used Scala collections, they've behaved exactly how I'd expect
them to. What parts of the collections perform poorly?

~~~
dk8996
I hate to call you out on this but look at the collection hierarchy and tell
me its not complex.

[http://docs.scala-
lang.org/resources/images/collections.muta...](http://docs.scala-
lang.org/resources/images/collections.mutable.png)

~~~
kasey_junk
That is just the "published" hierarchy as well. Paul Phillips likes to pick on
the ParSeqViewLike trait, and if you ever find yourself delving into it,
you'll see why.

~~~
thescrewdriver
As someone who actually writes production code in Scala on a daily basis Paul
Pillips' "concerns" have had zero practical impact on my daily use of the
language. I tried to find content in his presentations that actually had any
impact on me but I couldn't.

~~~
kasey_junk
As someone who also writes production code in Scala on a daily basis, and who
took exception to the idea that the Scala collections library was a good
example of type programming, Paul Phillips' concerns are spot on.

If you are using the collections library as example of how to structure your
own code, you are in for a bad time. The abstractions are not right, and
things like the silly ParSeqViewLike trait are an expression of that.

~~~
thescrewdriver
In day-to-day use I haven't run into any of these issues. Your mileage may
vary.

------
NigelTufnel
"Brilliantly simple" is an odd description of Scala. I would easily put Scala
in the top 3 most-difficult-languages-for-me to work with. Maybe even top 2.

~~~
btd
What is on top?

~~~
NigelTufnel
Template-heavy C++ and point-free Haskell code.

------
aidos
I had my first experience for Scala last week with doing the Stripe CTF.

I really liked the look of the language and I started trying to develop my
solution in it. I knew exactly what I wanted to do, and had a reasonable idea
of what to write to get there.

Holly molly, compilation times were absolutely _horrible_. I tried to
persevere but a tiny change would mean 2 minutes waiting for a recompile. In
the end I just switched to python where I could develop a solution from
scratch (remember, the Scala solution was 90% finished) in no time at all.

Would like to look closer at the language one day but I have better things to
do with time than waiting for a machine to churn through code.

~~~
virtualwhys
> I tried to persevere but a tiny change would mean 2 minutes waiting for a
> recompile

incremental compilation: sbt> ~run

in most cases code changes should take one second. Note: SBT sub projects are
God's gift to Scala devs (or Mark Harrah's gift at any rate).

You have to get your feet wet in the language, trying something last week for
a day or two is not going to result in you flying to the moon on the
productivity spaceship of delight.

Programming in Scala 2nd edition is a great intro to the language.

~~~
aidos
Ok. Sounds like there's a solution so I'll try again at some point. There was
a build.sh with the project that I was using. I saw something about sbt in
there so had a look on their website but couldn't obviously see how to fix the
issue.

~~~
virtualwhys
Play framework's a decent gateway drug to Scala, can help you get some of the
basics under your belt while seeing tangible results.

Otherwise, a book or 2 on Scala goes a long way.

------
thescrewdriver
I've used Scala for a few years now. The blog post doesn't do a particularly
good job of selling Scala despite the best intentions. I would encourage
anyone who is interested in Scala to spend some time learning the language and
using it, rather than worrying about occasional misdirected criticism which
the blog seeks to counter.

I've found Scala to be very expressive and well suited to large-scale systems.
It takes some effort to learn the language, but once you have put in the
effort coding in Scala is a pleasure (esp. compared to Java).

------
timtadh
"intellectual laziness of dynamically typed languages"

What a claim! What an absurdity!

Dynamically type checked memory safe languages (eg. Python, Ruby, Javascript,
etc...) enable styles of programming impossible in non-dynamically checked
languages. So it certainly isn't the users who are being "intellectually
lazy." Nor are the creators, who have focused on productivity and usability
instead of waiting for proof systems (static type checkers) to catch up with
their ideas. Laziness doesn't factor in on either side.

~~~
ionforce
Provide an example where such a style would be deemed useful or superior to
doing it the statically checked way.

~~~
virtualwhys
Canonical example would be marshelling one type to another, something that
typically requires a fair amount of boilerplate in statically typed languages,
whereas in Ruby, Grooy et al you just do something like:
complex_object.to_json

and you're done with it (assumes a valid object of course, which can be a
rather large assumption on the dynamic side of the fence ;-)).

It's a total PITA in Scala to query your DBMS; marshall a tuple result to a
collection of case class(es) and then have to go down boilerplate road again
in order to create a a typesafe JSON result.

I basically render everything server-side and use JSON sparingly (e.g. AJAX
responses). Until Scala pickling or other cutting edge lib allows me to
convert an arbitrarily complex object graph from A to B without the
boilerplate, I'll keep to the server-side and leave client-side
templating...off to the side.

~~~
lmm
> Canonical example would be marshelling one type to another, something that
> typically requires a fair amount of boilerplate in statically typed
> languages, whereas in Ruby, Grooy et al you just do something like:
> complex_object.to_json

The popular scala libraries only require one line of boilerplate per class for
that, e.g. in spray-json I do jsonFormat3(MyClass) and then I can do
myObject.toJson. With scala 2.11's implicit macros this will go down to 0
lines and work exactly like in ruby/groovy/etc.

(Whether the scala ecosystem will want it to be 0 lines or prefer to keep the
1 line as a "flag" for which objects should be convertible to json is an open
question, but scala-the-language certainly supports doing it the 0-boilerplate
way)

> It's a total PITA in Scala to query your DBMS; marshall a tuple result to a
> collection of case class(es) and then have to go down boilerplate road again
> in order to create a a typesafe JSON result.

Huh? Squeryl just gives me the results as my case classes (I have to define
the schema _somewhere_ , but I have to do that with e.g. Django as well). I
don't even need to do the json conversion explicitly - as long as it's the
only serializer for that type in scope, spray will pick it up implicitly.

~~~
virtualwhys
You're talking about simple 1-to-1 mappings where both db result and case
class to json conversion are straightforward.

The example I gave was for objects of arbitrary complexity; it's a trivial
operation in dynamic languages because there are no types (or 1 type if you
like). In Scala, this is not (yet) the case, beyond a certain point you have
to roll up your sleeves and do the marshelling yourself.

~~~
Peaker
In Haskell, I can add a single line containing a macro to derive the JSON
[de]serialization code.

Even when there's no simple 1-to-1 mappings. I don't see why you think
unityping makes this serialization easier?

~~~
virtualwhys
I have no idea whether or not the implementation is easier is dynamic
languages or not. I do know that for the language user it's a simple
foo.to_json, end of story.

If you can marshall objects of arbitrary complexity to JSON in Haskell with a
single line of code that covers all possible cases (e.g. your entire database
model), consider me beyond impressed.

~~~
Peaker
It's (toJson foo) on the entire data, however complex, as long as there is a
sane way to jsonify it. For example, if the data contains functions, there's
no default way to convert it into json.

And also, deserialization is going to be more concise in Haskell because type
inference decides which type to deserialize to.

~~~
virtualwhys
That's pretty awesome, sounds ideal for a RESTful API. In Scala I've noticed a
tendency toward using NoSQL storage engines like MongoDB, which speaks a form
of native JSON (i.e. it removes the BP required to marshall to/from JSON).

A few months ago I took a stroll through available Haskell libraries for web
dev., found Yesod, HaskellDB, and a couple of other glue items.

What's the state of the art on the web framework front in Haskell? Snap looks
interesting but incomplete, and HaskellDB is fairly ancient (LINQ-to-SQL lib
would probably get me very interested in Haskell sooner rather than later).
Assume email, PDF generation and other web must-haves exist in Haskell
ecosystem.

~~~
Peaker
I do a lot of Haskell development, but virtually nil web development.

I know the Yesod ecosystem is well-developed and should have good solutions
for most problems. I think the downside of Yesod is that it is not as
principled/based-on-sound-theory as most of the Haskell ecosystem is, so it
gets a lot of negative sentiment. But it solves a real problem now -- at least
until a principled approach is proven.

Yesod also has "persistent", which can persist over SQL and IIUC, nosql DB's
as well.

Snap is more minimalist, and solves a smaller part of the problem for you --
but is much simpler (and perhaps more elegant) than Yesod.

Happstack is another web framework, like Yesod (all 3 are under active
development). Its main problem (perhaps this was fixed already) was prevalent
use of "lazy I/O" which is very controversial. I personally despise lazy I/O
and think it violates the basic principles that make Haskell great. I heard
something about Happstack immigrating to an alternative to lazy I/O though.

Email is a solved problem in the Haskell ecosystem, as far as I can tell.

PDF libraries exist:
[http://hackage.haskell.org/packages/#cat:PDF](http://hackage.haskell.org/packages/#cat:PDF)
but I haven't used them, so I don't know how good they are.

I don't know about other must-haves. I know an automatic "admin webpage"
didn't exist until recently even in the Yesod ecosystem. A friend who
encountered this missing piece contributed one, but it was pretty
barebones/preliminary. This was a couple years ago though.

~~~
virtualwhys
Thanks for the overview, midway through Learn You a Haskell and it's clear I
need to sit down and write some code as reading about Haskell is entirely
different than reading about Java, Scala, etc. ;-)

In other words, a simple web project is in order. Snap looks like a good call,
along with Yesod's Persistent. PDF, email, etc. can come later, just trying to
explore the language.

Thanks again.

------
lmm
It would be nice to have more substantive criticisms. While I dislike SBT[1],
scalaz and spray are a large part of why I enjoy scala so much. While akka was
so difficult to use that it almost soured me on the whole thing, and
shapeless' monstrous compile times made it practically unusable. So don't
think this post represents some kind of consensus.

[1] The notion of configuring your build tool in a full programming language
is alluring but ultimately a bad idea IMO; builds should be simpler and more
declarative than that.

~~~
benburton
I know that I'm in the vast minority, but I don't see what people find
difficult about SBT. For the most part, it seems to keep itself out of the
way. I would say I've found it only slightly more cumbersome than Rake, and a
breath of fresh air when compared to the JVM alternatives (although I haven't
had first-hand experience with Leiningen).

~~~
lmm
If used with discipline it's fine. But it ends up encouraging people to put
complex logic in their build files. I prefer the rigidity of maven, where it's
simply impossible to do e.g. conditional dependencies.

~~~
frowaway001
I can't understand that. Maven is the absolutely worst cluster fuck in terms
of a build system I have ever seen.

I can't deal with Maven's position of "Oh, you want to have some tiny bit of
intelligence in your build? Guess what, a) fuck you, b) write a crappy plugin
for it." anymore after seeing that simple things can be indeed simple and
straightforward with SBT.

------
ojbyrne
I'm not a big fan of arguments based on "its the fault of other people's
ineptitude."

~~~
ionforce
What if it's true?

~~~
ojbyrne
Everyone is inept to some extent or another. Systems (which includes language
ecosystems) should be robust enough to correct for that.

------
binarymax
_" intellectual laziness of dynamically typed languages"_

Ouch. So if I choose to use python, ruby, javascript, lisp, - I am
'intellectually lazy'?

~~~
rwallace
Yes, and this is a feature not a bug. As Larry Wall observed, three cardinal
virtues of a good programmer are laziness, impatience and hubris. Laziness is
important because I have more things on my to-do list than hours in my
lifespan, and more things I need to know than neurons in my brain. I didn't
choose Python only or even primarily because it's dynamically typed, but
nonetheless, every thought I don't have to think about static types is a
thought I can instead think about something I actually care about.

~~~
asdasf
Odd that you cite Larry Wall given that he thinks haskell is one of the most
important languages for any programmer to learn. I always find it weird that
people try to use someone famous to support their opinion when that famous
person disagrees. Perl lacks a type system because that was what made the most
sense for perl. That doesn't mean it makes the most sense period.

>every thought I don't have to think about static types is a thought I can
instead think about something I actually care about.

Static types do not add something to think about. You already have to think
about what things are. Static types just let the compiler ensure that you
didn't make any mistakes. Passing a user object into a function that wants a
string isn't suddenly useful because there is no type system giving you an
error.

~~~
raiph
> Perl lacks a type system because that was what made the most sense for perl.

Perl 5 that is. Perl 6 has a (gradual) type system.

------
eternalban
Ultimately, every language is simply a tool and they all have their issues.
I'll admit that I pegged Scala as "C++ for JVM" when it first came out, but am
not a hard headed man.

Q to the op is what is the turn over of your dev team? Please provide a
defense of Scala in terms of economics of development (from a business pov).
Items to address are maintaining the codebase after the whiz kids have left
for more exciting pastures.

~~~
frowaway001
Nurturing, retaining and hiring competent developers ... that's probably
vastly simpler with Scala than with Java-enterprise-patterns-EJB2 stuff.

------
porlw
"The biggest issue with Scala’s perception is the deeply varying quality of
frameworks and tools that significantly affect one’s perception of the Scala
language itself"

I've seen the same thing said about Common Lisp.

------
rch
I know of two new businesses using Scala in Boulder. That's been enough to put
it back on my radar.

~~~
saryant
Not sure if we're already on that list, but we use Scala heavily at Conspire
and we're in Boulder.

~~~
rch
Nope, but you are now. Thanks for speaking up!

------
asdasf
That's a pretty terrible defense of scala. Sounds more like a "I hate some
random scala projects for made up reasons". How does scalaz have "colossal
snobbism" exactly? Because it contains stuff you haven't learned?

~~~
virtualwhys
Agreed, doesn't paint Scala in a good light despite claiming to defend it.

As for Scalaz elitism, the canonical example would be the T-hole himself, _
Morris (who has more or less been expelled from the main Scala user groups). I
think the general POV the OP is trying to convey is that Scalaz is an
incomprehensible cluster fuck of symbols to everyone but those in the know; in
other words, the learning curve is steep and historically the response to
beginner questions has been something along the lines of, "go read this paper"
a la Haskell.

SBT suffers a similar problem but that's, IMO, more due to lack of IDE support
for the project/ build than anything else (i.e. it's difficult to discover
[for me] the library without being able to click through method calls and
experientially explore the code [Scala docs only get me so far]).

In other news the last milestone of Scala 2.11 was just released; 2014 should
be a good year for Scala on many fronts (faster compilations and improved IDE
support particularly)

~~~
rtpg
> historically the response to beginner questions has been something along the
> lines of, "go read this paper" a la Haskell.

There's a lot of tutorials in Haskell that are papers, but if you go to
#haskell or ask on stack overflow, the answer to questions are rarely "go read
this paper", at least in my experience (even for some pretty deep type-level
programming stuff).

