In 2007 I established several professional development goals (and later reported my progress on these), one of which was to learn Groovy and Grails. This goal stemmed from the continually referenced idea from The Pragmatic Programmer to “learn a new language every year.” This idea has become so ubiquitous that it even has it’s own four-letter acronym, LOTY (Language of the Year).
Since establishing and reporting on these goals, I’ve had several things get in the way of fully realizing all of them. However, I can safely say that in the last two years I have mastered enough Groovy and Grails that they no longer fit in the LOTY category. At this point they’re really not showing my anything that is causing any paradigm shifts for me. They’re comfortable. When I learn a new feature, it just seems to make sense, and nothing surprises me anymore. Languages like these aren’t good LOTY candidates because one of the purposes of learning a LOTY is to challenge and change your ideas about programming. Groovy doesn’t do this for me anymore. It’s time to move on (not to say that I’m dropping Groovy and Grails as a tool – I’m using them more now than ever – they’re just not a learning tool for me anymore).
So, at this point I want to delve into a language that attempts to tackle the concurrent/multicore programming challenge. I’d like to stay on the JVM because I appreciate the benefits that it brings as a platform, so for now Erlang is out. The two leading candidates in the JVM/concurrent/multicore arena seem to be Scala and Clojure. An added benefit of both of these languages is that they support the functional paradigm, something I haven’t really played with since my computer science education days and a very interesting language named Haskell.
Scala is a multiparadigm language, supporting both object-oriented and functional constructs. It is statically typed, yet offers very nice type inference. Clojure, on the other hand, is a functional Lisp derivative with almost no OO constructs that is dynamically typed. Both are designed to enable concurrent programming. Which one do I choose? I open the floor for comments.
Posted by Mike Mayo on April 2, 2009 at 3:29 pm
I felt the same way after spending a year with Ruby on Rails. I love Rails, but there’s nothing new for me. While I haven’t gone after concurrency, I have gone into a functional/OO split with Objective-C and building iPhone apps. So that’s my LOTY
Keep posting! I want to know how this turns out.
Posted by Chris Roberts on April 2, 2009 at 3:47 pm
I vote for Scala. Besides having more of a following right now (and thus more books and resources), it’s a functional/OO hybrid, so it can server to ease you into the more functional Clojure for next year. Plus I hear Twitter is using it, so you know it’s cool
Posted by Mark Volkmann on April 2, 2009 at 5:06 pm
I vote for Clojure. If you want to learn about functional programming, I think you’d be better off using a language that isn’t an functional/OO hybrid. That will force you to do things in a functional way instead of slipping back into OO habits.
I wrote an article on Clojure that can help you get started quickly. See http://ociweb.com/mark/clojure/article.html.
Posted by Floyd Gantt on April 2, 2009 at 7:42 pm
+1 Scala
Posted by Ricky Clarkson on April 5, 2009 at 12:25 pm
I suggest Scala. Scala supports both FP and OO, true, but you can restrict yourself to a small amount of OO. I find that quite comfortable. Scala has a typesystem; functional programming with a typesystem is a very different experience to without.
That said, learn a lisp sometime, clojure or not.
Posted by mateusz.f on April 5, 2009 at 2:19 pm
+1 Scala
Posted by Matt on April 5, 2009 at 6:52 pm
Hmmmm….so currently it looks like:
Scala 4
Clojure 1
Yet the argument for learning Clojure is extremely compelling….I worked with Scheme while in college and it was quite a bit of fun toying around with a Lisp, and it would be interesting to try again. That being said, I hear a whole lot more about Scala and am intrigued by the buzz. This is a hard call regardless of the wide-margin in the voting….
Posted by Tim Dysinger on April 6, 2009 at 4:36 pm
+1 Clojure but by all means learn both and choose.
I choose Clojure after 5 years C/C++, 10 years of Java, 4 on Ruby and 1 yr each Erlang & Lisp. I like Dynamic and Functional.
If you like Static and AOT Compile then Scala. Both languages have really neat features.
One word of caution is that you can program imperative Java easy in Scala and it would be easy to fall back into old Java habits (not learning anything).
Posted by LOTY…Part Deux by Matt Stine’s Blog on April 6, 2009 at 10:32 pm
[...] A few days ago I pontificated on my need to choose a new “Language of the Year.” Right now I’m attempting to choose between Scala and Clojure. If nothing else, I’ve learned from this exercise that asking the community for feedback is a GOOD thing. Your comments have been very helpful. [...]
Posted by Greg on June 2, 2009 at 11:53 am
As much as I’m interested in scala, and am looking at how to “sneak it in” to my current project, I say go in deep for clojure. Why/how?
I stumbled across a fantastic online book “Practical Common Lisp” http://gigamonkeys.com/book. It shows real-world samples of using Lisp, including writing a unit test framework in less than 50 lines of code, along with an MP3 database and HTML generation library. At least the introduction chapter. It hooked me.
Now for the kicker, another guy wrote a corresponding blog, showing the equivalent solutions in Clojure! http://blog.thinkrelevance.com/2008/9/16/pcl-clojure.
Posted by Anthony on June 12, 2009 at 11:36 am
If your goal is to learn and expand your mind, definitely Clojure.
Nothing like a Lisp to show you how powerful a programming language can really be.
If you go the Scala route, you’ll just end up using the same constructs you are comfortable with, so where’s the learning?
Posted by Kanwa on August 7, 2009 at 6:48 am
Please don’t attempt Scala or Clojure. Neither any scripting lang.
Stick to Java as you will face problems related to data type.
Eg: Can you tell me what types are passed here in the function argument
public void runMyFunc(dob, favy)
{
}
If long code(> 500 lines) like the above one is written, we never will understand
what’s happening in the code and worst if you check your code after say two
months, you will weep to understand the code because you don’t know what is
dob or favy is.
You will break your head on try to figure out what “dob” is –
an object or int or what?
Your LOTY shud be FOTY (F- Framework of the year)
Cheers,
Kanwa
Posted by tek on August 16, 2009 at 10:42 am
@Kanwa: Scala is a static typed language, no “scripting lang” or dynamic lang.
Posted by kanwa on August 30, 2009 at 11:19 pm
Oh Telo!
Sorry if I sounded wrong. I did not mean to say that Scala is a scripting language.
I just meant that don’t learn scala (or) scripting languages.
For the quote you mentioned “Scala is a static typed language” part, I beg to differ
as I found this in the home page of scala under Introduction:
“Scala is a general purpose programming language designed to express common
programming patterns in a concise, elegant, and type-safe way.”
What is this type-safe way they mentioned? you know better
Thanks
Kanwa
Posted by mawdo on November 1, 2009 at 11:59 am
I’m at a similar stage and have taken a look a detailed clojure [and an inital squint at scala and erlang] and have been pretty impressed – clojure feels my natural next step having work a long time with traditional OO and more recently with ruby and DSLs – I’ve been describing my ruby based DSLs a kind of macros that inflate my ruby env – a principle you’ll see embedded in clojure – the other shift clojure brings for me is functional programming and I’m trying real hard by practicing thinking in this way – its kinda of like the way you had to force yourself to think set-level RDBMS or the XSLT processing model in the past
ruby reignited my programming fire – clojure have added another boost
Posted by Steve on November 12, 2009 at 8:40 am
@Kanwa
Please at least do a little bit of Google leg work before commenting on these languages. You state that:
”
Stick to Java as you will face problems related to data type.
Eg: Can you tell me what types are passed here in the function argument
public void runMyFunc(dob, favy)
{
}
”
While your argument is one that I would agree with (loss of legibility due to lack of types) Scala does not suffer from this problem – your example would have to look something like the following:
def runMyFunc(dob: Date, favy: Int) {}
Looks pretty statically typed to me!
Later you make this comment:
”
What is this type-safe way they mentioned? you know better
”
Exactly *what* are you talking about? Do you have a different definition of type safety than everybody else? Perhaps it would interest you to know that Scala is *more* strict about types than is Java.
Next time use The Google. It is your friend.
Posted by Carl on April 6, 2010 at 3:36 am
Another comment to/at Kanwa:
Perhaps a brief Googling of Scala didn’t leave behind the correct impression. Kanwa worries about losing types in Scala. Nothing could be further from the truth! In fact, my personal impression of Scala is that it is a programming language built around an obsession with types.
Scala is one of those languages where “everything is an object,” including numeric constants, and they all have a type. There are cases where Scala will guess a type for you from context (this is called “inference”) but except in this case, everything is and needs to be very solidly typed.
Martin Odersky, the main author of Scala, is the same person who built the generics extensions for Java 1.5 (or so). Yes, his very code is in the Java runtime! Generics in Java is a bit half-assed for compatibility reasons; in Scala, he was able to pull all the stops, so Scala handles generic types very pedantically. In working with Scala, you will see messages about type related errors that other languages wouldn’t even have known to detect! But on the upside, you do get some of that pleasant effect of (explicitly) statically typed languages: Once you get your program past the compiler, it’s forced you to think hard enough about the code that chances are it’s free of logic errors as well.
As for FOTY: Blech! Everybody and their dog are building new, improved mousetraps every week. Having absorbed a handful of them, I’m starting to feel diminishing returns from chasing after ever newer ones. There comes a time when meta-meta-meta-programming is not more concise than actually coding what you mean.