A number of developers at thoughtbot have been intrigued by the functional programming language Haskell. There’s a general feeling of, “Haskell looks really cool, but what would I use it for?” At today’s thoughtbot developer discussion in Boston we’re going to discuss why we’d want to use Haskell.
The University where I studied is one of the best in the country in Formal Methods and they use Haskell extensively. Actually I learnt to program with Haskell, and I don’t think any of them has found a good use for it (apart from formal methods) yet.
I guess it is too slow for production right now, but maybe because it has been mainly used in the academic world thus far.
Would love to hear what you have to say about it.
PS: It is also nice in order to understand types, high order functions, recursion, etc…
My notes for this were basically a summation of Joe’s slides, so I’ll let those do most of the talking. A couple of things that were discussed as a group:
Learn You A Haskell is really one of the best programming books out there.
While Ruby lets you opt in to lazy behavior with things like Enumerable#lazy, Haskell has it everywhere. Everything is Lazy. This leads to better memory usage among other things.
When you hear “static typing” you might think of Java and C# and think, “Yeah, I’ve done that before. It wasn’t great and I went running to Ruby” but their type systems have little to do with Haskell’s. They still allow for plenty of type decisions to be made at runtime (casting, boxing, unboxing, generics) and nil to be used as the value for any type.
Polymorphism in Ruby is easy to get wrong - introduce a method to the interface of one object and forget to add it somewhere else. You probably won’t find out about that until runtime. Haskell just won’t compile.
Haskell smokes Ruby in performance.
Also worth noting that we’ll be reading Learn You a Haskell as a group over the next few weeks.
Memory usage is obviously situational, and Haskell has some odd situations because of laziness. At this point, though, I don’t think it’s harder to make Haskell use similar memory to languages like Ruby for most situations, and for some situations, like streaming data processing, laziness makes it much easier.
The point I was trying to make on that slide was not actually that laziness always (or even usually) performs better in terms of memory usage; it was that it allowed consistent constructs whether you’re dealing with a small string or with a potentially giant file, whereas Ruby required a special construct (IO.each_line) for performance reasons.