5 ms·

Can Programming Be Liberated from the von Neumann Style? (classic)

52 points by fogus 17y ago

jacquesm 17y ago
There goes the rest of my afternoon... But thank you fogus, you can have 10 upvotes from me, unfortunately there is only the one 'upvote'. I guess I could petition PG to do a little tweaking of the lists :)
maurycy 17y ago
You guys have no mercy. So many interesting readings today.
- biohacker42 17y ago
  I usually complain about the ever decreasing quality of the HN frontage, but today practically every single link is great! I don't know what changed today, but I love it.
dkersten 17y ago
Ahhh! I love this one. FP was such an interesting language and point-free programming is still one of my favourite styles. I like this topic too (breaking away from von Neumann style programming) because I believe that it is useful for some, but NOT all, problems. There are problems which are better solved with other paradigms. For example, mathematical algorithms and inherently sequential calculations (issuing commands to hardware often has to be strictly sequential, for example) - I'm sure I missed a load - are very well suited to von Neumann style programming. There are other tasks, however, which are not so well suited, as we have recently discovered: concurrent programming, for example, is pretty difficult in this style of programming. I'm sure theres plenty of alternatives, but the one I'm currently interested in is dataflow, which appears to solve concurrency inherently and without programmer input, though obviously, being implemented on von Neumann hardware means the implementations may not make the best use of this. Dataflow is interesting, to me, because it seems to be a minor step from imperative programming - a step which could have been taken arbitrarily back when computing was in its infancy. I don't believe that it was, I believe that imperative was chosen because it was, indeed, most suited to what early programmers were trying to achieve and the flaws (mainly concurrency) only became apparent a long time later. Its interesting to think about what programming would have been like if dataflow were the programming paradigm of choice, though. Ultimately, a nice balance between both would be best, IMHO. I see it like this: in imperative programming, you have a stream of instructions, which is routed through the data it processes (that is, the next instruction is chosen by the previous instruction and the operate on a static (non moving) block of data) whereas in dataflow, you have static instructions with streams of data (that is, the data is routed by the instructions, much like logic gates route electrical signals in digital circuits). Conceptually, the difference is very small - but it makes a big difference. I think theres values in both ways and would love a programming model which allowed both of these seamlessly. Oz provides some dataflow constructs, but IMHO they're too limited (and also the implementation should make use of these for implicit and transparent concurrency). Thoughts?
- jerf 17y ago
  "(issuing commands to hardware often has to be strictly sequential, for example)" Do they, though? I mean, yes, sure, with current hardware this is true, but is this a true necessity, or an artifact of the fact that modern hardware is designed to be used by von Neumann machines? Honest question, I don't know enough about hardware to have an answer. Can there be "functional hardware", or perhaps more practical, "dataflow hardware"?
  - notaddicted 17y ago
    If the commands don't have to be executed sequentially, then you don't have to issue them sequentially. A modern processor will look at the incoming instructions and execute whatever it can without creating a hazard, this is called out of order execution. http://en.wikipedia.org/wiki/Out-of-order_execution http://en.wikipedia.org/wiki/Out-of-order_execution
    - wmf 17y ago
      OOO still preserves sequential semantics, so it's not that interesting from the programmer's perspective.
  - wwalker3 17y ago
    It would be hard to create truly "functional" hardware. A piece of hardware is a real physical object with an internal state which is shared by all accessors and which can change over time. Shared, modifiable state is the exact opposite paradigm from the one that pure functional languages use. I think this is also why pure functional languages are so hard for "normal" people to understand -- their basic premise is the opposite of the real world around us that's filled with stateful physical objects.
    - dkersten 17y ago
      I think one other reason why von Neumann-type imperative programming was chosen over dataflow IS because sequential instructions and shared memory makes a lot of sense to us. Having said that, a lot of non-programmers use graphical dataflow languages all the time, so maybe dataflow is ACTUALLY easier (at least for non-programmers - maybe the mathematical feel of imperative code attracts us programmers to it?) - eg, graphics tools often have dataflow languages for defining animations, materials, lighting and so on. I once used a dataflow tool for generating 3D visualizations and it was very intuitive.
