[jacquesm]

This page doesn't load for me, which is a pity.

Why limit the question just to functional programming?

This applies just as much if not more to imperative programming, at least in functional programming you have the option to execute any pure function in parallel on some independent chunk of hardware.

Whether imperative programming can be 'liberated' from the von Neumann bottle-neck is a much harder problem.

In the end both will still have to deal with Amdahl's Law, so even if you could get rid of the 'looking at memory through a keyhole' issue you're going to have to come to terms with not being able to solve your problem faster than the sequential execution of all the non-parallizable chunks.

[tome]

> This page doesn't load for me, which is a pity.

https://web.archive.org/web/20131225040636/http://conal.net/...

> Why limit the question just to functional programming?

There was already an article about the general case :)

http://web.stanford.edu/class/cs242/readings/backus.pdf

[conal]

Sorry about that. My blog seems to be working now. I don't know what happened earlier. I think the server I've been using is underpowered. Hopefully I'll get my site migrated soon.

[liscovich]

Here is the cached version of the article: http://webcache.googleusercontent.com/search?q=cache:CHoIZZi...

[profquail]

Coral cached version: http://conal.net.nyud.net:8080/blog/posts/can-functional-pro...

[ExpiredLink]

> This page doesn't load for me, which is a pity.

It only loads in browsers written in a purely functional language!

[chongli]

A pure function cannot always be executed in parallel. For that it might need access to shared data. On non-von Neumann machines this may not be possible.

[pohl]

Wouldn't such a function not be pure? Or am I not understanding the notion of purity?

[chongli]

Of course it can be pure, so long as the shared data is not mutated. Functional languages such as Haskell don't copy values all over the place when calling functions, they pass in pointers.

[jdiez17]

But that's an optimisation. Which can be switched off to get the benefits from parallelism. This is a tradeoff that programmers would traditionally have to consider, but with functional programming the compiler can figure it out for us.

[chongli]

That's assuming that "figuring it out for us" is decidable. Many of the things we wish the compiler could do for us are not.

[dllthomas]

"It's not decidable" is not a guarantee that humans can do better than a compiler. It means any approach will sometimes be wrong, but a compiler might well (in principle) be wrong less often than a human.

This is separate from the "a human has a lot of additional context that's hard to express" argument, which is valid but has nothing to do with decidability.

[eru]

> A pure function cannot always be executed in parallel.

Try doing that to eg calculating chained hashes.