Haskell - A Peek Inside the Ivory Tower - Daniel Chambers

Functional programming is becoming more and more popular and is starting to penetrate mainstream software development. You may have already used languages and libraries that support a functional programming style. But one language stands out as the epitome of functional programming: Haskell. What is it about Haskell that makes it a pure functional programming language? What features does it provide that can help us write quality, maintainable software? How can Haskell give us the confidence to safely refactor and change our software over time?
In this talk we'll take a tour around the Haskell language and see what makes Haskell an all-in functional programming language. We'll look at both Haskell's strengths and its weaknesses. We'll look at what sets coding in Haskell apart from coding in languages like F#, or coding FP-style in languages like JavaScript. We'll also dispel the myth that Haskell is not suitable for "normal" software. By the end of the talk, your peek inside Haskell's ivory tower will hopefully entice you to explore its potential further.

NDC Conferences

[bjornkihlberg]

When you use a language like Haskell or F# you start to notice that you don't feel that ever present stress of "what did I break?". You can write code for hours without running your program and then at some point you look at your code and you just know it's going to work and it does. This is why functional programmers get so "religious" about it because they become so aware of all the stress OO brings you.

[RaminHonary]

This was a good presentation, but he made a few simplified claims, like how it is impossible to declare a mutable data structure. There are no keywords like "mutable" or anything in Haskell, and I think this is what he meant when he said "impossible."

But to be sure, you can model mutable arrays in Haskell. This is done with things like the IO monad and the ST monad to indicate to the type system that the code evaluation produces stateful updates that are "non-pure" which means the state can be seen in other parts of the program, possibly by other threads.

In my opinion, one of the most important innovations of Haskell is how they use the type system to separate pure code from non-pure code by way of the IO and ST monad. When the type system can enforce the difference you cannot accidentally mix the two, you know when to be careful about state and when you can code freely. Haskell programs try to keep their code pure for as much of the program as possible, and only use IO at the input or output points of the program, and only use ST when efficient stateful updates are necessary (like writing to a large array).

[gylkag]

A very good introduction to language, thank you!

[timh.]

While I appreciate the enthusiasm for FP concepts, I don't think it's the next step.

It's not at all obvious how or even if it is possible to write an operating system in Haskell or any mainstream functional language, because they're built with no thought about how to work with the hardware underneath, instead adding in a runtime translation that needs an existing system to support it.

Of course, not every language needs to be capable of describe an OS, but we need at least one modern language that has all the wonderful properties of functions and types, but gives the fidelity necessary to compile against bare metal.