Hacker News Reader

Comment by pdimitar | Hacker News Reader

> Functional programming is another tool, not a panacea.

That's extremely true and I am not denying it. I'd like to add the nuance that us the Homo Sapiens seem to operate better when we are pushed into the right direction.

Giving us too much choice -- like global mutability and OOP in general -- can cause analysis paralysis and make people do all sorts of panicked dumb choices in their software projects. As a guy with 19 years of experience I seriously wish I could forget some of the codebases I had to inspect.

So while FP is just another tool, it's also a framework for thinking that helps people make better choices. Same goes for static strong typing.

View on HN

> 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

2. Pits of Success by Mark Seemann - https://youtu.be/US8QG9I1XW0

3. Grokking Simplicity by Eric Normand - https://grokkingsimplicity.com/

Yep, 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.

Free 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.

I'm curious. How did Free Pascal make you a better programmer?

Not 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.

Thanks!

For 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.

Ironically 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.

I 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.

I 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.

In 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".

Completely agree and I feel this every day.

Half of my job is split between a functional language on the backend and a class-based language on the frontend.

I have made a conscious effort to avoid shared state, but it's harder. For example, the friction of cloning objects before passing them around. Or dealing with sort APIs that sort in place.

I'm going against the language defaults while with the FP language, it feels natural.

Reply on news.ycombinator.com