

The Next Big JVM Language - thebootstrapper
http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1

======
knowtheory
> At JavaOne on Monday I spoke on the topic of "The Next Big JVM Language". My
> conclusion wasn't what I expected it to be when I started researching the
> topic. Read on to find my conclusion...

That seems ironic given the conclusion of the post. The reasons for rejection
of Clojure and Scala are respectively "Clojure is too different fom Java", and
"Scala is too powerful".

It's almost comical how well this encapsulates Blub programming
(<http://c2.com/cgi/wiki?BlubParadox> ). or more to the point, assumptions
about blub programmers by the author, who clearly at least understands
programming languages.

The thing about this is, I don't see why we have to replace Java. The power of
the JVM is that there need not be One True Language To Rule Them All.

Let people program in Clojure or Scala or JavaScript or Ruby. Design sensible
interfaces for data interchange, and let people get on with their lives (and
promote Polyglotism!).

Searching for the Next Big JVM Language is like searching for the next
Facebook. Sure there are going to be new popular entrants, but the ecosystem
is such that there will never be another Java, just the same way there won't
be another Facebook.

Change is hard, and it challenges lazy thinking in blog posts like this.

~~~
pragmatic
The question is, how much do you gain from this power or difference? That's
the real challenge of language design, not what you put in, but what you keep
out.

------
lemming
"If you're still using or advocating checked exceptions, then I'm afraid your
skill set is 5 to 10 years out of date."

Josh Bloch must be devastated.

"Code in static methods is inherently less reusable and accessible than code
in objects."

I'm really not sure this is true. Since I've started programming in functional
languages more I find myself using static methods more and more - my code
seems to be perfectly reusable. I still use objects where they make sense, of
course, but using singleton objects instead of static methods is insane.

The idea of a Java 3 (with corresponding new JVM) is an interesting one,
though. It really shouldn't be that hard to create an automatic conversion
tool since the semantics are formally specified. However I suspect that unlike
what most Java programmers would like to think, most of the decisions around
the Java language really aren't made with programmer comfort in mind - things
like backwards compatibility and tool support have historically been much more
important.

~~~
m0th87
Why are singletons worse than static methods?

~~~
Tichy
Because they have a state, I would suppose. My memory is actually foggy on why
Singletons are bad. I guess they make it hard to make the app distributable,
and they are generally error prone? Like how to make sure there really is only
one of them.

~~~
barrkel
Static fields are also state. Singletons have a bad rep in C++-land and
similar because they have initialization problems - static initialization is a
PITA with C-oriented linkers.

A lot of the problem here is branding. Schemes that are isomorphic with one
another, and called singletons in one language and modules in another, are
respectively reviled and lauded, sometimes by the same people.

~~~
Tichy
The question was about static methods, though.

~~~
barrkel
It's my position that the question "why are singletons worse than static
methods" is ill-formed and implies a dichotomy where there need not be one.
Static methods are already instance methods on an implied singleton, whose
state consists of static state; except this singleton doesn't have an identity
and isn't a value that you can pass around, and so isn't composable, isn't
first-class.

~~~
Tichy
Sure, in that sense it is the same. I was thinking about methods without side
effects. Then it wouldn't matter if they exist in several instances, I
suppose.

------
mark_l_watson
I have been using Java since the early beta releases and I have written a few
books on Java. That said, I don't use the language very much anymore,
preferring Clojure and JRuby wrappers for useful Java libraries, and sometimes
Scala (really a nice language!)

I know it is bad form, but when I do still use Java for my own work, I have
started making it look a bit like Ruby by using public instance variables (no
getters/setters). Also, by not using checked exceptions and heavy use of
generics I can keep code fairly concise.

~~~
cageface
I've had similar experiences. Java is a clumsy language but it doesn't have to
be absolutely terrible if you set aside some of the conventions.

------
jhrobert
I would suggest the next big JVM Language should be a blend of JavaScript and
Java where one would provide optimization hints to a javascript program using
element of java syntax.

Strong typing should be viewed as an optimization, either to optimize code's
correctness or to optimize code's speed.

If you add CoffeeScript on top of that... whoa!

~~~
m0th87
It's also about better IDE facilities. I mostly use Python now, but boy do I
miss solid autocompletion and refactoring.

~~~
barrkel
Unfortunately, providing solid autocompletion for dynamic languages implies
solving the halting problem.

~~~
mahmud
How so? you just need reflection. Slime does it for Common Lisp and it doesn't
break a sweat, that is, without using any advanced MOP stuff.

~~~
barrkel
Reflection implies that you're running the code at code editing time,
otherwise there's nothing to reflect over. That, in turn, opens up a huge can
of worms for a large class of applications which aren't easily editable in
what effectively is a debug session.

Just to be clear, this is what I mean when I talk about autocompletion (cursor
is |):

    
    
        def foo(bar):
            bar.|
    

In order to complete on bar, you need to know the symbols available on the
potential runtime values of bar. Everything can be in a system image, and you
still don't know what gets through to foo() unless you either symbolically or
actually evaluate the code and have a semantic breakpoint at the start of
foo().

~~~
mahmud
Reflection doesn't mean "you're running the code at editing time". I hope
we're not confusing Java reflection with Eclipse's aggressive compilation of
things as you type.

As per your specific example, I think the reason SLIME works is because Common
Lisp uses generic functions, instead of class methods. The calls are not
Object.Method() rather Method(Object:Class) so Metho| always resolves.

However, I will grant you this: automatic class loading will easily trip up
SLIME and similar tools.

Hmmm, I am gonna need to think about this further.

~~~
barrkel
I have no idea what Eclipse does as you type; I don't normally use Eclipse. I
am, however, employed to maintain a static language compiler which is used by
its IDE for code completion (Delphi in RAD Studio). I also implemented the
runtime reflection object model (Rtti unit) used in the latest versions of
Delphi.

By reflection, I'm talking about interrogating _runtime_ objects to see what's
available on them. They need to be runtime objects because of monkeypatching
and similar techniques. Because they're runtime objects, in some sense the
code needs to be run in order to interrogate the objects. That execution may
be symbolic, but that symbolic evaluation hits the halting problem, because
it's normally a Turing-equivalent machine which determines how the objects
will get constructed.

------
thomas11
The author focuses on the removal of features from Java, like generics and
method overloading (!). His polemics about complex features ("Scala [...]
quickly bites your head off") are unnecessary.

But from a hacker's point of view, Java is not expressive enough. Do we need
to accept a dumber mainstream language for "the masses", or can we advance the
state of the art by moving most developers to more expressive languages?

------
pragmatic
From the conclusion of this article, porting C# to the JVM would be the best
"new" Java language.

C# borrowed heavily at the beginning, seems like Java should return the favor.

------
barnaby
I work with groovy in my day job, and I have to say that it _is_ the NBL on
the JVM. It has:

* ease of adoption from existing Java developers because it's a superset of the java langauge

* the enterprise capability (which the author mistakenly dismissed it for) thanks to groovy++

* finally, if you were to change Java the way the author suggested for Java 8 and 9, then it would end up looking like Groovy anyway. So DRY and just adopt Groovy as the NBL and leave Java to be backwards compatible.

~~~
cageface
I wish you were wrong about this but I think you're probably right. I'd much
rather see a more carefully designed and powerful language like Clojure or
Scala succeed but the blubbiness of Groovy will probably win out.

------
cageface
The people that dimiss Scala as too complicated almost never seem to have
actually tried it. Scala can look scary on paper but it's really not hard at
all once you start real coding in it.

~~~
Dn_Ab
Im learning Scala and the part that is currently tripping me up the most is
the syntax around its OOP. Basically getting your head around all the ways
_that are not quite orthogonal_ to do the same thing is the big hurdle for me.

    
    
        def method(a:'type,...) {}
        def method(a:'type,...) = <expression>
        def method(a:'type,...) : type = {}
    

Undoubtedly due to my ignorance and I do see the usefulness in each version
but why so many ways? And the sugar that makes constructors so nice are a
headache with tags and java library interop. I kinda prefer the F# middle
ground on how it does constructors like that.

And there are some other things to do with interop with Java - mainly varargs
ive come up against tbh. I am sure I will have more trip ups as I learn.
Otherwise I am very happy that a functional language like this exists on the
JVM.

~~~
cageface
TBH I think Scala has gone a little _too_ far in its syntactic flexibility,
and the variety of syntaxes for declaring a method is a good example of this.
The constructor shortcut can also be a bit of a pain on more complex examples.

On the whole though, I'm finding Scala coding a very pleasant experience. A
solid FP language on the JVM is turning out to be a very powerful tool.

------
dochtman
I still want my operator overloading back. Oh yeah, and something better than
explicit getters and setters.

------
10ren
Mirah is arguably what he suggests: an attempt to redo java - though with
Ruby-like syntax, so it wouldn't be particularly adoptable by the hoards of
Java developers <http://www.mirah.org/>

But the alternative, of re-doing Java using the existing syntax with slightly
different semantics, has serious dangers.

------
Rickasaurus
This is one of those rare occasions when I wish I could actively vote down an
article. Seems more like a "get off my lawn" post than anything. Also, his
reasons for disliking Scala are completely arbitrary.

------
javanix
_Another possible definition that 15% of the developers in the world are using
that language at a point in time. Based on these, I listed C, C++, Java, C#,
COBOL, VB, Perl, PHP and Javascript as Big Languages._

As an aside, are Perl and PHP in wide enough use to really support that 15%
figure? Just curious - if I were making that list based on my own perceptions
and experience I would leave those two and possibly COBOL off of it.

~~~
chromatic
Based on the statistics I've seen, yes.

------
allertonm
I've been wondering why Fan/Fantom has not had more traction, I rather like
the pragmatism that seems to have guided its design.

Is it just not exciting enough?

