Comment by _a_a_a_ | Hacker News Reader

Comment by _a_a_a_ | Hacker News Reader

Parent Full thread

I'm getting seriously pissed off with articles like this. There is inadequate discussion of the real cost...

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

When you boil it down like that, then all problems in the world is a people problem. They can also be a systems problem, an incentives problem, and often a training/cultural problem. These framings are all valid, and have their place. But certain framings can help solve certain situations better.

In the narrow confines of programming, a way of thinking where we structure problems as transformation of data from one shape to another and minimizing mutable state can help systems be more robust. It is not an object-oriented vs functional programming debate. It is just a good practical way of approaching problem solving.

Unfortunately that is a very high-level description bordering on woo-woo. Which is why the book discusses these ideas with concrete code examples. For a lot of us who've hit a wall with the kind of reliable systems we could build, and discovering this new approach, it is an understanding borne out of lived experience. There is a lot of tacit knowledge here that's difficult to unpack and even more difficult to transfer to others. This book, like many others, helps, but cannot be a substitute for doing the actual work of experimenting, making mistakes, and internalizing.

But all of that is moot unless folks care about it, and care about it in the right way (like not going all in on functional programming and deep copying and immutable values where tight zero-memory-copy zero-alloc zero-kernel-call code was necessary), all of which finally makes it a people problem I guess?

> But all of that is moot unless folks care about it ... all of which finally makes it a people problem I guess?

Nailed it.

Did you realise that this article is the author's notes on someone's else's book? Have you read that book? Does either actually take the absolute positions you appear to be criticising here? I didn't get that sense from them personally - more that the book presents some ideas that come from the mindset of functional programming and can be useful elsewhere as well - but YMMV.

Think about the cost dynamic ("interpreted") languages incur. They are an order of magnitude or two slower than native code. Nevertheless, they are used all the time, for their simplicity of starting and flexibility.

Human time costs way more than CPU time.

I remember that it was proven that any algorithm on mutable data can be implemented on immutable data paying no more than O(log N) cost for that. It may be a very reasonable cost for all the benefits immutable data bring, like absence of data races, and general simplicity of operation which makes programmers' job way easier. The general thrust towards functional and immutable in the industry is not (just) fashion but real benefits in the speed and quality of writing the code. See how React, with its pretty purist functional and immutable approach, took the world of web dev by storm.

> Human time costs way more than CPU time.

Few mantras have done more to damage the quality of software world than this one, sorry to say.

In the realm of commercial software that is rarely true. The cost of writing more performant (and/or more memory efficient) code is amortized among all the users and all the time the code will ever run.

It might seem silly to the programmer to spend a week to reduce runtime of some operation by a second. But if that operation is run once a day by merely a million customers, it actually saves 278 hours per day collectively so it is totally worth it.

Let alone if it is code that runs multiple times per minute and there are billions of users.

And that's just wallclock time. If the code runs on mobile devices, more efficient code will lead to longer battery life. (And even on machines always on A/C power we should give a thought to wasting CPU which means wasted electricity with the associated environmental impact if it's code running at a large scale.) More memory efficient code leads to less memory pressure and a more responsive pleasant system to use. And so on.

Thank you for saying it for me. I keep reading it here and it's so frustrating I'm starting to give up trying to correct it.

Also @nine_k "...paying no more than O(log N) cost for that". Assuming this is true, and I've never heard of it, please consider by what metric that price is paid. In computing science terms things are usually given in numbers of operations but that's a terrible fit for modern CPUs.

I'm not sure about any, but a lot of the persistent data structures seem to fit within that limit, and it's what's used in FP languages like Clojure. There's also some compiler research of identifying when something won't be used anymore and simply doing the mutation in-place, which can reduce even further the costs incurred by immutability

Cost of addition: 1 cycle (I think).

Cost of a read or write to RAM: 150 to 200 cycles, and it gets worse from there if you have a TLB miss

It gets complex, but basically don't believe me or anything else you read without digging into it and asking why and what.

An extreme generalisation.

Only a small minority of software has enough users to justify that paradigm.

> Only a small minority of software has enough users to justify that paradigm.

You'd be surprised. Any legitimate commercial product (legitimate in the sense that it's trying to actually pay for it's costs and make a profit) is going to have thousands of users at a bare minimum.

Oh I agree.

Only, most software isn't customer facing commercial.

Functional versus imperative programming is a bit like socialism versus liberalism; the best solution is probably a combination of both.

Reply on news.ycombinator.com