
Can Programming Be Liberated from the von Neumann Style? (classic) - fogus
http://www.stanford.edu/class/cs242/readings/backus.pdf
======
dkersten
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
"(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"?

~~~
wwalker3
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
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
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
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
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.

~~~
dkersten
Hrm, you could be right. Could be...

Can you elaborate at all? I'd be very interested to hear (since this is a
topic I find quite intriguing).

For humans, we ourselves may work sequentially, but there are many of us
working concurrently. Like many many sequential processing cores. Perhaps your
comment was targeted at the "message passing" aspect. Its a bit of shared
state mixed with message passing, really. Often we interact directly - I could
tell you something (message passing) or I can shout something (multicast
message passing). Of course, we also operate in a shared state model: multiple
people taking food from a plate, we have to synchronise this so that we don't
clash (physically, in this case).

~~~
dasil003
It just seems biased towards an OOP mentality.

If I were to conceive of the universe as a program, I would think of it as one
giant state with a few fundamental particles and a simple functional program
that resolves the state over time based on the previous state.

Passing messages to me implies a finite set of messages and pre-conceived
interaction, whereas in reality there is no such thing as discrete objects or
interactions, everything interacts with everything, and the world we know is
emergent from the low level physical properties.

I suppose there could be an infinitely polymorphous OO program behind the
universe, but that just doesn't strike me as a good fit with what we know
about physics.

~~~
dkersten
I never meant to imply OOP when I said message passing. I guess it was the
wrong term to use, because its got too much of an OOP ring to it. What I mean
is that events or packets of data or what have you are passed between
independent agents. The communication is loosely coupled fropm the agents and
the agents all function independently (they often work together, but the
"function" independently).

If I say "Hello, Bob", this "message" or communicatable data is passed from me
to Bob. But coupling is also low - Mary and Peter, who are standing nearby,
can also hear this - unless I whisper.

Basically, the events or messages or data packets or whatever you want to call
them are simply sent OUT for whatever to pick them up and do with them what
they will. The messages can be directed though (say to Bob vs simply yell) and
the listeners can be restricted (whisper). In this respect, I see the world as
independent threads of execution which communicate through some (anonymous, if
I hear someone yell "Fire", I don't care who) message dispatch system.
Something like this:
<http://didntread.files.wordpress.com/2009/07/components.png>

People are made up of sub-agents, which themselves are made up of smaller,
independent agents and so on. Cells communicate with nearby cells through
proteins and chemical reactions and electrical signals - these are messages
being passed (anonymously) between agents.

Now, if each agent was a single thread of execution, then you have discrete
points where communication and interaction occurs. You said that this is not
how the world works, and you are right. Imagine instead a network of connected
operations, where when one operation produces some result, it passes it to all
the connected operations. When an operation has received all its inputs, it
can execute - concurrently, in parallel with any other operations which also
have their dependencies met. At some point, these operations too will complete
their processing and their output is propogated to connected operations. In
such a system, when a message is received or when an interaction occurs, the
network of operations (the agent) can process it immediately. No longer does
the agent have to wait for a certain discrete point in a sequential processing
system to communicate or interact - it can do so as soon as some data is
available. These entworks do contain state, just like you said the agents in
the real world do, but instead of having some fixed memory buffer contain the
state (well, technically, you could have that too..), the state is maintained
in feedback loops between operations (think of a flip-flop in electronics: the
output of a logic gate is fed back as its input, either directly or indirectly
through other logic gates).

What I have just described is a dataflow system and THAT is how I think the
world works, if it were a programming system.

Note that some things ARE inherently sequential - the operations are still
ordered by their dependencies. Maybe the operations themselves process their
data in a number of sequential steps. This is fine, because certain things
require ordering to make sense or to work well.

------
akkartik
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....](http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html))
Reading both at once is just so much better.

------
nopinsight
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)

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

~~~
biohacker42
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.

------
frig
FL is cute.

If you want to try it out this is a fun tool:

<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.

------
jacquesm
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 :)

