

Why Scala seems difficult but really isn’t - nuriaion
http://markusjais.com/why-scala-seems-difficult-but-reallyisnt/

======
bad_user
As a replacement for Java, Scala is a failure. It is a language too complex
that doesn't provide enough benefits for people that just want something
better than Java.

The perfect Java replacement would have - local type inference, less verbosity
(e.g. public by default), full closures, anonymous blocks, no generics,
special syntax for arrays and hashes, operator overloading and the ability of
a variable to behave as if dynamic (e.g. leveraging the future InvokeDynamic).
I would also completely purge checked exceptions and also get rid of the
general syntax for anonymous classes - basically get rid of anything not
useful.

People actually liked earlier versions of Java. It was a simple language,
while still a lot more productive than C++. They fucked up its evolution and
IMHO it's pretty sad that people like Scala so much; it just shows how low are
the standards.

~~~
mark242
"The perfect Java replacement would have"...

"local type inference". That's Scala. List(1,2,3)

"less verbosity (e.g. public by default)". That's Scala. def
myMethod(arg:Int=1, arg:String="myDefaultValue") ... with no boilerplate crap.

"full closures". That's Scala. val myImmutable = { runThisCode }

"anonymous blocks". That's Scala.

"no generics". That's-- more or less Scala.

"special syntax for arrays and hashes". That's Scala.

"operator overloading". That's Scala.

"the ability of a variable to behave as if dynamic". That's Scala.

"I would also completely purge checked exceptions". Scala, so long as you stop
writing try catch blocks.

"and also get rid of the general syntax for anonymous classes". Scala.

Look, I just recently rewrote a ten-thousand-line Java web app into Scala. I
got-- no joke-- 75% code reduction, and the only reason I didn't get more was
due to the fact that I decided to stick with Struts2 instead of moving to
Lift.

Think of your typical method that accesses a Hibernate named query, and
returns a boolean as to whether or not that item exists.

Here's the Scala version:

def domainExists(domain:String) =
Option(HibernateUtil.getSession.getNamedQuery("domain.findByName").setParameter("name",
domain.trim.toLowerCase).uniqueResult.asInstanceOf[Domain]).getOrElse(new
Domain()).id > 0

That's a one-liner, and I'm sure there are Scala experts out there who could
reduce that code even further.

~~~
bad_user
You made more or less my point -- but my point was that Scala provides too
much; and I don't want to choose a subset, as my subset will be different than
yours.

Also, I would like a language that's as close to the JVM type system as
possible, yielding the same performance as Java in all instances (including on
Android, where Dalvik doesn't have the same GC and optimization
characteristics).

    
    
         "no generics". That's-- more or less Scala.
    

Generics are an inherent part of what Scala is. Surely it takes care of some
gotchas, but I see many code samples where I feel like puking.

Generics weren't really meant for languages without Hindley-Milner.

    
    
         "the ability of a variable to behave as if dynamic". 
         That's Scala.
    

Scala is not dynamic by any stretch of imagination, no matter how much wishful
thinking you can incur because it has structural typing -- I see this notion
flying by all the time, but people generally don't know what they are talking
about.

E.g. you don't see people saying this same thing about Haskell, when compared
to Lisp, even if Haskell is even more concise than Scala, taking structural
typing to extremes.

What I mean was that I'd like something like the dynamic types in C#.

~~~
riffraff
I believe grandparent point about dynamic variables is the newly introduced
Dynamic type in scala 2.9.

~~~
bad_user
Oh, sweat, I may be wrong but that's what I wanted.

Unfortunately, for now it is an experimental feature. But thanks for pointing
it out, it seems that it's coming :)

------
Lewisham
Can someone please explain to me why Scala has been getting such vitriol on HN
comments lately? I've never found Scala "difficult"; you can use Java and take
in new bits as you go. Why do people keep saying its too complex? It's no more
or less complex than Ruby, and certainly less of a learning curve than
Haskell, more familiar syntax than Lisp (for more programmers), yet the
comments here indicate that "Oh, Scala is so complicated, how could anyone
learn it?" This article seemed on the money for me.

I know things like type erasure and other programming language bits and bobs
upset the PLs gurus, but I really don't care about that. I can write concise
code that looks like a dynamic language, but get full static type-checking.
That's a huge win.

I really just don't understand it.

~~~
Elrac
It so happens I've been trying to write my first "real" Scala application
these past few days. It's been a harrowing experience. Just a few highlights
off the top of my head:

