Monday 6 July 2009

Scala as the long term replacement for java/javac?

Don't get me wrong - I've written tons of Java over the last decade or so & think its been a great evolutionary step from C++ and Smalltalk (lots of other languages have helped too like JavaScript, Ruby, Groovy, Python etc). However I've long wanted a long term replacement to javac. I even created a language to scratch this itch.

Java is a surprisingly complex language (the spec is 600 pages and does anyone really grok generics in Java?), with its autoboxing (and lovely NPE's hiding in there), primitive types, icky arrays which are not collections & general lack of polymorphism across strings/text/buffers/collections/arrays along with extremely verbose syntax for working with any kind of data structure & bean properties and still no closures (even in JDK7) which leads to tons of icky try/catch/finally crapola unless you use frameworks with new custom APIs & yet more complexity. Java even has type inference, it just refuses to use it to let us save any typing/reading.

This issue becomes even more pressing with there being no Java7 (which is even more relevant after Snorcle - I wonder if javac is gonna be replaced with jdkc? :). So I guess javac has kinda reached its pinacle; closures look unlikely as does any kind of simplification or progression.

So whats gonna be the long term replacement for javac? Certainly the dynamic languages like Ruby, Groovy, Python, JavaScript have been getting very popular the last few years - lots of folks like them.

Though my tip though for the long term replacement of javac is Scala. I'm very impressed with it! I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

So why Scala? Scala is statically typed and compiles down to the same fast bytecode as Java so its usually about as fast as Java (sometimes a little faster sometimes a little slower). e.g. compare how well Scala does in some benchmarks with groovy or jruby. Or this. Note speed isn't everything - there are times when you might want to trade code thats 10x slower for more productivity and conciseness; but for a long term replacement for javac speed is important.

Yet Scala has type inference - so its typically as concise as Ruby/Groovy but that everything has static types. This is a good thing; it makes code comprehension, navigation & documentation much simpler. Any token/method/symbol you can click on to navigate to the actual implementation code & documentation. No wacky monkey patching involved, or doubting of who added a method, when and how - which is great for large projects with lots of folks working on the same code over long periods of time. Scala seems to hit the perfect sweet spot between the consise feel of a dynamic language, while actually being completely statically typed. So I never have to remember the magic methods that are available - or run a script in a shell then inspect the object to see what it really looks like - the IDE/compiler just knows while you edit.

Scala has high order functions and closure support along with sequence comprehensions so you can write beautifully concise code. Scala also unifies functional and OO paradigms beautifully together into a language thats considerably simpler than Java (though the type system is of a similar order to truly understand than generics - but then thats usually an issue for framework creators rather than application code developers). It also lets folks gradually migrate from a traiditional OO/Java way of coding to a more functional way - which is particularly relevant for folks writing concurrent or asynchronous code (which due to the GHz of chips no longer going up but instead we're getting more cores is becoming more necessary). You can start the OO way and migrate to using immutable state if/when you need its benefits. Increasingly functional programming is becoming more and more important as we try and make things more concise and higher level (e.g. closures, higher order functions, pattern matching, monads etc) as well as dealing with concurrency and asynchrony via immutable state etc.

Scala also has proper mixins (traits) so you don't have to muck about with AOP wackiness to get nice modular code. There's even structural types in case you really do need some duck typing.

The thing which most impresses me is the core language syntax is pretty small and simple (the spec is about a quarter the size of Java's); but its way more powerful and flexible and is very easy to extend in libraries to add new semantics and features. For example see the Scala Actors. So its ideal for creating either embedded DSLs or external DSLs. There's really no need to have Java , XPath, XSLT, XQuery, JSP, JSTL, EL and SQL - you can just use Scala with some DSLs here and there (examples of this later...).

Scala does take a little bit of getting used to - I confess the first few times I looked at Scala it wasn't that pleasing on the eye - with Java you're kinda used to dumb verbose code which doesn't do very much - it can be quite a shock to see quite a few symbols at first. (It took me a while to get over the use of _ in scala which is the 'wildcard' symbol since * is an identifier/method).

If you've been doing lots of Java then Scala does feel quite different at first - (e.g. the order of types & identifiers in method/variable/parameter declarations - though the reason for that is to make it easy to miss out redundant type information).

e.g. in Java
List<String> list = new ArrayList<String>()
in Scala
val list = new List[String]
or if you want to specify exact typing
val list : List[String] = new List[String]
However if you keep at it, the beauty of Scala soon becomes apparent; its simplified so many of the gremlins in the Java language, allows you to write very concise code describing the intent behind the code rather than the implementation cruft - together with providing a nice migration path to elegant functional programming which is awesome for building concurrent or distributed software.

I highly recommend you take a look at Scala - with an open mind - and see if (once you're brain adjusts) you can see its beauty too.

Some scala links and online presentations
If you have a spare hour or so these video talks are great to watch
Handy Scala frameworks and libraries
  • liftweb the rails of scala
  • specs and ScalaTest for BDD and more literate testing showing how a typesafe DSL can help you write more consise and expressive code that is very IDE friendly
  • scalaz a handy library of utilities
  • dispatch for working with HTTP/JSON services
BTW for those like me who love JAXRS you can now use lift templates with Jersey via the new jersey-lift module.

As an example of this in action you can check out RestMQ which is an open source project I've been working on lately to provide a RESTful API and web console to message orientated middleware which is built on JAXRS (Jersey), Scala and Lift.

From a tooling perspective there's Ant/Maven plugins, an interactive Scala console (REPL) and IDE plugins for IDEA, Eclipse, NetBeans along with the usual editors (TextMate/Emacs etc). The IDE plugins are not yet up to the Java grade, but they are very useful with good code navigation & completion.

I've tried the plugins for NetBeans, Eclipse and IDEA they all have strengths and weaknesses; it seems Scala folks are split between them all. For code navigation and completion along with maven support I've found IDEA to be quite good. When you open a Maven pom.xml it seems to grok the code nicely, finding the scala source so you can navigate through any type/method to see its documentation/source etc. (You do typically have to manually add the Scala facet to run/debug stuff). Though IDEA is not always the best at highlighting syntax errors as you type. They could all use some work to bring them up to line with their Java counterparts though - try them out and see which you prefer.

Scala nits
With any language there's gonna be bits you love and bits you're not so keen on. Early impressions of Scala do seem like there's a bit of an attempt to use a few too many symbols :-; but you don't have to use them all - you can stick to the Java-ish OO side of the fence if you like. But then I guess longer term its probably better to use symbols for the 'special stuff' to avoid clashing with identifiers etc.

I'm not a massive fan of the nested import statement, using _root_.java.util.List to differentiate a 'global' import from a relative import. I'd have preferred a child prefix. e.g. if you have imported com.acme.cheese.model.Foo then to import model.impl.FooImpl i'd prefer an explicit relative prefix, say: import _.impl.FooImpl which would simplify things a little and more in keeping with Scala's attempt at simplifying things and removing cruft (being polymorphic to import java.util._).

However compared to all the massive hairy warts in Java, these downsides of Scala are tiny compared to the beauty, simplicity and power of Scala.

Conclusion
Given that MrJava, MrJRuby and MrGroovy are all tipping Scala as javac's long term replacement, there might be something in it. So what are you waiting for; get the Programming in Scala book or the O'Reilly Scala book and start having fun :)

120 comments:

Alan said...

One of my favorite parts of developing in Scala has been use of simple build too, an awesome piece of software in Scala that does dependency handling, compiling, and the usual Ant/Maven tasks for Scala projects in an XML-free way.

Unknown said...

I'd be interested to see what you think about fandev.org as well. It has many of the things that you seem happy to see in scala (though I don't really know scala so I can't really compare the two). I'm a long time java dev'er who's looking around for something more ... interesting to work with and right now that's fan for me. Though your comments on scala certainly elevate that as a possibility as well. So, have you looked at fan at all? I'm not trying pimp it or persuade you. I honestly just looking for your thoughts on it since you're a language guy and i'm really not.

James Strachan said...

I think fan is pretty good language too btw; though worry about its focus of being .Net / Java agnostic. Also its static and dynamic typing approach actually mirrors what Groovy does. I kinda prefer the static typing approach really; and generics/operator overloading are very handy in Scala.

Finally the support for functional programming and immutable state seems way more pervasive in Scala than just adding closures like fan/groovy.

Jeff said...

I don't think there needs to be one replacement for Java on the JVM. It's pretty cool that a family of languages can be used on the same underlying VM; different strokes for different folks.

Have you tried Clojure? It's at the other end of the typing scale (dynamically typed), but it's interesting because of macros + the concurrency capabilities (STM).

James Strachan said...

I love how there is a plethora of choice for languages on the JVM of all shapes and sizes. I'm not trying to argue there should be just one language for the JVM.

But given (i) java 7 is no more, there is no spec only openjdk7 and that (ii) javac is now effectively in maintenance mode my blog post was musing what should be the long term replacement for javac (since its not going to change much now and it keeps falling further and further behind C# etc).

Anonymous said...

I share your point of view. When it comes to Java integration, I've done a few tests myself, and Scala was the language that more impressed me. Cheers.

Matt Watson said...

I agree! You've inspired me to quickly write some of my thoughts. I went to the Scala Lift Off after JavaONE: the excitement and creativity of the people there was obvious - Scala/FP can open you up to new ways of thinking and programming.

The plethora of languages on the JVM is fantastic, but I'll be writing as much new code as I can in Scala.

Donny said...

You might want to check out C#.
It solves a lot of your problems you had with Java. If your not a microsoft fan then use Mono which is an open source version of .NET.

R. Mark Volkmann said...

I see this sort of apology for language features quite often.

"Early impressions of Scala do seem like there's a bit of an attempt to use a few too many symbols :-; but you don't have to use them all"

This always raises my ire because while you don't have to *use* them all, you DO have to *understand* them all because other people with use them all and you will have to read their code!

Steve said...

@Donny
Actually, the comparable language on .Net is not C#, but rather F#. Having said that though, I'd take Scala over F# any day for the following reasons:

1) In the F# culture, OO just doesn't seem to be that important. In all the books, there is the obligatory chapter on classes, and then the rest is all focused strictly on functions. Contrast this with Scala where Odersky didn't just offer the same mechanisms as Java, but went above and beyond with things like object types, traits, enhanced visibility rules, etc. Scala makes a guy like me who's been thinking and coding in OO for decades very comfortable, while offering functional features that I can take advantage of to make my code as concise as possible.

2) F# is much more a HM language than Scala, and on the surface this seems a good thing. Unfortunately, because one rarely ever needs to write type annotations, many of the code examples one can find don't, which makes the code more difficult to read and reason about. At least in Scala one has to declare parameter types and it is strongly encouraged that method return types are declared as well in all but the most obvious cases.

3) F# tries to be as close in syntax to OCAML as possible, and so syntactically it really isn't innovative. Scala on the other hand feels like a synthesis of some of the best things learned from other languages. Additionally, it feels like there are mechanisms that were included not because they were necessary, but because they might help the developer better express intent. Martin gets huge props from me for having taken the trouble to add things like implicit conversions, extractors, etc.

4) Scala is in my opinion an easier sell to Java coders than is F# to C# coders. The reason for this is that by and large, a Java coder doesn't have to start by drinking the declarative kool-aid - Scala can simply be used as a Java with less boilerplate. As the programmers skills mature, functional programming concepts can be increasingly exploited. I don't see the same progression in any other OO/functional language out there.

