

Scala is not a better Java - mnemonik
http://john.freml.in/scala-is-not-a-better-java

======
stephenjudkins

      Java is deliberately not programmer-orientated. That's the point of using it — it was designed to restrict the kind of trouble programmers can get themselves into. If you're stuck with the JVM, I guess the question is: how much rope do you want to give your programmers? Scala is essentially the opposite answer to Java.
    

This was an interesting read but I disagree with this assertion. Java's lack
of power as a language hasn't meant that people haven't written huge, complex,
unmaintainable messes with it. Indeed, I think all the crazy dependency
injection frameworks, configuration-by-XML, and other general insanity is due
in part to the language's lack of power. Things that are simple in other
languages (say, dependency injection, which can be replaced with runtime
stubbing in Ruby or mixing in traits in Scala) often require painful and
complicated ad-hoc solutions in Java.

That said, it is possible to write code in Scala that requires a PhD in
category theory to understand (see Scalaz), but there are also many examples
of simple, functional, easy to understand code (see stuff that has come out of
Twitter, like Kestrel or Nagatti).

I think in practice, working with the modern Java ecosystem gives one at least
as much rope to hang oneself as using Scala does.

~~~
btilly
You may disagree, but the assertion is correct. Java was deliberately designed
to restrict what programmers could do. The belief was that this would help
maintainability, and particularly when trying to get large teams to cooperate.

That Java users have found ways to get around deliberate limitations does not
change the fact that this was the original intent of the language design.

~~~
stephenjudkins
The part I was disagreeing with is that Scala gives programmers more "rope to
hang themselves with". You may be correct that restricting what programmers
could do was a goal of Java, but writing Java in practice gives a tremendous
number of opportunities to hang oneself. Apologies for not being more clear.

Further, it's not like this complexity is something that arose independently
of Java itself. One of the most frequently cited examples of super-complicated
insanity in the Java world is J2EE, which is a standard and set of libraries
created by Sun itself. If the creators of language have managed to create and
propagate one of the biggest tarpits available in Java, that reflects poorly
on the overall Java ecosystem.

------
gte910h
Scala is finally giving Java programmers a grown up language.

Java is the "oh this is explicit, I just wrote a program the size of the
federal register!" language. It is overly simplistic in several areas thereby
causing complex workarounds to be implemented to solve real world issues.

------
mhd
It's not _just_ a better Java, if you ask me. Scala, like Clojure, aren't
really pure Java replacements, fixing some of the bugs and awkward syntax
details. Both try to steer the programmer towards different ways of
programming. They're better, and more.

As I'm currently taking a look at Android development, I wish there was a
simply "better Java". Something that doesn't stray too much from imperative
C/Algol/Pascal-like programming, but doesn't require me to use a huge, bloated
IDE just to cope with the language features. Better variable declaration,
better modules, uniform access principle etc. Fantom looks interesting but --
again -- tries to be more than that (own library, multi-VM etc.).

------
narrator
Scala is actually a better Ruby. All the messy fun stuff that we all love with
Ruby like duck typing and monkey patching can be done easily with Scala,
except it's all statically typed so it keeps the whole mess under control.

For instance, you can have a duck type as a function argument that's contract
is it implements a particular method signature. In Ruby there is no type type
enforcement so you can get runtime errors when you pass in an object that
doesn't have the right method, while in Scala the compiler catches it.

You can monkey patch by doing implicit conversions in Scala to a rich type,
allowing one to add methods to the Integer class, for example, but if you have
to libraries that do the same monkey patch Scala will alert you to ambiguous
situations. In Ruby this depends on load order and can cause all kinds of
screwy bugs.

~~~
cageface
Scala is brilliant in a way in that it hides all the incredible complexity you
incur when you try to statically type a programming style evolved in dynamic
languages. That is, it hides it to a point. It's easy enough to get started
writing simple scripts and sprucing up old Java code but before long you get a
compiler error that sends you scurrying away to the reference books and then
it hits you that you really are going to have to come to grips with the type
system and it's a _doozy_.

I'm still not persuaded that all the gymnastics Scala has to do to allow Ruby-
like flexibility really result in a more productive language overall. I need
to spend more time with it to be sure but at first blush it really feels like
the faustian bargain Scala has had to strike to merge expressive, Ruby-like
syntax with strong, static type-checking and java compatibility has resulted
in a language too complex for most working programmers.

Clojure seems a lot more elegant and comprehensible.

