
Scala – 1 Star Would Not Program Again - theotown
http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-again/
======
yummyfajitas
Blogspam, original is here:

[http://overwatering.org/blog/2013/12/scala-1-star-would-
not-...](http://overwatering.org/blog/2013/12/scala-1-star-would-not-program-
again/)

Some thoughts: I've worked on several large scala projects, and I've found
that long incremental compile times are often a sign of bad encapsulation. If
you change the type signature of a _public_ method then any file using that
class needs to be recompiled.

I've found that explicit type annotations on method return types help a lot
here:

    
    
        def getBandit(ref: BanditRef)= {
          ...
          ConcreteSimpleBandit(...)
        }
    

This has type `BanditRef => ConcreteSimpleBandit`. If I change the
implementation and return a ConcreteNonSimpleBandit, the inferred type
signature changes to `BanditRef => ConcreteNonSimpleBandit`. If I use an if-
statement and return one or the other, the return type will be the nearest
superclass of both (say a ConcreteBandit).

However, if I explicitly annotate it to return a BanditLike

    
    
        def getBandit(ref: BanditRef): BanditLike = {
          ...
          ConcreteSimpleBandit(...)
        }
    

then only the class in question needs to be recompiled.

The author is spot on about the use of infix methods. These are nearly always
evil. What would be great if Scala gave you a way to _explicitly declare_
certain functions as infix, and everything else uses the java-style calling
convention. For a monoid, a |+| b |+| c makes perfect sense. However,
consider:

    
    
        optionalResult map (x => x*x) filter (_ % 2 == 1) getOrElse -1
    

Yeah, you need to do work to figure out what's going on. Compare to:

    
    
        optionalResult.map(x => x*x).filter(_ % 2 == 1).getOrElse(-1)
    

But I suppose the former will save some bits ('.' and '(' take more bytes than
' ', right?).

~~~
ryanobjc
This comment reminded me of a book called "Large Scale C++ Software Design"
which is essentially about techniques to speed up your build time.

My short handed criticism about Scala is this: It's the C++ of the JVM.

Specifically it has many features of C++ we thought we left behind: \- slow
compile times \- complex language features and syntax

The language features have a benefit, and a cost. I just personally believe
the cost outweighs the benefits for me.

~~~
bad_user
Having worked with both Scala and C++, I actually think that people saying
this don't know what they are talking about.

I encourage you to take another look, as we often jump to criticisms with only
a superficial understanding, often based on comments made on forums by other
people. In particular, the idea of writing the code in a certain way to avoid
recompilation is rather silly and I never, ever did it in the last 2 years
since I worked with Scala.

On syntax and complex language features - having trained rookies unfamiliar
with Scala myself, I can tell you - it's neither the syntax or the language
features that are problematic, but rather the concepts involved. The Scala
ecosystem is chock-full of paradigms coming from static FP languages such as
Haskell. Scala's features are actually very elegant and orthogonal. It does
have ugly corners that are a result of its interoperability with its host, the
JVM, but that's a tradeoff I like, because people that don't like the JVM,
haven't seen what it can do.

On compilation speed, it's not much of a problem though I understand why
people don't like it. But the type system is very static - and in comparison
with Java in which the type system does nothing else but to stay in your way -
in Scala it actually helps you to write code that is sometimes provably
correct or to design safe and user-friendly APIs. For me it's not a problem if
my code takes an extra couple of seconds to compile, because the compiler does
help me in the case of Scala. In terms of recent developments, both SBT and
Maven are doing incremental compilation. Plus, SBT makes it really, really
easy to break your project into multiple sub-projects that depend on each
other, to keep them small, something which helps with compilation speed though
personally I do it for keeping the code base cleaner.

~~~
yapcguy
Correctness. Hmm.

See other comments below where co-founder of Typesafe (who has quit) gave a
talk explaining why Scala is doing everything wrong.

In his video he has a slide with the words "No wonder nothing works" and on
the slide:

    
    
      scala> val x1: Float = Long.MaxValue
      x1: Float = 9.223372E18
      scala> val x2: Float = Long.MaxValue - Int.MaxValue
      x2: Float = 9.223372E18
      scala> println(x1 == x2)
      true
    

