Functional Programming Lessons Conclusion

I mostly agree with the sentiments in this article. I was once an extremely zealous FP acolyte but eventually I realized that there are a few lessons worth taking from FP and applying to more conventional programming: 1. Pure functions are great to use when you have the opportunity. 2. Recursion works great for certain problems and with pure functions. 3. Higher order functions can be a useful shorthand (but please only use them with pure functions). Otherwise, I think simple, procedural programming is generally a better default paradigm.

> I consider [having a big benefit at 100% vs an 80/20 rule] a characteristic of type systems in general; a type system that you can rely on is vastly more useful than a type system you can almost rely on, and it doesn’t take much “almost” to greatly diminish the utility of a given type system.

This! This is why I don't particularly care for gradual typing in languages like Python. It's a lot of extra overhead but you still can't really rely on it for much. Typescript types are just barely over the hump in terms of being "always" enough reliable to really lean on it.

web development today is literally just massive massive mutation operations on databases.

Functional programming can't stop it, it just sort of puts a fence around it. The fence makes sense if it's just 10% of your program that you want to fence off. But the database is literally the core of our application then it's like putting a fence around 90% of the house and you have 10% of pure functional programming.

Most operations are located at the database level. That's where the most bugs occur and that's where most operations occur. You can't really make that functional and pure.

This high level stuff is actually wrong. At the highest level web apps are NOT functional.

I get where he's coming from but he missed the point. Why do functional paradigms fail or not matter so much at the micro level? Because web applications are PRIMARILY not functional by nature. That's why the stuff doesn't matter. You're writing and changing for loops into recursion/maps in the 10% of your pure code that's fenced off from the 90% core of the application.

You want to make functional patterns that are applicable at the high level? You need to change the nature of reality to do that. Make it so we don't need to mutate a database ever and create a DSL around that is functional. SQL is not really functional. Barring that you can keep a mutating database but create a DSL around it that hides the mutation.

I agree with the 100% rule. The problem with Typescript is how many teams allow “any”. They’ll say, “We’re using TypeScript! The autocomplete is great!” And on the surface, it feels safe. You get some compiler errors when you make a breaking change. But the any’s run through the codebase like holes in Swiss cheese, and you never know when you’ll hit one, until you’ve caused a bug in production. And then they try to deal with it by writing more tests. Having 100% type coverage is far more important.

There must be something wrong in the way FP is taught if the takeaway that people have is that it prevents or is somehow opposed to mutation.

On the one hand you have bunch of FP languages that don't care in the least bit about "purity" (i.e. being side-effect free) or are more pragmatic around it, such as various LISPs, OCaml, Scala or even parts of the JS ecosystem. And on the other hand, there's a lot of research and discussion in e.g. the Haskell community about how to properly deal with side effects. The idea here is not that side effects are bad, but that we want to know where they happen and combine them safely.