nopinsight 17y ago
Why is imperative programming still by far the most popular and widely used form of programming? Because the world, in most cases, is sequential and our brain has learned from babyhood (and probably over evolutionary time too) the sequential style of processing. No wonder mathematics & functional programming is hard for 99+% of the population and most programmers, (People here are mostly above average, so YMMV)
frig 17y ago
FL is cute. If you want to try it out this is a fun tool: http://www.dia.uniroma3.it/~paoluzzi/plasm/ http://www.dia.uniroma3.it/~paoluzzi/plasm/ It's a dialect of FL with stuff tossed in for programmatically generating 3d models. I'm not aware of any other easily accessible working implementations of FL-alike languages.
nopinsight 17y ago
Why is imperative programming still the most widely understood and used form by far (despite its certain weaknesses)? Because the world, in most cases, is sequential. Understanding of time and tenses are very important for navigating life. We learn to process in sequential style from babyhood (and likely over evolutionary time as well). Mathematics (anything beyond basic) and functional programming are hard for 99+% of population and more than half of programmers. (People here are above average, so your mileague may vary.) Functional programming corresponds to the Present Simple tense in English. The tense is not that common in everyday conversation and we rarely see it in complex sentences apart from technical/scientific writing. No wonder most people have little training for such style of thinking.
- dkersten 17y ago
  I think you're "almost" right. The world is not quite sequential - the world is composed of a vast quantity of concurrently running agents which communicate through a message passing system. Not unlike a many core system running sequential tasks and using a message passing system. Or a dataflow system where the data stream could be seen as messages being passed between concurrently executing operations. You are right, though: we work and think in a very sequential manner. Once you introduce concurrency to any everyday life aspect, it becomes more difficult for us to grasp. Even cooking is difficult when you prepare multiple things at once and must remember the timing for each of these things and schedule your time or the work between multiple cooks.. with practice, its not so bad - programming is the same, it gets complicated when you stop using a sequential paradigm, but with practice other paradigms can become natural too. It is also for this reason why I think the "ultimate language" (tm) would be a mixture between something like dataflow and sequential programming, offering the programmer the choice to use whichever style is most natural to the task at hand, without having to put much effort into splitting the program into components of either category. I have started to see languages moving that way, slowly, though I think it'll be another while still before they're usable enough to replace currently popular languages.
  - dasil003 17y ago
    I'm reluctant to characterize the world as being composed of independent agents passing messages. I can't put my finger on it exactly, but it just feels like a very lossy oversimplification.
akkartik 17y ago
Everytime Backus's Turing award lecture comes up I feel obliged to point to Dijkstra's take on it: (http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692....) Reading both at once is just so much better.

52 points by fogus 17y ago

There goes the rest of my afternoon... But thank you fogus, you can have 10 upvotes from me, unfortunately there is only the one 'upvote'. I guess I could petition PG to do a little tweaking of the lists :)

maurycy 17y ago

You guys have no mercy. So many interesting readings today.

biohacker42 17y ago
I usually complain about the ever decreasing quality of the HN frontage, but today practically every single link is great! I don't know what changed today, but I love it.

dkersten 17y ago

Ahhh! I love this one. FP was such an interesting language and point-free programming is still one of my favourite styles. I like this topic too (breaking away from von Neumann style programming) because I believe that it is useful for some, but NOT all, problems. There are problems which are better solved with other paradigms. For example, mathematical algorithms and inherently sequential calculations (issuing commands to hardware often has to be strictly sequential, for example) - I'm sure I missed a load - are very well suited to von Neumann style programming. There are other tasks, however, which are not so well suited, as we have recently discovered: concurrent programming, for example, is pretty difficult in this style of programming. I'm sure theres plenty of alternatives, but the one I'm currently interested in is dataflow, which appears to solve concurrency inherently and without programmer input, though obviously, being implemented on von Neumann hardware means the implementations may not make the best use of this. Dataflow is interesting, to me, because it seems to be a minor step from imperative programming - a step which could have been taken arbitrarily back when computing was in its infancy. I don't believe that it was, I believe that imperative was chosen because it was, indeed, most suited to what early programmers were trying to achieve and the flaws (mainly concurrency) only became apparent a long time later. Its interesting to think about what programming would have been like if dataflow were the programming paradigm of choice, though. Ultimately, a nice balance between both would be best, IMHO. I see it like this: in imperative programming, you have a stream of instructions, which is routed through the data it processes (that is, the next instruction is chosen by the previous instruction and the operate on a static (non moving) block of data) whereas in dataflow, you have static instructions with streams of data (that is, the data is routed by the instructions, much like logic gates route electrical signals in digital circuits). Conceptually, the difference is very small - but it makes a big difference. I think theres values in both ways and would love a programming model which allowed both of these seamlessly. Oz provides some dataflow constructs, but IMHO they're too limited (and also the implementation should make use of these for implicit and transparent concurrency). Thoughts?

