I'm getting seriously pissed off with articles like this. There is inadequate discussion of the real cost...<p>> 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<p>...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.<p>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.<p>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 <i>and that needs to be understood</i>. I've seen a commercial project brought to its knees by going all-in on functional programming done badly (the aforementioned people problem).<p>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.<p>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.<p>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.<p>End of rant.
If you like these notes, you should read the (very good) book:<p><a href="https://www.manning.com/books/grokking-simplicity" rel="nofollow">https://www.manning.com/books/grokking-simplicity</a>
A good headline. It's important to remind that one should keep on improving their thinking to be a good engineer. All the techniques are secondary to the conceptual toolbox of your mind.
Among non-pure functions I can think of two interesting subclasses:<p>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<p>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.<p>Are there any names for these classes of functions?
I too find Reactive Programming appealing and have successfully used RxJS as you mention to build a fully reactive app - every action and data change can be observed and reacted to - its a fantastic library and it makes TS really powerful IMO (not to say other languages don't have this, just a powerful addition to an already versatile language).<p>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.
> & aims to avoid side effects by using pure functions<p>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.<p>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.<p>Said another way, functional programming doesn't try to do anything, it simply computes in a different way.
It's strange. Most of the site displays fine on mobile except this link. I know we're not supposed to comment on it.<p>However, the left side of the readable content is truncated, so I do not know what word or words start each sentence.