~~~
sreque
I agree that Scala will never be a good replacement for languages Ruby both
because of its complexity and the fact that dynamic languages are always going
to be more flexible than statically typed languages. The fact that majority of
new languages are in fact dynamic ones is also a good indication of the
inherent difficulty in designing a good statically typed language. Scala is a
much grander project in scope than Clojure, Ruby, Python, Groovy, or pretty
much any of the dynamic languages sprouting up on the JVM probably ever will
be. For instance, because these languges are dynamic, they don't care to deal
directly with things like the cost of autoboxing, the price of type erasure,
the ugly hackery that is java arrays, and so on. Life is simple when
everything is of type Object! Of course, this grander scope comes with a cost,
and that cost is language complexity.

In my opinion, Scala's aim is to take on Java by providing a much more overall
productive language than Java while still maintaining Java's performance. I
feel it's very much akin to the goals of C++ versus C. Fortunately, the people
behind Scala are well versed in PL theory and make sensible language design
decisions, so at this point Scala is in little danger of someone writing an
FQA on it any time soon.

~~~
gfodor
Sorry, but this comment is pretty misinformed. Clojure has numerous facilities
to address the performance issues you mentioned. You can, for example,
annotate parameters to a function with type information to use primitives,
java arrays, and remove the need for reflection.

Additionally, JRuby has had a JIT that attempts to do smart things to avoid
unnecessary boxing and reflection. They've been rather impeded by the JVM on
this front, but JVM 7 looks to open a lot of doors for the JRuby team to
remove a lot of unnecessary dynamic dispatch in the execution of Ruby code.

The problem I see with Scala is it reeks of Perl 6's "everything and the
kitchen sink" language feature-a-thon. Having learned Clojure and started
Scala recently I'm constantly asking myself why Scala code has so much
incidental complexity compared to the equivalent Clojure code. Often, it is
due to the type system or the excessive number of constructs and syntax
available in the language.

~~~
sreque
I thought you might bring some of that up! :)

