9 ms·

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

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/2013/05/102657970-05-01-acc.pdf http://archive.computerhistory.org/resources/access/text/201...

ipnon 5y ago
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 5y ago
  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.
  - dnautics 5y ago
    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.
    - mpweiher 5y ago
      Yes it is, and Erlang isn't a counterexample. As you noted, it's not a "pure" FP, and it is exactly the messaging elements that let it handle these things. Q: Erlang "object-oriented" after all? A: Yes. http://erlang.org/pipermail/erlang-questions/2009-November/047748.html http://erlang.org/pipermail/erlang-questions/2009-November/0...
      - dgb23 5y ago
        In a talk he admitted that Erlang is the unification of OO and FP, although he didn’t realize it when he created the language. He also mentioned Hoare‘s CSP as an inspiration with the caveat that he didn’t agree with the lock-step synchronization as messages should be async. Makes sense from a physicist‘s perspective.
        dnautics 5y ago
        I'm sorry, I have a lot of respect for Joe Armstrong but this is simply something he got wrong, probably because he didn't fully understand smalltalk objects. Before he 'admitted' as such, he understandably thought OO was stroustrop style OO. Then someone pointed out to him that originally OO was smalltalk OO, which admittedly looks vaguely like erlang message passing. But there are critical differences.
      - dnautics 5y ago
        something can be both object-oriented and functional. they're not exclusive. However, although erlang's process model superficially looks like smalltalk objects, if you design your erlang program like a smalltalk program, your performance will suffer and you will be in a world of hurt when stuff breaks. The point of message passing concurrency in erlang is to create failure domains, not to organize your code. In short, please do not structure your erlang program like smalltalk OO, and it is definitely not what a contemporary programmer would call OO.
        mpweiher 5y ago
        > something can be both object-oriented and functional. they're not exclusive Indeed: not a "pure" FP, and it is exactly the messaging elements that let it handle these things > However, although erlang's process model superficially looks like smalltalk objects Did anybody claim Erlang objects were like Smalltalk objects?
  - Quekid5 5y ago
    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.)
    - brazzy 5y ago
      I was replying to a comment that specifically bemoaned that the low level hardware is not functional.
  - stingraycharles 5y ago
    Of course, but in the end everything is an abstraction. You can use functional reactive programming to expose a stateful API, for example; there’s nothing wrong with that. And on the other end of the spectrum, if you go low level enough you realize that everything is stateful in the machine, so you will need to build (or already have) functional abstractions on top of that. Bottom line, it’s almost impossible to have a single paradigm on all levels of your stack.
- deleted 5y ago
  [deleted]
- marcosdumay 5y ago
  I will call reactive paradigms "satisfactory" after I get to see any real framework on it that is easy to read and write large programs on. Yes, they are very promising. But since every single widely deployed language (and "widely" here includes things like Haskell) is a bad fit to it, we are missing some more development before that promise is fulfilled or failed. (And by the way, the JS frameworks, popular as they are can not claim to be free from the Von Neumann constraints. That requires a pure language.)
  - solomonb 5y ago
    I've always found Arrowized FRP to be really nice to work with.
    - marcosdumay 5y ago
      The abstract concept of arrowized FRP is quite promising. The practical implementations are either way too complex for everyday usage¹, or specialized into a narrow application. Also, arrows create a completely different sublanguage on any mainstream language that supports it; a sublanguage where things don't compose as nicely. 1 - You can't demand that people will convert a simple procedure into a series of unrelated steps spread all around, that's a receipt for bad code. The fact that people do such things on unrelated domains is not a reason to have it here, it creates bad code there too.
  - ipnon 5y ago
    Angular uses RxJS as a primitive. It's a breeze writing reactive components and applications that way.
    - taeric 5y ago
      I have yet to see even a medium size program stay "a breeze" due to choice of this kind. Tons and tons of small parts that give the facade of easy breezy. But then the whole that they make up is left incomprehensible. Would be delighted to see counter evidence.
- amw-zero 5y ago
  > So long as bare metal looks more like a Turing machine than a Church calculus This will always be the case. The Turing machine is simply a much better model for implementing a machine capable of executing programs. The Lambda calculus (and math in general) are obviously better tools for _reasoning_, but the reason that reasoning in them is so powerful is precisely because you don't have to consider the execution cost of certain operations to reason about them. Think about all of the common set theory operations. It is trivial to write: PrimeNumbers ⊆ NaturalNumbers, however, think about _computing_ the result of this expression. Generating prime numbers is not a simple computational task, and even if it were, you can only ever verify it for a subset of the natural numbers since computation is inherently finite. It's all fun and games until you need to execute the program. The functional style is great in terms of expressivity, but you want a Turing machine at the bottom executing it if you ever want the program to finish in your lifetime.
  - kaba0 5y ago
    I may not get your point - but a mathematical expression in itself is not functional - as far as I know. You have to give a definition that will likely be an infinite recursive function - which is strictly equivalent in what it can do to a Turing machine.
    - TomSwirly 5y ago
      General recursive function, you mean. The point is that creating hardware that executes a Turing machine or something like it is easy, but constructing hardware that executes a general recursive function is so hard that it has never been done.
      - kaba0 5y ago
        My point was that a random mathematical expression will not be constructive in itself. And you are right, that either general recursive functions or lambda expressions are required to be equivalent to Turing machines. And while I agree that recursive functions are hard to execute on hardware - but certain aspects of it are apparent in CPU design — out-of-order execution is sort of lambda-like.
