5 ms·
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 u
by 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 agocomonad encodes time, but first good paper i know of that describes this is 2006
- ffhhj 5y agowhich paper?
- bradrn 5y agoWell, 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 agohttp://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 agoThank you!
- mumblemumble 5y agoWell, 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...
- ulrikrasmussen 5y agoDid Clean have uniqueness typing from it's inception ('87)? That's another way to deal with time.
- edflsafoiewq 5y agoIO solves the "time problem" by just encoding a von Neumann machine in the functional language, which is less like a liberation than a peace treaty.
- creata 5y agoMaybe my imagination is too small, but what else could a solution look like? You want sequencing, and IO gives you exactly that.
- dustingetz 5y agostream, signal, and differential programming
- mumblemumble 5y agoPerhaps. But I think that you're also wandering away from the plot. Clinging to our contemporary way of thinking about this stuff isn't really going to help us understand what he was grappling with 30, 40 years ago. It's more likely to muddy the waters. I don't see any evidence in there that Backus was looking for anything quite so lofty as the stuff you're bringing up. While it's true he wrote the paper that kicked off the whole idea behind FP, we've also got to keep in mind that, as he repeatedly mentions in the interview, he was a lifelong Fortran programmer who, in marked contrast to most fans of FP nowadays, held a lifelong affinity for Fortran. It sounds to me like encoding Von Neumann bits into the functional language so that you're there when you need them is exactly the sort of thing he was looking for. To my reading, his Turing lecture would seem to suggest the same.
- juliangamble 5y agoCould you provide a link or example?
- catgary 5y agoI feel like Hagino had talked about coinductive data types in the early 90’s.
- catgary 5y agoMoggi solved it in his thesis in ‘88.
- lukashrb 5y agoI would really appreciate if someone takes the time to enlighten me how monads solve the problem.
- deleted 5y ago[deleted]
- mumblemumble 5y agoCheck out that Tackling the Awkward Squad that I mentioned elsewhere. It's about as lucid an explanation of the what and why as I've ever seen, by one of the original authors of Haskell. https://www.microsoft.com/en-us/research/publication/tacklin https://www.microsoft.com/en-us/research/publication/tacklin...
- loopz 5y agoWith pure code you cannot really do much of practical value. You can perhaps compute values, solve relational or logic problems, do math, etc., but you only end up with results at the end of computations. Even that may require monads to print out or somehow follow a specific sequence, if the language is pure enough. Pure lazy code simply won't do anything, and evaluation order of lazy execution is variable, undefined even. Purity taken too far, won't do anything useful by itself. So you use monads to add magic while starting off evaluations, often in specific sequences. They make up code blocks that are explicit about having side-effects. So are often used to separate pure code from impure code, as the magic monads can do could be anything one would like to add. So it's kind of like an impure addon to the existing language, but also by being explicit and more precise about the taints on purity. Each monad do different things, so are kind of like different addons. However, monads may generally be used purely too. They are more general tools than just the famous IO monad. So the concept of monads are reused for abstraction. It's useful that so many things are solved by reusing the same general pattern. To explain all of that would require more context of the language itself, ie. Haskell. I'm sure somone with more experience has a short and easy explanation! :) There are StackOverflow pages and such that have good explanations for those with a bit of familiarity with Haskell.