Unless this URL (<http://clojure.org/java_interop>) is out of date, then I
fail to see how I'm misreading this section.

"All arguments are passed to Clojure fns as objects, so there's no point to
putting non-array primitive type hints on fn args. Instead, use the let
technique shown to place args in primitive locals if they need to participate
in primitive arithmetic in the body.".

Also, I'm not an expert on JRuby's attempted optimizations, but if I
understand correctly they are very limited, much in the same way that Java's
escape analysis is. The post By Charles Nutter less than a year ago is
illuminating in that regard([http://groups.google.com/group/jvm-
languages/browse_thread/t...](http://groups.google.com/group/jvm-
languages/browse_thread/thread/2c10bde4b9985086)). Have things changed that
significantly since then? I follow his blog regularly and in most benchmarks I
can remember him talking about he still compares JRuby to Java running boxed
math.

------
barrkel
_"it was designed to restrict the kind of trouble programmers can get
themselves into"_

Every programming language is designed to restrict trouble programmers can get
into. The key is that they all have different ideas of trouble.

------
strlen
Scala's DSLs are internal DSLs, made through the use of higher order
functions, closures and implicit conversions. That's _very_ different from
external DSLs, written in a separate language (macros in C and C++). There are
also DSLs that straddle the line e.g., C++ templates ("generic meta
programming") and Lisp macros (application of Lisp but at a different stage,
resulting in new s-exps). That's a big distinction.

------
wheaties
Inventing good languages within other languages is a good thing. Just look a
Rails. Inventing bad languages, well, bad code is always going to be bad. I
disagree that Scala is not better than Java. Any language which adds
additional mechanisms to make my life easier as a developer is a good thing.

~~~
Chris_Newton
> Any language which adds additional mechanisms to make my life easier as a
> developer is a good thing.

What if they make life easier for you but harder for everyone else on your
team?

I'm not saying I disagree with your philosophy, just that there is merit in
the other side of the argument as well. I want tools to build powerful
abstractions, but I want those powerful abstractions to be easy for everyone
to read and, when necessary, explore in detail.

~~~
btilly
How big does your team need to be?

There is a productivity valley between small teams (up to 5-8 people) and
large teams (20+). In that valley you get less done than on either side, so it
makes no sense to be there.

What this means is that organizations need to make a choice between maximizing
what can be done with at most 5-8 people, or else making teams of 20+ people
work together smoothly. And the sets of features that are good for either of
those goals are frequently bad for the other goal.

~~~
Chris_Newton
> There is a productivity valley between small teams (up to 5-8 people) and
> large teams (20+).

Sorry, but I don't agree with that at all. As soon as you have more than one
person working on the same part of your code, you incur some degree of
overhead. I don't see why the numbers 8 or 20 are special. Are you really
claiming that a competent development team of 18 people cannot do more than a
competent development team of 8 people?

To co-ordinate teams of many developers, we divide projects into manageable
chunks, each with a relatively small number of developers working on them.
This requires good abstraction tools, so that developers can see how their
contribution fits into the larger picture, can work with the code written by
others without having to know it in intimate detail, and can combine all the
components into a complete product. Again, I don't see how this picture
differs whether you have 8 people or 20 people, unless you're following some
sort of surgical team model where you really are trying to get all of the
smaller team working on the same code but most of them aren't actually writing
that code at all.

~~~
btilly
It doesn't matter whether you agree, it is true.

See page 229 in _Software Estimation_ for references to research that a medium
size project will be produced in the same number of calendar months by a team
of 5-8 people or a team of 20-25 people. And it will take LONGER if your team
is between those two sizes. Beyond that larger threshold, development also
speeded up.

In this case a medium sized project was 10-100 thousand lines of code, and for
all the team sizes looked at across all of the projects examined averaged
50-60 thousand lines. I would expect that the small team likely had less code
duplication within their project, which would indicate that when measured by
functionality, the small team had an even bigger advantage.

Note that this is calendar months to finish the project. If you measure in
terms of dollars spent to finish, the most productive team size is 1.

And yes, this is with the larger teams using standard practices such as being
divided into smaller, more focused groups. The reason is that the process of
doing that requires completely changing how you work, and that results in a
significant productivity impact. Once you take that hit you can scale, but you
have to take that hit first.

~~~
Chris_Newton
I'm all for evidence-based debate, but as I don't have that particular book,
could you please provide specific citations?

I am willing to accept that I am wrong if the evidence really says I am, but I
remain deeply suspicious of these conclusions on the basis of the data you
have provided so far. A typical 50-60 KLOC project is the sort of thing I
would expect one or two decent developers to put together in less than a year.
I don't know why even a team of 8 people would be working on a project that
small under most circumstances, never mind a team of 20-25 people. Of course
if you go into the low end of the tail then the communications overheads will
dominate development time with that sort of team size, but that's hardly
typical of a realistic project with a competent development team.

(I keep using qualifiers like "competent", because I don't think this level of
performance requires exceptional developers and managers, but I am ruling out
clueless management or developers who aren't good enough to function
effectively in a team at all. Of course with such people your supervision and
communication overheads go through the roof.)

Edit: Never mind. I found the relevant excerpt of the book you mentioned. You
are making a completely unfounded generalisation, extrapolating from data
taken in a very specific context, with no logical basis whatsoever. I stand by
my previous posts.

------
Daishiman
Why yes, giving you difficult to check XML files as a bad replacement for
introspection, decent conventions, and complex class hierarchies (with tons of
casts in the middle) to account for absence of features is just so much
better.

------
andybak
I mainly know OO through Python. I had a Java programmer try and explain why
Dependency Injection frameworks were great and I went off and googled around
and there are a few for Python.

I still can't grok why I'd need one though. Is DI for Python the product of
damaged minds or do they provide some real benefit?

~~~
JulianMorrison
Even in Python, you benefit from structuring an object to accept its
dependencies as inputs, rather than calling to them by their global names. It
lets you test each class independently with mock objects that support the same
interface.

~~~
andybak
By writing XML config files? (or is that just a Struts wart rather than an
intrinsic part of DI?)

Anyway - if mocking for tests is the major benefit of DI then there some other
simpler ways to that. Everything I've read on DI makes it sound like a fairly
complex beast.

------
guelo
Java beats Scala, and many other languages, in readability and
maintainability. Java has a lot of best-practice conventions developed over
many years of pain on how to make the code as readable as possible. The
functional languages need these guidelines even more than Java does, but they
seem to lack them. It's really easy to write insanely convoluted unreadable
code in Scala.

~~~
TeHCrAzY
"It's really easy to write insanely convoluted unreadable code in Scala."

It's really easy to write insanely convoluted and unreadable code in any
language. The language isn't really the factor there, more the programmer.

~~~
guelo
That's why I said conventions. Java has many years in this area. There is
nothing like Joshua Bloch's "Effective Java" for Scala.

~~~
TeHCrAzY
You are missing my point: that the language isn't the key part here, its the
programmer. If a programmer doesn't adhere to some sane formating and code
structure, it won't matter what language they write in, the result will be
spaghetti.

~~~
guelo
No you're missing the point, the point is that the "formatting and code
structure" conventions haven't been developed for scala the way they have for
java over many years.

------
dman
Can any of the scala folks point me to a good introduction of the language ?

~~~
bitsai
Daniel Spiewak has written a fair number of Scala articles, and I've found
them to be quite helpful:

<http://www.codecommit.com/blog/category/scala/page/10>

------
acg
Seems a superficial argument, C++'s features have not been added into Java to
create Scala. Even the Java community is pushing Java7 in a direction with
richer features, except the language is beginning to get in the way. Generics
are not implemented too well, closures are likely to complicate matters
further.

