April 2009

It's April and that means that I should look at the new programming language for the year soon. Thus far, my leading candidates for the next one were all functional languages (in particular, Erlang, Haskell, or Scheme). Then, yesterday, through Slashdot, I read this interview with the Twitter team discussing replacing some of their Ruby backend stuff with Scala.

I'd heard of Scala before. Some time ago I ran across Ricky Clarkson's post explaining what (0/:l)(_+_) means. (For those of you who don't want to read the post, the Ruby equivalent is something like l.inject( 0 ) { |x,y| x + y }.) A little poking around lead me to David Pollak's post comparing Ruby on Rails to his Scala-based Lift framework. (However, it's been over a year since then and I think that Rails has made some improvements but I have no hard data or anything really beyond my respect for the Rails developers since I think they're pretty smart people.)

I have been going through the online tour of Scala periodically and some of the features look interesting. The major issues I have currently are the use of the JVM and the typing overhead of static typing but both are minor. It definitely has allure.

As I think about it more, I am not sure that Scala is the correct way to approach functional programming for the first time. In his comparison of Scala and Erlang, Yariv Sadan calls Scala "an OO/FP hybrid." This certainly seems to be true. And while being a hybrid is not necessarily a bad thing, it may not be conducive to properly learning functional programming. It's like learning to swim for the first time. If you're in the shallow area of the pool, learning to properly swim isn't that big a deal because, if something goes wrong, you can find the bottom of the pool and stand up. If you're in the deep end of the pool, you'd better know how to swim or find a way to get out of the deep end real fast.

The proper thing to do then might be to learn a proper functional language (Erlang, Haskell, and Scheme all have their fair share of proponents) and use those in their own right for a while. And then, next year, having some of that understanding and practice, come back and look at Scala and see how to merge OO with FP using Scala.

As mentioned elsewhere, I maintain the local copy of this site through a combination of subversion and Piston. Sometime in the past couple months, version 2.0.1 (and now version 2.0.2) of Piston was released and, when I updated my local Ruby gems, ended up upgrading.

Piston 2 allows for the ability to use Piston with Git as well as subversion. This requires significant changes to the backend. So in order to use Piston 2 with existing Piston-managed copies, you must first upgrade those copies to use Piston 2's new format. This can be done with piston upgrade.

Piston 1 stores all of its backend information as properties within subversion. Piston 2 instead saves it to a special file, called .piston.yml, since properties are not available with Git. To use this with a public site, access to .piston.yml should be blocked. This can be done with this directive:

RedirectMatch 404 /\\.piston.yml$

After doing all of this, I encountered a bug with Piston. Every time I tried to update a Piston-managed directory, I got an error like:

/usr/lib/ruby/gems/1.8/gems/piston-2.0.2/lib/piston/svn/revision.rb:30:in `check
out_to': Did not get the revision I wanted to checkout.  Subversion checked out
280, I wanted 280 (Piston::Svn::Revision::InvalidRevision)

280 is equal to 280, isn't it?

I'm not sure why this behavior would manifest. I did not see anything on it. I suspect it may be an issue with the upgrade process. A simple, hacky solution was to change line 29 from:

          elsif revision != $1.to_i then

to:

          elsif revision.to_i != $1.to_i then

(I haven't filed a bug report on this but I will shortly.)

After doing this, Piston ran normally as expected and I could install the pending updates for the Drupal modules.