Re:Can functional programming be liberated from the von Neum...
by tome on Thursday January 01, 2015 @05:37AM
(#8822587)
> 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 :)
Re:Can functional programming be liberated from the von Neum...
by conal on Thursday January 01, 2015 @09:03PM
(#8825185)
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.
Re:Can functional programming be liberated from the von Neum...
by liscovich on Thursday January 01, 2015 @05:30AM
(#8822580)
Here is the cached version of the article: http://webcache.googleusercontent.com/search?q=cache:CHoIZZi...
Re:Can functional programming be liberated from the von Neum...
by profquail on Thursday January 01, 2015 @02:15PM
(#8823885)
Coral cached version: http://conal.net.nyud.net:8080/blog/posts/can-functional-pro...
Re:Can functional programming be liberated from the von Neum...
by ExpiredLink on Thursday January 01, 2015 @11:53AM
(#8823418)
> This page doesn't load for me, which is a pity.
It only loads in browsers written in a purely functional language!
Re:Can functional programming be liberated from the von Neum...
by chongli on Thursday January 01, 2015 @05:40AM
(#8822592)
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.
Re:Can functional programming be liberated from the von Neum...
by pohl on Thursday January 01, 2015 @06:34AM
(#8822671)
Wouldn't such a function not be pure? Or am I not understanding the notion of purity?
Re:Can functional programming be liberated from the von Neum...
by chongli on Thursday January 01, 2015 @07:41AM
(#8822775)
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.
Re:Can functional programming be liberated from the von Neum...
by jdiez17 on Thursday January 01, 2015 @09:43AM
(#8823033)
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.
Re:Can functional programming be liberated from the von Neum...
by chongli on Thursday January 01, 2015 @10:19AM
(#8823141)
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.
Re:Can functional programming be liberated from the von Neum...
by dllthomas on Thursday January 01, 2015 @02:46PM
(#8824005)
"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.
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.