I am a believer of continuous improvement over the ceremonial new year resolutions. However, as my upcoming birthday approaches, it’s time to start my long-delayed writing project. This blog is a collection of my public notes on technical trends, programming paradigms and general software engineering, serving as my platform for sharing ideas and discussing views, especially with my colleagues. There are 2 main types of updates.
- Lists to external sources on topics of interests, usually with additional notes, to support an offline discussion or tutorial.
- Long form writings where short conversations don’t cut it, or when/where I may want to refer to the same content again for a future teammate.
There isn’t an “about me” page, as we probably know each other IRL. The usual disclaimer applies, the opinion expressed here are mine and not that of my employer.
Let’s start with the first update.
This week’s issue is all about functional programming, and how it fits into the context of what we are doing at GC.
Despite being somewhat a cliche, I found the Wikipedia page an extensive introductory resource to the topic. After reviewing the definition, have a look at the examples of various programming language. FP languages’ codes are typically flatter and are easier to reason than their imperative counterparts. Although it’s possible to write functional programs in most mainstream languages (including our beloved PHP), there are different levels of support and learning curves for FP. Pure functional languages (such as Haskell and Clojure) are beautiful to write and quite pleasant to reason about. However, the engineer in me is louder than the poet, which brings us to…
Here is another tutorial that I quite enjoy. It is for Java, but the ideas translate well to other languages. If you don’t have time for the whole thing, I suggest that you go through the first 4 sections, which cover core FP concepts. There’s also an alternative series here.
For the uninitiated, Haskell is the jewel crown of the functional programming world with “avoid success at all costs” as its motto (did you get the pun?). I share a similar view to David’s answer here, which is also why I did not push toward a fully functional language (such as Haskell) for our backend (at least not right now). If you don’t have time to read the whole answer, here’s the part that I’d like to point out:
Haskell makes lazy immutable functional programming really cool and elegant, but the majority of software is written to interface with users or mutate data, and these are worlds dominated by side-effects, not immutable functional programming.
In most real-world scenarios, I believe in the synergy of complementary ideas. One draw-back of functional languages that I have observed is their minor lack of structure (again, it’s not impossible, just a bit harder to do). Using OOP for general project structure and FP for the actual logic seems to be the right path forward for real-world scenarios.
This further supports my previous rationale of choosing JS as a middle-ground between the functional world of logic and the imperative world of side-effects.
Here’s a little bit extra. These are some of the mainstream functional languages that you probably heard of. Haskell is quite exotic whereas Scala & Elixir are more approachable. Learning a pure functional language may or may not double your pay but it certainly can help you become a better, happier developer. Here’s a link to StackOverFlow’s developer survey where 4 out of 10 most loved languages (out of millions out there) are functional.
Until next time!