The Rise of the Functional Paradigm
In yesterday’s address to the Ruby community, Dave Thomas invited Rubyists to fork Ruby, to freely research and experiment with new and interesting features. If this process is successful, many of these features will inevitably see their way back into Ruby’s core, thus improving the language in leaps and bounds. And I feel he couldn’t have been any more right. In fact, the whole industry is experiencing the trend of incorporating features developed in less common languages, research languages, “toy languages” if you prefer, within mainstream ones.
Experimenting with these alternative languages is important because occasionally they themselves become widely used, and even when they fail to do so, they lend their insight to the world of software development, finding their way into other languages. This approach greatly accelerates the development of common languages for the good of their large user bases and the improvement of the software industry. It’s a win-win situation for everyone involved and for the development community as a whole.
Pay attention to the development community online, and you’ll quickly notice a few non-mainstream programming languages appear over and over again. I’m referring to languages like F#, Erlang, Haskell, Scala and Clojure. I’ll admit to a certain selection bias, given that I tend to hang out in communities where hackers and developers actively pursue the betterment of their programming skills, beyond the stereotypical 9 to 5 requirements. But nevertheless, three or four years ago the average developer probably wouldn’t have heard about any of them (at least the ones that existed at the time). And today all of these languages have active communities, books being published about them, and most programmers have at least encountered some of these names.
They are all different languages, but their common denominator is the functional paradigm. Notice that I titled this post “The Rise of the Functional Paradigm” and not “The Rise of Functional Languages”. In a sense the latter is true as well, since there’s been much more attention towards functional programming languages lately. But there is a subtle difference. I don’t expect purely functional languages to become the most used programming languages anytime soon. For the foreseeable future, I don’t predict US companies to outsource Haskell jobs to India or China, like they do today for Java or .NET projects.
Yet these functional languages serve a higher purpose. Not only do they satisfy the needs of intellectually curious developers and companies looking for a competitive advantage, but they also have a great deal of influence on the rest of the development world.
We are seeing a convergence between these two groups of languages. Functional languages will strive to become as useful as possible, with libraries and tools that are more adequate for mainstream developers, while conserving their functional purity (I’m looking at you almighty Haskell). Meanwhile, mainstream languages will slowly adopt powerful features found in these functional and other research languages, adding further expressiveness and capabilities to their largely adopted foundations. F#, the evolution of C# and the addition of LINQ should be enough evidence that this is the case at least for the .NET platform. And even C++0x and D are leaning towards the incorporation of some functional features (e.g. lambda expressions and closures). The two types of languages come from different directions but will reach a similar destination.
The ever increasingly popular Ruby, Python and JavaScript owe their success to several factors. And while they are considered multi-paradigm and were mostly aided in their popularity by their immediacy, simplicity, usefulness and a set of historical circumstances, they’re all hybrid languages that adopt functional features. The functional paradigm is becoming so common, that it’s hard to imagine seeing any new programming language rise to fame without including at least a subset of the features available in other functional programming languages. As developers, we’ve grown to expect the elegance of functional features in a language. No lambda, no party.
If the 90s were characterized by the rise of the Object Oriented paradigm, and this decade can be considered as a transition phase, then the future belongs to the functional paradigm. Whether developers prefer to mix this with other paradigms (e.g. in languages like Ruby, Python, C#, etc…), like a powerful cocktail, or shoot it straight down (e.g. in purely functional languages like Haskell), the functional paradigm is here to stay.
Take this survey and win a free ticket for the Professional Ruby Conference
Addison Wesley will hold their first Professional Ruby Conference in Boston, Massachusetts between November 17 and 20, 2008. This conference, for which Obie Fernandez is the Technical Chair, is highly educational and boasts some of the best speakers from the Ruby and Rails communities.
The organizers were kind enough to invite me, offering me a complimentary pass for the Professional Ruby Conference. I won’t be able to attend, so I decided to donate my free admission to one lucky reader. They also provided me with a priority code (like a coupon) for my readers, which entitle you to receive a $200 discount off the regular admission price.
I really value your opinions and I’d appreciate it if you could take this survey, so that I can improve the quality of this blog. At the end of the survey you’ll receive your $200 discount code, and will be entered into my draw for your chance to win one free ticket. I will announce and get in touch with the winner early next week (Monday or Tuesday depending on participation levels).
More on Fibonacci. Oops, Sorry Lisp… Haskell runs it 5 times faster
My post about Ruby 1.9′s impressive improvement over Ruby 1.8.6 created quite an echo within the developer community. Sure, the headline was an attention grabber, just like this one is 
, but in a matter of a few hours, there were all sorts of blog entries with variants in many languages, more than 200 comments on Reddit, and fifty comments on my own blog. There were however, also a few misconceptions. It was great though because such a simple post generated a lot of discussion amongst developers, with some insightful arguments taking place – and besides it almost created a new meme with the whole “holy shmoly” thing. Fun as that certainly was, let’s try to summarize and clarify a few points.
First and foremost, for those who stopped at the title of the article and didn’t read on, I made it very clear in several places that I didn’t even begin to predict that Ruby 1.9 will be faster than Python 2.5.1 when it comes to real world applications. I ran a simple micro-benchmark where this just happened to be the case. Chances are that Python will have the edge in many instances, especially if we consider that it has several optimized libraries which may still be missing or suboptimal in Ruby. Within the scope of the recursive Fibonacci’s test, which essentially stress-tests method/function calling, Ruby 1.9 seems to be more than 13 times faster than Ruby 1.8.6, but within the Ruby community it’s well known that this improvement factor is not very often replicated in other micro-benchmarks or actual applications.
Ruby is improving, its progress is impressive, so let’s drive this point home and try not to speculate too much. Someone also pointed out Ruby’s lack of Unicode support and in other cases, its disadvantages over Python. That’s missing the point, the article isn’t aimed at comparing or claiming that one language is better than the other. The essence of the message was and remains, that Ruby’s main interpreter — which was typically fairly slow — will soon be replaced by Yarv, which will drastically improve Ruby’s speed, to the point where perhaps it will be comparable with the not-too-fast but acceptable CPython. And yes, even for Python there are psyco and pypy both of which would change the outcome of my test. With this out of the way, let’s move on.
Dima Dogadaylo and my friend Valentino Volonghi both blogged about a much faster version (they employed the use of generators) of my Python snippet. Many other people in this blog and on Reddit proposed faster algorithms too. That’s all well and fine, but it really compares apples and oranges. If we switch from a naive recursive algorithm to an iterative one, even Ruby 1.8.6 will be faster and able to compute the task in a few moments. The computationally expensive and inefficient recursive algorithm should be used by those who want to compare other languages with my results, otherwise the comparison will be meaningless. Using a fast language to implement a slow algorithm is always going to be slower than using a slow language with an efficient algorithm, for N sufficiently large.
The Fibonacci function is mathematically defined as follows:
In the intentionally naive and recursive algorithm I adopted in my original post, I essentially wrote the mathematical formula in Ruby and Python syntax, and then executed it for n in a range that goes from 0 up to 35. This is very inefficient, because the tree-recursive process generated in computing F(n) grows exponentially. We have:
F(0) = 0
F(1) = 1
F(2) = F(1) + F(1)
F(3) = F(2) + F(1) = F(1) + F(1) + F(1)
F(4) = F(3) + F(2) = F(1) + F(1) + F(1) + F(1) + F(1)
F(5) = F(4) + F(3) = F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1)
F(6) = F(5) + F(4) = F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1) + F(1)
…
You can see where this is going. The recurrence relation generated by the algorithm, implies that we execute 3*F(n) – 2 lines of code (for n nontrivial). When n=35, this is a huge number, since F(35) = 9227465. Now you can see why the algorithm really stress-tests function calling and why Ruby 1.8.6 chokes. If we want to evaluate the computational complexity of the algorithm in terms of big-O notation, we have O(phi^n), where phi is the Golden Ratio and equal to (sqrt(5) + 1)/2. That’s exponential. Valentino, Dima and many others came up with variants of iterative or tail-recursive algorithms, whose complexity is linear (O(n)). Using memoization (the technique of keeping a cache of the previous calculations) or a simple iterative loop changes the algorithm’s efficiency. The difference between my original algorithm and these others is humongous and there is no point in comparing them as a means of evaluating the runtime speed of a given language. At that point we could very well use Binet’s formula, or Edsger Dijkstra’s algorithm or even 2×2 matrix exponentiation, but we’d not be proving any point there. If you want to learn more about algorithms (a necessity for any serious programmer), I strongly suggest the introductory textbook “Introduction to Algorithms”.
Don Stewart, a real celebrity in the Haskell community, has replied to my post with two articles that essentially illustrate a couple of points that are not new to many people: 1) Haskell is fast, much faster than Python and Ruby, 2) Haskell’s ability to take advantage of multiple cores by following parallelism hints placed in the code for the compiler, is just plain awesome and easy on programmers. Don did use old versions of Ruby and Python, but I appreciate his response a lot, because he kept the same algorithm in place. He didn’t bait and switch, using one of the many fast implementations available on the Haskell wiki. His fair comparison showed, despite the very limited scope of the test, what kind of performance we can expect from this functional language’s main compiler (GHC).
As I said in the past, Haskell really is a language worth getting excited about. But it’s not all about performance and the trend of increasingly multicored CPUs. So I’m glad that we have both Ruby and Haskell with their strengths and weaknesses. While Ruby 1.9 will hopefully give us a runtime that’s seriously fast enough™ in most circumstances, it’d be nice if in Ruby’s future there were features that allowed us to take advantage of multiple cores, just like Haskell does without cumbersome code modifications.
Amongst the other replies there was a mix of everything, including Assembly and LOLcode, but I’d like to point out the post by a lisper, who took the Haskell vs Lisp approach in “Dude, your quad-cores have been smoking way too much Haskell!”. He runs the following code, first for n=45 and then for n=4500:
(defun printfib-trec (start end)
(format t "n=~D => ~D~%" start (fib-trec start))
(if (< start end)
(printfib-trec (+ start 1) end)))
(defun fib-trec (n)
"Tail-recursive Fibonacci number function"
(labels ((calc-fib (n a b)
(if (= n 0)
a
(calc-fib (- n 1) b (+ a b)))))
(calc-fib n 0 1)))
(time (printfib-trec 0 4500))
On my machine this runs in 3.291 seconds. Algorithm 101, guys. Quick question for my readers: how can an algorithm that is supposed to be O(phi^n) execute in 3 seconds, per n=4500? Simple, it’s that blogger who is being naive and not the algorithm that he adopted. If you pay attention you can see that he’s trying to compare the linear O(n) tail-recursive implementation of Fibonacci in Lisp, with the naive recursive one in Haskell, and from this he concludes “Oops. Sorry Haskell…”. Slow down, cowboy! You want to compare Lisp with Haskell? Let’s do a fair comparison then. Let’s keep the same algorithm for both and use n=45, shall we?
Here is my naive/recursive Lisp version:
(defun printfib (start end)
(format t "n=~D => ~D~%" start (fib start))
(if (< start end)
(printfib (+ start 1) end)))
(defun fib (n)
"Naive-recursive Fibonacci number function"
(if (or (= n 0) (= n 1))
n
(+ (fib (- n 1)) (fib (- n 2)))))
(time (printfib 0 45))
And here is the Haskell one:
import Control.Monad
import Text.Printf
fib :: Int -> Int
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
main = forM_ [0..45] $ \i ->
printf "n=%d => %d\n" i (fib i)
On my MacBook Pro, Intel Core 2 Duo 2.2 GHz and 2 GB of RAM, Lisp (well sbcl, which supposedly uses both cores, though there is no documented proof of this) took 259.743 seconds. See the difference between O(n) and O(phi^n)? Try n=4500 with this algorithm and the sun will have burned out before the computation is finished. Haskell, used only 1 core, and took 77.779 seconds. Hmmm, Haskell was 3.3 times faster than Lisp without even parallelizing it.
Just out of curiosity, let’s try again with Don’s code which still implements the same algorithm (whose complexity is O(phi^n)), but which introduces parallelism hints for the compiler. Remember, this is being done out of curiosity, we already established that for this particular micro-benchmark Haskell smokes Lisp away.
import Control.Parallel
import Control.Monad
import Text.Printf
cutoff = 35
fib' :: Int -> Integer
fib' 0 = 0
fib' 1 = 1
fib' n = fib' (n-1) + fib' (n-2)
fib :: Int -> Integer
fib n | n < cutoff = fib' n
| otherwise = r `par` (l `pseq` l + r)
where
l = fib (n-1)
r = fib (n-2)
main = forM_ [0..45] $ \i ->
printf "n=%d => %d\n" i (fib i)
Now that Haskell’s program uses two cores (assuming that Lisp does too, which is unlikely), Haskell runs it in 52.248 seconds versus Lisp’s 259.743 seconds. That’s about 5 times faster than Lisp. Does this prove that Haskell is faster than Lisp in general (or to be more exact, that GHC is faster than sbcl on Mac OS X 10.5)? Nope, guys it’s just a silly micro-benchmark after all. But damn the temptation to say “Oops. Sorry Lisp…” was too strong. 
Ruby, Python, Haskell and Objective-C Feed Survey
Having little time to follow the blogosphere and its crazy rhythms of publication is not a good enough excuse for not being up to date. This rings particularly true for me as a technical evangelist at IBM, and as someone who is deeply passionate about the development and the information technology world. The biggest challenge is to quickly and efficiently divide the wheat from the chaff or, in other words, filter out the noise from the overload of signals put out there. For me, feed readers are life savers, I couldn’t cope without them.
I recently adopted a setup that seems to be working particularly well. I purchased NetNewsWire for my Mac and FeedDemon for Windows, and automatically got a one-year subscription to the online premium service from the fine folks at newsgator. The two programs are a joy to use, especially for handling very large group of feeds in a short amount of time, as I often need to do. Each program automatically synchronizes with the newsgator service, therefore no matter which computer I’m using, I’m always dealing with the same folders, subscripted feeds and saved clipping. Sure, there are free services out there like Google Reader or Bloglines, but to me there is no comparison between the experience that I have when using a sluggish web interface and a rock solid, well designed desktop application. If I have the option, I’ll always choose the latter, especially since newsgator allows me to take advantage of a centralized repository of feeds from my desktop programs, just like as if I were using their online service through Firefox. For a few dollars, I got a setup that is working awesomely well for me and it’s saving me huge amounts of time. It also helped me to identify non-updated blogs, and those that I was no longer paying attention to, therein allowing me to reduce my over-all amount of feeds (granted with a conscious effort on my part) to a more manageable total of 160.
As mentioned above, my subscribed feeds are important to me, with a list that changes dynamically over time, as I add and remove entries. That said, I was looking at my Ruby and Rails folder when I decided to share my feeds with you. The list is understandably incomplete (after all, there are thousands of Ruby related blogs) and the presence of planets, aggregators and tags in bookmark services like del.icio.us, generate a few unavoidable duplicates. These are the Ruby/Rails blogs and sites that I currently subscribe to:
- alternateidea.com
- antoniocangiano.com
- blog.codahale.com
- blog.fallingsnow.net
- blog.grayproductions.net
- blog.innerewut.de
- blog.jayfields.com
- blog.leetsoft.com
- blog.segment7.net
- blog.talbott.ws
- blog.zenspider.com
- blogs.thoughtworks.com
- brainspl.at
- chneukirchen.org/blog
- dablog.rubypal.com
- db2onrails.com
- del.icio.us/popular/rails
- del.icio.us/popular/ruby
- demo.mephistoblog.com
- drnicwilliams.com
- eigenclass.org
- eli.thegreenplace.net
- errtheblog.com
- glu.ttono.us
- groups.google.ca/group/comp.lang.ruby
- groups.google.ca/group/rubyonrails-talk
- headius.blogspot.com
- hivelogic.com
- intertwingly.net/blog
- memeagora.blogspot.com
- metaatem.ne
- mir.aculo.us
- ntschutta.com/jat
- nubyonrails.com
- ola-bini.blogspot.com
- on-ruby.blogspot.com
- onestepback.org/index.cgi
- peepcode.com/products
- planetruby.0×42.net
- pragdave.blogs.pragprog.com/pragdave
- rubyblogs.org
- rubyforge.org
- ryandaigle.com
- tomcopeland.blogs.com/juniordeveloper
- twsummary.blogspot.com
- weblog.jamisbuck.org
- weblog.rubyonrails.com
- www.adaruby.com
- artima.com/buzz/community.jsp?forum=123
- chadfowler.com
- clarkware.com/cgi/blosxom
- cornetdesign.com
- danwebb.net
- igvita.com/blog
- jroller.com/obie
- juixe.com/techknow
- loudthinking.com
- oreillynet.com/ruby/blog
- pjhyett.com
- quotedprintable.com
- railscasts.com
- railsenvy.com
- robbyonrails.com
- rubyinside.com
- rubyonrailsblog.com
- rubyquiz.com
- slash7.com
- softiesonrails.com
- technorati.com/tag/ruby
- technorati.com/tag/rails
- therailsway.com
- urbanhonking.com/ideasfordozens
You can download the file Ruby-Rails.opml to easily import all of the above feeds into your own reader.
Since I’m sure there are plenty of other “must have” Ruby feeds and blogs that are not currently on my radar (no word of a lie, I’ve already added more since I put the list together), I openly invite you to write a small entry in your blog as well, and show us what feeds you subscribe to. Please link back to this original post, or I won’t be able to easily find your answer. Consider it a sort of Ruby and Rails feed survey.
And since we’re on the topic, and the amount of feeds that I follow is dramatically reduced now, I’d like to extend an invite for you to do the same thing with Python/Django, Haskell, and Objective-C, assuming you are into any of these communities respectively. Those are the languages that interest me the most and I’d like to start following a good selection of feeds on these topics. If you don’t wish to blog about it, or use the comment section below, you can always write me privately at acangianoATgmail.com, specifying if you are okay with me crediting your list to you. I’d like to collect and organize the most interesting ones in a “results” type of post.
I thank you in advance, as I think it’s an interesting “experiment” that can be quite useful, especially for those who are just starting to learn any of the languages above.
23 Programming Languages compared through their Amazon book sales
Technical books are a topic that interest me a lot. From book sale figures and trends we can attempt to better understand where developers are putting their money, not only their mouths. For this article I decided to perform a small experiment, by collecting some interesting data. I considered 23 fairly well known programming languages, and searched for the top selling book (according to Amazon) for each of them. The Amazon sales rank allows us to compare the success of books representative of each language, and indirectly compare the popularity of the languages themselves.
Below is the resulting table with all the data organized by sales rank:
Despite the limitations of the methodology employed (see disclaimer for details), I think this table gives us a nice picture of the status of our industry. I’ll let the data speak for itself, and allow you to speculate in the comments, but I’d like to point out a few interesting aspects of the resulting data.
According to the table above, it is clear that the once widely adopted Delphi is now much less prominent (consider that there are more recent books on Delphi, and that they have even worst sales ranks). This of course, does not take into consideration the fact that Delphi may have great documentation online, but I doubt that this would end up penalizing Delphi books that are on the market to this extent. Java and .NET on the other hand are doing very well. No surprise there. Also it doesn’t come as a surprise that Javascript is, thanks to Ajax, so widely popular on Amazon. Notice how developers seem to be embracing the study of dynamically typed languages, even though statically typed ones are still predominating. C, despite its age, still keeps our industry going. What I found surprising was the sales rank of the Groovy book, I honestly thought Groovy was a much more limited phenomenon. Regarding the functional paradigm, functional languages are slowly becoming more adopted, but it’s clear to me that the paradigm is being accepted by most when incorporated within existing Objected Oriented languages rather than in its pure form as seen in languages like Haskell for example. Speaking of Haskell, I’m sure the data will change a lot when the new book Real World Haskell hits the shelves. And that’s what the Haskell world really needs, because Haskell is often presented in an academic way which is hard for a wide audience to digest, and it is considered too theoretical by many.. It’s no wonder that 150 of us, fired off an email in reply to a request for reviewers.
You may notice that the fourth most popular book on the list is a “10 minute” type of book for SQL. This is ironic but it doesn’t contradict the anecdotal evidence, as real world experience suggests that many developers don’t really know SQL, and they resort to quick guides as a remedy while working on a given project. It’s a shame, because database and SQL understanding are essential skills needed to be successful programmers in many areas. To conclude, by looking at the table, it is apparent that the Pragmatic Programmers are definitively influential. Let’s face it, they contributed a great deal to the growth of the Ruby community and are now helping edge forward Erlang’s popularity. According to other data available on the web, Erlang should have been somewhere at the bottom of this list along with Haskell, but the Pragmatic Programmer’s book on this language has already presold many, many copies (it will be published in mid-July). It is clear that this book is going to be a best seller and that it will do a lot to promote the language itself. This is absolutely a good thing, because Erlang deserves the spotlight. By looking at the column of publishers, one can’t help but notice that O’Reilly truly successfully markets its books, and they are generally highly regarded by us developers.
Disclaimer (Or… wait a second, dude!)
- The method that I used didn’t account for books related to frameworks (Django, Rails, Seaside, etc…). The Agile Web Development with Rails book for example, has an incredible Amazon Sales Rank and it’s one of the best sellers of all time in our field;
- This methodology favors languages that have a book which has been widely adopted within the community, as opposed to languages where sales are split relavitely equally amongst a few titles;
- Not all languages are represented here of course. I just picked a reasonable selection;
- Amazon is not the only place on Earth where books are sold. But I think it’s still a fairly accurate indication of the US market;
- The Pragmatic Programmers sell many of their books directly, the sales ranks shown here don’t take this into consideration, so chances are they are underrepresented;
- The links to Amazon have my referrer id. This won’t cost you a cent more, and will help support this site.
book for example, has an incredible Amazon Sales Rank and it’s one of the best sellers of all time in our field;Haskell Eye for the Ruby Guy
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?
The future is functional and concurrent
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.
How to get started with Haskell
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:
- Grab the Glasgow Haskell Compiler which is the most popular Haskell compiler. It ships with GHCi which is an interactive console similar to irb for Ruby and Idle for Python;
- If you are mathematically inclined, read A gentle introduction to Haskell. It’s a short and sweet introduction, but should you find it as gentle as an angry Rottweiler, you may want to start with the Haskell Wikibook instead;
- As a reference, use Hoogle – The Haskell API Search Engine ;
- Join the Haskell-Cafe newsletter and the irc.freenode.net channel #haskell;
- If you have time, watch the English Video Lectures from a German University (from 2005-SS-FP.V01 to 2005-SS-FP.V26). They introduce Haskell step by step, so you may find them helpful albeit a bit slow.
And lastly, you can take this article as an announcement about my future entries on Haskell in this blog.