spicybbq 5y ago
This whole interview is on YouTube as well: https://www.youtube.com/watch?v=dDsWTyLEgbk https://www.youtube.com/watch?v=dDsWTyLEgbk
mumblemumble 5y ago
The rest of the interview provides an interesting context there. He retried in 1991, and, since then, he seemed to have been extremely uninterested in keeping up to speed with any newer programming languages. Meanwhile, Haskell 1.0 entered the world in 1990, and the Haskell community figured out how to use monads to solve the time problem in 1993. So, it's not necessarily that the problem wasn't solved, it just wasn't solved by him, and he perhaps wasn't aware of the solution.
- dustingetz 5y ago
  comonad encodes time, but first good paper i know of that describes this is 2006
  - ffhhj 5y ago
    which paper?
  - bradrn 5y ago
    Well, more generally speaking comonads encode costate i.e. context, but I haven’t yet seen them being used represent time. Do you have a link to the paper?
    - dustingetz 5y ago
      http://cs.ioc.ee/~tarmo/papers/essence.pdf http://cs.ioc.ee/~tarmo/papers/essence.pdf also it needs to be updated for cofree comonad
      - bradrn 5y ago
        Thank you!
  - mumblemumble 5y ago
    Well, the interview never really addresses this clearly and directly, but my sense was that it seemed that the biggest problem he was grappling with was dealing with situations where things have to happen in a certain order. The formulation of functional programming that he presented in Can Programming be Liberated from the Von Neumann Style? is, at least to my reading, pure and lazy. For a while at least, nobody really knew how to deal with things where time matters in even the most basic way - ensuring that they happen in a certain order, or even at all - in a pure and lazy language. The Haskell community figured out how to use monads to crack that problem in the early 1990s. Haskell 1.0 didn't have monadic IO, what it had instead was, from what I've read, kind of an unwieldy hack. SPJ covers these sorts of issues in some detail in his paper Tackling the Awkward Squad: https://www.microsoft.com/en-us/research/publication/tackling-awkward-squad-monadic-inputoutput-concurrency-exceptions-foreign-language-calls-haskell/ https://www.microsoft.com/en-us/research/publication/tacklin...

ipnon 5y ago

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 5y ago
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.
- dnautics 5y ago
  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.
  - mpweiher 5y ago
    Yes it is, and Erlang isn't a counterexample. As you noted, it's not a "pure" FP, and it is exactly the messaging elements that let it handle these things. Q: Erlang "object-oriented" after all? A: Yes. http://erlang.org/pipermail/erlang-questions/2009-November/047748.html http://erlang.org/pipermail/erlang-questions/2009-November/0...
    - dgb23 5y ago
      In a talk he admitted that Erlang is the unification of OO and FP, although he didn’t realize it when he created the language. He also mentioned Hoare‘s CSP as an inspiration with the caveat that he didn’t agree with the lock-step synchronization as messages should be async. Makes sense from a physicist‘s perspective.
      - dnautics 5y ago
        I'm sorry, I have a lot of respect for Joe Armstrong but this is simply something he got wrong, probably because he didn't fully understand smalltalk objects. Before he 'admitted' as such, he understandably thought OO was stroustrop style OO. Then someone pointed out to him that originally OO was smalltalk OO, which admittedly looks vaguely like erlang message passing. But there are critical differences.
    - dnautics 5y ago
      something can be both object-oriented and functional. they're not exclusive. However, although erlang's process model superficially looks like smalltalk objects, if you design your erlang program like a smalltalk program, your performance will suffer and you will be in a world of hurt when stuff breaks. The point of message passing concurrency in erlang is to create failure domains, not to organize your code. In short, please do not structure your erlang program like smalltalk OO, and it is definitely not what a contemporary programmer would call OO.
      - mpweiher 5y ago
        > something can be both object-oriented and functional. they're not exclusive Indeed: not a "pure" FP, and it is exactly the messaging elements that let it handle these things > However, although erlang's process model superficially looks like smalltalk objects Did anybody claim Erlang objects were like Smalltalk objects?
- Quekid5 5y ago
  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.)
  - brazzy 5y ago
    I was replying to a comment that specifically bemoaned that the low level hardware is not functional.
- stingraycharles 5y ago
  Of course, but in the end everything is an abstraction. You can use functional reactive programming to expose a stateful API, for example; there’s nothing wrong with that. And on the other end of the spectrum, if you go low level enough you realize that everything is stateful in the machine, so you will need to build (or already have) functional abstractions on top of that. Bottom line, it’s almost impossible to have a single paradigm on all levels of your stack.
