- Don't rush learning
- Just start somewhere
- Functional programming has different flavors
- Use the strengths of the language
Don't rush learning
Although I have spent a lot of time learning functional programming from an academic perspective, putting it into practice with real problems required more deliberation. I am certainly not going to give up, but I recognize that forcing myself to solve a problem each day with a difficulty growth rate that was larger than my learning growth rate was unhealthy. My plan is to continue practicing Haskell using Exercism, which makes learning pretty much any language an exciting journey.
Just start somewhere
Part of the reason that I hadn't started programming in Haskell earlier was that I was unsure about what it would take to get started. I was amazed at how easy it was to install the necessary tooling. The VSCode Extension that I installed enables inline code evaluation using a certain comment syntax that made it really easy to test small parts of my code. Truthfully, I avoided any IO or other side effect producing code in Haskell and just focused on the data processing and algorithmic sections of the problem.
Functional programming has different flavors
My definition of functional programming has been shaped by my studies on category theory, particularly through the writings and videos of Bartosz Milewski and others. I enjoyed learning about monoids, functors, monads, algebraic data types, typeclasses, currying, and more. Haskell has been the quintessential functional programming language in my view, and if a language claimed to support functional programming, there were certain features that it needed to have.
I recently started learning Elixir, and it has many amazing features I would want in a language. All data structures are immutable, there are no statements only expressions, and there is both literal and structural pattern matching. Unfortunately, currying is very difficult to write idiomatically, and the dearly loved pipe operator passes data as the first parameter to a function instead of the last (both resulting from the dynamic type system combined with the support of pattern matching).
I think the essence of functional programming can be summarized as the following:
- Discouraged use of mutability
- Encouraged use of higher order functions
- Support for composition of effects and data More on this topic in the near future.
Use the strengths of the language
Top comments (1)
Fun fact: you can play with the past year advent problems any time you like