by jasim on 4/30/23, 7:41 PM with 32 comments
by _a_a_a_ on 5/1/23, 11:19 AM
> Okay, so let's address the elephant in the room: performance. Yes. Immutable data structures do use more memory, and they are slower to operate on. However, they are fast enough
...and are presented in a way that gives the impression to people with not enough experience that this kind of thing is "the future of programming". Which then gets parroted back on HN by people who can't justify it – it's something they've read and they're sure it's true.
The problem I'm complaining about is not functional programming or anything else, but a people problem. IME that's where the problem is in programming, and functional programming is just as prone to being abused as any other kind.
Functional programming is not "fast enough". It can be and usually is, in my personal project I'm quite happy to waste memory and thrash the TLB and cache and whatever else to get the job done, but in other cases it's not and that needs to be understood. I've seen a commercial project brought to its knees by going all-in on functional programming done badly (the aforementioned people problem).
I'm going to say this really loudly: don't absorb articles like this and spout them back. They provide easy solutions that are often correct but sometimes very incorrect where it matters, or completely ignore – yet again – the people problem.
I have a lot of experience and I keep reading on HN that "functional programming is the right way" or that "you don't do that in SQL" but these people with the strongest opinions seem least able to back up their claims.
Programming is fundamentally a people problem and that fundamentally is where I've seen most of the problems come from. Functional programming/object-oriented programming/procedural programming... These are all good in the right place. They can all be abused. They can all be combined. They all have costs and benefits. Don't write them off, And equally, don't treat them as 'the solution', because they are tools, and will only ever be tools to be used in the right place, and that takes judgement.
End of rant.
by adamkl on 5/1/23, 1:20 AM
by nine_k on 5/1/23, 12:15 AM
by augustk on 5/1/23, 11:29 AM
1. A functions with no side effects which (possibly) returns different values each time it's called, for instance a function which reads a global variable and returns its value
2. A function with side effects while running but which leaves the state of the program and its environment unaltered once it has returned, for instance a function which displays a dialog window and returns when the user clicks a button in it.
Are there any names for these classes of functions?
by bagerbach on 4/30/23, 8:25 PM
by drunkan on 5/1/23, 1:48 AM
With TS and RxJS I really like to do all the plumbing and housing a little more classically with some container classes that I call services who house and expose RxJS observables with an init() and a destroy() function where a service needs to manage its own subscriptions. So classes "services" group observables and there functionality, RxJS observables are the "plumbing" of the app, piping data around via events and then all the logic is in pure functions. I find programming like this leads to a clear data/event flow and neat seperation of concerns.
by amw-zero on 5/1/23, 4:23 AM
I think this has always been an incorrect framing. Functional programming does not _avoid_ side effects purposefully. It simply doesn't have them without explicitly modeling state, because it's based on math and logic which are stateless at their foundation. That's it.
We only bring up state because of how closely all of our languages are tied to stateful CPU designs - and for good reason btw, seeing as that's how all of our processors have been designed for all of the history of modern computing.
Said another way, functional programming doesn't try to do anything, it simply computes in a different way.
by turtleyacht on 4/30/23, 7:45 PM
However, the left side of the readable content is truncated, so I do not know what word or words start each sentence.
by Graziano_M on 5/1/23, 3:11 PM
by egberts1 on 5/1/23, 2:22 AM