While I do enjoy learning, there are tons of technologies to know these days. I currently write all server side software in Java and all client side software in Flex (unless the client platform requires something else - like Television channels I've written that absolutely required BrightScript). If you know Java, why would you learn a language like Clojure? If you were wanting to expand your skills, would you learn something like Clojure or would you focus on some other language?
Alvin Watkins wrote:If you know Java, why would you learn a language like Clojure? If you were wanting to expand your skills, would you learn something like Clojure or would you focus on some other language?
With Java / Flex as your primary development technologies, you're steeped in OO which is certainly the mainstream paradigm these days (and has been for most of the last two decades). Knowing more than one paradigm is useful, however, since it lets you examine a problem from several different points of view. I highly recommend Bruce Tate's "Seven Languages in Seven Weeks" which takes you on a whirlwind tour of Ruby, Io, Prolog, Scala, Clojure, Erlang and Haskell. Tate introduces each language as a character (e.g., Prolog is described as Dustin Hoffman's Rain Man) and teaches you just enough to show you why each language is unique and what it can teach you about problem solving and just thinking differently. You'll notice there's a heavy emphasis on languages with a function programming aspect.
So, why would you learn a language like Clojure? For the leverage that knowing a functional programming style can bring you.
I'm a long time OO developer: I started with C++ in '92 and picked up Java in '97. I'm working a lot with Clojure right now. Immutable data means easy concurrency and the pure functional nature means small, easily testable, highly reusable components. The Java interop is excellent - in fact I just blogged about writing a custom appender for log4j and the code was just a few lines. That's the other nice benefit of functional languages: they tend to produce much more concise code because of the much higher level of expressiveness. I'm seeing about a 10x reduction in code between Clojure and Java in general.
What about other languages that could offer similar benefits? If you're working on the JVM and need Java interop, your only other real choice is Scala in my opinion (there are certainly other great languages that you'd learn a lot from - but let's focus on functional programming on the JVM). I like Scala and took a project to production with it last year. Whilst I feel more productive in Scala than Java - due to type inference as well as the functional style - I find I'm still more productive in a dynamically typed language that I can treat like a scripting language, hence my choice of Clojure.
Try Tate's book - see what resonates with you. Even if you don't pick up any of those languages for projects, just reading the book (and doing the exercises - very important!) will teach you enough new things to improve the way you approach problems in Java.
Joined: May 25, 2011
Thanks so much for the thoughtful reply Sean. That's great. I will read Seven Languages in Seven Weeks. That sounds like an excellent resource for me.
I also know some scripting languages - like ColdFusion - and I have noticed a lot more speed to develop in that language. A good example is creating an SHA hash. In CF, it is one line to do that (<cfset hashedValue = Hash("SHA" "string_i_want_hashed")> whereas in Java it takes this:
Thanks again for your input. I'm absolutely getting that book.
Alvin Watkins wrote:I also know some scripting languages - like ColdFusion - and I have noticed a lot more speed to develop in that language. A good example is creating an SHA hash. In CF, it is one line to do that
That's down to the rich runtime library, more than the language. In Clojure you'd have to dip into the Java layer to create a SHA hash and it's arguable whether the resulting code would be better or worse. Java's habit of having void return types on mutators means you're forced into a more procedural style:
Rather than a more functional style:
Because of that, in Clojure you'd end up having to use doto and multiple "procedural" expressions, something like this (untested):
At that point I'd probably create a few helper functions to wrap the Java code and clean it up, especially if I was going to use base64 stuff and/or MessageDigest elsewhere, and add type hints to avoid Java reflection (and therefore improve performance):
So, overall, it's no shorter than the equivalent Java, although I now have some convenience functions that might be usable elsewhere. This second version has been tested and seems to work just fine, with no Java reflection happening.
If you don't like the inside-out nested function calls in get-sha256, that could be written: