views:

905

answers:

11

For the next 3 years I will have to work with the JVM (project requirement) using a very specific third party API. They want Java but I've been given leeway to move away from Java. I was hoping we could move back to the .NET framework so I could develop code in F#, being absolutely in love with OCaml. .NET development has been struck down by our customer. It is a no go.

I've turned to looking, reading, and poking around programming blogs/forums trying to understand which language might appeal to me further: Scala or Clojure. Those seem to have the largest community/fan base. Being experienced with ML languages I see lots of people who compare Scala to ML. However, there are some real naysayers when making this comparison. If Scala was that close to ML my productivity and learning curve would benefit making this switch.

The internet is full of misinformation and wonder if I'm suffering from such. I don't like the syntax of Lisp (don't hurt me!) but if Scala has the warts I'm reading (poor IDE support, in flux Unit testing framework, performance issues) I'm wondering if Clojure is the better option. I want to be productive out of the gate, using functions as first class objects, and minimizing concurrency pain.

So anyways, before I spend too much time on the internet and not working... I'm stuck with the JVM, sick of Java and wondering where to go?

A: 

Noop? http://code.google.com/p/noop/ (experimental though)

UpTheCreek
Can't go with something too experimental. That's why I was limiting myself to Scala/Clojure. Scala has already been shown to work in industry while Lisp has been around for ages.
wheaties
+7  A: 

Have you considered Groovy? I don't think it is quite as functional as Scala/Clojure, but it's certainly a lot more functional than Java**. In general, I can get the same work done in Groovy with about 50% of the code it would take me in Java.

This is because Groovy is syntactically similar to Java and provides seamless access to the JDK libraries, but the addition of a lot of language features (closures, meta-programming, properties) and dynamic typing eliminates almost all the boilerplate associated with Java programming.

** I mean functional in the sense of 'functional programming' rather than 'working correctly'

Don
Groovy is a great suggestion. It's similar enough to Java that it doesn't necessarily inspire fear in the hearts of Java houses, but it's similar enough to Ruby that it's a lot easier to be concise and expressive and try functional-style solutions than with plain Java.
Chuck
Groovy, huh? I'll have to give that one some thought! Thanks for your answer. That would make the very good point Oscar Reyes brought up in his post about me working in one language, the rest working in another less of an issue.
wheaties
That's right. But it seems Groovy has lost most of its momentum, and who knows if it'll get it back? (I have no data to prove this, other than the fact I see it less often mentioned now than the other alternatives).That said, watch out for Groovy's performance. It's definitely a lot behind Clojure's and Scala's. Plus, since you come from ML, you will find yourself quite limited on the functional programming side of the things.
Daniel Jomphe
Groovy's sweetspot is to be used as a scripting language. From what I remember, it aims to bring dynamic typing to Java and a few functional features, and etc.
Daniel Jomphe
Don
Don, you're right. I should have restrained myself to saying Scala and Clojure seem to now have more momentum.
Daniel Jomphe
That's probably true, but I'd attribute much of the coverage they've been getting to their newness, rather they any great success or large user base. I reckon there are a lot more developers using Groovy regularly than Scala and Clojure combined, but I've exactly zero evidence to support that statement :)
Don
While I have been accused in the past of dissing Groovy, I'll take this opportunity to point out that calling Groovy APIs from Java is a non-issue, while care must be taken when designing Scala code to enable seamless calling of Scala APIs from Java. Note that neither language has any problems calling Java APIs.
Daniel
So one way calling is seamless but backward compatibility with Java has to be approached with care? This is food for thought. One more reason I should give Groovy a much more thorough look even if it isn't functional in the FP sense.
wheaties
+2  A: 

Tool support for Scala and Clojure may be immature, but it's steadily improving.

Since you like F#, then Scala is most likely your best bet. I say try it out and form your own opinion - you might find that the things people gripe about are things that don't matter to you, or things you can work around.

Christian Vest Hansen
+1 for the scala vote.
Stefan Kendall
You're probably right.
wheaties
+6  A: 

Quite frankly, get another job.

If you are to spend the next three years feeling uncomfortable on what you're doing, you should consider looking for more attractive alternatives.

