4 ms·
No. I always wanted to say that to the title of this paper ;) The complaint of van neumann programming langauges, as the paper describes, is that it can only b
by ozy 10y ago
No. I always wanted to say that to the title of this paper ;)
The complaint of van neumann programming langauges, as the paper describes, is that it can only be extended as a framework. Todays imperative languages are much more powerful, either they are untyped (implicitly generic), or they include generics, or at least have objects with polymorphism.
The paper puts forward applicative (functional) programming, as a start, because it can be extended much better. The main point, functions can be put together, because you don't have to name, and thus not give types to, the arguments.
To make the system complete (useful), he adds a applicative state transition system, or mutable state. Think IO monad.
I have a different take. You want systems where everything can be abstracted over. That is, put inside of a function (abstraction). And whatever the system does is truly hidden, unobservable to the outside. That might sound like fp, but it has problems when you want to hide state, or when the abstraction is about input/output. Example:
function downloadAndVerify(url):
data = http.get(url)
hash = http.get(url + ".md5")
return data, md5(data) == hash
In my opinion, the above expresses what I want. If I need async, my callers need async. If I need IO monad, my callers need IO monad. Neither can hide that. If it blocks, it can be solved the same way as CPU intensive operations, do it in the background. So processes need to be easy.
You want a language where any async api can be converted into a blocking api, and any blocking api into an async api. (Using processes, most likely.)