Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Dionysios G. Synodinos on Jul 09, 2009
Scala has been receiving much attention lately as a possible candidate to replace Java in the future. James Strachan creator of Groovy advocates in favor of Scala as James Gosling, creator of Java and Charles Nutter JRuby Core Developer, have done in the past.
James first explains the things he doesn’t like about Java:
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.
He seems impressed by Scala to the point of saying that he wouldn’t have created Groovy in the first place, if Scala was available back then:
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.
There are of course parts of Scala that he’s “not keen on”:
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._).
In any case, James overall opinion about Scala is far better than Java’s:
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.
As Adam Bien has reported in his blog, even the father of Java, James Gosling seems favorable towards Scala:
During a meeting in the Community Corner (java.net booth) with James Gosling, a participant asked an interesting question: "Which Programming Language would you use *now* on top of JVM, except Java?". The answer was surprisingly fast and very clear: - Scala.
Charles Nutter, JRuby Core Developer thinks that Scala is most likely candidate to replace Java, compared to Groovy and JRuby:
Scala, it must be stated, is the current heir apparent to the Java throne. No other language on the JVM seems as capable of being a "replacement for Java" as Scala, and the momentum behind Scala is now unquestionable. While Scala is not a dynamic language, it has many of the characteristics of popular dynamic languages, through its rich and flexible type system, its sparse and clean syntax, and its marriage of functional and object paradigms. The supposed weakness of Scala as being "too complicated" or "too rich" can be countered by developing coding standards, creating more robust editors and tools, and by better educating polyglots on how best to use Scala. Scala represents the rebirth of static-typed languages on the JVM, and like JRuby it has also begun to stretch the capabilities of the platform in ways Java never could.
Scala was one of the main themes in this year’s JavaOne, with several related sessions and even an open space conference which followed the last day of the main conference.
What do you think, is Scala the most suitable contender to take Java’s place in the near future or is Java the Last Big Language (LBL)?
IMHO, I do not think that Scala may actually replace Java. Although Scala seems to appear as the most powerful language for the JVM, I still see it to co-exist with Java. Although some new projects with Scala fans may avoid Java, Java may still have a good share as a JVM language. We cannot forget those legacy applications, where thousands of lines of code are written in Java.
This is similar to how the .NET platform supports many languages, though C# is the most recommended, there are still many people who sometimes only use Basic (for VB), while there are still some others who use a mix of the CLR supported languages.
The Java replacement is not Scala - it is Clojure. Seriously, take a look at that language.
Exactly. It seems that Java will never replace C++
Clojure is awesome, but there's no way that a Lisp will replace Java.
I think the question isn't whether or not legacy apps will be converted to Scala, or that Java the language will stop being supported, I think its more a question of, "If Java goes into legacy/maintenance mode, will there be a new de facto language for the JVM? And will it be Scala?"
The Java replacement is not Scala - it is Clojure. Seriously, take a look at that language.
No, it's Brainfuck or maybe COBOL
I do think that Groovy is a beautiful language in the fact that it is dynamic, has all these great features like closures, MOP, AST, Grails :)
All of these things are great, but the fact that it is not strictly typed and just not enough IDEs truly support it well (providing refactoring support for example), will always hold it back.
Scala's support in IDEs is still mature also (probably more so than Groovy), but it is strictly typed and the fact that it is a hybrid functional and OO makes it attractive.
I think that both Scala and Groovy will end up replacing Java at some point.
Scala will become the new Java and Groovy will continue chugging along in scripts and any needed dynamic usage that will be needed.
I think that the Grails and Lift frameworks should seriously think about collaborating. Grails is way ahead in the game and is starting to take off in terms of all of the plugins that are being written for it.
These make for huge productivity gains.
Where Scala excels is in performance that for sure.
I'm wondering how Groovy and Scala compare in their Concurrency model.
Will they ever surmise Erlang?
Maybe I'm wrong but at the moment I don't see strong support of Scala from big IT companies.
Instead Groovy is already well supported from them: SAP (Composition on Grails), IBM (sMash), Oracle (GroovyMBean/Grails) and obviously SpringSource.
Remember that with these companies Java would never have been a success.
I discuss this on my blog The puzzled-programmer. I think that operators use as method names should be reserved for very special cases. Other than that I vote for Scala because of the static typing and the performance that is about the same as Java. Two other strong points are the pure object model and the better implementation of generics (declaration site variance).
we hear that "Java is a surprisingly complex language" - and this is true, mostly because of the inconsistencies and surprises that backwards-compatibility has demanded (arrays, type-erasure in generics, etc).
but in all fairness it must be said that Scala is a hellishly complex language as well. it's far removed from the beautiful minimalism that, for instance, old-style functional programming languages exhibited. the reasons for Scala's complexity are more varied than in Java's case, though:
- backwards-compatibility is still an important reason for complexity: Scala runs on the JVM and so type-erasure in generics is still an issue; add to that the new complexity of interfacing Scala with Java classes. i believe Scala has achieved the optimum in hiding these complexities, but they are still there.
- innovation: compared to Java, Scala introduces conceptual complexity arising from its object-functional nature and powerful language features: first-class functions and the way they are implemented on the JVM; generalised control structures and in particular "for" expressions; traits; modules and how to use them for componentisation; case classes and pattern matching; proper variance for generics; structural types; implicit conversion; and quite a bit more. this is the complexity that's fascinating to master, because it is really the reason-to-be for Scala. but it's still true complexity to master...
- surprises: a few aspects of Scala just seem unnecessarily complex/different to me: import statements; packages and the new access modifiers (that are not enforced on the JVM at runtime) come to mind.
don't get me wrong: Scala is in most respects truly fascinating and a pleasure to use. but to contrast it with "complex Java" is misleading...
cheers,
gerald
www.gerald-loeffler.net/
Null is a subtype of everything. I'm guessing this is probably for backwards compatability with java.
For your paying job, learn action script.
For java replacement and joy of programming: D! D is butter.
.V
Null is a subtype of everything. I'm guessing this is probably for backwards compatability with java.
Yes, Null is the subtype of all reference types. However, for all intents and purposes this is something that as a Scala programmer you don't have to worry about. As this is the case, it is hard for me to see how this qualifies as the 'worst thing about Scala'.
The Java replacement is not Scala - it is Clojure. Seriously, take a look at that language.
What, that's it? Perhaps you could elaborate on the features that have you so enthusiastic.
having null being a subtype of everything breaks the type system :) if A is a subtype of B then you expect to be able to use A wherever B is expected. Having a type that can be substituted for any type and throws exceptions when you try and use its behaviours destroys some of the safety you get from the type system.
I might be wrong, but I think we are slowly moving to an era where the programing language is becoming less relevant. With the advent of DSLs, an entire Zoo of languages will co-exist - the higher on the abstraction level, the more specialised the language. Actually, this is already reality today, but will probably increase in the future. Getting the right mix will be crucial. However, I see the purpose of discussions like this one especially that many people are asking themselves what is the next language that is really worth my time / investment?
I think that its too hard to tell what language is the "right" language, so what I would say is the best thing to do would be to familiarize yourself with a range of languages. Then when you really need to learn a specific language you'll be more prepared.
Consider:
- Scala's interoperability with Java definitely makes it far more complex than Haskell or OCaml. But they also make adopting it far easier. As an experienced Java developer and an awful functional programmer, I found moving to Scala easy because I could start out by writing my code in the regular imperative/object oriented manner, just using Scala's syntax. I still had tremendous benefit because type inference, Scala syntax rules, Scala getters/setters and Scala tuples make Scala code far more concise than equivalent Java. I also have a good shot at getting Scala code accepted for production at work as a Java-based language. Selling management and the other developers at a Java shop on Python, Ruby, Haskell, and so forth is much harder.
- Scala has its own generics, which do not use type-erasure. If your Scala code uses Java generics, you keep the type-erasure problem, but not if you are using Scala's own generics.
- I'm no genius at software development, and especially not functional programming. So I admit, Scala's functional features are dizzying. But the ideas and uses of case classes and pattern matching (Think Java "switch" on steroids. No, actually, think Java "switch" turned into a 9 foot super-strong cyborg.), traits (This is multiple inheritance done right! Both powerful and also very easy to understand.), and even first class functions (Think java.reflect.Method, but far easier to use and more flexible) really are not that difficult to understand for a developer without a grasp of functional programming.
- No question on the surprises. There do seem to be some confusing corner cases. But overall, I would say that Scala's complexity cost is well worth paying for the features it adds.
Having been through two of these transitions (C to C++ to Java to ?) I tend to think of Scala as Java++. C++ was like C in many ways but had it's own idioms and style. C programmers transitioning to C++ could continue to write C for a long time, and Scala (also Groovy for that matter) allow Java programmers to continue to use Java (perhaps using a couple of the simpler improvements but avoiding the weird-looking features).
WIll Scala take over from Java? Normally I'd be the first to pour scorn on such a notion. But now - I don't know. Sun was an imperfect Java controller but Oracle looks to be much more restrictive:
www.zeroturnaround.com/blog/renaming-javarebel/
www.apache.org/jcp/sunopenletter.html
If Oracle tries to make Java into a brand - strongarm legal restraint of use of the trademark and keeping Apache from being able to test their Open Source version of the language - they could wind up driving an exodus from Java to ? (Scala, Ruby, Groovy)?
I don't want to be dependent on a 'branded' language at the core of my skillset. It's one reason I've avoided C# thus far (though that may change soon). If Oracle tries to make Java into another C# I might have to reconsider. Micro$oft may prove a more enlightened master than Oracle.
Have you seen ESME?
Null is a subtype of every class that is a subtype of AnyRef. Null is not a subtype of Any or the subclasses of AnyVal.
And, yes, since you can use any Java class as if it were a Scala class, "null" must be supported.
Scala has type-erasure. It's parameterized types are not existential, like Java's, and that does provide for a stronger type system, but type-erasure (ie, type parameters do not exist at run-time) is still present.
Thanks to point me to this nice project. Maybe in the future the big companies will "directly" support Scala too.
Scala is a hybrid Object-Oriented/Functional Programming language on the JVM. When I heard that Twitter was using Scala, I was curious and started collecting all the sites and articles to learn scala programming. If you are interested check the link below for the big list I have gathered (more than 200 sites) for learning scala programming.
markthispage.blogspot.com/2009/06/more-than-100...
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
24 comments
Watch Thread Reply