I love to anticipate trends in the industry, because it can give you that warm fuzzy feeling of betting on the right horse. Particularly, I find satisfaction in seeing a small, welcoming community grow and slowly observe fellow programmers adopt a language, framework or technology that I deeply care about. This is the type of evangelism that I like: bringing to the attention of other programmers innovations that I find, which can make us more productive or help us produce better software. It’s a matter of awareness, there is no intention of pushing anything on anyone.
When a critical mass is reached, you are on top of the wave, ready to help out and already a sufficient expert on the given subject. This was the case for me with the first beta releases of C#, at a time when most developers didn’t have a clue about this new programming platform (.NET). Later in the years, I found myself in a similar situation again when I got into Ruby before Ruby on Rails made it so popular.
It’s not an easy game because there are so many options, a plethora of interesting languages and frameworks. Time is limited and it’s very easy to bet on the wrong horse. Even studying a language with a lot of potential, which is going to be the Next Big Thing™, doesn’t have an immediate payoff. In fact, both C# before its commercial success and Ruby before Rails, weren’t likely to land me many jobs. But eventually they both did.
The reasons behind the desire to spend time and resources on learning something new, shouldn’t only be the prospective of getting a good job. It’s rather the joy of learning new concepts, letting the mind bend and forge to a multitude of paradigms, within different communities and environments. Having the right motivation is key. The monetary gain is more of a byproduct. To quote from The Pragmatic Programmer:
Learn at least one new [programming] language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut.
So a few months ago I asked myself, what’s next now?
Before I decided what language was worth studying in depth next and even before attempting to suggest the same to my readers here, it’s important to clarify what are the characteristics that I considered the most in picking my choice. I mentioned a different paradigm as a first requirement. As the Turing Award laureate Alan Perlis put it:
A language that doesn’t affect the way you think about programming, is not worth knowing
For me, this pretty much excluded languages which were too similar to the ones that I had already well endorsed (e.g. Perl or Smalltalk).
We are also at a turning point in the development sector, because CPU producers are focusing on the production of multiple cores/processors rather than trying to merely increase the speed of a single CPU. This, more than the raw speed, introduces a radical change of requirements for programmers. If we have 2,4 or 16 cores, we better start thinking about how to develop applications that take full advantage of them. Concurrent and parallel programming can be quite tedious and error prone when adopting languages that are not designed for these requirements. Ruby’s current lack of native threads is then particularly unfortunate in these scenarios, as it implies that Ruby will take advantage of a single processor only.
My third requirement, which further specifies the first one, was that the programming language needed to be a functional one. The ever growing software complexity requires the power of high level abstractions and the functional paradigm which helps us adopt a more declarative programming style where the side effects are marginalized.
There are two programming languages I mentioned a few months ago which meet these requirements quite well: Haskell and Erlang. About a year ago I started to show an interest towards both of these, mostly favoring Haskell, despite Erlang’s excellence in concurrent scenarios. In 2006 however I mostly put aside my interest for them, trying to focus on improving my existing skill-set. Having covered the basics of Haskell and Erlang quite some time ago, it was about time for me to make a decision and pick my new challenge.
Many folks blogged about the Pragmatic Programmers announcement about a book on Erlang, written by the language’s author Joe Armstrong. This is excellent news because there is so much need for an authoritative and accessible book on the subject. So much so, that I informally proposed to the Haskell community to get in touch with Dave Thomas if interested in producing a book of this caliber for Haskell.
Erlang is very tempting, and I’d buy that book just to promote the writing of excellent books on less common subjects. We don’t need the Nth book on Java, we desperately need great books on not so popular and emerging topics like Haskell, Erlang, Clean, OCaml, D, etc…
The Pragmatic Programmers have been very influential in the Open Source community and they have surely contributed to the success of Ruby. There is no doubt that they will be crucial for Erlang too. Their Erlang book won’t be the only reason why I think Erlang is going to be more popular than Haskell in the long run though. Despite this, my choice is Haskell, and I’ve been concentrating my efforts on gaining in depth knowledge about it.
Haskell is an extremely easy to learn programming language… Sorry, I couldn’t say that with a straight face. Let me rephrase it: Haskell is an easy to learn language if you’re a mathematician. But it’s definitely not the easiest one for the average programmer. This may cost Haskell a lot in terms of its popularity. Erlang is easier to learn if you come from an object oriented/imperative background because, unlike Haskell, it is not purely functional. However I absolutely love the radical paradigm change in Haskell, the Monads, the referential transparency and the lack of side effects. Plus I think it’s the right tool for developing solid and reliable software systems for the future. It’s an extremely advanced programming language, that makes you reconsider the way you think about programming. It is quite possibly one of the few programming languages which is able to expose the limits of, gasp… Ruby. It can be very complex for many, and I’d love to contribute towards making Haskell easier to learn, but let’s not forget that it is not expected to be very easy or become as popular as Ruby. It is instead expected to be powerful and able to produce less bug prone programs. To quote E. W. Dijkstra:
The proper technique is clearly to postpone the concerns for general acceptance until you have reached a result of such a quality that it deserves acceptance. It is the significance of your message that should justify the care that you give to its presentation, it may be its “unusualness” that makes extra care necessary. And, secondly, what is “general”? Has Albert Einstein failed because the Theory of Relativity is too difficult for the average highschool student?
It is very likely that other languages will keep integrating features, particularly from Haskell for the functional side and from Erlang for the concurrent model, but I’ve chosen to give a shot to the “real thing”. I love the technological advantages that Haskell can provide me with and it has been my biggest personal interest for some time now. It’s a very beautiful language which I recommend wholeheartedly to the most adventurous Ruby and Python programmers.
If you are interested in exploring Haskell, the official wiki has a lot of information. In order to take the first steps, I do suggest the following though:
And lastly, you can take this article as an announcement about my future entries on Haskell in this blog.
No related posts.