[HN Gopher] Can programming be liberated from the von Neumann st...
___________________________________________________________________
Can programming be liberated from the von Neumann style? (1978)
Author : tosh
Score : 60 points
Date : 2021-06-18 20:03 UTC (2 hours ago)
(HTM) web link (dl.acm.org)
(TXT) w3m dump (dl.acm.org)
| RodgerTheGreat wrote:
| Even when this paper was published, Backus' comments toward APL
| did it a massive disservice.
|
| Modern descendants of the language have freed it entirely from
| "expression/statement" splits, and the collection of operators
| has grown richer. More than any other family, APLs today
| represent the most successful realization of function-level
| programming as yearned for in this paper.
| rackjack wrote:
| Joy [1] is a function-level stack-oriented (read: FORTH-y)
| programming language inspired by Backus's FP. Funny how these
| things end up connected.
|
| [1]: https://en.wikipedia.org/wiki/Joy_(programming_language)
| brylie wrote:
| This style of programming, such as unnamed arguments, sounds very
| difficult to understand. An important part of programming is
| thinking clearly by using simple and explicit writing style.
| Clear code should be as close as possible to explaining the
| problem domain and how you would like to influence the outcome.
| jhomedall wrote:
| It most likely sounds difficult to understand because you are
| not familiar with it. Try working through the first few
| exercises in SICP; you'll see that it can be quite
| straightforward.
| carapace wrote:
| The thing in this paper that I see missing from most discussions
| of Functional Programming is the use of an algebra to derive
| programs.
|
| I've worked a bit with an FP concatenative language Joy and this
| sort of algebraic manipulation is easy and fun, and seems to
| permit (nearly) bug-free development.
|
| Here's a very simple example of deriving a function for the
| quadratic formula:
|
| https://joypy.osdn.io/notebooks/Quadratic.html
|
| A more complex example deriving a combinator "treestep" to
| process tree datastructures:
|
| https://joypy.osdn.io/notebooks/Treestep.html
| js8 wrote:
| I came across this paper recently while looking at Kitten (it
| was actually mentioned in HN before):
| http://evincarofautumn.blogspot.com/2012/02/why-concatenativ...
|
| I think really explains the idea. I always liked combinatory
| logic more than lambda calculus, although it didn't click to me
| that the concatenative languages are essentially the formalism
| for it (as opposed to ML-style syntax).
|
| Although I would say functional programming is somewhat
| orthogonal concept, the concatenative languages can have
| functions with side effects, like Forth does.
| [deleted]
| ardit33 wrote:
| Perhaps the universe is state based, and not function based...
|
| Programing language are away to represent reality, and
| manipulate it to your desire.
|
| Object Oriented, and Procedural programing both use functions
| to manipulate state, while in pure functional languages you use
| functions and unnamed variables to present state.
|
| The problem is when you communicate, you always do it with
| state and not functions. From API to storing data as it allows
| to very different systems to understand each other without to
| have the same internals. A java web based api/program and a
| swift/objective-c program running in a phone can easily
| communicate with each other via state (aka, rest of soap apis),
| and they don't have to know the internal state of each other.
|
| You can save functions, and pass them along, but the other part
| has to know how to run it, and have the same type of hardware
| in order to run it.
|
| I really think pure functional programming is a mathematicians
| pipe-dream, and theoretical CS nerds trying to shoehorn
| Math/Algebra equations into being the default type of
| programing paradigm, but for practical Computer Science
| problems the von Neumann style (statements and expressions) has
| won as it is the most practical
|
| The only true successful alternative to von neuman state type
| of languages, is really SQL and its derivatives, which is a
| declarative style of programing language. You can pass SQL
| queries around, and they will be understood by all kinds of
| systems. But, ultimately they all act on some kind of
| state/data in a table.
| gmfawcett wrote:
| > The problem is when you communicate, you always do it with
| state and not functions.
|
| I'm not sure that's true. A "callback" is way of
| communicating with a function as the message. Callbacks are a
| way for systems to communicate while hiding their
| implementation details. (One could argue that the callback
| itself is a first-order object -- a piece of state -- but
| nonetheless we are communicating with state _and_ functions
| then.)
| ardit33 wrote:
| Callbacks are a signal that your operation is done, and the
| data is ready... usually they have some kind of state (i.e.
| success, error, the data read from disk/api, etc).
|
| They are usually used within one program itself, and not
| across systems. Something like the Firebase real time
| database, or webhooks, are for callback achross systems,
| but they always are used to pass data/state, and not
| functions itself.
|
| Again, SQL and maybe Regex (which is not a full programming
| language anyway), as the most successful alternatives to
| normal Object Oriented/procedural programing.
|
| Most functional languages have not become successful. I
| learned Prolog in the 90s, and I could see how it might be
| useful in some situations, but it is hard to do anything
| practical with it.
|
| Some functional concepts, like map/reduce, have become
| popular in mainstream languages, as they are useful in
| certain scenarios, but pure functional languages have not.
| [deleted]
| youerbt wrote:
| > Perhaps the universe is state based, and not function
| based...
|
| That didn't stop physics, why should it stop CS? No paradigm
| won, game is not over yet.
| beders wrote:
| Did you just compare passing data to passing functions?
|
| Because absolutely nothing about transferring data is
| specific to the program language paradigm chosen.
|
| Here's a task for you: Build a graph of objects holding state
| with your chosen OO language. Now write that state to disk
| and read it back in - guaranteeing a consistent state.
|
| Oops, a thread mutated some of the state while writing to
| disk?
|
| Damn it, need to add a some synchronization stuff. In all my
| objects. Oh now all my mutations need to go through a
| semaphore?
|
| No, wait I'll implement the Memento pattern for all my
| objects, that will help? (nope, it won't, you still need to
| synchronize across threads)
|
| If you operate on immutable data, that exercise in a
| functional language is literally two lines of code.
| js8 wrote:
| In concatenative languages, you can easily provision for
| both. Joy is purely functional, but in Forth, the individual
| "words" frequently manipulate state.
| JoshuaAshton wrote:
| b sqr 4 a c * * - sqrt
|
| Yeah no. This being "bug free" seems like a joke.
| js8 wrote:
| This is just a "minor usability issue". Seriously. In Factor,
| you can solve this with references to local variables, which
| under the covers manipulate the stack as needed. It can also
| typecheck, so you wouldn't be able to write the expression in
| a way which unbalances the stack.
| discreteevent wrote:
| Booch: Your functional programming work was unsuccessful.
|
| Backus: Yes.
|
| Booch: Let's dwell upon that for a moment, because there were
| some other papers that I saw after your Turing Award lecture
| ["Can Programming Be Liberat ed From the von Neummann Style",
| 1977] which was also a turning point. Because I'd describe it as
| a wake-up call to the language developers and programmers, saying
| there's a different way of looking at the world here. The world
| was going down a very different path. Let me pursue that point of
| why you think it didn't succeed.
|
| Backus: Well, because the fundamental paradigm did not include a
| way of dealing with real time. It was a way of saying how to
| transform this thing into that thing, but there was no element of
| time involved, and that was where it got hung up.
|
| Booch: That's a problem you wrestled with for literally years.
|
| Backus: Yeah, and unsuccessfully.
|
| http://archive.computerhistory.org/resources/access/text/201...
| ipnon wrote:
| Reactive paradigm programming seems to have handled this
| problem is a satisfactorily functional way. But these higher
| reactive layers are almost always built on Von Neumann paradigm
| languages like JavaScript. So long as bare metal looks more
| like a Turing machine than a Church calculus we will struggle
| to take functional paradigm from top to bottom.
| brazzy wrote:
| The whole thing still runs in and has to interact with the
| real world where everything is governed by time and state.
| You can't avoid having the impedance mismatch _somewhere_ in
| your stack.
| Quekid5 wrote:
| Monadic IO, Uniqueness types (as in: Clean), voluntarily
| working in a pure subset until the End of the World
| (Scala), effect-first languages, etc. We _can_ impose
| actual semantics upon an ultimately imperative computer. Is
| it restrictive? Yeah, but that 's, like the point, man.
| Restricting what _can_ happen allows us to reason about
| what _might_ happen given a piece of 'random' code. In an
| imperative-only world, Capabilities serve a similar
| function.
|
| The fact that the world is made up of elementary particles
| subject to the 'laws' of thermodynamics has very little
| impact on the semantics we choose for our programming
| languages. (If you want to take your appeal to 'nature'
| that far.)
| dnautics wrote:
| The inability to deal with time and state is not
| fundamental to functional PLs (though possibly a difficulty
| for pure FPs). Erlang handles time, state, AND space
| (though isn't that just time?) fantastically. Perhaps
| unsurprisingly, the lead creator was a Physics PhD
| (candidate dropout? I don't remember). Concepts of giving
| up on absolute synchronicity, for example, reliability of
| transmissions across unreliable channels, permeate the feel
| of the (functional) system. It is decidedly not pure
| functional programming though, as the choice of a
| functional system was made more of a pragmatic / developer
| ergonomic choice than a theoretical one.
| [deleted]
| dang wrote:
| The pdf is at https://dl.acm.org/doi/10.1145/359576.359579
| dang wrote:
| Past related threads:
|
| _Can Programming Be Liberated from the von Neumann Style? (1977)
| [pdf]_ - https://news.ycombinator.com/item?id=21855249 - Dec 2019
| (32 comments)
|
| _Can Programming Be Liberated from the von Neumann Style? (1977)
| [pdf]_ - https://news.ycombinator.com/item?id=14673817 - June
| 2017 (3 comments)
|
| _Can Programming Be Liberated from the von Neumann Style? (1978)
| [pdf]_ - https://news.ycombinator.com/item?id=13210988 - Dec 2016
| (107 comments)
|
| _Can Programming Be Liberated From The Von Neumann Style? (1977)
| [pdf]_ - https://news.ycombinator.com/item?id=12159792 - July
| 2016 (175 comments)
|
| _Can Programming Be Liberated from the von Neumann Style? (1978)
| [pdf]_ - https://news.ycombinator.com/item?id=10182712 - Sept
| 2015 (57 comments)
|
| _Can Programming Be Liberated From The Von Neumann Style? (1977)
| [pdf]_ - https://news.ycombinator.com/item?id=7671379 - April
| 2014 (72 comments)
|
| _Can Programming Be Liberated from the von Neumann Style?
| (classic)_ - https://news.ycombinator.com/item?id=768057 - Aug
| 2009 (34 comments)
| failwhaleshark wrote:
| Feature request for the submit page: live AI fuzzy suggestions
| of URLs to prevent dupe submits.
| dang wrote:
| It's important to understand that this submission doesn't
| count as a dupe by HN's standards. Reposts are fine after a
| year or so, and/or if an article hasn't had significant
| attention before (the latter isn't the case here, but often
| is).
|
| Because there's so much randomness in what gets noticed on
| /newest, overzealous dupe detection would prevent many good
| articles from ever getting discussed. That would be a poor
| trade for better deduplication! HN's dupe detector is
| therefore left porous on purpose (https://hn.algolia.com/?dat
| eRange=all&page=0&prefix=true&que...). We will probably
| implement karma sharing amongst the various submitters of an
| article, though, at least when it's a first-time discussion.
| akomtu wrote:
| On a half serious note, the traditional 0-1 computing model is
| the origin of mental polarisation in our society, because such
| model permits no shades of gray. A better model would use
| probabilistic bits where each bit represents a probability
| density.
| njdullea wrote:
| So there wasn't 'mental polarisation' in society before
| computational models were created? Don't think that's correct..
| kstrauser wrote:
| That's why I use only floats in my code, and a patched Python
| interpreter that replaces "if" with "seemslikely".
| agubelu wrote:
| #define true (rand() < 0.99)
| andrewmcwatters wrote:
| I await our enlightened future where we can run programs that
| have differing state that can be simultaneously true.
|
| What one thread on my CPU calculates as true is it's truth.
| Other threads might not agree, because it's not their truth.
| Apocryphon wrote:
| Isn't that what quantum computing is on about
| Banana699 wrote:
| you meant a 0% serious note right?
|
| The 0s and 1s are in the human brain friend not the computers.
| You can make computing as probabilistic as your heart desires,
| people will not stop simplifying and caricaturing the world to
| fit their biases, not by one "bit".
| asimjalis wrote:
| Maybe.
| xkeysc0re wrote:
| If only ternary computing had won!
| https://en.wikipedia.org/wiki/Ternary_computer
| andrewmcwatters wrote:
| I would like a system that produces "true," "false," and
| "enthusiastic" results. Enthusiasm left as an exercise for
| the implementor.
| peheje wrote:
| I prefer trulse
___________________________________________________________________
(page generated 2021-06-18 23:00 UTC)