James Strachan said...

@R. Mark Volkmann in Scala symbols are typically just method calls (apart from _ which is one of the few special symbols) there's nothing to 'understand' per se - its just an abbreviation of using method names.

So I don't think its a language smell; its more something you just have to get used to when joining the scala community; that different domains/libraries within the scala community make use of some symbols to aid readability. e.g. using :: for cons in functional stuff, or ! for send in actor stuff) which is really aimed at the well known sub domain (functional programming or actors or whatever).

kaosjester said...

Just a few questions in response to your post:

0) Why is it so important that we move away from java now that we're at java6 forever? You complain about the length of the spec, but then bemoan the lack of new features coming along. Why do we need to give Java up?

1) What do you have against arrays? I know that lists work 'nicely', but seriously, the array data structure describes not only data storage, but a memory layout that may be read from in O(1) time. With a list, you are never assured of that. So what's the deal?

2) Generics in Java are sort of like templates in C++, with the exception that they don't get inferred at compile time. Scala does the same thing, with inferred typing, but it doesn't give the programmer any control over exactly how. For example, whenever I write a KD tree, I make it generic on a variable T extends TreePoint, where TreePoint is an interface that provides a getVal(int axis) function. This lets me build a whole spatial tree of generic types that will assuredly work with any class that implements TreePoint. What if I wanted such a data structure in Scala? Would I have to make TreePoint an -object- and extend it from other objects? Does Scala even support inheritance? What about interfaces?

3) You praise Scala as being more elegant. I'd like your take on something.

Here's printing even numbers in Java:
even(int max) {
for(int i = 0; i < max; i++) {
if (i % 2 == 0) System.out.print(i + " ");
}
}

Here it is in Scala:
def even(to: Int): List[Int] =
for (i <- List.range(0, to) if i % 2 == 0) yield i
Console.println(even(0, 20))

That just seems cumbersome to me. I don't know. Also, in the Scala example the code structure is somewhat unclear. How does it help with code complexity and conciseness to use non-standard for loop styles? What does it contribute to writing code?

4) Since it's a scripted language, lines don't use ';' but '\n' to end, and thus we again lose the war to the whitespace delimiter. I know that Ruby, Python, etc., are all cool languages because they don't make you denote the end of a line with a real symbol, but doesn't that bother you? In fact, this bothered the Scala people enough that they allow things like:
val t = a(i); a(i) = a(j); a(j) = t

5) You call out the Java spec for being over 600 pages, and then proceed to talk about additional libraries available for Scala that allow similar functionality. However, the reason the Java spec is so long is partly because it describes a lot of these libraries as 1st-party libraries, to ensure interactivity and consistency across all versions of Java. What does Scala do to ensure that interactivity is preserved when using these after-thought libraries?

6) You say Java is icky for primitive typing. How so? What does Scala do to correct this problem?

7) You are aware that JavaScript can't be used to develop desktop applications, right? Like, it is in no way a comparable replacement for Java, Python, Ruby, etc.

8) A little note about Java polymorhism with strings: every object in Java has a toString method, and every class you write can provide its own toString method (simply define it in the class with an @Override). That being said, you can tell Java exactly how you want to print any object you might ever try to print. What happens when you try to print a non-primitive type in Scala?

Just some thoughts. Scala seems powerful enough (though my FPs of choice are J / Scheme), but it seems like a lot of the complaints you raise about Java are carried over to Scala without much addressing. We're still using a VM, with VM memory, bytecode compiled at runtime, and variable typing. This post isn't meant as a flame, but a series of questions raised in my mind from your post.

James Iry said...

Just a technical note. It looks like angle brackets got eaten in the line "List list = new ArrayList()."

When using Java libraries from Scala you can cut down on some boilerplate by dropping unneeded parens

import java.util.ArrayList
val list = new ArrayList[String]

or, if you want to type it as just a List[String] then

import java.util.{List, ArrayList}
val list : List[String] = new ArrayList

Note the lack of type parameter on ArrayList.

James Strachan said...

0) javac is past its sell by date. Can we not move onto a vastly improved language? You don't have to move if you don't want to. Folks still hack COBOL today BTW :)

1) for one, arrays are not a Collection; they don't implement Iterable<T>. (FWIW List and Arrays in Scala support iteration and natural index operations like myArray(5)).

2) I'm not 100% sure I follow this point but it might be worth reading up on how Scala supports abstract types for things like this.

3) I don't follow; the scala code defines a lazy collection that can be iterated over whenever (very handy!) - the Java does an iteration. You're not comparing apples to oranges. You also miss out a huge amount of power in Scala's for comprehensions.
http://www.scala-lang.org/node/111

which can avoid heaps of ugly nested for loops.

4) scala is as scripted as Javac. I like the optional ; rule which is common in JavaScript, Ruby, Groovy as well.

5) Scala is a much simpler - yet massively more powerful language. The trick with elegant design is how to remove as much as you can but still give folks enough power.

6) in Java there are so many gremlins in there to do with primitive types, autoboxing and arrays for example.

7) Huh? How is JavaScript the language any better/worse than Java/Ruby the language. e.g. you can do most things in Rhino on the JVM.

8) In Scala everything is an object.

In summary; I love the JVM and its platform & ton of libraries. I'm just over the javac compiler that makes the bytecodes and think Scala is a massive improvement

James Strachan said...

@The Kaos Jester

BTW I really recommend reading one of the 2 Programming Scala books I mention on the blog post - with an open mind.

Pretty much all the icky bits of Java are nicely resolved in Scala (I'd forgotten how many icky bits of the Java language there were until I read these books); plus it opens your eyes to a lovely new world where object orientated and functional programming are united together in a clean way.

So Scala is not just a better Java; its a unification of OO and functional languages - all in a simpler & more elegant language than Java - which mostly compiles to bytecode which is about as efficient (sometimes a little bit more sometimes a little bit less).

Cedric said...

Sorry James, but I really don't think the Java community is ready for something as complex as Scala. Because it *is* complex, despite what you think. Besides, I think that language designers such as yourself are paradoxically too knowledgeable in the area to make an educated judgment (didn't you list "monads" as a plus? Think about this for a while...).

In many ways, I have this impression that Scala is to Java what C++ is to C: very feature rich and using the excuse that "you don't have to use all the bells and whistles", while in practice, these bells and whistles contribute greatly to code complexity. Take a look at the code snippets that are posted on the Scala mailing-list every day to see what I mean: it's like Java generics times ten.

Just like you, I am regularly annoyed at the verbosity of Java, and while I would love to see the right combination of type inference + static typing in Java, I'm reasonably happy with compromises such as "List<String> l = Lists.newArrayList()", which already performs a lot of type inference for me.

I bet that in five years, Java will still be the predominant JVM language and that a small but vocal community of people will still be claiming that Scala is a better replacement.

From a purely design perspective, Fan has better odds of attracting the community of Java programmers because it hasn't crossed the complexity threshold like Scala has, but 1) the .Net compatibility concerns me because it might cripple the language in odd ways and 2) I'm afraid that Andy and Frank are not focusing their IDE efforts properly.

James Iry said...

@Kaos,

0) Because we're writing ever more complex software and need tools to help manage the complexity. Functional programming is one such tool, DSLs are another, etc.

1) I happen to think arrays are a fine imperative data structure. But in Java they're too special. They're inappropriately covariant and semi-primitive. In Scala they are properly invariant and not so different from other types.

2) If you can express a generic structure in Java then you can express it in Scala. You can also deal with some of the kinds of things you would do with templates in C++ by using implicits in Scala.

3) If you want to just print even numbers in Scala then

def even(max : Int) {for (i <- 0 to max) if (i % 2 == 0) println(i)}

The version you gave, though, is more "elegant" in that it returns a list of evens that can be used for many purposes other than just printing. Still I would write it as

def even(max : Int) = for (i <- 0 to max if i % 2 == 0) yield i

or, better yet, define an infinite stream of evens and let the recipient lazily filter on max

val evens = Stream from 0 filter (_ % 2 == 0)
def even(max : Int) = evens takeWhile (_ <= max)

4) I have no idea why you think the optional semicolons makes Scala more of a scripting language. Haskell makes semicolons optional but it's hard to call it a scripting language.

5) The Java Language Specification does not describe libraries. James was talking about the JLS.

6) Scala doesn't have primitive types. For instance, it has a top type that is a supertype of even the primitives. It allows "primitive" types as type parameters so that you can have a List[Int]. That's quite different from Java's strange dichotomy between primitive and non-primitive types. Yet, in spite of erasing this distinction, Scala doesn't generally box primitives except when needed.

7) JavaScript can be used to develop desktop applications. See for instance Rhino as a JavaScript environment with access to the Java world.

8) scala> println(7.toString)
7

Some thoughts: J and Scheme are radically different languages, it's hard to see how you can put a / between them. I have no idea what "variable typing" means. Scala is statically typed, which means every expression is assigned a type by the type checker before expressions are evaluated.

James Iry said...

@Cedric,

Scala is to Java as C++ is to C? That makes no sense. (Most) valid C programs are valid C++ programs. No valid Java programs are valid Scala programs. C++ takes C and adds things. Scala takes Java and both adds and removes things. The C++ grammar is several times the size of the C grammer. The Scala grammar is slightly smaller than the Java grammar. C has peculiar holes in it that C++ adopted whole. Java has peculiar holes in it (e.g. raw types) that Scala ditched.

I could go on and on. The analogy is false and always has been. I've written extensive code in all 4 languages in the C : C++ as Java : Scala analogy and I can promise you that it does not hold. I can keep Scala in my head pretty easily but cannot say that about C++ even though I've written far more C++ code in my life.

Neal Gafter said...
This comment has been removed by the author.
Neal Gafter said...

The relative length of language specifications are not a good measure of the language's relative complexity unless written in the same style. A Java specification written in the style of the Scala specification would be much shorter than the Scala specification.

Erik Engbrecht said...

Let's see...Scala has:
- autoboxing (although better than Java)
- primitive types (just hid by autoboxing)
- icky arrays (just a different, more confusing form of ickiness)
- No polymorphic Strings/Text/Buffers (it uses Java strings)
- No "batteries included" way to avoid try/catch/finally crap
- Generics that make Java generics look dead simple

Cedric is right in that Scala is a heck of a lot more complex than Java. However I think Java programmers can learn to embrace it because the complexity really does add a lot of power.

James Strachan said...

@Cedric - Hi BTW - long time no see!

Already some of the Java community are ready for Scala BTW; folks who try Scala tend to love it. You can please some of the people some of the time and all that.

FWIW Java is not super simple either - e.g. just about every decent Java developer I know has got lost in generics hell a few times - or in the various Java puzzles folks find using autoboxing with collections.

I purposely didn't list monads to avoid scaring folks away; I tried to stick to terms most Java folks would grok. Ruby/Groovy folks tend to avoid academic words too :)

I do quite like Fan; but prefer Scala being 100% statically typed with complete functional programming features like immutable state & for comprehensions along with generic & abstract types. (I share your fear of Fan obsessing about .Net/Java abstraction rather than making a better replacement to javac).

I do agree with you that Scala can look complex and can take a little while to read at first (the academic bias doesn't help there). But then anything that is more concise and powerful would look a bit different right? Ruby/Python looks very odd at first to a Java guy (especially doing meta object stuff!). Reading any of the good books on Scala soon gets folks up to speed.

If the javac replacement didn't look different - it'd just be Java with closures; which is nice (and looks like it will never happen BTW :), but it is not that big a deal in and of itself.

Matt Malone said...

@The Kaos Jester

def even(max: Int) = (0 to max by 2).foreach(println(_))

That looks better.

James Strachan said...

@Erik

- in scala, everything is an object; you can call methods on numbers etc.
- not sure what you mean by icky arrays in scala; all collections/arrays in scala are polymorphic (can be iterated over etc). They all implement Seq so things are nice and polymorphic unlike Java
- to avoid try/catch/finally crap in Scala you pass closures to methods so that helper methods can hide all that try/catch/finally crap

James Strachan said...

@Neal very good point! :) I guess we need to do word count on the BNF or something :)

Erik Engbrecht said...

re: Everything is an object
Scala certainly tries very hard to give this impression but it's not really true. The "methods" on primitives are a combination of compiler magic, Java-style boxing, and implicit conversions to Rich* objects. While most of the time this is nice, sometimes the cure is worse than the disease.

re:Arrays
Arrays can take several subtly different forms. There's unboxed monomorphic arrays (essentially Java arrays), boxed monomorphic arrays (boxed Java arrays that give you the nice functional methods), and polymorphic arrays (which are boxed). The compiler tries very hard to hide this complexity, and most of the time succeeds, but it doesn't always.

re: try/catch/finally
As you say, Scala provides to tools required to abstract a lot of this away, but it doesn't really provide any pre-existing abstractions that do it.

Anonymous said...

3) Your java code does less than the scala code


def even(lim: Int) =
for {i <- 0 to lim if i % 2 == 0} print(i + " ")

James Strachan said...

@Erik

re: Everything is an object
So at the language level its true right? Where it might not be true is if you look at the generated bytecode; or interoperate with existing Java bytecode right?

re:Arrays
Agreed; though again this only usually shows its head when using existing Java bytecode right?

re: try/catch/finally
What did you have in mind? Its easy to create little libraries that create DSLs for dealing with exceptions & hiding the try/catch stuff. What language level features would you want?

Erik Engbrecht said...

re: Everything is an object
For most practical purposes you're right. Most of the problems I'm thinking of have to do with the RichX conversions, which have nothing to do with primitives being objects are not.

re: arrays
It depends on your performance expectations. The boxed array varieties, especially the polymorphic one, are much slower than raw monomorphic variety. Of course if you measure them against Ruby then they're all blindingly fast.

re: try/catch/finally
There's some automatic resource management stuff in Scalax that's nice. I've done some neat things with wrapping j.u.c.ReentrantLock to allow lexically scoped locking and unlocking. It's just a matter of filling out the standard library more. Hopefully some of the Scalax ARM stuff will make it into Scala 2.8.0. Josh Suereth and I are working on that...
http://github.com/eengbrec/Scalax.IO/tree/scala-2.8.0-improvements

Unknown said...

I think its a forgone (if radical) conclusion now that in a few years, Java the language will be reduced to the language of interfaces and contracts, just as in 2001-03 it was a forgone (but radical) conclusion that J2EE was bloated and toxic and needed to be replaced with something similar.

I think we're all going to go polyglot, and that's not a terrible thing.

At the same time, I prefer Clojure for Java-Next over Scala. Less to remember, very concise, no confusing operator precedence rules (not operators!), and all the power that a functional, persistent (i.e., immutable data structures), concurrent language brings to the table.

I've been repeatedly asked "which will win ... Scala or Clojure". There is no win, and even Rich Hickey (inventor of Clojure) points out that they are designed to solve different problems.

I think the difference is that Clojure is an entirely new language (with Lisp syntax) that builds on the JVM infrastructure and interoperates, on its own terms, with Java classes ... and Scala is an embrace-and-extend approach, with syntax similar to Java but many, many more features.

I think ultimately many projects will use Java + at least one Java-Next (Groovy, Scala, Clojure, Fan, etc.) and individual Java developers will be functional across languages, but most fluent in one (or two). For me, the fluency language will be Clojure.

martin said...

Thanks for the endorsement, James! That means a lot to me. I believe we'd all be better off if instead of trying to put down other alternative languages on the JVM we worked together to convince Java programmers that there are now viable alternatives. Thanks for having taken a lead in this.

From what I know about Groovy (unfortunately, not as much as you know about Scala), it does not look to me that they try to fill the same space anyway. Groovy's appeal seems to be that it's a dynamically typed scripting language with a syntax that's familiar to Java programmers. Scala's appeal is that it's a strongly and statically typed language that blends functional and object-oriented programming in new ways.

shift said...

"Java is a surprisingly complex language" could have easily read "Scala is a surprisingly complex language". and it has little to do with the foreign syntax/style. for one, scala is a multi-paradigm language, so i'm not sure how it can be less complex than a single paradigm language. that would seem to defy real world laws.

Charles Oliver Nutter said...

Simple truth: Scala can't replace java/javac until it can produce all the same constructs java/javac has.

For example, you can't define a static method that looks "normal" from a Java perspective. This prevents any frameworks that (for example) use reflected static methods as bootstraps or entry-points from working directly with Scala. You also can't call multiple superclass constructors from a subclass. Sure, these may be antipatterns...but they're antipatterns found all over the place in existing Java libraries.

Of course if the whole world was written in Scala, this would all be fine. But it's not, and so replacing java/javac is not possible. Without a full complement of Java language features.

I like Scala a lot, and I think it's the best candidate for taking a lot of day-to-day development away from Java. But it's not possible for it to replace java/javac completely right now.

James Strachan said...

@martin FWIW Groovy is quite like Fan in that it supports optional static typing. So rather than using type inferenceing like Scala, Groovy & Fan let you switch off static typing whenever you like.

I now prefer the static typing with inferencing approach :)

James Strachan said...

@Charles

Generating static methods in bytecode that can be reused by legacy Java code sounds a pretty narrow limitation to me :). Java code could always just access Scala's singleton objects and invoke regular methods from there.

However I'm sure this minor issue could be addressed with a compiler plugin in Scala 2.8 to deal with your icky legacy request.

I doubt though that the long term replacement for Java the language is gonna be held back by this requirement :)

Charles Oliver Nutter said...

James: Groovy doesn't support optional static typing in the same way Fan does, since in Groovy all it does is add runtime type checks all over the place. Fan actually compiles to those static types, which results in better performance as compared to Groovy's worse performance when types are specified.

I think Fan's approach is a great way for dynlangs to go, and have considered how to bring it to Ruby for some time. And I think Scala's approach is the way static-typed languages should all work, including Java. But I don't think either will be the "one true approach", and Scala does not cover all use cases for a dynlang.

Charles Oliver Nutter said...

James: The lack of those features may not hold it back as a language in its own right, but unless you can produce every construct javac produces, you can't replace it, since the wide majority of the world will be using javac long into the future. If future Scala versions fix all those gaps, I don't see any technical reason it couldn't take over. But it can't now.

James Strachan said...

@Charles

Agreed; Groovy's implementation should be more like Fan's where it generates static method dispatch if static types are present. Though thats an optimisation rather than language design issue :)

I agree dynamic languages should consider adding optional static typing - particularly for APIs; though that could cause flame wars. e.g. see what happened when Guido tried it in python. I wonder if Mats would fare any better with Ruby? Fan and Groovy are examples of it working.

I'm not saying there will be 'one true approach' or anything like that. I'm just saying folks who want static typing should switch from Java to Scala. Folks who want dynamic typing there's a ton of choice out there which will surely grow with time (Fan, Groovy, Ruby, Python et al)

