Skip to content

Instantly share code, notes, and snippets.

@ludflu
Last active August 29, 2016 02:54
Show Gist options
  • Save ludflu/38d659f9bf7e6605e98a to your computer and use it in GitHub Desktop.
Save ludflu/38d659f9bf7e6605e98a to your computer and use it in GitHub Desktop.
why functional programming is important (to me)

#Why Functional Programming Matters (to me)

This is my response to being asked not to use functional programming techniques.

###What I mean by "Functional Programming" Different people mean different things by "Functional Programming". Here's what it means to me:

  • Functions are first class, fundamental atoms of software, and proper functional programming languages allows passing functions as arguments, assigning them to variables, and composing them together to form new functions.
  • Strong Static Typing prevents many common programming errors automatically.
  • Null pointer dereferences can by virtually eliminated using Optional/Option/Maybe/Either data types to explicitly represent empty or error conditions.
  • Together with sum types, strongly typed languages can automatically perform local totality checking, informing the programmer when a logical branch is not handled.
  • Single assignment and segregation of mutable state: Mutable state is a major source of software errors. In most cases, its completely unneccesary. Immutable data types allow strong guarantees of thread safety, and leads to cleaner, more readable code.

###Static vs. Dynamic Typing & Technical Debt

Statically typed languages have a [well deserved] reputation for being more difficult to get started with. When data types are decided at compile time, the language stops you from compiling a nonsensical program. This means you need to apply more forethought to your code. Dynamically typed languages will happily allow you to run an incorrect program, and then throw a runtime exception when the nonsensical logic branch is reached. The question is: when do you want to grapple with the error in your thinking? At compile time, or runtime? Development or production?

The financial analogy is apt: would you prefer to finance your business by borrowing money, then slowly pay it back with interest? Or to pay as you go? There are appropriate uses of leaveraged debt, and likewise there is a appropriate place for dynamically typed languages: one-off programs and simple prototypes that need to be rapidly developed at the expense of quality and correctness.

###Use the Best Tools Available

Functional Programming leads to simpler code that's easy to refactor and maintain. When you need to change a datatype or function signature, the compiler can automatically find all the relevant code that needs to change. Some refactoring tools even allow you to automatically perform the changes. Its true that you can write bad code in any language, but that doesn't mean that all languages are the same. Some languages make it hard to write good code, and others encourage good habits. The language you pick matters.

If you force engineers to use inferior tools, you can expect frustration and higher maintainenance costs.

###Complexity and Boredom

Writing software is a battle with complexity. We solve complicated problems that reflect a complicated world. But not all complexity is the result of modeling a complex problem domain. The distinction is between "Accidental" and "Essential" complexity.

Accidental complexity results from the arbitrary choices we make when approaching a problem. We might represent a collection using an array when a set or hashmap is more appropriate. Perhaps we're using a language that requires manually memory allocation, when a garbage collected language would perform acceptably well. Accidental complexity can be addressed by choosing the right data structures, algorithms, and languages, if you know about them.

By contrast, "Essential" complexity is the result of grappling with the hard facts of the universe. Solving problems that emerge from the essential complexities of the world is exciting and fun. Solving problems caused by accidentally complex technical choices is tedious and boring.

###Functional Programming is the Future

Functional Programming features from Haskell are creeping into every language from Javascript and Java, to Swift and Scala. Besides simplifying error prone code, another driver is the decline of Moore's law. As we approach the physical limits of how small a transistor can be made, the acceleration of microprocessors clock speeds is grinding to a halt. To compensate, chipmakers add more and more cores to individual CPUs. But in order to exploit those extra cores, our software needs to be refactored to support parallel and/or concurrent execution. This is easer said than done.

Traditional approaches to multi-threaded execution often turn into a nightmare of callbacks and deadlocks. However, using immutable data structures and work-stealing, many common operations like mapping can be done in parallel, with trivial changes to your existing (Functional!) code. Aggregation operations can be done incrementally in a distributed fashion using monoidal data structures.

In some cases, large speedups can be attained simply by switching from sequential arrays to a compatible parallel version of the same interface. The payback for Functional Programming is huge, and growing. Moores law is dead, and its not coming back. However, we've not nearly approached the physical limit of the number of cores we can pack into a single machine. The number of cores per CPU will probably continue to grow for decades. What's more, massively distributed architectures are just now become really important, and the same techniques work there.

###Hiring Engineers

A common objection to using sophisticated tools is that it will be harder to hire engineers. However, if you're hiring people mainly by keyword matching your tech stack with the resume pile - you're doing it wrong. You should hire bright people with the ability to learn quickly, rather than looking for "Python programmers", "Javascript developers", "front-end" or "backend" developers. Besides: good engineers learn new tools with or without your encouragement. If its the latter, you'll probably find yourself with a different hiring problem: replacing a team that you refused to invest in.

Embrace Functional Programming and reap the rewards of simpler, cleaner, more scalable code. Ignore it and you can expect to pay more on maintenance and higher turnover.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment