3 ms·

> (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if

by dualogy 10y ago

> (I have exactly the same objection to the actor model as a foundational unit of computing. Theoretically, it's fine, but in practice it doesn't really work if it's all you can do. Similar to "pure" lambda calculus.) With these models, it's all about making compilers ever better at their specialized job of translating "abstract machinery" into the current physical-machinery paradigm of the day. No idea about "actors" but "pure lambda calculus" works terrifically well thanks to 25 years of top-notch efforts invested in the Glasgow Haskell Compiler. OO is really in the same boat in that it's not exactly ASM either, just has even more "compiler investment" behind it broadly speaking.

lomnakkus 10y ago
GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern matching, etc. which leads far afield from LC. For another, there's "IO" which doesn't have any kind of formal semantics in Haskell, nevermind LC, so... EDIT: I'm not saying it's not useful as a model, I'm just questioning whether it's practical. I think both LC and the Actor model are both interesting and valuable, I just don't think they should be the foundational model for ABSOLUTELY EVERYTHING as e.g. Alan Kay seems to be advocating. EDIT#2: I should say... I realize that LC actually is Turing-Complete, as I believe Hewitt has also demonstrated that the Actor model is. However, I believe Hewitt assumes infinite queues. As always, infinity gives quite a bit of leeway.
- dualogy 10y ago
  > GHC isn't even close to "pure lambda calculus" Well I reckon you're using a "strict" definition of pure and I'm using a "lazy" one.. ;) Let's say Haskell-the-language is on the purer side of things and GHC-the-compiler by necessity closer to the messy not-so-pure real-world-er side of programs that run acceptably speedily reliably and sturdily most-of-the-time.. (IO monad "while used by the coder" seems plenty pure to me other than the background knowledge that eventually with a `main` entry point it will become hooked up with actual I/O.. but that's "semantics" hehe)
  - lomnakkus 10y ago
    Alright, then -- I think we agree for all practical purposes :). Still, I think it is important to realize that while "IO" is 'sort-of-a-monad'... the truth isn't quite that simple :). There's a lot of nastiness hidden behind it, especially FFI and exception-related things... ugh. EDIT: My original point was mostly that maybe he hadn't thought this whole "async every method call!" thing through. That... leads to a mess, especially if every single "thing" you do is a "method call".
- sriku 10y ago
  It looks like what you're trying to say is that the difference between theory and practice is that in theory there isn't any but in practice there is. (Someone else said this, not me)

by dualogy 10y ago

lomnakkus 10y ago

GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern matching, etc. which leads far afield from LC. For another, there's "IO" which doesn't have any kind of formal semantics in Haskell, nevermind LC, so... EDIT: I'm not saying it's not useful as a model, I'm just questioning whether it's practical. I think both LC and the Actor model are both interesting and valuable, I just don't think they should be the foundational model for ABSOLUTELY EVERYTHING as e.g. Alan Kay seems to be advocating. EDIT#2: I should say... I realize that LC actually is Turing-Complete, as I believe Hewitt has also demonstrated that the Actor model is. However, I believe Hewitt assumes infinite queues. As always, infinity gives quite a bit of leeway.

dualogy 10y ago
> GHC isn't even close to "pure lambda calculus" Well I reckon you're using a "strict" definition of pure and I'm using a "lazy" one.. ;) Let's say Haskell-the-language is on the purer side of things and GHC-the-compiler by necessity closer to the messy not-so-pure real-world-er side of programs that run acceptably speedily reliably and sturdily most-of-the-time.. (IO monad "while used by the coder" seems plenty pure to me other than the background knowledge that eventually with a `main` entry point it will become hooked up with actual I/O.. but that's "semantics" hehe)
- lomnakkus 10y ago
  Alright, then -- I think we agree for all practical purposes :). Still, I think it is important to realize that while "IO" is 'sort-of-a-monad'... the truth isn't quite that simple :). There's a lot of nastiness hidden behind it, especially FFI and exception-related things... ugh. EDIT: My original point was mostly that maybe he hadn't thought this whole "async every method call!" thing through. That... leads to a mess, especially if every single "thing" you do is a "method call".
sriku 10y ago
It looks like what you're trying to say is that the difference between theory and practice is that in theory there isn't any but in practice there is. (Someone else said this, not me)