

Switching to Plan J (From Scala back to Java) - cfontes
http://alarmingdevelopment.org/?p=562

======
plinkplonk
What the the article seems to miss is that Scala _can_ be used strictly as a
"better Java" without using any of the advanced type features or idioms if
that is what you want.

(Anecdotal)War Story: Once upon a time I worked with a team of scientists (not
professional developers) who had some legacy research code in Java, had tried
moving to Scala and got badly bitten by the advanced type theory bits and so
were considering moving back to Java. When I joined the team I taught them how
to use the "Scala as a better Java" approach, (which would correspond to
approximately the L1 level in Martin Odersky's blog post at <http://www.scala-
lang.org/node/8610>) and to this day they are happily building new stuff in
Scala (and Java).

Just as you can use Common Lisp without completely mastering macros, the
condition system etc, to get stuff done at the cost of some redundancy when
compared to what the code would look like if an expert were to write it, so
can you use subsets of Scala to get serious work done.

I suspect problems arise when you have the attitude that you must completely
master the language before you start using it to build stuff. This excludes
all but the ultra simple languages from consideration. Reductio Ad Absurdum,
Imagine a world where the only programming language in use is VB (or even C) !

I offer the hypothesis that when using any _new_ _and_ "large" language on a
real life project you have to work with a subset. This is not a bad thing and
"subset" is not a dirty word (as long as the subset is clearly identified and
at least as good as the alternative languages). As you gain experience with
the subset and actually build useful systems with it you can then go deeper
into the language and learn more advanced features, which you can then use to
refactor your code to use those advanced features where appropriate, in a
virtuous cycle.

Imagine you are learning a non programming language (say French) or even
musical notation. If you wait till you have wrapped your head completely
around whatever you are learning before you start using it, you are (a) going
to wait a long time (b) very unusual in your approach. Is having an ultra
simple syntax or a small surface area a virtue? Yes it is. It is _one_ aspect
of a design but not the only one.

The lack of an IDE is a more valid complaint, (especially if you plan to have
big teams of mediocre programmers) but then you restrict yourself to using
only core mainstream languages with very strong vendor ecosystems (say Java,
VC++, C# and VB). It would be nice if every new language sprang from their
creators brows fully equipped with ultra functional IDEs but that maybe a tad
unrealistic a wish ;-).

I also suspect that most of the carping comes from people who haven't actually
used Scala in any serious fashion. Complaints about "too complex a type
system" from people who have never used Scala to actually build something have
about as much legitimacy as people who refuse to use Lisp because it has "too
many parantheses" and just "know" that parantheses are confusing.

~~~
Nitramp
I think the "subsetting the language" approach is a red herring. Yes, you can
decide you'll only use feature X, Y, and Z. Many people do that in similarly
complex languages like C++.

But the programmers will, one way or the other, get exposed to the features
you considered esoteric. Be it through libraries, or sample code, or whatever.
And then they have a piece of code in the language they use for daily work
that they don't understand, can't debug, and are alienated by strange compiler
errors - not good.

It's IMHO also quite hard to come up with the subset you like. I mean,
programmers like to have endless discussions about completely irrelevant
topics, like brace placement; wait and see the discussions about actual
language features to (not) use! Like I said in the other comment, most
features are in themselves completely reasonable, so it's hard to make a cut
here.

I also think the 'mediocre programmer' is a red herring. Not that there aren't
mediocre programmers that will have trouble to understand certain language
features at all - there certainly are.

But I'd wager that even for very good programmers, having many complex
language features (that interact!) in a code base will be problematic. Of
course you can understand what's going on with some effort on your side, but
the problem is with the effort. Programming languages are IMHO a bit like user
interfaces in this regard - "don't make me think". Having code in a code base
that's complex and/or hard to understand is a really, really bad thing. People
will shy away from reading and modifying it, and over time it'll grow into an
unmaintained monstrosity.

Again, this is about the complexity budget. Original Java code was dead easy
to understand, now with generics it's a bit harder (but overall I think
generics are less bad than you hear all the time). That was and still is one
of the really killer Java features. Not only for mediocre programmers, but for
general readability, and thus usability of the language.

~~~
plinkplonk
"Of course you can understand what's going on with some effort on your side,
but the problem is with the effort. Programming languages are IMHO a bit like
user interfaces in this regard - "don't make me think"."

By this logic no one would use the command line and Windows click thru wizards
blow Unix away. I agree that guis are good for non programmers. Java _is_
better than Scala for some subset of programmers. So is VB. The problem arises
when that statement is modified to use the Universal Quantifier.