deleted 5y ago
[deleted]
marcosdumay 5y ago
I will call reactive paradigms "satisfactory" after I get to see any real framework on it that is easy to read and write large programs on. Yes, they are very promising. But since every single widely deployed language (and "widely" here includes things like Haskell) is a bad fit to it, we are missing some more development before that promise is fulfilled or failed. (And by the way, the JS frameworks, popular as they are can not claim to be free from the Von Neumann constraints. That requires a pure language.)
- solomonb 5y ago
  I've always found Arrowized FRP to be really nice to work with.
  - marcosdumay 5y ago
    The abstract concept of arrowized FRP is quite promising. The practical implementations are either way too complex for everyday usage¹, or specialized into a narrow application. Also, arrows create a completely different sublanguage on any mainstream language that supports it; a sublanguage where things don't compose as nicely. 1 - You can't demand that people will convert a simple procedure into a series of unrelated steps spread all around, that's a receipt for bad code. The fact that people do such things on unrelated domains is not a reason to have it here, it creates bad code there too.
- ipnon 5y ago
  Angular uses RxJS as a primitive. It's a breeze writing reactive components and applications that way.
  - taeric 5y ago
    I have yet to see even a medium size program stay "a breeze" due to choice of this kind. Tons and tons of small parts that give the facade of easy breezy. But then the whole that they make up is left incomprehensible. Would be delighted to see counter evidence.
amw-zero 5y ago
> So long as bare metal looks more like a Turing machine than a Church calculus This will always be the case. The Turing machine is simply a much better model for implementing a machine capable of executing programs. The Lambda calculus (and math in general) are obviously better tools for _reasoning_, but the reason that reasoning in them is so powerful is precisely because you don't have to consider the execution cost of certain operations to reason about them. Think about all of the common set theory operations. It is trivial to write: PrimeNumbers ⊆ NaturalNumbers, however, think about _computing_ the result of this expression. Generating prime numbers is not a simple computational task, and even if it were, you can only ever verify it for a subset of the natural numbers since computation is inherently finite. It's all fun and games until you need to execute the program. The functional style is great in terms of expressivity, but you want a Turing machine at the bottom executing it if you ever want the program to finish in your lifetime.
- kaba0 5y ago
  I may not get your point - but a mathematical expression in itself is not functional - as far as I know. You have to give a definition that will likely be an infinite recursive function - which is strictly equivalent in what it can do to a Turing machine.
  - TomSwirly 5y ago
    General recursive function, you mean. The point is that creating hardware that executes a Turing machine or something like it is easy, but constructing hardware that executes a general recursive function is so hard that it has never been done.
    - kaba0 5y ago
      My point was that a random mathematical expression will not be constructive in itself. And you are right, that either general recursive functions or lambda expressions are required to be equivalent to Turing machines. And while I agree that recursive functions are hard to execute on hardware - but certain aspects of it are apparent in CPU design — out-of-order execution is sort of lambda-like.

spicybbq 5y ago

This whole interview is on YouTube as well: https://www.youtube.com/watch?v=dDsWTyLEgbk https://www.youtube.com/watch?v=dDsWTyLEgbk

mumblemumble 5y ago

The rest of the interview provides an interesting context there. He retried in 1991, and, since then, he seemed to have been extremely uninterested in keeping up to speed with any newer programming languages. Meanwhile, Haskell 1.0 entered the world in 1990, and the Haskell community figured out how to use monads to solve the time problem in 1993. So, it's not necessarily that the problem wasn't solved, it just wasn't solved by him, and he perhaps wasn't aware of the solution.

dustingetz 5y ago
comonad encodes time, but first good paper i know of that describes this is 2006
- ffhhj 5y ago
  which paper?
- bradrn 5y ago
  Well, more generally speaking comonads encode costate i.e. context, but I haven’t yet seen them being used represent time. Do you have a link to the paper?
  - dustingetz 5y ago
    http://cs.ioc.ee/~tarmo/papers/essence.pdf http://cs.ioc.ee/~tarmo/papers/essence.pdf also it needs to be updated for cofree comonad
    - bradrn 5y ago
      Thank you!
- mumblemumble 5y ago
  Well, the interview never really addresses this clearly and directly, but my sense was that it seemed that the biggest problem he was grappling with was dealing with situations where things have to happen in a certain order. The formulation of functional programming that he presented in Can Programming be Liberated from the Von Neumann Style? is, at least to my reading, pure and lazy. For a while at least, nobody really knew how to deal with things where time matters in even the most basic way - ensuring that they happen in a certain order, or even at all - in a pure and lazy language. The Haskell community figured out how to use monads to crack that problem in the early 1990s. Haskell 1.0 didn't have monadic IO, what it had instead was, from what I've read, kind of an unwieldy hack. SPJ covers these sorts of issues in some detail in his paper Tackling the Awkward Squad: https://www.microsoft.com/en-us/research/publication/tackling-awkward-squad-monadic-inputoutput-concurrency-exceptions-foreign-language-calls-haskell/ https://www.microsoft.com/en-us/research/publication/tacklin...