James Strachan said...

@Charles

re:static methods and stuff

Given that Scala is not backwards compatible with Java source code; it will never ever be a drop in replacement for javac in that sense. Scala is more a replacement language to be used instead of the Java language.

Code that's still using Java language syntax should probably stick to using javac. Though when writing new statically typed code, consider changing to scalac instead.

James Iry said...

@James,

I often hear that Groovy has optional static typing but as far as I can tell it does not. What it does seem have is optional dynamic testing based nominal types as opposed to the more common dynamic testing based on structure. But I can show that it's not static type checking very simply, Groovy will accept this as a definition

groovy:000> class Foo{}
===> true
groovy:000> class Bar{}
===> true
groovy:000> def Foo test(Bar x) {return x}
===> true

A statically typed language like Scala would reject that.

At runtime, when expressions are evaluated, there is a dynamic check which results in a cast exception

groovy:000> test(new Bar())
ERROR org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'Bar@3fbbfc' with class 'Bar' to class 'Foo'

Watch as I repeat in Scala

scala> class Foo
defined class Foo

scala> class Bar
defined class Bar

scala> def test(x : Bar) : Foo = x
console:6: error: type mismatch;
found : Bar
required: Foo
def test(x : Bar) : Foo = x

The error occurs before any runtime attempt to evaluate any expressions based on test.

James Strachan said...

@James Iry

Totally agreed! It was always my intention to make Groovy behave as Scala did in your example; but just never got around to actually implementing it :)

Kris Nuttycombe said...

The notion that the Java community is not ready for the complexity of Scala strikes me as a red herring. In other language communities, advanced and complex language features (for example, metaprogramming in Ruby) have been rapidly adopted. Java folks aren't any less capable than other developers; they've just been chained in a language dungeon for too long.

Cedric said...

Krys: the size of the Ruby community is dwarfed by Java's, which dwarfs even further the Ruby community that actually uses meta-programming, so you are essentially making my point: very few people actually understand this, much less will use it.

Rajat Gupta said...

James, I have been following your post for a long time and this one is excellent, simply superb. Your statement that you might not have proceeded to build Groovy is very strong and almost puts the nail in the coffin for Groovy.

We have a product for data processing targeted to end-users (http://www.pawanalytics.com) and we chose Groovy (over Jython and JRuby) as an open-ended way to extend the capabilities (from writing formulas on variables to doing complex scripting). A lot of what you and the rest of the Groovy team built with Groovy was really glue code (in addition to the core language). We leverage things like the integration with MS Office products and the web services support in Groovy. I hope that if the Groovy team is willing/starting to fully endorse Scala, those libraries don't end up in the dustbin and get exposed as the useful libraries that they are, in a Scala context.

Thanks,
Rajat

Bill said...

Cedric said:

Sorry James, but I really don't think the Java community is ready for something as complex as Scala. Because it *is* complex, despite what you think. Besides, I think that language designers such as yourself are paradoxically too knowledgeable in the area to make an educated judgment (didn't you list "monads" as a plus? Think about this for a while...).

Hi Cedric,

I hear this "Scala is too complex" objection from time to time, and I always get the feeling that the people saying it haven't used Scala much. Because the experience of the people who I know use it (and my own experience) is that Scala's complexity isn't really that much of a problem in practice. And I'm not a language designer and neither are most of the people using Scala. My best way of describing it is with a car analogy, which I posted elsewhere but will repost below:

Bill said...

Hi Cedric,

Here's the way I think complexity really plays out in Scala (reposted from elsewhere):

It is definitely true that Scala's type system is more complicated than that of Python's, say, but in exchange certain kinds of refactoring can be simpler in Scala than Python, figuring out what types are being passed to a method can be simpler in Scala than Python, and so on. The complexity of Scala's type system is there to make programmers lives simpler when they are actually programming, just as the complexity of the engine of your car is there to make the lives of drivers simpler.

I'll give you an example. In the old days, to start a car you had to use a manual choke. And you had to take into account the temperature outside, how long the engine has been turned off to estimate how cold the engine is, and the phase of the moon frankly, to try and get the car to start. If you got this wrong in the direction of too much air it wouldn't start, but if you got it wrong in the other direction of too much fuel you could flood it, making it even harder to get it to start. Nowadays the starters that come with new cars are more sophisticated (or as you might put it, "complicated"), but in exchange for that complexity starting a car is pretty darn easy. You turn the key and it starts. I've been amazed at how reliable this has become. I used to have a lot of trouble getting cars to start when I was a teenager, but now it just always works.

What's most difficult about starters today, given their complexity, is building them. Using one is easy. Similarly, what the complexity of Scala's type system really makes most difficult is writing a Scala compiler. This also makes it harder to create IDE plug-ins and other tools such as bug finders that need to analyze Scala source code. But it is possible, and everyday programmers don't write such tools, they just use them.

One way tbe complexity of Scala's type system may in fact add some complexity to your programming life, however, is if you're designing a library. This is something application programmers will indeed do from time to time, though often on a team there will be more experienced folks designing libraries and frameworks that the rest of the team uses. So this task will often fall to more experienced developers. But regardless, in the process of designing a library you may find yourself scratching your head over a tricky type problem. This is the process of figuring out what the types should be for your library. I can give two specific examples of type challenges from when I was designing ScalaTest that I found tricky if you're interested. I had to think about these a bit, but I was able to solve them, and they make using ScalaTest quite easy.

And that ease of use of ScalaTest has been my general experience with Scala libraries. Writing code in Scala that uses libraries is quite easy. You do need to learn the language, and you'll need some level of understanding of its type system to use it, but it isn't out of reach of most programmers I've worked with. I think if someone can program in Java they can learn to program in Scala. The one place the complexity of the type system can rear its ugly head for these folks is if you get a compiler error message that is complaining about a type error. Most of the errors you get, though, are simple enough, pointing out a "typo" in a method call or what not. Sometimes they aren't obvious, such as when they complain about not being able to resolve an overloaded method call. But in my experience very rarely does understanding a compiler error message require a sophisticated understanding of the type system. Most of the time the problem is you spelled a method name wrong. Things like that.

Unknown said...

You mentioned scala's actor model, but I don't think you give it the importance it's due. This is the Erlang approach to concurrency and when combined with strong immutability constraints, this will enable highly scalable and reliable concurrent solutions.

I'm surprised you didn't propose scala+groovy as the replacement for java+xml. Why not?

Dominique De Vito said...

Yes, Java keeps falling further and further behind C# ! Java looks like more and more the new cobol.

Microsoft language work is much more living, as C# 3.0 has shown good ideas about closure and type inference. And the more I learn about those ideas, the more I want to program with C# 3.0, after more than 10 years of Java programming.

One of the pbs that Java faces today is closure adoption, as closure and type inference do have relationships: to make easier closure adoption, Java would need a dose of type inference; see my post for arguments, here is one example: the closure introduction faces a dilemma,
- if the legacy notation is reused, then closures appear to be heavy,
- if a new notation is defined, then the language gives the feel of a certain lack of coherence.

The problem is: adopting closures is one step, adopting type inference is another step, and adopting both, as the same time, while it would alleviate the closure burden, is a 2-step move that looks like too much enough for Java drivers.

Well, the pb with Java is that Java looks like in maintenance mode, may be it's the reason beyond why little modifications only are planned for JDK 7. Take one example: the diamond operator (a little add) is discussed for JDK 7 inclusion, while no type inference is planned.

Java drivers have enforced strong rules not to change too much. So, it looks like we need the rise of another language.

This being said, last time, I have tried to learn Scala, Scala code hurted my eyes.

May be there is a given threshold to go beyond in order to accept the new beauty of the Scala code.

Unknown said...

I introduced scala in my small java shop, on some research projects last year.
Nowadays scala is the main programming language.
We've been bought by scala for the possibility to use traits to build type systems capable to keep distilled know how from previous projects and as an effective replacement for model-driven approach and related code generation to inject behaviour inside application classes. Then we used the possibility to pass around functions to enhance parametrization of components.
In a word, scala offer better mechanisms than Java to build reusable components.

James Strachan said...

@Dominique

Agreed! Certainly it takes a little while to get your head around Scala code as a few things are different from Java (particularly the ordering of class/method/variable definitions, the for loop differs and the use of case which is pretty common rather than switch - plus the heavy use of functions/closures). The books I mentioned on the blog really help though!

Scala is not just Java plus closures + type inference. But on the plus side, its a neat, clean, consistent, elegant language which compiles to bytecode which is about as efficient as Java - and completely implements type inference and closures & first order functions today. So there's no need to cross our fingers that the planets align and maybe both these things get fixed in Java 8 or Java 9 in a not too sucky way in 5 to 10 years time - we can just program in Scala today!

James Strachan said...

@Cedric

Just like few folks in Ruby need to do meta programming (its the framework folks who do that like Rails implementors), in Scala much of the perceived complexity (implicit conversions, abstract types, generics etc) would be used by framework implementors (e.g. folks who implement Lift) so that there are nice high level DSLs for application programmers to use.

e.g. the Camel Scala DSL is very easy to use with smart IDE completion. Users only have to understand the real basics of Scala - no advanced type stuff.

James Strachan said...

@Rajat

I don't think any of the popular JVM languages are going to go away; there's always gonna be a big commmunity of folks hacking Groovy, JRuby, Clojure, Jython, Rhino etc.

One of the great things about the JVM is its pretty easy for all these languages to coexist and reuse each others code. So I don't think anyone has to worry about being left on the wrong language so long as folks stick to popular choices.

I don't necessarily think that Scala is a replacement for all dynamically typed languages like Ruby/Groovy/Fan; its more for cases where performance is important and Java used to be the clear choice of a fast statically typed compiler - now the clear choice for a statically typed compiler for the JVM is actually Scala - since Java the language is kinda dead (it'll probably never get closures, never mind type inference etc.)

Since discovering the power of type inference in Scala I actually think lots of the motivation for dynamic typing (concise code with little type noise) becomes increasingly hard to justify. e.g. you can write scripts in Scala, its got REPL (Read-Evaluate-Print Loop) just like Ruby/Groovy etc.