The thing about a "powerful" programming language though (or for that matter a
command line) is that it is a _power_ tool. No one forces you to use it and
you shouldn't if you feel it is too complex, but using some mythical
"complexity budget" as if it were some kind of inviolable scientific fact is
(imo) bogus. The "complexity budget" of anything is a function of the context
of its use. As cemerick points out in another post here, Scala or Clojure (or
Haskell or Erlang) will always have a "complexity" higher than VB or Java and
_that is fine_.

"Again, this is about the complexity budget."

There is no such thing independent of the intent of the language designer and
the context of the use of the tool. Scala and Erlang and Haskell are _not_
intended to occupy the same "complexity point" as Java 1.4. So what?

Pascal has a lesser "complexity budget" than C. That doesn't make the former
uncontestably "better" independent of context.

And anyway my original point was only that _once_ you choose a language which
you can't grasp all at once, for whatever reason, you should start programming
with the subset you do understand rather than wait till you completely grok
it. You can always choose to work with "low complexity" languages if that is
what you want.

~~~
jimbokun
"As cemerick points out in another post here, Scala or Clojure (or Haskell or
Erlang) will always have a "complexity" higher than VB or Java and that is
fine."

I find the complexity budget of Clojure much lower than Java, and maybe VB,
too (haven't programmed VB in a long time).

In many ways, immutability by default, first class functions, and a library of
higher order functions in the standard API make code much less complex with
fewer concepts to understand than the corresponding Java code would be. The
problem for many coming to Clojure is having to "unlearn" the "object
oriented" Java concepts they already know (true for other functional
languages, too, of course).

Clojure leaves type declarations completely optional. It does not try to
assemble disparate programming paradigms and integrate them into a coherent
whole. The built in data structures all implement the seq interface, so you
can use the same functions on all of them.

Rich Hickey spent his complexity budget very well. I would rank Clojure with
Scheme and Smalltalk in that regard.