Even if you manage to get a language you like, if you are part of a team ( which I guess you are ) the rest of the team might not like that language. If the rest of them code in Java and you in "fill in the blank" programming language, then problems may arise.

It is not that bad after all.

Talk with your boss, let him know how do you feel. Start looking for alternatives and have a nice and professional "leave".

There is no reason why you can't still have a good relationship with your current boss. If eventually they have a new project for .net you may come back. Talk about that also with them. Leave your doors open.

OscarRyz
Oscar, you raised a good point with me working in one language, the rest in another. Although I have talked to my bosses and they're ok with me going this route as long as my productivity increases. I won't leave a job just because I don't get to work in my language of choice.
wheaties
+4  A: 

Its not really a zero sum game, learn them all!
ps: i vote for Clojure, i find it the most fun!

Arthur Ulfeldt
+17  A: 

In my opinion, both Clojure and Scala don't have great IDE support, if that's really important to you. That said, here's what I can collect from my reading & experience.

Scala's pros

  • Faster than Clojure thanks to more static typing
  • Closer to ML (syntax, type-directed programming)
  • Bigger standard API (Clojure's APIs grow very slowly, because they want to make sure they find the best idioms before making them public. That said, Clojure still has semi-official supplementary APIs)
  • Better integration practices with the typical Java toolset (Clojure is still making some choices, so less firmly established yet on this regard)
  • Older than Clojure (but Clojure is built on top of a very old and proven core: Lisp)
  • People say it has chances to reach mainstream, while they wouldn't say the same about Clojure

Clojure's pros

  • Incredibly easy, fast and right concurrency thanks to MVCC-based STM and other concurrency mechanisms
  • Immutability by default helps doing the right thing first
  • More stable standard API
    • When things change, usually you don't have to rewrite any existing code
    • (Scala's collections are being remade again for 2.8)
    • (I have also read somewhere that it's common knowledge that Scala's Actors implementation needs a rethinking and rewrite.)
  • Easier to learn (small language, being a (very-clean) Lisp)
  • An opportunity for you to grow by learning something different
  • Clojure's performance will only get better with time; there's still room for nice optimizations in the compiler
  • Scala's tying to Java feels more limiting than Clojure's (interactions between Scala's and Java's static type systems). One could sometimes say the same about Clojure (Object-Orientation's support is not a 1:1 fit, but support for this will soon get better)
  • Rich Hickey has a gift for making choices that put Clojure in the position of having technical leading features that will be adopted by other languages in the decades to follow. And he also has a gift for explaining them. So use them today in Clojure, or wait to use them in another language in some number of years. :)

On distributed concurrency

If your concurrency needs are distributed, Clojure doesn't yet have anything for this unless you run it on top of Terracotta or something similar, in which case you'll be able to use all its concurrency features. If you do, you will end up with a better distributed concurrency experience than with Scala's Actors, IMO.

Conclusion

IMO Scala tries to do everything, and succeeds at doing most of it. Clojure doesn't try the same thing, but what it focuses on is more than enough and succeeds so well that most people really knowing Clojure wouldn't want to go back to something else. Disclosure: my personal preference goes, of course, to Clojure. I hope I've been able to be objective in what I wrote.

Daniel Jomphe
You've been very objective and informational. I hadn't heard about Terracotta. One more thing to bring to my boss. Thanks again.
wheaties
You're welcome. That said, if you consider using distributed concurrency with Clojure, make sure you search/ask the clojure google group about it; they have sometimes mentioned other choices besides Terracotta. Who knows if one of these would be a better fit for your project? I suggest searching the group for "terracotta", you'll find all discussions related to this matter, with lots of great insights.
Daniel Jomphe
+4  A: 

You should consider yourself lucky that you can use the JVM, because the JVM is becoming more and more popular for alternative programming languages than Java.

Besides Java there's Groovy, Scala, Clojure (a Lisp dialect on the JVM), JRuby (Ruby on the JVM), Jython (Python on the JVM), Jaskell (Haskell on the JVM), Fan (runs on the JVM as well as the .NET CLR) and lots more, and there's also an OCaml-Java, OCaml that runs on the JVM.

So, there's lots of choice in programming languages on the JVM, from purely functional to simple scripting and anvanced OO languages.

Jesper
It's been years since the last time I took a look at Fan. Interestingly, it looks much more interesting than Groovy! "Productivity of Ruby, Performance of Java". See http://www.fandev.org/
Daniel Jomphe
Lol, I am lucky to be using the JVM but I can always have hope that one day I'll find myself working with a language which mirrors all my loves. Didn't mean to come across as totally opposed to the JVM. I'm more opposed to working with Java and all its warts. Before I get flamed... All languages have warts, it's just which ones you're willing to handle.
wheaties
That's right, Java, the One language under the Sun with Dozens of Thousands of Classes in its APIs. :D
Daniel Jomphe
+9  A: 

I'll address the points you raised about Scala.

  • IDE support:

    Scala doesn't have the same level or IDE support Java has -- or, for that matter, that F# should have with VS10.

    That said, it has one of the best (maybe even the best?) IDE supports on JVM, outside Java. Right now NetBeans is good enough, and people have consistently said IDEA is still better (hearsay). The Eclipse plugin is unstable though.

    But you mentioned a 3-years range, and the IDE support for Scala should be greatly enhanced once Scala 2.8 is out, as it will provide some compiler-support for IDEs. There's no release date defined, but it looks to be within the next six months, maybe three. And the Eclipse plugin will be updated right along with it.

  • In flux unit testing framework:

    Yes, if you meant it is vibrant, evolving and well supported, instead of stagnant and abandoned. ScalaTest, Specs and ScalaCheck are top quality frameworks, compatible between themselves, and compatible with other Java frameworks and libraries, such as JUnit and JMock.

    The testing frameworks, in fact, are almost a child poster of what is possible with Scala.

    EDIT: Scala has basic unit test support in its standard library (scala.testing.SUnit). However, given that many superior, actively-supported and free alternatives have appeared, this has been deprecated and will likely not be part of the library shipped with Scala 2.8.

  • Performance issues:

    I'm unaware of any, aside from the fact that you can write lousy code, just as with any other language. People not used to functional programming will often do stuff that's not efficient, such as not using tail recursion, or concatenating lists, and the paradigm shift that Scala enables brings that to light.

    At any rate, you can write Scala code as fast as Java code (even faster with some upcoming features). And you can write Scala code with functional features almost as fast as Java code.

Daniel
Daniel, if I could I'd give you a bump in reputation. What you say is very true of the IDE support. On unit tests, I had thought I had found misinformation regarding these. There were conflicting views from "SUnit is being deprecated" to "JUnit doesn't work on Scala." Thank you for clearing that up.
wheaties
Ah! That makes sense. I'll complement the answer, but the short of it is that Scala (still) comes with a Unit test in its standard library, which is SUnit. While better than nothing, it has long been surpassed by the third party alternatives.
Daniel
A: 

In terms of IDE support and other doubts you're having, Clojure doesn't do any better than Scala. And for a person with ML/F# background (or generally that in strictly, statically typed FP languages), you'll definitely find Scala much closer to what you're used to.

Pavel Minaev
Damn. I was hopeful it might. Thanks.
wheaties
+1  A: 

Don't forget jRuby, and note that IDE requirements are less critical for non-Java

I think you have a great situation. How many people get permission to choose the implementation language? With everything available for the JVM having your environment chosen is not much of a restriction.

  • You won't need great IDE support in the less verbose languages
  • You won't really need an IDE at all in something like jRuby that doesn't declare parameter types
  • Scala was developed specifically to cure the verbose-java-blues
  • Count yourself lucky that you have three years of work lined up :-)
DigitalRoss
You're right. I am very, very lucky that I've been given permission to explore languages. I have heard wonderful things about Ruby. Hasn't it been described as "Perl without the baggage?" However, does it reduce concurrency pain? The client would like to see more emphasis on scalability.
wheaties
A: 

If you like ML you might like CAL which is more-or-less Haskell 98 for the JVM.

It is high quality and very stable, and has good IDE support on Eclipse, but sadly is no longer under active development.

tdavies