* Eclipse support is spotty. Apparently legal programs suddenly develop lots of errors. Sometimes restarting Eclipse will allow the program to run anyway.

* Types are constantly getting in my way. Sometimes types are correctly inferred, sometimes I need to add types to hint the compiler about what I'm doing.

* Writing anonymous functions remains hit and miss. I just throw in underscores at random until something works.

* I don't understand where the round or squiggly parentheses go in for comprehensions; i.e. what goes in the parens and what stays outside.

* Hashmaps have a cool "+=" operator to add a key-value pair. So why does "put" work but "+=" doesn't? Another mystery.

* Sometimes the parentheses after function invocations are optional if there are no parameters. Sometimes not. Why?

It's not Scala's fault that the Eclipse plugin is less than perfect, it's
already very powerful. As for my little struggles with the language, none of
this is witchcraft; I'm sure there are well-defined rules and sensible answers
to all these questions and many more. But I must say I'm annoyed with the huge
number of rules behind Scala. The amount of stuff I need to learn to really
use Scala effectively is daunting.

Contrast this with my Ruby experience. This is a language that places great
value on orthogonality: wherever possible, every operation works the same in
every situation. So you have a smallish number of versatile functions, not too
much stuff to absorb and things generally Just Work (TM). I taught myself Ruby
and Rails and wrote my first useful Web app in a couple of weeks' worth of
evenings, and it was a very pleasant experience.

Clojure, similarly. All the parentheses took some getting used to, but the
language's syntax is wonderfully simple and consistent, so getting stuff done
is mostly just a matter of looking up the most appropriate function in the
cheat sheet. I managed to be productive (for small programs) with Clojure in a
couple of days.

Scala is no doubt a fantastic language. But thanks to its kitchen sink
attitude, it's not an easy language to come to grips with for someone with an
aging memory and a less than full-time commitment.

~~~
Lewisham
_But thanks to its kitchen sink attitude, it's not an easy language to come to
grips with for someone with an aging memory and a less than full-time
commitment._

Perhaps this is one of the things that is tripping people up that I'm not
doing. I tend to still be quite verbose in my code, even if only as a way of
reminding myself what I thought the code was supposed to do (ever look back at
Python and you're not really sure whether the variable is supposed to be a
list or a tuple or a string? I have that problem _all the time_ ). I don't
tend to use all the flourishes like underscores and such.

