Hacker News Reader

Comment by sklivvz1971 | Hacker News Reader

sklivvz1971

This article relies on the assumption that OO has been designed to work with single core or "few" core processor.

It's a false assumption. OO has been designed to model the world in the hope that this would make expressing business logic easier.

It's not hard to imagine what would happen with these many cores, because we already have specialized systems with many cores: GPUs and CUDA.

And as every single time people talk about parallelism as a holy grail of performance, the truth is obvious to whomever actually uses this hardware: not many problems are highly parallelizable and parallelism is always harder than single threaded code -- it's harder to think about, and this has nothing to do with the programming paradigm.

View on HN

>OO has been designed to model the world in the hope that this would make expressing business logic easier.

OO was designed for multi processing by sending msgs between multiple processes[0]. Like nature does. However I do not find it suitable for most parallel computing work because race conditions.

[0] https://www.youtube.com/watch?v=fhOHn9TClXY

It think you are incorrect in your last statement. All functors are inherently parallelisable. This means that any map operation is parallelisable. Also as long as the operations are associative (which is a surprisingly large number of cases), your reduce operations will also be parallelisable. That means that any computation that can be represented by a map/reduce is usually fully parallelisable and always paralellisable in the map operation. The only operations that aren't paralellisable are those that depend on the previous values (and even then you can make judicious use of partial function application to cut down on the dependencies). Basically this is where you have effects where order matters and recursive calls.

I think the main reason we have difficulty imagining massively parallel computing systems is that we hold onto mutable state and imperative syntax. This pretty much forces us into a situation where order is significant. It seems to me that abandoning that idea is the key to freeing ourselves up, programming-wise. Personally, I don't find pure fp, or immutable OO that much harder than imperative. Different, for sure, but both have advantages and disadvantages.

No. As someone who has spent five years programming computing clusters, I have seen many problems that are fundamentally hard to parallelize. If it falls within mapreduce you are basically "done" no matter what language you use (no need to argue fp vs imperative) but very many interesting problems to solve doesn't.

I am a big believer in FP too, but for other reasons.

I can't edit my previous statement, but after spending more than a couple minutes thinking about it, I can see I was wrong. It's quite convenient to have downvotes to clue you in when you get things wrong, even if it is embarrassing ;-)

Reply on news.ycombinator.com