
Can Programming Be Liberated from the von Neumann Style? (1978) [pdf] - tosh
https://www.cs.cmu.edu/~crary/819-f09/Backus78.pdf
======
paulddraper
Previous discussions:

[https://news.ycombinator.com/item?id=768057](https://news.ycombinator.com/item?id=768057)
(2009)

[https://news.ycombinator.com/item?id=1059884](https://news.ycombinator.com/item?id=1059884)
(2010)

[https://news.ycombinator.com/item?id=7671379](https://news.ycombinator.com/item?id=7671379)
(2014)

[https://news.ycombinator.com/item?id=10182712](https://news.ycombinator.com/item?id=10182712)
(2015)

[https://news.ycombinator.com/item?id=12159792](https://news.ycombinator.com/item?id=12159792)
(2016)

[https://news.ycombinator.com/item?id=12571950](https://news.ycombinator.com/item?id=12571950)
(2016)

------
godmodus
reads like an ode to Haskell/ML.

while haskell/ML is beautiful, and i'd much prefer it if everyone did adopt it
- it seems human nature is preferring languages such as C, Python, C# and
Java, exactly due to their expressiveness and distance from the pure math side
of things.

maybe FP will be the future, but right now and considering everything is a
stack machine that has ASM/C under the hood, things have to change on the
hardware level to enable deep change in both our hardware and our curricula,
which often produce "math is hard". it wouldn't hurt if the larger players put
out mobile FP sdks. (i know we can program android in SCALA and that many folk
wrote Haskell hooks for iOS, but it's not all very supported by the main
players)

if anything, dabbing into Haskell made me understand math better. our
youngsters would benefit greatly from such a change and it'd boost things
beyond what we can imagine today if more than 5% of the population could
program.

a low level FP styled non-gc`ed programming language would be interesting to
see rise too. though haskell is making its way through the bushes, it's nooks
and crannies leave a bit to be desired, esp. when complex software becomes
extremely difficult to read by others, despite it's beauty and conciseness.

~~~
amelius
> it seems human nature is preferring languages such as C, Python, C# and
> Java, exactly due to their expressiveness and distance from the pure math
> side of things

I personally think humans prefer imperative languages because they are closer
to the metal, and hence more predictable in terms of performance.

~~~
taeric
Also closer to how most of us learn and are taught.

Consider, I often tell my kids that they need a cup if they want water. I just
as often have to change that to "go get a cup, and I'll get you water."

Declarative seems to be natural at a desire level, but at an action level,
imperative seems to be more common.

I believe this is flipped for topics and actions that are well internalized.
When my kids are older, I can just say "cup". If cups aren't in the right
drawer, I have to provide imperative to where to check, though.

And yes, all of this is anecdotal. YMMV. I'm highly interested if folks know
of studies or counter examples.

~~~
hood_syntax
You're right that it's closer to how people are taught, but there's no reason
we can't teach from the FP perspective.

Consider the imperative

    
    
      cup_of_water get_water (cup_loc, water_loc) {
          cup = get_cup(cup_loc);
          return fill_cup(cup, water_loc);
      }
    

or something like that, versus

    
    
      getWater :: CupLoc -> WaterLoc -> Cup Water
      getWater cupLoc waterLoc = fillCup (getCup cupLoc) waterLoc
    

It's just a slightly different way of thinking about things.

~~~
hyperpape
There's nothing in either example that is intrinsically functional or
imperative, they're just different syntax.

------
dhab
I think it's fair to assume that most of us have been schooled in imperative
then later OO styles, with probably no attention (my case) or little attention
given to FP styles. Having tried FP a little bit now, I think it's quite
powerful (although not a silver bullet).

    
    
      Given function: max x y = if x > y then x else y
      foldr max (minBound::Int) [1,10,-11,1] // yields 10
      foldr (max.(uncurry max)) (minBound::Int) [(1,-11), (10,1)] // yeilds 10
    

While not always the case, I think much of FP code demonstrates ease-of-
compositionality (partial func, composition operator in second ex), ease-of-
reuse (of max function in different contexts) in a vein similar as above. I
think most of the time maintainability is a positive side-effect.

I wonder how many of commenters here have seriously tried all
imperative/OO/Functional styles of programming, and still think FP is not
something to invest anymore time/effort in vs the other paradigms.

Personally, I'd hope more energy was spent on eliminating the short-comings of
FP, than keeping a firm foot in the OO camp, which I think is already
overloaded with too much attention with quickly plateauing benefits in return
(at language level, not in terms of products that come out of it)

------
mej10
Equational reasoning like it is presented in the paper is alive and well in
the Haskell community.

------
microDude
Is Von Neumann Style, not the most efficient way to program a Von Neumann
Architecture? Which as I understand it, is pretty much all major commercial
computers today.

------
undersuit
I have this article printed and I read it occasionally, if only to try and
reach a deeper understanding of the points made in it.

This isn't about functional programming, ML and Lisp even predate this paper.
I shall quote myself from a previous submission: "The paper describes
function-level programming, it is different than functional programming; see
the languages APL, K, and J."

Don't believe me? Check out the John Conway's Game of Life in APL[1] or J
Language[2]. Even a high level language like MATLAB[3] still reads like normal
code.

[1]
[https://www.youtube.com/watch?v=a9xAKttWgP4](https://www.youtube.com/watch?v=a9xAKttWgP4)

[2] [https://copy.sh/jlife/](https://copy.sh/jlife/)

[3]
[https://rosettacode.org/wiki/Conway%27s_Game_of_Life#MATLAB](https://rosettacode.org/wiki/Conway%27s_Game_of_Life#MATLAB)

------
ozy
To me it is about abstractions. FP cannot abstract over mutable state. In a
way that is a good thing, less mutable state is easier to control as you grow
a program. But inability to abstract is not a good thing. (Just like how async
infects your callers, so does mutability in FP.)

But also note that in this paper, the main trouble pointed out with imperative
languages has long been solved. Using objects/classes and generics or runtime
typed (dynamic) languages. All these make it easy to extend and compose.

------
fiatjaf
Functional programming is magical. The majority of people who works with
magical frameworks tend to agree that having libraries doing simple
predictable things is better than magic. At the same time, everybody seems to
think functional languages are awesome.

~~~
dustingetz
fp is the opposite of magical because it is essentially math, 100% predictable
(follows laws) and all things composed of simple primitives

~~~
user837387
I'll jump into the flame war and say that every single programming language we
use with computers is math. It may just not be expressed in a way you are
comfortable with. And they are all as 100% predictable as FP.

~~~
eof
There is a difference though.

In a (strict) functional language, foo(bar) always returns the same way and
always has the same affect.

In almost every non-strict language foo(bar) can do anything, and can always
be different based off some state not contained in foo or bar, but only the
scope of the program.

So while mathematically they may both be equally as predictable at the
physical level, given only a function its parameters, a strict functional
language is predictable while a 'traditional' language is not

~~~
clusmore
I don't think that this is because of functional vs other, but because of the
assignment operator and mutable primitives (which functional languages tend to
omit). Consider

    
    
      \x y -> g (f x) (f y)
    

We have no way of knowing what this function will do, because f and g are free
variables with respect to the function. But we assume they are constant, so
we're happy. And if you zoom out far enough eventually you'll find the binding
locations.

Instance members and globals are just the imperative version of free
variables, and if it weren't for that pesky assignment operator or mutable
primitives, they'd be constant and hence completely harmless too.

You could imagine an OO language without assignment or mutable primitives that
would have all the advantages of "functional" languages but that would still
feel different enough in style that we wouldn't call it one.

------
chmaynard
I'd like to get a copy of a digitized version of this paper. Also, can anyone
point to information about the response from CS academics and software
engineers to its publication?

~~~
james_hague
I'm quoting a citation-free sentence from Wikipedia (ugh), but it sums up what
I've always heard: "this paper did less to garner interest in the FP language
than to spark research into functional programming in general."

------
bitL
Looking at kinesin that just walks over a protein in raw nature in Von Neumann
style, I doubt so.

------
partycoder
For me, functional programming and ideas that come with it, like immutability,
gain relevance while constructing software for verification (making software
testable), as well as when trying to make software more maintainable by
discouraging side-effects.

For me, learning those concepts helped me write better software, even while
using imperative languages.

------
KuhlMensch
Henceforth, I will add "Keywords and phrases" sections to my crawlable writing

------
agumonkey
my most recent "non" von neumann discovery
[https://www.infoq.com/presentations/power-144-chip](https://www.infoq.com/presentations/power-144-chip)

------
alkonaut
-"Computer says no"