It seems a bit like Perl's many ways to do it attitude. Except I feel like
Perl was designed by ideology, whereas Scala has a lot of bits and pieces
because it wasn't clear to Odersky et al. which bits people would like and
which they wouldn't. Perhaps rather than trying to enforce an idomatic style,
they wanted programmers to find their own way. But that means there's things
in the language that exist and can't be taken out (XML literals), and there's
no documentation cohesion (by which I mean different documents will tell you
to do different things, and you're not sure which is best).

If you Google "effective scala", you'll see a number of people clamoring for a
book along the lines of Effective Java, and Scala sorely needs it, but Scala
is still too much of a moving target to warrant putting anything in dead tree
form yet. The Davetron Scala Style guide, however, is a really good stop gap,
and helped me a lot.

------
leftnode
I've given up PHP for Scala recently, and it doesn't seem too difficult yet.
Do yourself a favor, pick up a copy of "Programming In Scala" by the languages
author, and read it starting from page one, even if you think you're an expert
programming.

I can't learn a new language quickly, so to learn I'm blogging about my
experiences at <http://leftnode.com> and trying to write as many small
programs as possible, moving into larger ones when I'm ready.

I'm trying to ignore many of the larger projects and in-depth Scala projects
for the time being so I don't overwhelm myself and give up on learning the
language.

~~~
jshen
I used scala for a few projects, and overall I like it much more than java.
Let's just get that out of the way upfront :)

I loved scala when I was writing and reading my own code, but it started to
feel like perl when I had to use and dig through other peoples code. This is a
fairly superficial feeling, and I could be off mark, so take it with a grain
of salt. I definitely plan to use scala again when I need the performance over
jruby/clojure, in place of java of course.

------
darklajid
Down for me, cached link here:
[https://webcache.googleusercontent.com/search?q=cache:q2kp8R...](https://webcache.googleusercontent.com/search?q=cache:q2kp8RKQ5h8J:markusjais.com/why-
scala-seems-difficult-but-reallyisnt/+&cd=1&hl=en&ct=clnk)

------
jinushaun
I have the same problem with learning Ruby. The official tutorial basically
runs you through "regular" style imperative programming. But when you see
real-world Ruby in the wild, it's always so cryptic, and uses popular language
features that don't really get touched on in the tutorials.

~~~
bad_user
If you're talking about the Picaxe book, Ruby is all about meta-programming,
so that's only a book to get you started. I also think it's a highly overrated
book and personally I haven't had the patience to read it.

Ruby code gets really clear when you understand "self", eigenclasses and
closures.

Required reading: <http://pragprog.com/titles/ppmetr/metaprogramming-ruby>

Also, Ruby is not a functional language; but IMHO is much better and more
elegant than many languages that claim to be functional.

~~~
nvarsj
Pickaxe is pretty awful for learning Ruby. I also did not have a great
experience with it. My favorite Ruby book is [http://www.amazon.com/Ruby-
Programming-Language-David-Flanag...](http://www.amazon.com/Ruby-Programming-
Language-David-
Flanagan/dp/0596516177/ref=sr_1_3?ie=UTF8&qid=1308760667&sr=8-3).

------
perfunctory
A bit off topic rant on the Eckel's article linked in the post.

1\. I wish people stopped saying "static language that feels like dynamic".
This is just a marketing slogan. Type inference is not a substitute to dynamic
typing.

2\. I know that coming up with a good, plausible code examples is difficult
but it's not an excuse to give bad examples. House has-a Bedroom; House not
is-a Bedroom.

3\. > Scala has the best of both worlds: true multiprocessor parallelism and a
powerful functional programming model

This sounds as if usually multiprocessor parallelism and functional
programming are mutually exclusive and Scala finally managed to have the best
of both worlds.

4\. > v.foreach(println)

... eh, isn't this just passing a named function as a parameter?

~~~
riffraff
as someone pointed out on HN before "dynamic" seems to be an increasingly
common way of saying "doesn't annoy me much" or something like that.

------
currywurst
Coincidentally, today is the first day I'm seriously looking into Scala, and I
think his points serve well to temper one's approach to language.

I think Scala is an admirable and ambitious effort to allow oo + func
programming on the JVM. I also got the impression that the type system is
"good enough" for most DRY efforts. But then, my background in this area is
virtually non-existent.

Depending on what sources you learn from, you don't need to learn all the
intimidating language features in the beginning itself. I am currently working
through [1] - well written, but slightly outdated. [2] is where I got oriented
initially.

It's also great that they do well to come within striking distance of Java in
performance (this is not my impression of Clojure). Another super cool
approach seems to be that of Mirah (no special runtime, Ruby-like syntax).

[1]: [http://www.codecommit.com/blog/scala/roundup-scala-for-
java-...](http://www.codecommit.com/blog/scala/roundup-scala-for-java-
refugees) [2]: [http://grahamhackingscala.blogspot.com/2010/12/guide-to-
lear...](http://grahamhackingscala.blogspot.com/2010/12/guide-to-learning-
scala-by-graham.html)

------
davidw
As someone who is curious about Scala, what's the current "state of the art"
in terms of a web framework? Can you point to some example code?

~~~
michaels0620
Lift (<http://liftweb.net/>) is the most widely adopted Scala web framework.
Scalatra (<https://github.com/scalatra/scalatra>) is another that is based on
Ruby's Sinatra.

------
code_duck
I've found Scala to be more intimidating to approach than the average non-
functional language because the people who tend to use and write about it are
of a relatively high level of expertise.

I'm rather sold on it, though. I've been warily learning it in dribs and drabs
for about a year, and one of these days will actually write something that
accomplishes a task.

------
numbsafari
Scala runs on the JVM, which is owned and encumbered by Oracle. So... why
should we care?

~~~
dstein
There are many JVM implementations:

<http://en.wikipedia.org/wiki/List_of_Java_virtual_machines>

~~~
numbsafari
And how many people running Scala are actually using those other JVMs? How
many of them even compare to the Sun/Oracle JVM? I mean, honestly? And given
Oracle's new penchant for suing people and their spat with Google/Apache, do
you really want to keep your eggs in that basket?

People keep trying to sell new languages to Java developers using the JVM. The
problem isn't the language, though, it's the JVM itself and the licensing
problems, too.

------
speckledjim
Either you care about shipping products, and making things of value, or you
care about what the latest fashionable language to do it in is.

~~~
PaulHoule
That brings us to point (1) of his article. He asks us to make a large
investment in learning a language that might pay off in the future... might.

My understanding of Scala is quite imperfect but the more I've learned the
more it seems that it's got pretty facades built over weak wood. Rather than
being a 'scalable language' it comes across like a fake town that was built as
a set for a Western. Look at any beautiful concise code sample that they try
to seduce you with and you find that any small change requires tripling the
code size. Look at the chapter in the book on DSLs and the take-away is "don't
try to build internal DSLs".

Be it looking at the profiler running on on a Scala program that uses actors
or finding that I never quite seem to get away with not having to declare
types explicitly, I have a facepalm event every hour or so working with Scala.

In my case, (2) has nothing to do with it. I'm quite familiar with functional
programming, both in languages that support it well and languages that don't.
These days even my PHP looks like LISP.

(3) is certainly true, and I think it has something to do with the cultural
difference that @speckledjim points out.

Anyone who's got to work with Scala will definitely confront (4); if you're
working in Java or PHP or some other commercially viable language you can
probably solve a high fraction of problems by using Google and Stack Overflow.

If you're programming in Scala you'll have a lot more success understanding
the fundamentals of the language. If, for instance, you need to access Scala
objects from Java (particularly the super-prevalent ones like Option and List)
you'll find that cookbook-style documentation is 100% AWOL. Go look at the
scaladocs for Option and List, however, and you'll be calling methods on them
in no time from Java.

If you insist on working with Scala, get a book and read it all the way
through from the beginning, skipping forward when you don't understand
something.

~~~
fogus

        Look at the chapter in the book on DSLs
        and the take-away is "don't try to build 
        internal DSLs".
    

Which book do you mean? Also, do you mind elaborating on why one should avoid
building DSLs with Scala? In my own experience [1] I've found it extremely
nice for internal DSLs.

[1]: <https://github.com/fogus/baysick>

~~~
troutwine
Presumably he means Ordersky's Programming Scala. While it is possibly one of
the better Scala books available it is downright bad, having committed the
doorstop producing sin of confusing a language tutorial with a reference with
a thesis defense. The second edition of the text is all over the place,
providing little in the way of even trivial program examples and maintaining
shockingly conservative advice from the first edition, written for the
language in its state a few versions back.

The assessment that Scala is a pretty structure built of weak wood is not too
far off, at this point. Compared to other strongly functional languages--
Haskell and ML, say--the type system is shoddy and limited. In part this is a
frustration of maintaining objects on Java's terms, but also defects in the
JVM: type erasure is a hair-shirt that neither of languages I mentioned
previously have to wear. You can somewhat avoid the loss of types with
manifest hacks, but it's shoddy business. Often you can't; note that Akka has
a distinctly dynamic feel, being that certain messaging functions--!! and !!!
--must return an Option[Any] even when the original message is well-typed. The
system loses the type information at runtime!

Compilation speed is also an agrivation. It's a slower process than Haskell--
not zippy to begin with--and comes with less result, to boot. All that said, I
tentatively like Scala, especially if a project is required to run on the JVM.
I find it to be an especially pragmatic language, if unbeautiful and not
something I intend to use for long-term, exploration coding. A fine choice for
a language to be used in anger, let's say, if the memory usage of the JVM is
of no concern.

~~~
gaius
I was very surprised, having only started Scala recently, that it cannot infer
types in function arguments. OCaml has no problems with this.

~~~
fogus
Scala doesn't have Hindley-Milner global type inference (of which OCaml has an
extended version of) and instead uses a form of local type inference. Hindley-
Milner doesn't work well (i.e. undecidable) in the face of overloading and
inheritance.

------
Meai
I think this is just a case of different viewpoints. The author clearly states
himself in the last paragraph that learning Scala in under 3 weeks should not
be expected. Personally, I consider any language that I can't learn to a
reasonable level in 2 days difficult.

~~~
nuriaion
Any language which uses concepts which you haven't used before (Like
Functional Programming or in the other direction OOP etc.) will need more than
2 days. You will need the time to learn the new concepts and not the language.
So the language per se isn't difficult but the new concepts...

~~~
Ubersoldat
I've been an OO programmer for a long time and I really, really like the way
functional programming works. It takes some time to re-think your previous
assumptions, but even when in pure Java, a more functional approach provides a
much better code. And, maybe it's because I've used another languages that I
find Scala pretty straight forward.