But my point of this blog post wasn't to try start a war of Scala folks versus the dynamic type crowd of Ruby/Groovy/Clojure/JavaScript etc - it was more to get folks stuck on Java the language to realise there was a much better statically typed language out there right now - which has all those features folks have wanted (along with a solution to most of the new enhancement requests for the Java language) - all done in a more consistent, elegant language (albeit a little different to Java with a little bit of a learning curve).

James Strachan said...

@bwtaylor

Agreed - I love Scala's actor model (especially now it appears to have fixed the memory leaks in 2.7.5 :). I think Scala is going to have a dramatic effect on how folks build asynchronous, concurrent, distributed applications on the Java platform - particularly with the new continuation support in 2.8.0!

On reflection I should have highlighted this a bit more in the blog post; but even on a basic level; ignoring the awesome Scala libraries for concurrency, monads/collections, writing DSLs, building web applications (Lift) and testing (Specs/ScalaTest et al) - just looking at Scala as a fast statically typed compiler for the JVM which has closures, first class functions and good type inference - should be enough to convince most folks to switch from Java :)

Dominique De Vito said...

@James

Yes, no need to wait for a planets alignment before using another language than Java.

Still, it's "sad" to see Java no evolving.

Seymour Cray said once he didn't want to be a pioneer because pioneers make mistakes. Well, C#, and the different languages on top of JVM, just show different ways illustrating how Java could evolve. Even with that help, Java looks like in maintenance mode only. What a lost of a good occasion.

James Strachan said...

@Dominique

I hear you & feel the same! But think of it this way. Whenever we say Scala we secretly think "Java 9"; then the problems solved :).

Java 9 has evolved to being more powerful and elegant than C# and F# combined! (Its just we can't say "Java 9" out loud due to trademark issues, so we have to say "Scala" instead :-)

Unknown said...

James,

I'm very impressed with it! I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

You are simply a genius. Each piece of work you do is innovative, from ActiveMQ to ServiceMix to Camel to Groovy

Cedric said...

James,

By "Java is kinda dead", do you mean that the language is on its way out to be replaced by something better (Scala according to you) or that it's no longer evolving?

I certainly agree with the latter, but you fail to recognize that this is precisely Java's strength, and the reason while it's still thriving today when coupled with features such as annotations, XML and frameworks versus all the babble about DSL's, which hasn't led us anywhere and is mostly discussed in conferences and nowhere else any more these days.

Scala might be technically "better" than Java (good luck defining this, though) but it takes more than that for a language to cross the chasm, and it's surprising that you, of all people, fail to see this.

I do agree with you that the case for dynamically typed languages becomes harder to make every day, though, but let's save this flame fest for another day.

James Strachan said...

@Cedric

I meant the latter; Java the language is not gonna evolve much more now - particularly with the death of Java 7 - now there is just openjdk7.

I realise Java the language is very popular. I think its gonna be really hard for any JVM language to achieve this level of popularity as there's always gonna be a ton of legacy java code out there. Lots of folks still hack C code remember.

I see a lot of growing adoption and momentum behind Scala. I'm not sure exactly what it means to cross the chasm when applied to JVM languages? 10% of Java developers prefer to use Scala for new stuff?

Note the title of the blog post was *long term* - I'm not expecting tomorrow to wake up and 90% of Java hackers to switch to Scala. But if we keep seeing a steady flow of folks moving from Java (the language) to Scala, who knows what'll happen long term?

I'm kinda confused by this argument though; if something is better and folks usually prefer to use it and do switch to using it, over time that will become a replacement (for those folks). But not everyone wants a replacement, but thats fine right?

Let me turn it around. Are you saying folks will always stick to using javac on the JVM forever and there's never gonna be a better replacement. Or do you have a better tip for what will be it? Or do you think Java will get closures before a replacement turns up & gains enough adoption? :)

gruffa said...
This comment has been removed by the author.
gruffa said...

Can only agree with the writer. Ive been working 1,5 years with scala in a typical web-entreprise-app and have now delivered into production. What makes me halleluja this underhyped langague:

1. beeing typed (first and foremost.. untyped languages just suck to refactor),
2. beeing functional has, to my suprise, made my code so much more robust. As it allways forces you to think about all execution paths.
3a. having all the nextgen luxurary with closures, first-class functions that enable me to create all abstractions that i could wish for and...
3b. ...all efficiencies this gives list/map handling makes it a breeze compared to languages that dont have them.
4. Pattern matching gets you rid of alot of ugly if-else/instance-of statements making code much more readable
5. implicit conversions - no more convert/translate methods for you

Im doing spring/hibernate/scala - and theres just aint no problems with it.

Not leaving scala!

Tom Flaherty said...

James - great post. In recent Scala presentation I suggested the same idea that Scala's future maybe to replace Java. My main argument is that strong typing is the key to a stable foundation that the other weakly typed dynamic languages can build on. But for those in the know, Scala can do anything. So I appreciate your insight and the great references.

Claus Ibsen said...

Thanks for the write up and especially for the great Scala links to resources. Comes handy when I got the time to check up more on Scala.

Unknown said...

@James
You are saying "Java is a surprisingly complex language" but also "it keeps falling further and further behind C# etc".
I'm sorry but the second statement is a non argument...
C# is quickly overtaking Java in complexity. Ever found the <? extends T> and <? super T> tricky?
Guess what? C# 4.0 is eagerly catching up with the equivalent <in T> and <out T>...

I'm happy that Java is falling behind in this race. In my view the (over-exaggerated) issues in Java will not be solved by unreadable code structures (closures or lamdas) however useful these may be...

I feel that today's language designers are letting us down. :-(

How have we ended up compromising must-haves (readable code) against nice-to-haves (more features)? Is that what is taught in design school nowadays?

Neal Gafter said...

@Tasos-Zervos:

C#'s in/out is "declaration-site variance", which is quite a bit simpler than Java's "use-site variance". Experience with it so far in C#, Scala, and other languages has been quite good.

As for the readability of lambda expressions, experience there has also shown it to be a significant improvement over the alternatives currently available in Java.

James Strachan said...

@Tasos

A language can be over complex yet at the same time under powered. There are many simpler yet more powerful languages than Java.

Scala is generally simpler & much more consistent (admittedly the type system is probably a bit more complex and loads more powerful) - yet at least as powerful as C#/F#.

One of the most important aspects of the Scala language is, the actual language itself is quite small; its designed to be scalable, so the language can be extended in libraries to satisfy different domains (e.g actors for concurrency).

I personally prefer more concise code which represents the intents rather than reams and reams of boilerplate noisy code which each line is very easy to understand - its very hard to see the bigger picture.

However having said all that, if you find closures/lambdas unreadable you'll also find C#, Groovy, Ruby, Python, Clojure, JavaScript, Smalltalk and many other languages unreadable too - so I'd definitely suggest sticking with the Java language - it sounds just what you need!

On the other hand, I love expressive languages that you can clearly describe your intentions with minimum redundant noise; so I love closures, first class functions, for comprehensions etc.

Its definitely harder to read Scala code (as Java code is quite dumb in comparison); you have to think a bit more as you read until you're brain bends to the Scala way - its kinda the difference of reading many lines of Java code per line of Scala; it should be a bit harder as the code is more dense; you're getting way more in a shorter space. But that density helps you see the bigger picture & intentions more easily (which is really quite hard in Java even though each individual line is trivial to grok).

James Iry said...

@Tasos Zervos,

Given a list of people, please create two lists - one of minors and one of adults. Minors are those under 18, adults are those 18 and up.

In Scala it looks like
val (minors, adults) = people partition (_.age < 18)

I've presented that example to many Java programmers and all have been impressed at how clearly that code maps to the requirements, even though they don't know Scala. Most have even made fairly correct guesses as to what "_" means - but even when they don't know exactly what it's doing they can see the relationship between the code and the requirements.

That one example uses a tuple, pattern matching, a lambda, and partial function application.

Now, convince me that any Java alternatives are more "readable."

lsjb said...

And what about the richness of Java API? Can Scala compete with that? How about JDBC, Servlets, and all the Web specification? When choosing a language I also look for whats in top of that language.

Matthew Hall said...

@James:

Not to hijack the conversation, but I want to clear up some misunderstanding you seem to have about Fan:

Fan is statically typed. I'm not sure where people got the idea otherwise. It is true that for a while there was an experimental "dynamic type" class, but this was a small part of the language, and was removed several months ago.

Fan does support so-called duck-typing using obj->methodName(arg0, arg1...) syntax instead of obj.methodName(arg0, arg1...) but this is just syntactic sugar for obj.trap(methodName, args) which maps to a reflective call at runtime.

Fan does support immutable state via the const modifier, but only forces you to use it when doing concurrent programming with actors. If you don't want a particular class to be const but need to pass it to an actor, you can make the class serializable instead. In this case, Fan will clone your object by serializing and deserializing the object, so that the actor receives an equivalent but distinct instance. Thus side effects are confined to an object's originating thread.

Fan does support generics but for the moment only in sys::List and sys::Map. I personally hope this will be available to the rest of the language some time in the future.

Fan does not support comprehensions to my knowledge.

If you haven't looked at Fan for a while, you may want to take another look. A lot of improvements have been made (Scala's actor model has been adopted) and the project is ramping up for a 1.0 release in Q3 of this year.

At this point the language is basically finalized, and work is underway to complete the .NET port as well as the JavaScript port.

Simon Chemouil said...

lsjb said...

And what about the richness of Java API? Can Scala compete with that? How about JDBC, Servlets, and all the Web specification? When choosing a language I also look for whats in top of that language.

@lsjb

You can use all Java code, including libraries/API from Scala. You can in fact call to any JVM class or interface definition, hence you can use code that has been defined in another JVM language (Clojure, Groovy, ...).

When you use Java code, of course it will not always look like idiomatic Scala code (the main problem is that most Java libraries use "null" which is a bad idea from a functional point of view).

It can be interesting to provide a thin wrapper in Scala to use the proper idiomatic Scala patterns over the Java library you are calling into. For instance, Apache MINA (a NIO library) provides a Scala wrapper based on Actors.