This is the guy who has worked on the Scala compiler. He says it will never be
fast and there are things which are fundamentally broken (like above, and
there are many more).

I think any start-up using Scala is making a big mistake.

~~~
noelwelsh
A Long is 64 bits. An Int is 32 bits. A Float is 32 bits (8 bits exponent, 23
fraction, 1 sign). I don't see how anyone could expect a Float to have enough
bits to represent the difference. The only different behaviour I can envisage
is an error, but it is standard practice to disable these for performance
reasons.

~~~
bad_user
A Float on the other hand, by definition, is only an approximation. You can
use fixed-point numbers, but they are either too slow or lack the required
precision.

> _val x: BigDecimal = Long.MaxValue_

Problem solved. Or is it?

------
blakesmith
More of these "This language sucks" blog posts need to focus on the problem
domains actually being solved and less on the aesthetics of the tools. My team
uses Scala as one of our primary backend languages and have been extremely
productive with it. We're building large distributed systems that store and
manage large quantities of sensor data and push Scala pretty hard. Are there
warts? Yes, just as with any other tool. But the important part is that we
create value quickly for our customers, and Scala has fit our problem domain
quite well.

I've also seen too many consultants who get caught up in technology for its
own sake, because that's what many of them sell (We use this new development
methodology, with this hot new framework, hire us!).

Let's all spend less time worrying about what tools we're using and more time
worrying about whether we're solving the right problems.

------
michaelwww
The Co-Founder of Typesafe, Paul Phillips, hates Scala too. Working on the
compiler seems to have driven him mad (he says this, not me, but I don't
disagree based on this performance.)

