I learned Haskell and it's a giant waste of time. I'm not the only one who regrets functional programming either. Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter. It's the string theory of computer science.
If you like math/category theory, go deep on the math itself. Your knowledge will be transferable to more than just some man-made story (like a programming language).
> Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter
Hm interestingly I actually felt like learning Haskell had a huge benefit to my day job, probably much more than I imagine learning x86 assembly would. (Though admittedly I have learned some assembly in the past and that was also helpful).
I feel like Haskell forced me to write better code by forcing me to think about side effects. I don't know that I would actually use it in a production project because unfortunately real projects often rely a lot on state, even if constrained to a subsystem, and I still find it difficult to reason about the performance of a Haskell program.
Not trying to invalidate your point; perhaps you were already very good at what I learned via Haskell =] I admit I also find Haskell much more enjoyable to program in for the most part.
> I feel like Haskell forced me to write better code by forcing me to think about side effects.
I see, but wouldn't that be possible by "forcing" yourself to think about side effects in the language you were already using?
I mean, at the end of the day, it's learning the functional programming concepts that is supposedly going to make you a better programmer. Why not just start learning those in Java, Python, JS, etc.?
One thing I hear a lot from people who've learnt Haskell is they admit they're probably never going to use it in a real-world project (for so many reasons). Then, isn't it inefficient and a waste of time to learn parts of Haskell that are only found in Haskell?!
If I were to learn FP (which I will soon), I'd choose to learn it in the language I'm using now. It's not only more efficient, but also I'd enjoy being able to put what I've learnt in practical use.
> I mean, at the end of the day, it's learning the functional programming concepts that is supposedly going to make you a better programmer. Why not just start learning those in Java, Python, JS, etc.?
That could totally be possible for many, but for me, I need something more concrete. I had read about Haskell and the benefits of immutability and agreed from a high level, but until I actually used it, I didn't feel like I understood it.
> I mean, at the end of the day, it's learning the functional programming concepts that is supposedly going to make you a better programmer. Why not just start learning those in Java, Python, JS, etc.?
Because every OOP/imperative programmer I've ever known for 18 years has the easy way out in not thinking about side effects or immutability and they never proactively reach for them.
Granted my bubble is not representative of the world but this trend is nevertheless quite telling. I also never proactively reached for FP techniques in OOP/imperative language until I learned my first FP language.
This is a very narrow-sighted perspective. Most application-level programming these days happens in languages that are "abstract model[s] with [little] connection to the machine or any physical processes". You just happen to be a type 2 programmer: https://josephg.com/blog/3-tribes/
One thing I've found interesting in my very limited experience of Haskell is the connection to formally verifiable properties. Programs written in C or assembly very often have correctness and safety problems—among many others, memory corruption problems. Haskell and many related systems help provide tools to check programmatically that various large classes of error condition can't be present in a code base.
You might think that this isn't worth the mathematical rigamarole that comes with it and that it's grown up with, but as people have seen in a number of other HN threads, formal methods are having a renaissance now and the tools we have that engage with them can get us a lot further than they could in the 1960s.
I have written many bugs, of many different kinds, in other languages that could have been detected automatically by a type system like Haskell's. I'm not suggesting that that makes the other languages inherently bad, or that other programmers (or I) couldn't adopt other methods that would also help avoid these errors, but I think the ease with which Haskell's approach can do it is something interesting to consider.
This is what attracted me to FP to begin with, the "if it compiles it works" meme.
Program verification and functional programming are separate things. Ada predates Haskell by at least a decade, and it's not functional at all. Rust is kind of a revival of that in proving memory safety via borrowing; not functional either.
But the set of programs which can be formally proven is smaller than the set of all programs, so I'd rather not miss out by only making formally proven software. (The entire field of deep learning is a good example of useful code which can't be formally proven.)
I totally disagree. Functional programming teaches practices that are helpful regardless of what paradigm you use. Pure functions by definition adhere to dependency injection and single responsibility principle. While most programming languages don't enforce immutability, being aware of mutation is a generally helpful skill. There's a reason that lambda have become table stakes for new programming languages, and that's because composing functionality is a generally useful feature. I have never been paid to write in a functional language, but learning from functional languages has always improved my general programming skills.
Doing FP makes you a better programmer because you're writing programs. I'm taking the null hypothesis that after a year of writing functional code you would have improved just as much as you would have writing non-functional code. I have literally never seen anything to demonstrate otherwise other than hand waving and personal anecdotes.
> Pure functions by definition adhere to dependency injection and single responsibility principle.
Dependency injection and SRP are other man-made constructs with dubious utility in the same vein as functional programming.
> There's a reason that lambda have become table stakes for new programming languages, and that's because composing functionality is a generally useful feature
Lambda in functional programming is supposed to be a primitive you use to do everything ahem y combinators ahem. In Java 8/C++11/Swift, the lambdas you speak of are used only as embedded subroutines.
Functional programming selects for better than average programmers to begin with--the "programmer's programmer" that writes code for fun and probably visits this site. You're unlikely to convince to learn Haskell the person who writes enterprise .NET, never used anything but Windows, and who never opened a text editor after work. The functional programmers were already good before they became functional programmers. Then you get the cargo cult type of intrigue. "X writes really good code. X also uses $FP_LANG! Be more like X!"
If you like math/category theory, go deep on the math itself. Your knowledge will be transferable to more than just some man-made story (like a programming language).