But why?
The natural way that a programmer gets interested in programming is to see others doing it, get intrigued, and then try it out for themselves. The same is true of probably any hobby, profession, educational topic, etc. The problem with this is that it limits a newcomer's likelihood to learn a different and potentially better way to approach said activity.
Assuming the "wisdom of the crowd" is always correct or getting comfortable with an already familiar approach can further stifle the likelihood of someone changing their approach later. These, and many more, factors perpetuate widely-adopted standards that are far from ideal. There are a large number of examples of this in software development and beyond.
From the day I first became interested in programming, and to this day, I am fascinated by the foundational concepts that make the magic of computing possible. The research and science that has gone into discovering the concepts and processes that enable everything we're capable of today is often taken for granted. I'm also guilty of this, but actively trying to shift my mindset.
..we believe technological progress in computer science, programming, and programming languages is possible, desirable, and critical to software becoming a true engineering discipline. By that, we mean that while the phrase “software engineering” is in common use, engineering disciplines involve the application of both scientific and practical knowledge to the creation and maintenance of better systems. As the available materials change and as knowledge grows, so must engineers.
- Chistopher Allen from the book "Haskell Programming from First Principles"
The recent explosion of software in the world happened faster than anyone was truly ready for. In effect, this has lead to a massive ecosystem of software development work that has not been carefully built on top of a set of engineering principles to ensure the best possible results.
I believe that over the next decade we will see a shift to adopt better principles. We're seeing it already in small pieces here and there, but as the dependency that our world has on software grows, and the potential for damage to be done by inadequately built systems, the demand for tools and practices that harness these principles will increase significantly.
I want to learn Haskell because, more than any other modern language, it harnesses the research and progress made over the last three or four decades regarding how to write safe, robust software. While I have continually learned as an engineer throughout my career, it has been way too focused on specific tools and implementations.
I believe that to truly grow as an engineer, I need to learn new concepts and abstractions that can improve the way I think about engineering problems, and Haskell embodies these ideas more than all (or most) modern languages.
On another note, this article by Paul Graham titled "Beating The Averages" also explains a good reason to have a tool like Haskell under your belt: http://www.paulgraham.com/avg.html
So that's why I want to learn Haskell. I've been dabbling with the language in very small amounts for over a year now, and keep getting distracted by the newest shiny thing in the JavaScript ecosystem. Now is the time I commit to it!
From "The Haskell Book", a section titled Haskevangelism
We’re going to compare Haskell a bit with other languages to demonstrate why we think using Haskell is valuable. Haskell is a language in a progression of languages dating back to 1973, when ML was invented by Robin Milner and others at the University of Edinburgh. ML was itself influenced by ISWIM, which was in turn influenced by ALGOL 60 and Lisp. We mention this lineage because Haskell isn’t new. The most popular implementation of Haskell, the Glasgow Haskell Compiler (GHC), is mature and well-made. Haskell brings together some nice design choices that make for a language that offers more expressiveness than Ruby, but more type safety than any language presently in wide use commercially.
In 1968, the ALGOL68 dialect had the following features built into the language:
- User-defined record types.
- User-defined sum types (unions not limited to simple enumer- ations).
- Switch/case expressions supporting the sum types.
- Compile-time enforced constant values, declared with = rather than :=.
- Unified syntax for using value and reference types — no manual pointer dereferencing.
- Closures with lexical scoping (without this, many functional patterns fall apart).
- Implementation-agnostic parallelized execution of procedures.
- Multi-pass compilation — you can declare stuff after you use it.
As of the early 21st century, many popular languages used com- mercially don’t have anything equivalent to or better than what ALGOL68 had. We mention this because we believe technological progress in computer science, programming, and programming languages is possible, desirable, and critical to software becoming a true engineering discipline. By that, we mean that while the phrase “software engineering” is in common use, engineering disciplines involve the application of both scientific and practical knowledge to the creation and maintenance of better systems. As the available materials change and as knowledge grows, so must engineers.
Haskell leverages more of the developments in programming languages invented since ALGOL68 than most languages in popular use, but with the added benefit of a mature implementation and sound design. Sometimes we hear Haskell being dismissed as “academic” because it is relatively up-to-date with the current state of mathematics and computer science research. In our view, that progress is good and helps us solve practical problems in modern computing and software design.
Progress is possible and desirable, but it is not monotonic or inevitable. The history of the world is riddled with examples of uneven progress. For example, it is estimated that scurvy killed two million sailors between the years 1500 and 1800. Western culture has forgotten the cure for scurvy multiple times. As early as 1614, the Surgeon General of the East India Company recommended bringing citrus on voyages for scurvy. It saved lives, but the understanding of why citrus cured scurvy was incorrect. This led to the use of limes, which have a lower vitamin C content than lemons, and scurvy returned until ascorbic acid was discovered in 1932. Indiscipline and stubbornness (the British Navy stuck with limes despite sailors continuing to die from scurvy) can hold back progress. We’d rather have a doctor who is willing to understand that he makes mistakes, will be responsive to new information, and even actively seek to expand his understanding rather than one that hunkers down with a pet theory informed by anecdote.
There are other ways to prevent scurvy, just as there are other programming languages you can use to write software. Or perhaps you are an explorer who doesn’t believe scurvy can happen to you. But packing lemons provides some insurance on those long voyages. Similarly, having Haskell in your toolkit, even when it’s not your only tool, provides type safety and predictability that can improve your software development. Buggy software might not literally make your teeth fall out, but software problems are far from trivial, and when there are better ways to solve those problems — not perfect, but better — it’s worth your time to investigate them. Set your limes aside for now, and join us at the lemonade stand.