I took it upon myself to begin learning Haskell recently. This isn’t my first adventure into the realm of functional languages; I spent some time a year or two ago learning Erlang as well. As someone who spends most of their time developing in (and quite frankly, enjoying) C and/or C++, it might seem like a strange foray into bizzaro-world. However, I don’t have any definite or particular interest in the functional paradigm, only in the sense that it offers a new perspective on the way software is built, and perspective is good.
From the imperative perspective, functional programming is a bizarre and imposing approach to writing programs. These languages are all concerned with things like side effects, mutability, and state, and its often difficult to identify the advantages of functional languages over more conventional ones with respect to these concepts and others. In addition, they often have the stereotype of being less practical and more academic (translation: interesting but useless) technologies – although this is not necessarily the case.
I’ve been learning Haskell from this tutorial, which I recommend not only for its technical completeness, but also the author’s sense of humor. I’m not at the stage yet where I was with Erlang (which was, actually building programs), but I could be if I spent a little more time on the subject. So far, one thing I’ve found to be an incredibly useful aspect of Haskell is:
- Its clean, rigid syntax
However, the thing that probably drives me the most insane about Haskell is:
- Its clean, rigid syntax
Make no mistake, that when you begin building some application in Haskell, your code will look pretty much identical to what is produced by your coworkers. If you have some sort of writing style, or you don’t like the default formatting and structure of the language, too bad. It sort of forces you into structuring your application a certain way, and to be honest, this is invaluable when you’re collaborating with others – you should know what to expect in their work.
Haskell people will also argue that the immutability of variables, the brevity of code for tasks, and stateless program design will reduce defects as well in the final product. I can’t find any numbers to back that up, but that seems like it might have a reasonable amount of truth to it. The tradeoff being, spending five years finding a developer who is an expert in Haskell.
I stopped learning Erlang at the time because I couldn’t stand the syntax; Erlang has a lot of very strange characters and formatting in the language. Certainly, you would have to write considerably less code than for an equivalent program in C++, but I’d use Python in that case any day over it.
Anyways, stay tuned for more feedback about Haskell. Should be an interesting adventure.