Real functional programmers don’t need functional languages!

My first non-trivial program I was paid to write, was as an summer intern my sophomore year of college. It was a Zephyr client built using eXene reading raw UDP packets sent to it from the FoxNet. This was “way back” in 1994. This introduced me to some amazing researchers and put me on my current career path! Up until then I was thinking of specializing in HCI and in fact asked for a recommendation to work on the Garnet project that summer, but got convinced to work on the Fox Project instead.

After the Fox Project I did an internship at Bell Labs the following year working on documentation generator that produced the documentation for the yet to defined SML Basis. From the years of 1994 till I escaped graduate school and got a real job in 2001, my primary language of choice was Standard ML. This means I had 7 years of pretty hard-core functional programming experience before functional programming was “cool”. Hard-core functional programming includes writing garbage collectors, network stacks, compilers, UIs and theorem provers in functional languages.

Since 2001 I have gotten paid to program in more traditional languages like C, C++, Java, C#, Perl, and Python. So it’s been 15+ years in the real world. I’m recounting my seven years of hard-core functional programming before with a bit of nostalgia. I remember conversations of the sort “This functional programming stuff will never be practical. It seems to work because the researchers have a massive 64MB of memory on their machines. On machines with 16MB it swaps like mad.” It seems today even the relatively spartan Google page causes Microsoft Edge to use 348MB. The increase in processor speed and memory in the last few years is hard to imagine. It also seemed to have provided the functional languages and programming a chance to see main stream adoption. However, I’d like to let you in on a small secret. For the last 15+ years even though I’ve been programming in non-functional languages. I’ve been structuring all my programs as functional programs! So I’d like to say I’ve got 22+ years of functional programming experience under my belt.

There is old sayin that “… the determined Real Programmer can write FORTRAN programs in any language.” This is true for any determined real functional programmer. So those of you new the game, let me attempt to condense two decades of experiences in into a few simple points that will hopefully be enlightening if not thought provoking.

Real functional programmers…

  1. Real functional programmers avoid mutation and other side effects when they are inessential, and use whatever tedious mechanism exist in their current language to make sure the data structures they create are read only by default.
  2. Real functional programmers know how general recursion, tail recursion, structural induction, simple induction, iteration and loop invariants are all related. They write efficient and correct by construction code without any drama. The use explicit stacks and while loops when necessary to compensate for deficiencies in their language implementations. They will remind themselves of the principles of coinduction when dealing with infinite lists and data structures.
  3. Real functional programmers know state and side-effects are often necessary. State and effects are not things to be banned, but rather managed explicitly. They manage mutation and side-effects with effect systems and monads even if the underlying language does not support them as first class concepts. They understand, non-termination is a side-effect as well and that Turing completeness is over-rated as often the right catamorphisms is all you need most of the time.
  4. Real functional programmers realize that iterators/generators are nothing more than an imperative way to define a lazy list. They understand how effects and laziness interact poorly and avoid mixing them when possible without having to be told. They use laziness in general as a mechanisms to reduce the overall memory footprint their system rather than increase it.
  5. Real functional programmers understand that the idempotency of your REST API is something you should normally get for free if you are thinking functionally. They think of their backed database as a large structured heap and their frontends as stateless logic. The also understand the meaning of idempotency is all relative to the set of observations you consider to be relevant.
  6. Real functional programmers build fault tolerant distributed systems that look like the application of an actor model at a macro-scale, because doing it at a micro-scale would be a disaster since they can’t use Erlang. They’ll role their sleeves up and use event loop apis and polling rather than pretend threads are cheap when they aren’t, since they are really duals of each other and one day will get unified.
  7. Real functional programmers know what continuation passing style is and know better than to try to build an entire async programming pattern around it, but can deal with the “callback hell” if they are stuck with it.
  8. Real functional programmer can program in language without a full Beta reduction rule and get by with the more common the Beta value rule and not whine like a punk about not having the equational theory they would like, but deeply understanding the equational theory they have and live with it.
  9. Real functional programmer may gripe about the poor support for functional programming really puts a crimp in their style, but never uses that as an excuse to not apply the best practices of functional thinking to the problem at hand. They wonder what the fuss is with MapReduce and why a generation of programmers wasted all that time learning Object Oriented Programming.
  10. Real functional programmers understand how to program effectively in any language, because their mathematical problem focused first-principles approach to thinking lets them take extremely complex problems and decompose them into small well defined easy to compose solutions. They aren’t following language fads, but getting the job done with what’s in front of them.