jerf 17y ago
"(issuing commands to hardware often has to be strictly sequential, for example)" Do they, though? I mean, yes, sure, with current hardware this is true, but is this a true necessity, or an artifact of the fact that modern hardware is designed to be used by von Neumann machines? Honest question, I don't know enough about hardware to have an answer. Can there be "functional hardware", or perhaps more practical, "dataflow hardware"?
- notaddicted 17y ago
  If the commands don't have to be executed sequentially, then you don't have to issue them sequentially. A modern processor will look at the incoming instructions and execute whatever it can without creating a hazard, this is called out of order execution. http://en.wikipedia.org/wiki/Out-of-order_execution http://en.wikipedia.org/wiki/Out-of-order_execution
  - wmf 17y ago
    OOO still preserves sequential semantics, so it's not that interesting from the programmer's perspective.
- wwalker3 17y ago
  It would be hard to create truly "functional" hardware. A piece of hardware is a real physical object with an internal state which is shared by all accessors and which can change over time. Shared, modifiable state is the exact opposite paradigm from the one that pure functional languages use. I think this is also why pure functional languages are so hard for "normal" people to understand -- their basic premise is the opposite of the real world around us that's filled with stateful physical objects.
  - dkersten 17y ago
    I think one other reason why von Neumann-type imperative programming was chosen over dataflow IS because sequential instructions and shared memory makes a lot of sense to us. Having said that, a lot of non-programmers use graphical dataflow languages all the time, so maybe dataflow is ACTUALLY easier (at least for non-programmers - maybe the mathematical feel of imperative code attracts us programmers to it?) - eg, graphics tools often have dataflow languages for defining animations, materials, lighting and so on. I once used a dataflow tool for generating 3D visualizations and it was very intuitive.

nopinsight 17y ago

Why is imperative programming still by far the most popular and widely used form of programming? Because the world, in most cases, is sequential and our brain has learned from babyhood (and probably over evolutionary time too) the sequential style of processing. No wonder mathematics & functional programming is hard for 99+% of the population and most programmers, (People here are mostly above average, so YMMV)

frig 17y ago

FL is cute. If you want to try it out this is a fun tool: http://www.dia.uniroma3.it/~paoluzzi/plasm/ http://www.dia.uniroma3.it/~paoluzzi/plasm/ It's a dialect of FL with stuff tossed in for programmatically generating 3d models. I'm not aware of any other easily accessible working implementations of FL-alike languages.

nopinsight 17y ago

Why is imperative programming still the most widely understood and used form by far (despite its certain weaknesses)? Because the world, in most cases, is sequential. Understanding of time and tenses are very important for navigating life. We learn to process in sequential style from babyhood (and likely over evolutionary time as well). Mathematics (anything beyond basic) and functional programming are hard for 99+% of population and more than half of programmers. (People here are above average, so your mileague may vary.) Functional programming corresponds to the Present Simple tense in English. The tense is not that common in everyday conversation and we rarely see it in complex sentences apart from technical/scientific writing. No wonder most people have little training for such style of thinking.

dkersten 17y ago
I think you're "almost" right. The world is not quite sequential - the world is composed of a vast quantity of concurrently running agents which communicate through a message passing system. Not unlike a many core system running sequential tasks and using a message passing system. Or a dataflow system where the data stream could be seen as messages being passed between concurrently executing operations. You are right, though: we work and think in a very sequential manner. Once you introduce concurrency to any everyday life aspect, it becomes more difficult for us to grasp. Even cooking is difficult when you prepare multiple things at once and must remember the timing for each of these things and schedule your time or the work between multiple cooks.. with practice, its not so bad - programming is the same, it gets complicated when you stop using a sequential paradigm, but with practice other paradigms can become natural too. It is also for this reason why I think the "ultimate language" (tm) would be a mixture between something like dataflow and sequential programming, offering the programmer the choice to use whichever style is most natural to the task at hand, without having to put much effort into splitting the program into components of either category. I have started to see languages moving that way, slowly, though I think it'll be another while still before they're usable enough to replace currently popular languages.
- dasil003 17y ago
  I'm reluctant to characterize the world as being composed of independent agents passing messages. I can't put my finger on it exactly, but it just feels like a very lossy oversimplification.

akkartik 17y ago

Everytime Backus's Turing award lecture comes up I feel obliged to point to Dijkstra's take on it: (http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692....) Reading both at once is just so much better.