Lift, the main Web framework for Scala makes use of JEE standards (including but not limited to servlets, WAR archives, persistence possible with JPA even if another method is proposed, etc). It is currently being modularized with OSGi using an OSGi-DSL for Scala named ScalaModules.

When you switch to Scala, you don't lose anything from the Java world, but you gain a lot. It's a blessing and a curse, because once you have tasted it, it's hard to go back to Java :).

Unknown said...

I saw this rocket up on dzone - at the moment it's #1 for the last 7 days. So I checked the last 365 days and the #1 and #6 articles for the YEAR are about groovy on app engine and the groovy 1.6 release, respectively. If you look at the last 30 days, this article is #4 and #5 is "The Case for Groovy".


It seems like Groovy is finally gaining a lot of traction, especially in unison with grails. Reflecting on this article coming from YOU, I'm simply stunned.

It begs the question: what do you think the future of groovy is? Why are you NOT celebrating it?

One thing is clear: with groovy, scala, jruby, and jython all on the rise, the future is polyglot.

James Strachan said...

@bwtaylor

Its all taken me a bit my surprise :).

I still like Groovy (and Ruby and JavaScript); they are all good dynamically typed languages. Folks hacking web applications often tend to prefer dynamically typed languages. So whether its on the browser (JavaScript - and sometimes server side too) or in web frameworks like Grails (Groovy) or Rails (Ruby) they are very popular approaches.

Groovy/Ruby/JavaScript are certainly all very popular these days and thats cool with me. The future is definitely polyglot.

I personally find myself writing lots of code still in Java - either because of performance or due to the large code base and for me the need for static typing tends to outweigh the benefits of dynamic typing as code bases get big & used by many people. I've a lousy memory these days so I like being able to navigate from every variable/parameter/field/expression, to its type, to its APIs whether in an IDE or in javadoc/scaladoc and being able to do safe refactoring. If you're hacking a simple MVC web app this probably isn't a big deal; but I don't tend to hack on those that much these days.

My blog post was really aimed at folks who are still stuck hacking Java code due to its static typing & performance (i.e. it wasn't really aimed at folks who'd left javac to do Groovy/Ruby/JavaScript) - that there's a statically typed alternative to Java that fixes pretty much all of the issues in Java the language and introduces a ton of great new features as described in the post and comments.

Whats surprised me with Scala is that I've found I actually prefer static typing with type inference to dynamic typing. I'm not saying I'm only ever gonna use Scala for everything; I still use other languages when they make sense - but mostly I'll be trying to use Scala for as much code as I can as it has all the benefits of static typing, many of the benefits of dynamically typed languages (concise elegant code with little noise), is amazing at writing DSLs and opens the door to functional programming (pattern matching, for comprehensions, immutable state etc) while still being a much better OO language than Java (e.g. I love the traits in Scala).

The future is certainly polyglot - we'll never all agree on one language and there are wide range of use cases. We can probably all agree Java the language is just about at the end of its road; bar a few little tweaks its in maintenance mode. But despite the polyglot future I do find in Scala I'm less tempted to jump to other languages; I can do pretty much all I need in a single language (do great OO stuff, functional stuff, DSLs and do kinda dynamically typed stuff while really using static typing & immutable state where it makes sense).

James Strachan said...

@bwtaylor

BTW Groovy and Scala can look quite similar. e.g.

e.g. this is scala:

val (minors, adults) = people partition (_.age < 18)

this is groovy:

def (minors, adults) = people.split { it.age < 18 }

the main difference (other than some minor surface syntax differences) is the scala one is statically typed and using immutable state

Unknown said...

Neil said: "As for the readability of lambda expressions, experience there has also shown it to be a significant improvement over the alternatives currently available in Java."

@Neil
This is like comparing the bad with the worse...
I would like to have had functions in Java (like in C#, Scala, Groovy, etc.) but why can you only have them with all this "inference" capability? Why do I have to "become" the compiler every time I have to understand a new code-base?
My experience has shown that when applications break and I get called in to figure out what's going on, the less variable parts you have to take into account the quicker you find the bugs.

PS: I much prefer the name callback (ref to Scala) than closures, Lamdas/Func, etc.

Unknown said...

James said:
"if you find closures/lambdas unreadable you'll also find C#, Groovy, Ruby, Python, Clojure, JavaScript, Smalltalk and many other languages unreadable too - so I'd definitely suggest sticking with the Java language - it sounds just what you need!"

@James
What I need is not patronising comments. I expected you would "moderate" your comments above everything...
Readability for me is more about "least effort to understand".
I do in fact have spend sometime programming in Groovy and I'm now getting into Scala. I also hope to get into Clojure after that.
I'm open-minded but, I'm still not satisfied with some of their compromises. That's all.

James Strachan said...

@Tasos

apologies if you thought my tone was patronising.
You said "issues in Java will not be solved by unreadable code structures (closures or lamdas)" I took it to mean you found them unreadable - hence my comment that sticking to Java rather than moving to the various languages which make heavy use of them. I was thinking of you and your ability to read the code; not attempting to patronise. Languages are very subjective things; what suits one person, their mental models and fashions doesn't suit another.

But if you use Groovy and are starting to get into Scala/Clojure - maybe you are finding closures & lambdas are readable now? Or maybe you still don't like them despite this new experience? :)

Its worth mentioning that new pretty much every popular language apart from Java has lambda/closure support in some form or another including VB/C#/python/groovy/ruby and folks usually like the power they offer & I don't hear many complains they are hard to understand. Many also have for/list comprehensions too (python & C# for example).

Darren Cruse said...

I can say as a Java developer I definitely feel like Groovy and Scala are the two prime contenders for becoming a second "complement" language to Java - which realistically in my shop I don't see going away for awhile.

I don't mean to make this a flame war but I think the obvious questions are:

a. Are there use cases where Groovy is still a good choice over Scala? What are they?

b. Are there features/capabilities which Groovy has which Scala doesn't?

For example for a., in a shop with non-academically-inclined developers that only know Java today, would you agree that Groovy's learning curve is lower?

I tend to feel it is and maybe that's a compelling advantage in some cases... esp. if performance isn't the driving concern and if you're not expecting to replace Java but just complement it for some scripting or reporting or...

And regarding b.: Am I mistaken (I might be :) or hasn't Groovy's meta-programming features e.g the use of "method-missing" stuff allowed things like the SwingBuilder (which I think rocks)? Will/does Scala have the equivalent?

More simply and generally: Are people saying there's nothing that Groovy can do which Scala can't do (presumably with faster performance and similar lines-of-code counts)?

James Strachan said...

@Darren

great comment!

a) the main advantage Groovy has is its lower learning curve; I specifically tried to design Groovy so it reused Java syntax where possible, so the transition from Java -> Groovy was easy (folks barely need to know its a new language at first bar a few minor changes, then over time they can get more Groovy. You could say learning curve & dynamic typing were Groovy's main design goals.

However in terms of performance & static typing with its associated gains (more helpful IDE/compiler/documentation & better safe refactoring) Scala wins. Scala is also marginally better at writing DSLs too (e.g. the Apache Camel Scala DSL is a little cleaner & more concise than the Groovy one).

b) they are kinda functionally equivalent for the most part. You can create builders in Scala in a similar way (e.g. check out scalafx for a version of the SwingBuilder
or the Apache Camel DSL) - the benefit of the Scala approach is its typesafe, so your IDE can smart complete & the generated documentation of the builder describes the available methods etc.

So in general I think the languages are both better than Java! Its a tradeoff really for lower learning curve and much worse performance (Groovy) versus a bit higher learning curve; but with Scala its a single language that can be used for ad hoc scripting or in cases where performance is important - which is also statically typed which has lots of benefits; particularly when a team of folks work on a large codebase over time & need the extra compiler/IDE/refactoring/documentation help that static typing gives.

Darren Cruse said...

One final (burning) question then which I almost hate to ask but I hate not to:

Groovy on Grails seems very well done to me and it seems like they've made some very smart enterprise friendly choices in building it atop Spring and Hibernate, plus it's support for SOA/REST/SOAP stuff is important in my shop too...

With so much of this lower level infrastructure written in java, with Groovy just providing the glue, the performance story for Grails can be a perfectly good one right?

But are you saying that despite it's relative immaturity and lack of popularity, the potential for better IDE support and performance in Scala should make people take Scala with Lift seriously as an alternative to Groovy On Grails?

But Grails has to be more mature than Lift right?

Or is that an unfair question? It's a critical one for my shop though...

(please don bullet-proof blog vest before answering :).

James Strachan said...

@Darren

Like anything performance depends on what you're doing. Grails certainly can perform adequately for many use cases yes - but would you want to write all of your business logic in Groovy if performance was important? But as you say, most of the code is really Java. With Scala, 100% of it can be Scala without worrying about performance.

I certainly don't wanna start a Grails v Lift flamewar though! Both are good frameworks; Grails is probably a little more mature - they both have good things about them.

I'm personally a big fan of the Lift templating approach; it lets you have simple HTML templates with no code at all; then write many custom tags in a single statement (often spread over a few lines, one per tag) in Scala code.

BTW Lift isn't that different; you can reuse Spring and/or JPA as and when you want to.

i'd rather folks make up their own mind about Grails v Lift though!

Unknown said...

Clearly, Scala is a replacement for Groovy.

It is unclear that there is a compelling reason to drop Java and all of its support for Scala. However, there are some types of code that clearly will be easier in Scala. I am going to start using Scala for some of these tasks and see where it takes me.

Dean Wampler said...

One small comment on the issue of the complexity of languages and Scala in particular. Early in our book, we call Scala a language for "professional developers". (I'll take the blame for this one... ;) We know only too well the complexity that lurks within, yet we both believe the benefits justify the effort to master the language. Put another way, there is not much "accidental" complexity.

On a related note, Michael Feathers posted a blog today on "patronizing languages": http://blog.objectmentor.com/articles/2009/07/13/ending-the-era-of-patronizing-language-design

Goofy Idea Man said...
This comment has been removed by the author.
Cedric said...

Hi Dean,

That's a bit surprising because it seems to me that Scala is the opposite of a "professional language", if you take the meaning literally: right now, very few people who code in Scala are paid for it, they are more doing it as a hobby.

From that standpoint, the professional languages would be more C++, Java, C#, VB, Javascript, etc...

James Strachan said...

@Cedric

Sounds a bit of a pulled-out-your-ass statistic to me :). How can we prove/disprove this claim?

