Hacker News Reader

Comment by nine_k | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com