Random Kram

Functional Javascript

I just finished reading Functional Javascript and i would highly recommend you to read it. For Javascript programmers it is a must. For developers unfamiliar with functional programming it is a gentle introduction with the benefit of being explorable right in your browsers developer console. You do not have to install anything at all. So please try it out.

Iwas introduced to the benefits of functional thinking to creating solutions anyway. But being educated in object oriented design it takes a lot of beating with any tool/book/library/paper possible to get your thinking turned around. Why would you want to do that? What is it about? Just a short recap of my journey to functional programming:

  • Imperative programming looks at a problem and describes how to solve it.
  • Object oriented programming looks at a problem, models/identifies key entities and describes where to do what part of the solution
  • Functional programming looks at a problem and describes what to do

Why am i sold on functional programming, right now? I guess this is a typical route to take. I started programming being introduced shortly to imperative programming. You write your algorithm down and be done with it. If you have to solve another problem you write it down again. Not even realizing that most of the parts of the algorithm are the same things. Most of it is looping, accesing, merging and splitting of some data. You start to use subroutines, but that is it.

Then i started with object oriented design/programming and reusability improved, having solid interfaces between actors and looking at problems as a composition of various acting things which have well defined responsibilites made it much clearer what there is to do. Figuring out, against your programming language that inheritance may be easy to do but is most often the wrong thing is a major step to better composability. Learning about the SOLID principles helps alot in repping in the benefits of object oriented programming.

But at the end of the object oriented journey there came some insights. Immutability and notorious state reduction help a lot in reducing complexity. Interfaces got smaller, more speicalized and soon you see that major parts of your interfaces become methods which take specific interfaces to solve common things. Instead of lists you handle just iterable things, instead of values to check you give predicates or validator objects. At the end of this journey you realize a lot of these general things are just functions, often implemented with anonymous classes. And with the language i used, Java, this looks just awful.

So you go on, and you realize all the objects are a weird way of putting state somewhere and binding functions to the state at the same time. And to make things complicated you make the binding fuzzy again by introducing polymorphism.

And i do not think it is harder to understand higher order functions vs. polymorphic objects as method parameters. It still is the concept of receiving some thing which will act in a specific way not needed to know as long as it lives by a specific contract/interface.

The focus on purity and immutablity makes really nice composable system in functional sytems as well as object oriented systems. So object oriented style needs more things to understand. At first glance it looks easier because you can map it out into different models/entities. But if you look at the actual flow of data and control you have to understand more concepts as in the functional style.

Functional programming seems simpler to me. There are less concepts to understand. The difference between a function and a method is more or less a difference in the scope for variable lookup. When i look at functional code in comparison to object oriented code i feel like functional code is more explicit about dependencies at the call site. It feels more compact and moving parts are kept more close together, so reasoning about what happens feel easier. The idea of pure functions takes it up a noth again and it feels easier again. So yes, taking practices and ideas from functional programming is a very good idea to get to composable systems.

Composability should be high on your list of priorities. In the end being a developer comes down to one formula: do stuff to not having to do stuff anymore. It is the perfect job for lazy people who are in it for the long-term. If you have composable systems you have a higher reuse which means less stuff to do, less stuff to go wrong, less stuff to maintain. more free time to do stuff that matters.