~~~
plinkplonk
"I find the complexity budget of Clojure much lower than Java, and maybe VB,
too (haven't programmed VB in a long time)."

I am not disputing that you find Clojure easier than Java but if you include
complete mastery of macros and laziness and functional programming idioms into
the "complexity budget" it is very arguable that _some_ Joe Blow developer
would find Java easier to learn and read and consider Clojure "too complex". I
am just pointing out that they are bogus reasons to reject a language. The OP
is claiming that the deep type theory constructs of Scala are too difficult
for him. Of course they are, just as deep macro fu would be hard for a Clojure
beginner.

Please don't mistake me. I prefer Clojure to Java any day. I am reacting to
the idea that "too many parantheses" or "but macros are too complex" or
"laziness is too hard to wrap my head around" or "Scala has a more powerful
type system than I am used to" or "Erlang has too weird a syntax" etc are
sufficient reasons to reject them.

Back to Clojure. My (original) point is that you don't need to understand
macros (say) in all their glory before you build something in Clojure. Use a
macro-less or macro-lite subset and grow into macros as you gain experience.
Yes you will write less than the best Clojure for a while. (Imho) that is fine
(and unavoidable). _Rejecting_ Clojure because you couldn't completely
understand macros (or read "complex" code with lots of macros) is (imo) not an
optimal strategy.

------
rst
You don't know what Scala code is doing unless you're familiar with the
specific libraries it invokes; syntax isn't much of a guide.

You don't know what Ruby code is doing unless you're familiar with the
specific libraries it invokes; syntax isn't much of a guide.

You don't know what C++ code is doing unless you're familiar with the specific
libraries it invokes; syntax isn't much of a guide.

Heck, you don't know what annotated Java code is doing unless you're familiar
with the build tooling that processes the annotations, and the libraries it
invokes; syntax isn't much of a guide.

There's a pattern here. I'm not sure it has much to do with the language.

~~~
fedd
> You don't know what C++ code is doing unless you're familiar with the
> specific libraries it invokes; syntax isn't much of a guide.

i'd say this about Perl or Ruby, but C++?

~~~
stonemetal
C = A + B;

In C++ what does this line do? The list of things that can effect what this
line of code does are: Types of A,B, and C, single arg constructors, explicit
conversion operators, operator +, operator =, and copy constructors might come
into play. I more than likely have forgotten something from that list.

~~~
VMG
Macros.

------
Nitramp
This is what the Java designers always talk about: languages have a
"complexity budget".

You can choose to spend your complexity budget on different features (static
typing, generics, closures, manual memory management, auto casts, overloaded
operators, ...). Some features can take away complexity (GC). But once you've
overdrawn your budget, the language gets creaky to use and everybody starts
talking about "subsetting" the language. C.f. C++ - all those features do
serve a purpose, and looking at the feature alone, it might be reasonable.

I think Scala has way blown its complexity budget. They've innovated on too
many different fronts. I'd been happy to have Java with closures, first class
functions, and maybe better generics.

There was a lot of buzz around DSLs at some point of time, and they decided to
go all in with implicits, which I think was a bad idea. I guess they were
trying to market the language...

~~~
ominous_prime
I've been digging into scala recently, and although i'd have to agree, I
couldn't say necessarily where this budget was blown. I love that the generics
are improved over java (I usually don't need the IDE to check complex generics
for me in scala as I do in java), but the overall type system can be daunting.
First class function and closures are a easy win for me as well. I also love
some of the more "advanced" functional constructs, and lazy evaluation
(Stream! I love Stream!).

What gets me is the flexibility of the language. I don't want multiple ways to
declare and/or bind the same function, and I don't want multiple ways to
declare a lambda (why do I need a language shortcut, and then a shorter
shortcut to choose from?). I guess where I'm going with this, is that I think
the "complexity budget" would have been manageable, still with most of this
feature set, if the language wasn't a DSL factory, and there was a single
obvious way to write your program (obvious python bias on my part here).

Oh, and while I'm ranting; XML Literals? ಠ_ಠ

~~~
whakojacko
I think basically everyone agrees that XML literals are a bad idea. There is a
little more background described here: <http://www.quora.com/Will-Scala-ever-
remove-XML-literals>

------
cemerick
The disaffection of ex-Java-devs towards these newer JVM languages is only
really surprising if you were expecting any other language to overtake Java
for Java developers. I used to think that would come to pass, but I've been
convinced otherwise.

By the time Java 8 comes around (don't expect Oracle to drag their heels on
releases as prior regimes have), there will be little _inherent_ reason for
the typical Java developer to use Scala or Clojure. Only the biggest vendors
(Oracle, Microsoft, IBM, et al.) have the firepower and perspective to
produce/support whole-solution languages and ecosystems that go mainstream
with tooling, training, and general-purpose facilities approachable for the
vast middle.

That is, the next Java is Java′.

Of course, none of those typical devs are reading this or TFA. The real
question is, which language is most applicable to particular problem domains
and usable within particular organizations by atypical devs solving atypical
problems? (Added bonus goes to the language that makes bidirectional interop
with that vast middle of Java devs a piece of cake, for those atypical devs
looking to provide libraries, tools, and products to be used by those Java
devs.)

~~~
kumarshantanu
Few points I can recollect (without answering "which language is most
applicable...."):

1\. Future of Java-the-language is limited by backward compatibility. This
imposes a barrier on the scope of innovation in the language.

2\. #1 can be helped by the newer JVM languages.

3\. Current trend to increasingly adopt Ruby, Python or PHP for turnaround
time is the result of a momentum and has to mean something. There is clearly
demand for faster turnaround time in some segments.

4\. The JVM languages that can reach feature parity with Ruby/Python/PHP
ecosystem and tooling will have a better chance of adoption IMO.

5\. The next Java is certainly not Java alone. Probably a mix of languages,
depending upon which ones have a better VM, tooling, libraries, turnaround
time etc.

------
joshhart
I program in Scala because it's my pseudocode.

Filter this. Transform that. Collect these. I need an object that does such
and such. I'd like some new functions on an object from another library.

For the most part, Scala has an immediate, direct way to do whatever task I
need in a type-safe manner. The type safety is important - it really does
catch bugs and makes refactoring code a lot easier than in a dynamic language.
This matters when the project is larger than 2 developers.

Some others liken Scala to C++. I don't think Scala is as dangerous as C++
because of immutability and garbage collection, but I'll readily admit it's a
complex language.

You can write Scala as Java with some nice stuff (done at <http://sna-
projects.com/kafka/>, a distributed pub/sub messaging queue) or you can go
full on with the Scala like Norbert (<http://sna-projects.com/norbert/>), an
RPC/cluster management system used for search and the social graph at
LinkedIn. I don't think there's a problem with either.

------
thurn
If you need Eclipse-level tools to be productive, you probably shouldn't be
trying new programming languages. It takes hundreds or thousands of man-years
of effort to replicate those features for a new language. Python and Ruby only
really got there recently.

~~~
pnathan
I've really had to play with enough languages in the last few years that IDEs
are just more trouble than they are worth to me. The editing isn't great, the
tools are sketch, and the design of visual space tends to be poor. And always
being on the tool learning-curve gets old...

So I stick with emacs and my primary IDE-esque tools are syntax highlighting
and hippie-expand. The only time I break out of my emacs world is to run
debuggers.

~~~
zeugma
you should give GUD a try (M-x gdb).

------
nickik
Thats the reason Clojure is so great. Its an simple language. The only complex
things (if you get FP) are the macros and in the clojure world macros aren't
used often. The Clojure Community learnd from the old lisp makro overuse.
Everybody talks about not using makros if you don't really have to. Look at
this talk by C.Grand: (not= DSL macros)<http://clojure.blip.tv/file/4522250/>

If you really want to see what happens with your code just expand it. Its
extremly transparent and easy (most IDEs should be able to to this).

In a talk Simon Peyton-Jones once said something like: "Macros are like
missile. You don't need them often but if you want to destroy a small village
nothing can be better."

~~~
technomancy
> "Macros are like missile. You don't need them often but if you want to
> destroy a small village nothing can be better."

I'm partial to "Macros are like second amendment rights. You hope you never
have to use them, but if you've got no other choice then you will be very glad
you have them."

------
timtadh
I successfully used Scala as prototyping language for the first time recently.
It was nice. I kinda liked it. But, I will have rewrite what I did in it soon
because the VM startup cost for scala is too high for what I want to do. The
lack of IDE support that the OP complained about didn't really bother me as I
am more a vi/kate{+vi mode} kinda guy. That said, I could definitely see how
really good IDE support would be nice to have when integrating with large Java
libraries.

EDIT: I forgot to mention the one thing that is nice about Java from a
research perspective is it is a really easy language to work with. It's syntax
is relatively easy to deal with, it doesn't have a preprocessor. Its semantics
are straight forward. It has type annotations. There is a lot of code in it so
you can test your research on real code bases. This makes Java the best
language to conduct research on languages in. Even if it is not the best
language to write it.

~~~
narrator
JRebel is a must when doing Scala web development. It's not free but it
definitely speeds up the development process as it eliminates almost all
instances where one would have to restart the app server for code changes.

~~~
heiflo
Actually, you can get a free JRebel license for Scala development:
<http://sales.zeroturnaround.com/>

------
fab13n
One of the key design principles behind Java was to be a cleaner C++: remove
all the hippie stuff which make programs too hard to read back, which makes
one thing look like it's something else entirely, etc. The result is a boring
but reliable language, which gave birth to a wide ecosystem of good quality
libraries.

Scala puts back all the hippie stuff into Java. Together with them, it brings
back the associated problems which plagued C++. OK, some stuff are done in a
less broken way in Scala, largely because they don't try to be a superset of
C. But still, we end up with a language hard to read, hard to trust, hard to
support for IDEs... not something you want to use for big teams or long-term
programming.

~~~
fogus
And my natural question is: have you actually used Scala for real work, or are
you just theorizing?

~~~
fab13n
I had to make some evolutions in an Eclipse plug-in which was written in Scala
(the module wasn't intended to manipulate Scala code, it just happened to be
the implementation language). I initially had a positive prejudice, as a OCaml
enthusiast who used to get paid for developping in OCaml; moreover, as someone
who's been exposed to languages with serious abtraction power, I easily get
irritated by Java.

The code was a true pain in the ass to work with: integration with OSGi was
cumbersome, lots of black magic features were used gratuitously, the
possibility to define stuff-which-look-like-methods-yet-aren't-in-the-class
made quite a mess of code exploration, and of course tooling support was
abysmally bad.

I know the usual rebuttal: it's the bad developer's fault, not the language's.
I don't buy this, a "good" language for which you can't find decent coders
isn't any good.

\- Scala-like languages tend to attract guys who will mess with all the quirky
features of the language;

\- In real life, developers are a given and the language is the adjustment
variable, not the other way around. Most people don't have the luxury of only
working with rockstars, and most of the cornerstones of the Internet haven't
been developed by rockstars anyway.

\- The average developer will do an average job of writing maintainable Java,
and an awful job of writing acceptable Scala, if only because there's no
widespread consensus ov what it means for Scala code to be acceptable. Java is
dull and uneventful, and I'd rather take over a syntactically dull and
uneventful code base than an "interesting" one.

\- I've heared several times that "you can use Scala as a Java with closures".
It's a variant of the argument that there's a 5 times smaller language hidden
in C++ that's beautiful: nobody ever agreed over which 20% should be selected.

The two languages which gave me the impression of trying to support every
feature ever invented, and of making it very difficult for people to acquire
and share a notion of standard, maintainable code are C++ and Scala. An iconic
counter-example would be Python.

More anecdotically, I spent a couple of days studying how Lift works, for
personal curiosity. I found the code hard to navigate into. due to too many
non-orthogonal ways of composing code together. A good tooling support would
have helped, but if it doesn't exist after all those years, I might mean that
there's something wrong with the language: it's not as if the need wasn't
clearly perceived.

------
kokoloko
In this same thread Martin Odersky announces he is working in a new version of
the Scala plugin for Eclipse, to be released with Scala 2.9. A statically
typed language really shines within an IDE.

------
bad_user
I get this sentiment a lot ...

    
    
         Secondly, it is the ultimate language to date for writing libraries 
         and  embedded DSL’s with static types. ... These abilities go 
         way beyond any prior statically typed language.
    

The author conveniently left out dynamic languages; but regardless of that, I
don't like Scala because:

1) you can't override the method dispatching mechanism to make use of those
types in interesting ways (e.g. multimethods are possible with DLR in .NET)

2) You can't get the syntax-tree of a block of code, then recompile it to
something else (e.g. LINQ - and F# supports this as a general construct).
There was a compiler-plugin at some point, but it's deprecated and incomplete
and full of bugs

3) All OOP languages should have optional dynamic typing; OOP just doesn't
blend with static types, being one reason why Haskell is not OOP (while
providing other similar tools for polymorphism)

What you do get in Scala is a flexible syntax, that can lead to awkward
behavior (I often find myself asking whether some line needs a semicolon). And
the type-system, while better than the one in Java, is also too complex, too
verbose and definitely not elegant.

You know what would be elegant? Being able to test if some object is an
instance of List[String] (and yes, I know about manifests and implicit
parameters: it's still an ugly hack that doesn't solve all problems).

One could say that Scala is a pragmatic language, but so is C++; and C++ has
no replacement, while Scala does have many.

------
meowzero
I've been doing my scala stuff using sbt and vim. So far, it's working out
quite nicely. I haven't played with sbt plugins for various IDEs (I'm too used
to vim), I would assume it should still work.

------
dochtman
I did some research (but not actual programming) to compare Java to Scala,
specifically in the area of generics. If you are hoping for some language to
make static typing palatable again, Scala is not it: it's so good at static
typing that it can statically type anything, but it takes intricate details
and more knowledge of its type system than most would want to care about to
get it right. In general, I felt there were too many niggly little details in
the syntax to be a nice language to use.

Of course, I'm used to Python, so I may well be spoiled.

~~~
jfager
I agree with the characterization of Scala's generics as complicated, but I
disagree that that ends up making its static typing unpleasant or day-to-day
programming difficult. Type inference is a big win, and other language
features add enough that I find myself not reaching for generics for my own
code anywhere near as often as I did with Java. Aside from the occasional
container type missing from the standard API, I just pretty much don't use
generics in Scala except as a consumer, and I don't miss them.

------
dan00
Scala seems to be the academic kitchen sink of programming languages.

------
brendano
This exactly summarizes why I stopped using Scala. All I wanted was a cleaned
up Java, but it's much more and riskier than that.

~~~
ehsanul
Maybe you'd like Mirah?

<http://www.mirah.org/>

------
Peaker
I never understood why anyone would want a hybrid of OO and functional
programming.

I see OO as basically: Encapsulation, Inheritance and Polymorphism.

Functional programming provides better facilities for encapsulation and
polymorphism. Interface inheritance is pretty much a subset of implicit traits
or type-classes. I don't think implementation inheritance is ever the right
thing.

So if you have the full power of FP (including existential types and type-
classes), what is it in OO that you would yearn for?

------
mryall
Groovy is good alternative JVM language if you just want some improvements on
Java without a completely new language to learn. It addresses many of the
small frustrations I have with Java (lack of list and map literals, lack of
anonymous functions) without introducing many new paradigms or complexities.
I'd recommend it to anyone wanting a quick prototyping language on the JVM.

------
lsd5you
Scala subsetting (as mentioned in the comments) sounds like a promising
avenue. Especially if it were to result in better performing tools.
Unfortunately for all the great features scala does have, Java has a few
killer features that it lacks i.e. fast (instantaneous) and reliable
compilation and debugging.

