A Tale of Two Conferences – PyCon vs. LambaConf (Part 2)

So, what is the problem? Python is easy enough to read that Guido was able to debug his program in a matter of seconds during his keynote. If it were a large system with several dozen developers though, it would surely be more difficult to write tests and prevent errors from occurring. While Python is strongly typed, it is a dynamic programming language, meaning these checks happen at runtime instead of during compilation.

If you have ever had the pleasure of seeing Paul Phillips speak, then you can imagine where this is heading. He explained that all of our feeble languages and their syntax are distractions from the underlying abstract syntax tree, which deserves more focus. He also went on to describe the current state of programming as a “public health crisis” due to the massive amount of time and energy spent waiting for code to compile.

What Paul seems to want is a more efficient system of incremental compilation which will improve the experience of programming. However, in the meanwhile, he and the rest of the functional programming community are willing to wait. Why?

Python has the notion of “duck typing”, meaning “If it walks and talks like a duck, it’s a duck!”. You could argue that Haskell has a much better form of duck typing. If a value walks and talks like a duck, then it will be considered a duck through type inference, but unlike Python the compiler will also catch errors if later on it tries to bray like a donkey! – Why Haskell Matters

While type safety can help us prevent bugs from occurring at runtime, a purely functional language has no side-effects, which are arguably a much more significant source of bugs in large systems. But wait a minute… Aren’t computers essentially state machines? No matter how pure or functional our code is, it will always be translated into instructions with loops and states in assembly, right?

I associate functional programming with Lambda Calculus and imperative programming with the Turing machine. Since they are equivalent models of computation, I have a hard time understanding why functional programming is qualitatively better than other paradigms and how this is related to type systems and compilation.

It turns out that in this case, style matters. Catching bugs upstream by restricting side-effects and ensuring type safety during compilation is clearly more efficient in terms of programmer time than trying to detect problems with testing at runtime.

Huge thanks to @nuttycom, @puffnfresh, @datariot, @nathanlubchenco, and @dchenbecker. The big data team at Simple Energy is always drilling home the importance of type safety and helping mere mortals like myself understand the state explosion that takes place in large systems that aren’t written functionally. They are thought leaders in their community and just awesome people to be around.