Tuesday, September 28, 2010

Expert Tools



Quick snipits on the internet should be taken with a grain of salt and a little bit of thought.

There are two newer languages with a lot of momentum in the software world, Scala and Clojure. Both of these languages have strong pedigrees, Scala from Erlang and Haskel and Clojure from Lisp. Both languages offer great support for functional programming, a relatively new paradigm for most business developers. A direct consequence of the increased power of these languages is the barrier of entry is high for your typical developer who has only worked with object oriented code.

Anyone who was coding business systems around late eighties remembers the shift from pure a pure imperative style of programming (think C) to object oriented programming (think C++ and Java). The recall the skepticism that OO based systems will never perform, they remember the critics who thought the paradigm shift wasn't necessary and would be too difficult for developers to pick up. For those who were around in the late eighties the software climate of today should seem vaguely familiar. It is.

Now back to my first point about quick snipits and thinking. This quick snipit between the author of Scala and one of it's primary contributors was posted up on Artima:

Bill Venners: Some people lately have expressed doubt whether Scala is a language for the average Java programmer. What's your opinion?

Martin Odersky: Scala at the moment doesn't need to be a language for the average Java programmer. The programmers we want to appeal to are the expert programmers—the good programmers. Our aim is to make them much more productive than they are with Java. I believe over time there will be enough teaching materials and enough good tools to also make Scala appeal to more average programmers. But that's not what our immediate aim is, and I think good programmers can become more productive with Scala now.


This post was quickly linked to on Twitter and discussion ensued. Twitter to its credit and detriment, only allows for 140 character posts. This means you don't have to spend a lot of time reading through superfluous text but it can be difficult to explain things. The conversation went like this:

Me:
Both Scala and Clojure are not for the novice. At our last Clojure meetup the consensus was we're happy the barrier of entry is high

That being said I think there is a lot of value in beginner material with a solid progression for both languages.


Smart Developer:
Why would you be happy that the "barrier of entry is high"? I don't see any benefit to that.


Me:
Keeps the tourists at home. If someone takes the time to learn Scala or Clojure then they really want to be a good developer.


Smart Developer:
This is the kind of disturbing elitism that has cast Smalltalk and Lisp into obscurity and irrelevance, Scala deserves better


Woah. The key to my explanation is "wants to be a good developer." Anyone who has spent time developing tools knows that you often have to strike a balance between power and ease of use. Elegance exists when you are able to provide both. Scala has a low barrier of entry for Java developers who want to get started with it. However, to reach the intermediate stage and to be able to understand code written by others Scala presents a high barrier of entry. I personally think this is a good compromise for adoption, allows adventurous folks to get started and you don't pay the complexity penalty until you need it. The only issue is the barrier to intermediate Scala developer is rather high and can be a bit intimidating. However, the power through access to higher level patterns is amazing.

Clojure on the other hand has an initial high barrier of entry. Prefix notation combined with everything being immutable makes it difficult for folks to figure out how to get started. Once someone gets past this initial hump the language gets easier and many folks feel the complexity decreases. During the last Denver Clojure Meetup one of the members commented that they were glad the barrier to entry for Clojure was high, that way you know folks who are trying to learn Clojure are dedicated to taking the next step, to learning advanced tools and to becoming better developers.

I've spent a significant amount of time developing presentations on Clojure for the Denver Java User's Group, the Denver Open Source User's Group, the Boulder Java User's Group, and the Colorado Springs Open Source User's Group. I've presented five times in the past year on Clojure and spend my free time working on teaching examples. I truly want to make Clojure and immutable/functional programming accessible to whomever would like to learn. I stand behind my statement concerning the high barrier of entry, folks need to want to put effort in to gain access to the power provided by Clojure and Scala. If there is an easier way to provide access to these advanced power features I would welcome that level of elegance whole heartedly, it would save me a lot of time spent studying.

4 comments:

  1. I agree with you 100% in your experience-analysis of learning curve of scala and clojure. Hoewer, i think learn both langs (and haskell) help to understand each one (i talk about the "good part", intimidating one, of scala, not the easy plain oop fishhook).
    And talking about hook i think this is the key of one of diffs of philosophy of two langs. Scala was designed to be a better java for the elite (hopefully with the crowd following them) of java developers. XML native support, patterns injected in language core (like decorator) are symptoms of this.
    And that is a double-edged weapon. The price of being an hybrid and satisfy beginners and the aristocracy of statically typed computer scientists is more complexity, in a similar way c++ did in 90's. Odersky had to advocate for complexity not long time ago.
    All this sound pejorative but it doesnt. That is the scala way and i like the baroque composition of abstractions that gives you all power of haskell,ml and the old (still good) oop.
    OTOH Clojure was not designed with that ground. Simplicity and minimalism is the key, the features are strictly chosen. The lisp syntax is terse and tends to be invisible. Clojure was not created to subsitute java,ruby,python,scala or any language and nor for conquer the enterprise. And that is other double edged weapon.

    ReplyDelete
  2. Great post Dan. Can't agree more on the bias ..

    One would require to unlearn OO to learn FP. Seeking a tool with a middle ground (like Scale) with OFP capabilities will cause one to slip into their bad habits of state + identity conflation.

    In my case, I stepped back and spent a bunch of time learning Lisp and Scheme before plunging into clojure. The benefit of this approach enabled be to think more effectively with Clojure and Scala.

    Scala and Clojure has managed to attract an awesome community (less noisy, more productive)

    ReplyDelete
  3. As someone who suffered seeing his lisp code rewritten into mainstream I must agree with "This is the kind of disturbing elitism that has cast Smalltalk and Lisp into obscurity and irrelevance, Scala deserves better". Programming is team work.
    Also what do you mean by barrier of entry is too high? It might be high for someone who coded nothing but whatever c-flavor he's using at work for years and thinks of it as THE WAY. But lets have a group of beginners starting with java vs one group starting clojure I'll bet my life that the latter with outperform the java group by several times.

    ReplyDelete
  4. I love that quote from Martin. Mostly because I was sitting with him and Bill at last year's Scala Lift Off when Bill recorded it. :)

    I think that the important thing that's needed to get over the complexity barrier is to show how most of the functional idioms are actually cleaned up and simplified design patterns that developers are already familiar with and using. I find that Scala is much more challenging for developers who write Java like they write C than for developers who have already embraced factory, strategy, dependency injection, visitor et al.

    ReplyDelete