Thursday, April 21, 2011

And the best JVM replacement language for Java is: Java?

Although I use Ruby (mostly Rails) and Common Lisp on many customer projects, I am heavily invested in the Java platform and I don't see that changing in the next ten years or so.

Java is more than a little heavy on ceremony however, and I would like a really agile language for the JVM. I have used Clojure a lot in the last year for work on one customer's project but at least for now the lack of concise and useful runtime error backtraces kills some of the joy of using Clojure. Really nice language and community however, and I expect in a few years Clojure may be my primary JVM language. I love coding in Ruby and the JRuby developers do a great job moving the sub-platform forward. However, except for large Rails applications, I don't see myself writing very large applications in Ruby: for me Ruby is a scripting language for getting stuff done quickly and easily. I do like Scala but the learning curve is steep and that means that it is difficult to find pre-trained highly skill Scala developers.

Java has the sweet spot of lots of great tools and a rock solid infrastructure. So, how to make Java more agile? I do a few things that help: I use public attributes so I don't bother with getters/setters anymore unless I am using a framework that needs them for introspection. I very much like JPA, but I am growing less fond of the rest of the Java EE 6 stack - really a lot of layers between designing and writing code and runtime; too much abstraction for my tastes. The Play! Framework is great, in general, and I am using it on my personal project and I look forward to seeing how Play! develops as an agile platform over the next few years.

14 comments:

The Careful Programmer said...

I'm interested in your opinion about using Groovy and Grails. AS Groovy seems the oldest and more mature of the Java.next languages.

Mark Watson, author and consultant said...

I never got into Groovy, mainly because of performance problems (although it is probably faster now).

J.F. Zarama said...

Same experience here; I've invested significant time with both Clojure and Scala; as I work with Clojure I like it very much until I work with Scala and I like it also but for different reasons.

But inevitably when we have a serious projet to do, we gravitate to Java, Netbeans, Git, Guice, Google Guava Collectons++ library, Apache Click or GWT, MyiBatis and Jersey for REST with a couple of experiments using CouchDB via Jersey.

The difficulty with Scala and Clojure is getting a team to work with these JVM languages; the learning phase goes beyond the languages; there is a large ceremony, often with religious tones, determining which IDE, build and source versioning control to use.

We will keep reading and experimenting with both Clojure and Scala but for project work, I suspect Java will remain the main language for our projects for several years to come.

Dmitry said...

For what tasks do you usually use Common Lisp? Isn't Ruby sufficient for them, especially JRuby as it can access to tons of java libraries?

Shantanu Kumar said...

With respect to unreadable backtraces, see if this can help (v0.3):

https://bitbucket.org/kumarshantanu/clj-miscutil/src

;; On Clojars: [org.bituf/clj-miscutil "0.3"]
(ns foo.app
(:require [org.bituf.clj-miscutil :as mu]))

(mu/!
.. your code here that throws exception ..
foo)

This should remove undesired stack frames and pretty-prints the stack trace.

Mark Watson, author and consultant said...

Hello Dmitry: it is both a performance issue (compiled Common Lisp is very fast) and I find very large programs written in Common Lisp to be a little easier to maintain. For me, Ruby's sweet spots are Rails/Sinatra apps and shorter utilities (up to a few thousand lines of code). Coding in Ruby generally makes me happy, but it is not for everything.

Hello Shantanu: I just tried that. The first few lines of summary stack trace information is more helpful. The rest of the stack frame dump is verbose and fairly much useless to me. I would like Rich to make a wrapping like org.bituf.clj-miscutil/! to be a configurable (optional) global default.

Mark Watson, author and consultant said...

Hello J.F.: I bet that your experience is very common: keep experimenting with new technologies but rely mostly of solid mature tools. I agree that choosing tools that the team is comfortable with is of first priority.

All that said, there has been some incredible work with less mature tools like Clojure in areas like Hadoop processing, machine learning, etc. One thing I like about Clojure, (J)Ruby, and Scala: the communities are smaller, seem more enthusiastic, and the authors and maintainers of these languages are very approachable.

Shantanu Kumar said...

Hello Mark, thanks for your feedback on the ! macro. I will try to improve it in the next version -- if you have any suggestion on what configuration you may like to see, please let me know. I agree that such a thing might as well be part of Clojure as a configurable default.

patrickdlogan said...

Hi Mark, I suspect Java will remain the dominant jvm language for the foreseeable future. Presumably the complexities of "enterprise" java will continue to be eliminated. Restlet is another good path there.

I also had a good experience with groovy and restlet. For personal projects though I am currently focused on common lisp: sbcl natively and abcl on the jvm.

Mark Watson, author and consultant said...

Hello Patrick: Thanks for the pointer to Restlet - I just downloaded the stable version for JSE and JEE and mirrored some of the documentation: I have three long airplane rides in my near future and I'll enjoy taking a look.

I don't argue at all with the choice of Common Lisp. My problem is that I tend to split my "lisp time" between Common Lisp, Scheme (mostly Gambit-C), and Clojure. I like all three for very different reasons.

Fracking hell said...

Hey Mark,
Would love to see a blog related to the Play! Framework. Loved the article but the comments were the icing on the cake.

Mark Watson, author and consultant said...

Hello FH: I will probably write about the play framework sometime since I am using it for a personal project right now. My setup is simple: I run "play run" in a terminal window and have an IntelliJ project set up with all Play jar dependencies for nice editing with code completion, etc. I also put all of my non-UI Java classes in separate packages in the "app" directory so those are automatically recompiled as I edit them, just like the controller classes. Fast and agile.

Steven said...

I have to say that I've tried almost every web development framework out there, including Rails, Django, Seaside, you name it... I always had a problem with scripting languages because my brain just doesn't seem to work well with them. I guess that the product of a C++/Java Computer Science education. I started using Play! a few months ago and never looked back. I had to leave Java for the Rails-type frameworks because of the productivity gains. I have to say that with Play! you get the best of both worlds.

opensas said...

About your play setup, I usually place my own java code on a lib.xxx package, and they also get automatically recompiled...
BTW, I'm also lookinf forward for a play framework article...