4 ms·
> So while FP is just another tool, it's also a framework for thinking that helps people make better choices I’ve been getting more into functional programming
by adamkl 6y ago
> So while FP is just another tool, it's also a framework for thinking that helps people make better choices
I’ve been getting more into functional programming this past year (via Clojure, though my day-job is mostly JavaScript/TypeScript) and this is the big takeaway for me.
Type theory and monads may have their place, but thinking about separating logic from side-effects is, I think, the most valuable aspect of functional programming.
That is a thought process that you can apply in pretty much any language that will give you the biggest bang for your buck.
Edit: Here’s some great examples of the benefits of functional thinking without going off the deep end.
1. Boundaries by Gary Bernhardt - https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
2. Pits of Success by Mark Seemann - https://youtu.be/US8QG9I1XW0 https://youtu.be/US8QG9I1XW0
3. Grokking Simplicity by Eric Normand - https://grokkingsimplicity.com/ https://grokkingsimplicity.com/
- pdimitar 6y agoYep, there also exists such a thing as "I learned language X and will not use it for my paid work but it made me a better programmer". One such example for me is Racket.
- busterarm 6y agoFree Pascal. That said, I'll use anything in my paid work if the project is interesting enough. Hence the three years I spent writing PHP.
- pseudalopex 6y agoI'm curious. How did Free Pascal make you a better programmer?
- busterarm 6y agoNot an answer you'll like, honestly. Turbo Pascal as the first thing I learned after BASIC as a wee youngin'. Mostly it was about connecting young hobbiest programmer me with seasoned professional me. Basically, sometime's it's good just to kick back and have some fun with your work. Aside from that though, my impressions of the language are that it forces you to be a little bit more organized about everything than C-derived languages. In Pascal, the things that you do to satisfy the compiler are things you can do for anyone reading your code in other languages (not that you would in those languages conventions though...). And other languages do this even better... I wouldn't recommend anyone go learn it unless they had a real business need to.
- pseudalopex 6y agoThanks!
- tcbasche 6y agoFor me that's been Elixir. It's made me appreciate some of the more functional aspects in Python, like generators, map, filter and the functools library in general.
- pdimitar 6y agoIronically Elixir has become a personal favourite and I find it amazing for backend web work, especially API gateways -- although it does very well with server-side rendering web projects as well. It's my main work tool (very close second is Rust). But I fully get what you mean. Working with it and learning it has been a very strong eye-opening experience.
- tcbasche 6y agoI really enjoy the tooling as well. I feel like these days tooling can be just as important as the more “tangible” benefits of a language. The Phoenix code (and test!) generation in particular is just magnificent, not to mention docs. Pythons most lauded doc generation tool Sphinx on the other hand is just complicated and confusing.
- alisonatwork 6y agoI agree that separating logic from side-effects is an excellent lesson that easily translates to less functional programming languages. Another thing I tend to do now is order function arguments as if the programming language had partial function application. You can see this in JavaScript by comparing lodash to lodash/fp. I think once this practice is established on a team, it can help bring a more uniform feel to the code.
- Kwantuum 6y agoIn javascript it's pretty easy to write a function for partial application in either order, you can curry functions forward or backward. const map = (arr, mapper) => arr.map(mapper); // Non "traditional" order for arguments const curry = f => (...first) => (...second) => f(...first, ...second); // Classic currying: partially apply arguments to the start const reverseCurry = f => (...second) => (...first) => f(...first, ...second); // You might want to reverse() first and second depending on the desired syntax const arrayMapper = curry(map)(array); // Usually not that useful, more common to map over many arrays with the same function than to map over the same array with many functions const funcMapper = reverseCurry(map)(func); // Same benefits as having the classic argument order in the first place If you're working in a code base that doesn't already implement "most specific argument last", or does so inconsistently, it's very easy to write partial application functions for both cases. If your functions aren't variadic you can even get over the clunky double call syntax by checking the total number of arguments passed thus far, and if it's greater than or equal to the function's "length" (the number of named arguments that it takes) call it, otherwise return the partially applied function, something that is sometimes known as "autocurry".