"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.

Here is the Java version:

  public boolean domainExists(String domain) {
    return Option.of((Domain) HibernateUtil.getSession().getNamedQuery("domain.findByName").setParameter("name", domain.trim().toLowerCase()).uniqueResult()).getOrElse(new Domain()).id > 0;
  }

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#.

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

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 :)

"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."

Sorry, but that's the most ass-backwards point I've heard. The language provides too much power and flexibility, and you want to be locked into one specific format, syntax, and the subsequent reinventing-the-wheel nightmare that causes most projects to go horribly over time, budget, and stress levels?

Um, I think you might be over-attributing language features to project failure, there.

The language subsetting issue is a huge problem, c.f. C++. The complexity of Scala makes it very difficult to understand a lot of library code, even if you're quite competent in it. To keep code for a large code base manageable and understandable, most companies will end up defining the "allowed Scala" in a coding standard. This is a failure of the language, IMO.

Unfortunately I think you're right that Scala is too complex to displace Java. If you're looking for a functional language you can use to to real work though, Scala is just the ticket and it's really not that complex once you start using it. None of the above-average programmers I've worked with would have any trouble picking it up with a little motivation.

Personally I find myself much more productive in Scala for anything non-trivial than in any other language.

You basically described Scala. The only difference is that it does have generics, and the dynamic invocation is currently experimental.

I was going to say the same thing. I've been using Scala as a "better Java" for a while now, and the argument that Scala is too complex is kind of baffling.

Take your Java code, remove almost all the type info, and add some nice syntactic sugar for singletons. That's beginner Scala, and it's already worth using. The rest of the language is just gravy.

> 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.

Ahem. http://groovy.codehaus.org/

The #1 feature of Groovy in my mind is that there is almost no learning curve whatsoever. All Java code is already Groovy code - you can learn all the dynamic tricks as you go.

All Java is also a valid subset of Scala, IIRC.

Not true if you mean that their syntaxes are compatible, they are quite different.

Maybe I was thinking of Groovy.

Sorry, commenting before morning coffee :)

Scala introduces new versions of collections like Map and List that aren't compatible with Java's versions. The syntactic sugar only works with the Scala Maps.

Meanwhile, Groovy uses Java collections.

Luckily, in Scala there's a JavaConversions package that allows you to cast back and forth from Maps, Lists, Sets, etc, to whatever Scala type you want.

http://www.scala-lang.org/api/current/scala/collection/JavaC...

Damn, I wish I'd known about this sooner. Thanks!

You forgot "fast". The perfect Java replacement would also have to be as fast as Java. Groovy, Jython, allow you to program on the JVM more easily, but unfortunately run much slower than Java. One major benefit of Scala is that it runs at pretty much the same speed as Java.

Groovy is pretty fast with Groovy++

Not just pretty fast--it completely closes the performance gap between Groovy and Java.

http://code.google.com/p/groovypptest/wiki/Performance

I forgot about Groovy++.

See Fantom - http://fantom.org/

And it has same performance as Java

And that language (mod unlimited operator overloading, but allowing things like comparison operators to work on comparable objects, and having simplified generics rather than no generics) is... Gosu: http://gosu-lang.org

all we need is C# 4.0 running on JVM. And instead of no generics, substitute generics implemented as they are on the CLR. Done! no incoherent Scala to learn. I have no complaints about C# except that it exists on MS island, instead of running on JVM in the Java ecosystem. As language, I cannot complain about C#. I have found clojure to be very easy to learn and use recently, but I must honestly admit that if it didn't exist I would never have noticed if C# were on the JVM.

I can complain about C#. The type inference is artificially limited which forces you to write types everywhere. There is no way to define an interface on types which are not under your control. Generics are missing a number of features that would be extremely useful, like defining a parameterized type with a constraint on the parameter type's constructor. Metaprogramming is limited to treating lambdas as expression trees and has no syntactic sugar. There is no facility for destructuring function arguments or doing pattern matching. Events and properties are not first-class constructs that can be passed around, which limits composability. Tuples have no syntactic sugar associated with them so they look super ugly. Et cetera, et cetera, et cetera.

It severely beats Java, but it falls pretty far short of Clojure, in my opinion.

"It severely beats Java, but it falls pretty far short of Clojure, in my opinion."

agreed!

So Jython, got it.