[http://parleys.com/play/528cbfc3e4b084eb60ac78f2/about](http://parleys.com/play/528cbfc3e4b084eb60ac78f2/about)

~~~
melling
He says you need to be a "rocket scientist" to change the compiler.

We have computers that are thousands of times faster than the 1980's but Turbo
Pascal, then, could compile tens of thousands of lines per second on that
hardware. Scala is so complicated it takes minutes to compile large code
bases.

Anyone remember what the claims were for Turbo Pascal?

[http://en.wikipedia.org/wiki/Turbo_Pascal](http://en.wikipedia.org/wiki/Turbo_Pascal)

~~~
Mikeb85
They need to take a lesson from the OCaml or Haxe devs. Both have blazing fast
compilers that create efficient code for every platform known to man... And
both are very feature-rich languages.

~~~
yapcguy
He says the Scala compiler will _never_ be fast...

------
lemmsjid
It's sad that this particular blog post is getting double the attention
because it's not a strong critique of Scala, which, like any good technology,
is imminently critique-able. The extant HN thread got much more interesting
Scala critiques than the blog post:

[https://news.ycombinator.com/item?id=6829725](https://news.ycombinator.com/item?id=6829725)

That said, I would add the following meta-commentary, which has nothing to do
with Scala in particular:

Don't be scared away from Scala by the negativity. In fact, use said
commentary as evidence that Scala has hit a maturity point that makes it worth
exploring. When Rails first could come out, it could do no wrong, and I would
get regular queries from less experienced techies as to why we weren't
rewriting our code to use Rails, as though the hype made it a given that any
web application should be in Rails from now on. Now that Rails is more mature,
it gets regular negative articles. Using negativity around a mature technology
has some underlying theme that is valid (performance for Rails, overly complex
libraries for Scala), but not something that would or should scare someone
away if they are eyes-open assessing the needs of their final product against
the capabilities of the technology.

Really, we are in the infancy of software development. All languages are
incredibly oblique to their runtime environments, especially in distributed
scenarios. Any language that gets little but praise is simply not sufficiently
understood by enough people to be critiqued, or for said critiques to get up-
voted on news sites.

I am not, by the way, arguing that all languages are therefore equal in
quality. What I am arguing against is this: often when there's a vote-up
negative article about technology X, there's people who respond, "Aww shucks,
I was about to use X for my next project, what should I use instead?" And the
responses are, "Well, use Y instead", where Y is currently on the zenith of
its hype machine. This is a bad strategy for assessing technology, because
it's simply inevitable that Y will eventually receive a hailstorm of similarly
valid critiques. Consider it a given that any technology in use today will
look stodgy in forty years.

Instead, use the existence of critiques as a marker that a language is fairly
well known and mature. It's rather like the appropriate way to use Yelp
reviews: assume most of them are fake, assume nothing but positivity or
negativity is wrong, and instead look for volume and breadth of tone.

------
tenpoundhammer
I have written Scala on several large projects( and Play framework)

One of the problems with Scala is that there are a thousand ways to do
everything, which is often insanely confusing to a lot of people. And another
I think is that people try to teach scala like they teach other OO languages
and it just doesn't work.

Scala is not that hard once you boil it down the set of features that your
team wants to use.

After learning Scala and then teaching it to several java developers, I
believe I could get someone productive in Scala in 5-10 hours.

There are a couple of cognitive hurdles, and a few difficult to implement
features in the super deep realm of coding, but it's really not that hard.

~~~
hackerboos
>I believe I could get someone productive in Scala in 5-10 hours.

Write an book on leanpub. You'll make a fortune...

~~~
tenpoundhammer
I don't think I could do it with a book. I think I could do it with a
combination of lecture, exercises, and a little Q&A. At least that has worked
in the past.

------
quantumpotato_
I'm learning Scala (coursera, twitter) to write game servers that can handle
lots of request simultaneously. What's another good language for this? So far,
Scala seems rather powerful.

~~~
ivanplenty
I love Scala as a language and would encourage you to learn it on the way to
becoming a more rounded programmer. It does have its warts, and compile times
kill me. On HN the two common recommendations are:

* Go

* Node.JS (with Promises while we wait for generators!)

I personally use node for large-scale stuff since more people know JS, but a
lot of this comes down to personal preference.

~~~
nickik
Its interesting that you use Go (CSP) and Node.js (callback) and like them
both. Generally CSP people belive that the Node.js approach leads straight to
hell.

Rich Hickey is really good about why Callbacks are terrible (and that's why he
implemented CSP in clojure):

> [http://www.infoq.com/presentations/clojure-core-
> async](http://www.infoq.com/presentations/clojure-core-async)

>
> [https://github.com/clojure/core.async](https://github.com/clojure/core.async)

~~~
ivanplenty
"Like" is relative and based on tradeoffs. Loved Rick's talk, thanks.

This last year I worked on a project with people from the valley, we used Go,
and everyone contributed quality code. This is because people in SF area know
Go.

A year ago I worked on a project with people from the midwest, we used node,
and got the same quality. Much fewer people in the midwest know Go.

Independent of my feelings about both environments, CSP, callback hell, etc,
at the end of the day my team and I have to build a product, and I try to pick
the tool that best matches our combined skillsets.

~~~
nickik
Absolutly. For some stuff node.js works perfectly well and knowlage is often
the hardest thing to come by.

------
Pxtl
I think the key-value pairs vs typed objects for something like an HTTP header
is a holy war we'll _never_ hear the end of.

------
farginay
This post reinforces my sense that Scala is the new C++.

------
icedchai
I was at a job where I programmed in Scala for about 6 months. This was almost
3 years ago: immature tools (awful IDE support), slow compilers, long build
times (this was partially due to Maven project with literally 50+ modules and
too many unit tests), and inexperienced developers. Scala is too complicated a
language.

I'm sure it's a little better now... but, it's not for me.

------
mortyseinfeld
_With Scala you feel smart having just got something to work in a beautiful
way but when you look around the room to tell your clojure colleague how
clever you are, you notice he left 3 hours ago and there is a post-it saying
use a Map_

So he was making reference to Clojure here. That's fine, but you don't have to
make things complicated in Scala if you don't want to.

I love the semantics of Clojure, but until you get some optional typing and
possibly another syntax baked in forget about it for a whole class of devs.

~~~
lkrubner
About this:

"until you get some optional typing"

There is work being done on an optional type system:

[https://github.com/clojure/core.typed](https://github.com/clojure/core.typed)

There are also some interesting experiments in enforcing specific data
structures:

[https://github.com/prismatic/schema](https://github.com/prismatic/schema)

Much effort has been made to make contract programming easy in Clojure:

[https://github.com/clojure/core.contracts](https://github.com/clojure/core.contracts)

And if you would feel the urge to respond with something like "why is such
important functionality in a library", I'll point out enforcing pre and post
conditions (on a function) has a nice syntax that is part of the language:

[http://blog.fogus.me/2009/12/21/clojures-pre-and-
post/](http://blog.fogus.me/2009/12/21/clojures-pre-and-post/)

I find that every time I read an article about Scala I am left wondering "Why
don't these people just use Clojure?"

~~~
kasey_junk
Having made the choice between Clojure and Scala many times, always in favor
of Scala, here are the 3 main reasons I keep going back to Scala (even though
I don't particularly like it):

1\. I like type systems. I want strong typing, I'd prefer stronger typing in
Scala (ie purity constraints as type information etc). I don't want optional
typing (if I need dynamic interop, I can make a case for opt-out typing, but
I've never needed).

2\. Performance. I spend a lot of time dealing with performance issues,
specifically latency & throughput. I often have to back off of idiomatic Scala
to achieve these goals (especially when it comes to GC pressure). Scala makes
that easy & painless. Clojure doesn't.

3\. Style (purely subjective). I don't like LISP style languages. My very
first experience in programming is in Scheme, so it's not that, I just don't
like how they look. It's fine for other folks to like them, different strokes
and all that, but I don't like it.

There are a ton of things I don't like about Scala, but for me and my
projects, right now, if I'm targeting the JVM it is the best choice and
Clojure isn't even second.

~~~
Aqueous
"I often have to back off of idiomatic Scala to achieve these goals
(especially when it comes to GC pressure). "

Can you give an example of when you had to do this? I often wonder about the
performance costs of chaining together several collection API calls.

~~~
kasey_junk
Options are the most obvious:

def foo(opt: Option[Bar]) = opt.map(_.toString).getOrElse("")

This non-obviously creates an extra object in the Some case. As opposed to:

if(opt.isDefined) opt.toString else ""

which creates 0. Not a huge deal in this specific case (unless this is a hot
call). But this sort of thing is endemic to all of the standard libraries.

 __Edit -- only 1 extra object, but it is in both the Some & None case (which
is sort of the point, it is hard to know with idiomatic Scala)

------
frowaway001

      I also work in the same company as the poster. We are 
      currently running a huge Scala/Play project where the 
      team is a mix of many young developers (< 5 yrs) and a 
      few seniors. Overall it is a very pleasant experience. 
      There are multiple other projects using Scala which share 
      this positive feeling.
    
      It is difficult to explain these reactions, but they are 
      common among my colleagues. These are senior programmers 
      who are generally very good with any programming 
      language/task. They will pickup something new and be 
      productive in just a few days. They usually end up liking 
      Ruby, Javascript, Clojure and for good reasons.
      
      Scala on the other hand requires a lot of attention and 
      work to get mastery. One can get started in days but to 
      exploit the real power and appreciate design choices 
      takes months if not years. In my opinion this is an 
      important factor why these smart developers react so 
      badly to Scala which for them is just another tool which 
      takes too much time to grasp.
    
      There is little Scala can do. Maybe it should become less 
      ambitious. No macros, no compiler plugins, do not 
      challenge FP etc. But then it will not be the Scala we 
      all loved :) Also, it is important to note the blog post 
      does not criticise Scala in isolation. It used Spray DSL 
      for routes and Gradle as a build tool, maybe that 
      particular combination increases the pain.
    

[https://groups.google.com/d/msg/scala-
internals/153H3Ya4Nxk/...](https://groups.google.com/d/msg/scala-
internals/153H3Ya4Nxk/AngkiUE7VUIJ)

------
talles
thats a creative title

------
adricnet
I somehow misread this as Scalia (Supreme Court Justice) and thought this was
about one of the recent announcements from SCOTUS...

~~~
kleiba
This means you're browsing the wrong site.

~~~
adricnet
I'm not making an argument about that but there were two or three SCOTUS
stories on the frontpage of HN today.

Taking my downvotes and moving on, I am.