FWIW the main R&D team behind the language are paid working at (EPFL) AFAIK. Then most folks in the lift community tend to be building web apps for money. I myself get paid to hack Scala too BTW.

Folks tinker with every programming language; I'm not sure if more or less folks proportionally are paid versus tinker in Scala versus other emerging languages on the JVM.

Daniel Serodio said...

I've been closely following Groovy development since pre-1.0. I've been burned by the breaking changes leading to 1.0 but the fault was on me, since it was pre-1.0 and subject to change.

IMHO, the main pros are the learning curve (Java-like syntax helps a lot here) and dynamic typing.

Before discovering Scala, I really believed that Groovy would have a great future, and I've sold this idea to many colleagues. Closures feel natural in Groovy (as opposed to Java), Groovy Console is great for quick prototyping, etc.
In fact, I think if Sun had hired a couple of full-time Groovy developers 2 years ago, Groovy would be in position to "compete" against Ruby today.

OTOH, I also believe it really needs tooling to gain any traction in Java-land. We've been spoiled by Eclipse, and I'm currently more productive with Java on Eclipse than with Groovy on [insert great text-editor here].

I've never done a "real world project" using Groovy (or any other dynamically typed language), but I'm leading an experimental Grails project.

My pet peeve with Grails are the ginormous stack traces, that have very little to to with the actual error. Too many layers of abstraction magic that suddenly pop up.

Sadly, the Groovy Eclipse plugin is stagnating again... The "nightly build" update site doesn't even have a Grails plugin anymore, but it seems like this time (rewrite from scratch?) it'll be worth the wait.

I'll give Lift a try; maybe Scala will give me what Groovy still hasn't been able to deliver.

Cedric said...

James: just compare the job offers for Scala with other languages. It's pretty obvious that Scala is still in the very early adopter phase.

TJGodel said...

I've read about Scala last year while I was looking for a alternative to Java. Do you think anyone can use Scala as it is today as a simpler alternative in the enterprise? Even if the person doesn't know Java?

James Strachan said...

@TJGodel Sure! There's no reason why you can't just pick up Scala having no real Java knowledge. I recommend one of the books I reference on this blog post, they pretty much describe the whole language without much reference to Java the language.

Probably the area thats weakest in the books is explaining how the JVM works (class loaders, bytecode , jars and how you set the classpath); but starting with the scala compiler & REPL console should be a good introduction to get you started

TJGodel said...

Thanks James!! I'm excited about Scala I'm going to get started. I have tried over a few years to get excited about learning Java, but I just didn't like all the hoops a person had to jump thru to program in Java. Scala is very elegant and clean. It seems like I can focus on what I want the program to do instead wasting huge amount of time syntax.

author said...

I'm still only through chapter 2 of "Programming Scala" but i've already come across a several things that have been bothering me. Please understand i'm a complete noob to Scala. I do already love a lot about it and maybe when i get a better grasp of the reasons for some decisions and/or see more usage examples, reasons will be clear and not (so) bothersome.

22? __root__? _? Parsing sometimes trumps language consistency.


A fixed maximum for Tuples, Products, and Funtions seems unusual. It's unusual that there is a fixed maximum for a language feature. It seems like a random decision. Why not 23 or 17 or 26? Also, why differentiate Tuples from Lists. Like i said, i suspect this'll become more clear as i read more.

_ is used in different contexts with different meanings that are making it a little difficult to remember the meaning since they're unrelated.

__root__ ?? Why not overload _ again and use it at the beginning of a package as the anchor for root?

It seems too many language decisions are based on easing parsing, overriding what would be a more consistent language. I can't remember the examples but i think there were at least two in just the first two chapters.

So far, i still much prefer groovy. Mostly for one of the same reasons i like javascript. I love languages in which documents can be presented in a subset of the language itself.

Dean Wampler said...

@nicerobot. The common "thread" for using _ is that it's used anywhere you need a wildcard that matches "any" or "all".

There has been a lot of discussion on the scala mailing lists about _root_. My personal preference would be to use _ instead, as well.

The limit of 22 is arbitrary, I think. They had to pick a limit because all the "N" variants are defined explicitly as separate types. Of course, if you have 22 function arguments, tuple elements, etc., you've got a design issue, IMHO ;)

I would like to see a little more "unity" between tuples and lists. I think of tuples as a convenience for certain contexts, but I guess they aren't really intended to be used like lists.

James Strachan said...

@nicerobot I hear you, though tuples in Scala are quite different from general purpose Lists. A tuple in scala is immutable and each position in the tuple can have a different static type. So its kinda like an argument list to a method in Java code - its typically a small-ish size, its fixed at runtime both in size and in the types at each position. I'd be a little worried if someone was using a tuple of greater than 10 to be honest, so the fixed limit isn't really a big deal in practice.

The compiler could code generate tuple implementations at runtime for larger tuple sizes - but its highly unlikely they would be that useful in practice.

I love languages in which documents can be presented in a subset of the language itself.

Not sure I follow that one; what do you mean by document? Not sure how JavaScript/Groovy support documents. You are aware of the XML markup support in Scala - you can embed an XML/HTML document in Scala code?

Tom Gullo said...

I've been using Groovy/Grails for the past 2 years and I don't want to go back to a statically typed language.

Average Joe's like me get a huge performance boost when developing small/medium sized Web apps in Groovy/Ruby/Python.

I think you alpha-programmer, framework developing types underestimate the performance boost of dynamically typed languages.

James Strachan said...

@tom if the code is equally concise in a static or dynamically typed language and with dynamic languages generally being quite slow compared to statically typed languages; what is the performance boost you refer to?

Tom Gullo said...

@james,

When referring to performance I meant productivity. I get a huge productivity boost using Groovy/Grails instead of Java. I love typing grails console and prototyping anything I want and getting immediate feedback. Or groovyConsole and prototype basic things there.

In fact, if I have to switch from my Vim/Groovy/Grails environment back to a Eclipse/Java/Struts I'll probably just quit programming.

Where I live, most companies use Java and Struts and I'm lucky to have been given the freedom to migrate the shop to Groovy for Web development.

James Strachan said...

@tom so I totally get how a more concise syntax can really help productivity - plus having a REPL shell is great. However both are available in Scala as well as Groovy (and Ruby and other languages too).

i.e. the productivity gains you experience in Groovy can be experienced in a statically typed language like Scala - just not in Java.

So I'm sure you could experience a similar productivity boost in Scala (once you've learnt it) as you experience in Groovy - with the added benefits of static typing.

Tom Gullo said...

@james

I didn't realize you could have a REPL shell with a statically typed language.

Scala is intriguing. My efforts to learn Scala led me to your blog.

Thanks for the insights.

Charles Oliver Nutter said...

You can have a repl in Scala, but it ends up being a lot more limited. For example, you can't reopen classes in Scala's repl and add more methods to them; once you've defined a class, it takes over that name and previous versions are not accessible. This is a *key* advantage of Ruby over both Groovy and Scala, and it's exercised pretty heavily by many Ruby repl users.

I haven't played with Scala's repl much, but I'm sure there are many other such limitations, since Scala has no interpreted mode and no open classes.

James Strachan said...

@Charles FWIW I use JavaRebel with Scala particularly in web apps & Lift and am able to add methods & change code pretty radically and it all auto-reloads on the fly giving near immediate feedback.

I'm not saying that 100% of your Ruby REPL use cases are solvable easily in Scala or anything - but just that the idea that static typing somehow means you can't have rapid feedback to code changes isn't really true - its just a bit harder.

But then even in dynamically typed languages, it can get kinda tricky changing anything anywhere in code while keeping live objects around which were created with older versions of the code (though Ruby definitely copes with this better than quite a few other dynamic languages).

Be that as it may; I see this more as a tooling issue than as a criticism of the language. Using JavaRebel for example it should be possible to redefine classes in Scala's REPL for example

Charles Oliver Nutter said...

Using JavaRebel it's pretty much possible to do anything to anything with any language, so I don't really consider that a way to excuse Scala's staticness limiting the more dynamic features people love about Groovy or Ruby. Scala can do a lot, but it's not a dynamic language.

James Strachan said...

@Charles - noone is claiming that scala is dynamically typed :).

Just that you can get many of the perceived benefits of dynamic typing while still being statically typed thanks to JavaRebel + type inference.

Its just within the confines of static typing you need to implement things differently to dynamic languages (e.g. JavaRebel, structural typing, traits and implicits instead of open types and catching missing method declarations in Ruby).

But like anything in IT; there are trade offs.

Darren Cruse said...

A slightly vague question but: With both Scala and Groovy attempting to be "a better java", and (especially in the enterprise) that being a difficult thing, is there any chance the Scala and Groovy camps could work together and synergize more on syntax or features? Broadly: Could Groovy have been the interpreted dynamic version of Scala?

More concretely: There's a tradition of interpreted languages being written in lower level languages, e.g. Perl or Ruby (initially) in C, Groovy in java.

But in a different world, if Groovy had been designed after Scala was already available, might it have evolved as more of a true hybrid of this "type inferencing static language" which is Scala, and the truly dynamically typed language which Groovy is today.

And by this I mean that right now, though you can optionally specify types in Groovy, you don't get any performance benefits you just get some run-time type checking right...

But it seems like - ideally - those optional type specifications would have allowed Groovy to generate smarter byte code that was closer to what java or scala is doing. i.e. A true hybrid of dynamic and static typing where you can choose the greater run-time flexibility of a dynamic language or the greater performance benefits of static typing as you wish by just including or omitting the types...

I guess I'm probably underestimating the technical challenges behind this - mostly I just hate the thought of giving up my time investment in Groovy, and in some ways actually feel there being two choices - Groovy and Scala - is actually going to further delay adoption of either - since enterprises seem so afraid of choosing something which may or may not be the "winner" five years from now...

James Strachan said...

One of the really interesting things about Scala is that its a very scalable language - its easy to use a library to extend the language into other areas via DSLs and so forth. (e.g. see the Scala actor stuff, it looks kinda Erlang-ish yet its all done in a library - similarly there's no special language syntax for Maps and other Collections either, thats all done in libraries too).

Implicit methods in Scala do a good job of fixing the JDK rather like Groovy's GDK stuff. So it might be interesting adding some of Groovy's other features as a Scala library?

e.g. someone's already implemented a version of Groovy's Elvis operator...

http://www.codecommit.com/blog/scala/implementing-groovys-elvis-operator-in-scala

There is already structural typing in Scala so you can do typesafe reflection & duck typing.

I wonder if someone should create a concise syntax for dynamic method invocation? Then whenever you really want to use a dynamic method invocation rather than relying on type inference, you could go dynamic.

Am not sure how concise it would look though. XPath is quite concise...

document \\ foo \\ bar

I wonder if some similar syntax could be used to access methods & properties using dynamic typing?

Cedric said...

James:

"Then whenever you really want to use a dynamic method invocation rather than relying on type inference, you could go dynamic."

You make it sound as if dynamic invocation and type inference are mutually exclusive, not sure what you mean here.

As for your other point, this is the direction that Fan took by offering a different syntax for dynamic invocation:

foo.init(); // static invocation

foo->init(); // dynamic invocation

I like that.

James Strachan said...

@Cedric sorry I should have used the phrase "static typing" not "type inference" hence your confusion. I'd not had enough coffee!

BTW I mentioned this idea in passing on twitter - implementing dynamic typing in a library for scala, and someone's created an implementation already...

http://paste.pocoo.org/show/136348/

its not as clean syntax as Fan's use of -> as we need to use strings/symbols for the method names in Scala.

I wonder if we can improve the syntax any from this...

foo.init() // static invocation

foo->'init() // dynamic invocation

patient renter said...

Thanks for posting this James!

I've used bits of your work over the years (remember Jelly?) and am pleased to see "high profile" developers such as yourself get behind Scala. Hopefully you'll continue your advocacy and we can all benefit from the future growth.

For me, Scala's appeal is its native support for mixins (stackable traits), something that I've spent a lot of time replicating via bytecode gen in Java. Once you get used to code reuse in this way, there's no going back. I think it makes Scala an easy sell.

James Strachan said...

@Darren here is an example of someone adding dynamic typing to Scala as an extension in a library (in a surprisingly small amount of code)

http://paste.pocoo.org/show/136348/

Bill Venners mentioned on Twitter that ScalaTest uses ~~> as the dynamically typed method invocation operator

http://twitter.com/bvenners/statuses/3559485683

Unknown said...

Hi James,

Great post and great comments all around. Certainly made me wanting to find out more.

My question:

Java's succeess was not purely based on it's technical features (relatively less complex vs C/C++, OO, memory mgmt etc) but that it was strongly backed by an Enterprise player (Sun) that did a lot (understated and under-appreciated I feel) to push it into the enterprise.

A fixed set of standards (some good, some bad, some ugly) that did not evolve too radically also helped gained traction in the enterprise environment.

A lot of enterprise decisions are based on product (in this case Java language) stability; of technology and arguably more importantly, the organization backing that product.

With the acqusition of Sun, the backing that enterprises look out for is basically pulled from under Java. (When I say backing, I meant the paradigm of growing Java as an open language platform as opposed to developing it like a typical Oracle application.)

Yes there may be a scramble for a javac replacement. But how does Scala address the concerns of enterprise biz?

Technically Scala, Groovy, Ruby etc may be superior, but I feel that unless there is a big push (marketing, evanglising, support, open standards etc) by an enterprise-strength player into the enterprise, there will never be a language revolution like what we saw in the adoption of Java.

Unless there is a paradigm shift in how enterprises conducts technology decisions, the most likely Java replacement will not be Scala or Ruby etc, it'll probably be M$' C# or its ilk.

Adam Crain said...

I agree completely. My opinion is that anyone that thinks Scala is too complex hasn't given it a fair chance. The bottom line is that it will simplify your code. Here's a writeup I did that shows how language evolution (well, just traits and closures here) can make even the most mundane code easier:

http://agile-automata.net/?p=14

Our Scala code base is *much* smaller and easier to test than the equivalent java code would be. It also doesn't stink of the maintainability issues associated with any large Ruby code base (don't even get me started on performance).

Actors + immutable data are a *powerful* way of handling synchronization issues when you're tying together things coming from different threads and 3rd party java libraries. We've haven't tried to really use them for any kind of multi-core performance gains yet, but they make it much easier to write *correct* concurrent software as compared to the synchronization/shared memory model.

Unknown said...

First of all, sorry for my bad english.

To the people who think Scala is difficult to learn or hard to read. In my opinion, it is because your way of thinking has adapted to Java. I had no problems with learning Scala, as it was my first programming language.

Zimbabwe vgtjbkjkij said...

@Erik:

"Batteries included" way to avoid try/catch/finally crap: http://www.scala-lang.org/archives/rc-api/scala/util/control/Exception$.html

jqb said...

GUIs are more complex than the command line; they will never catch on.

I've heard the same sort of arguments against compiled languages vs. assembler, structured programming, OO, functional programming, and plenty else. These are reactionary arguments, and they are always wrong -- which is not to say that the conclusions are necessarily wrong, but the logic is. All of these "complexities" were technical advances that furthered fundamental software design principles, some of which weren't widely recognized until after the advances had been made. Scala offers a remarkable number of these advances in a language carefully designed to be scalable and pragmatic -- ignore it at your own peril.

Amir said...

Well, I believe Scala has the potential to be the replacement for Java language, however the reality is it is not gonna happen unless there is something out there which can replace the Whole Java EE and all related technologies using scala... I mean it is not all about language capabilities and simplicity...I bet many of those organizations who have decided to go with Java EE to implement their huge systems would never have done that if it was just all about simplicity and productivity....
what is most appealing about Java for organizations is actually its solid and mature foundation which has been constantly improved during the last decade for developing huge enterprise system with maximum reliability, scalability, security and performance. So I think if scala was to be the next java, we would need something like Java EE specification but for scala, say 'SCALA ENTERPRISE EDITION', and I am absolutely confident given scala's capabilities it could be much better that Java EE in all senses... and just to be clear I am not talking about Web Development frameworks and I am aware of Lift Framework, but again I believe if we are willing to see Scala as the next Java we have to follow the values and philosophy behind Java Technology...
Java EE is neither PHP nor Ruby, consequently paradigms like CakePHP or Rails won’t be a game-changer for scala although it might grab some attention and put scala in competition with Ruby , Groovy , Python and others, but no way it will even help scala to get anything near a substitute for Java for developing enterprise systems.
The big pity is I really think Scala has everything that it takes to be the next face for Java Technology and makes Java stands a head and shoulder above all other rivals again after a few years falling behind; however the reality is nobody is gonna ditch the whole Java EE and all well-proven related frameworks and start using a framework like Lift to implement their big systems, but if there was something like 'Scala Enterprise Edition' then it would be too hard to say no to it, since it would mean that you would get all good qualities that you could have achieved using classic Java EE plus improved productivity, testability and maintainability and more importantly having happier programmers since they would be able to indulge their inner curiosity and creativity without screwing thing up or falling behind schedule since they would be working with a nice, conscious and flexible language.

Unknown said...

Coming from lots of Perl experience, I have no issue reading Scala, Ruby, Python code at the first glance. So Java folks, printing out "Hello World" isn't always System.out.println(...) :D

I personally find language constructs such loops in Scala, Ruby rather concise and easy to read vs C style (and Java copies that) ...

James Strachan said...

@Amir very good point. A lot of enterprises like the appeal of Java EE. Though increasingly those same enterprises often are happy to go the Spring route instead these days too (or other open source frameworks).

The nice thing is you can use Scala and Java EE or Spring and Scala makes both of them better; though quite a lot of Java EE and Spring is a bit redundant or could be done so much better (with real functions) in Scala.

Though gradually lots of things are improving. e.g. Scalate is now much better than JSP. squeryl is easier to work with than JPA/Hibernate and the various Scala options or DSLs for dependency injection tend to be better than the Java EE way.

The main thing thats missing is Oracle backing "Scala EE" :) though hopefully Martin Odersky's company can help?

MCAndre said...

If you think a complex type system is cool, read O'Sullivan's "Real World Haskell".

http://book.realworldhaskell.org/

Wanderson Santos said...

Guillaume LaForge is the father of Groovy with all Groovy Team. They are doing a wonderful job!

Father isn't those who create, but those who make you son grow.

IMO Groovy will be the long term replacement for Java because today just because it innovate! Groovy breaks the trade-off "dynamic language vs. performance".

For those who want to see: http://stackoverflow.com/questions/1404917/groovy-vs-scala-vs-jruby-vs-closure-vs-jython/6236500#6236500

Groovy is a corolary for "Premature optimization is the root of all evil" (DonaldKnuth)

Have a nice day forever!

Sujay said...

Interesting discussion going on the language choices we have on JVM today, I like what I see in Scala so far, also looking into the SLIM stack (Scala, Lift, MongoDB), seems extremely interesting.

BTW, check out Venkat Subramaniam: Scala/Groovy/Java etc. can be good friends :)

http://blip.tv/thirstyhead/interview-with-venkat-subramaniam-2504854

Shahen said...

James, it is really very strange situation, usually language creator is more optimistic about the result of his work.

But I assure you, you heavily underestimating groovy.
Groovy is very nice script languages which perfectly fits for some purposes.

It is like Lua for C.
So, thank you for this language.

LevoTZ said...

I think Java will be here forever like C, and C++, Fortran, Lisp.

Oracle is already planning to run javascript and other scripting languages on their JVM within their control. But I do not think they (especially Oracle) will like others hijack their JVM and try to make business on it.

I have been digging Scala for a week. It looks nice, makes you to say wow. BUT I fell like learning a new framework. :)

I did not like their exception handling. It's like having an accident while turning a sharp corner, and then seeing a speed limit sign. --too late--