3 ms·

I downloaded a copy of SICP last week, and I was thinking about that chapter as I read this presentation. I haven't had a chance to give that section full atten

by IsaacL 17y ago

I downloaded a copy of SICP last week, and I was thinking about that chapter as I read this presentation. I haven't had a chance to give that section full attention yet, but have the ideas expressed there had much influence on language design? Is Rich's presentation representative of some ideas more advanced than that section of SICP? Or has it been largely ignored over the decades?

plinkplonk 17y ago
"but have the ideas expressed there had much influence on language design?" yes! Every imperative(I include OO in "imperative" here) language that allows local computational state, and every functional language trying to maintain referential transparency (and everything in between) embody those ideas, so yes the ideas of dealing with time in computation by local state, streams, pure functions etc are influential in all language design. "Is Rich's presentation representative of some ideas more advanced than that section of SICP?" This is a vague question, (what exactly do you think is "more advanced"? ), but to (try to) answer it, (imo) No, not really, not at the level of ideas. Haskell or Erlang is, for example, as advanced, in terms of ideas, (or more advanced, depending on your pov) than Clojure, for e.g Where Rich has done great (,brilliant!) work is to turn these ideas (and others- see his bookshelf!-,e.g many from lisp, e.g meta programming with macros) into a workable, practical, and beautiful language which interoperates with tonnes of existing libraries. The combination of deep theoretical insight and a ruthless focus on practicality is what (I think) makes Rich Hickey unique. The one aspect of Rich's talk not covered is SICP is the use of persistent data structures, but if you have worked through SICP, you'll instantly understand why this is a great solution and what the potential tradeoffs are. The problems (and advantages!) of state in programming languages and its interwining with time (and therefore concurrency) is clearly laid out in SICP Ch. 3. (Eg. Section 3.4 is titled "Concurrency: Time is of the essence", 3.4.1 is "The Nature of Time in Concurrent Systems" while the language is very clear, it needs repeated reading and deep thougt (imo) to get a good grip on the ideas). Every functional language(e.g Haskell) deals with the "functional" view of time. Every language that allows modelling of local state and loss of referential transparency(all imperative and OO languages afaik) choose the "other path" (some would say the dark side!) of dealing with time in computation. Let me repeat, my post above was not claiming that Rich's talk is valueless or that he is only repeating what SICP said. My point was (only) that a good understanding of Chapter 3 of SICP would be a great background to understanding this talk. Eg: You will understand exactly what he means by OO needing to "stop the world", even without seeing the details on the succeeding slides.
- IsaacL 17y ago
  Thanks for your answer. I took another look at that chapter, though I'll definetly need to come back to it and try out some of the excercises for understanding. I should take a closer look at Clojure as well (tried a few Project Euler problems, but would like to try a large project in a Lisp dialect).

by IsaacL 17y ago

plinkplonk 17y ago

"but have the ideas expressed there had much influence on language design?" yes! Every imperative(I include OO in "imperative" here) language that allows local computational state, and every functional language trying to maintain referential transparency (and everything in between) embody those ideas, so yes the ideas of dealing with time in computation by local state, streams, pure functions etc are influential in all language design. "Is Rich's presentation representative of some ideas more advanced than that section of SICP?" This is a vague question, (what exactly do you think is "more advanced"? ), but to (try to) answer it, (imo) No, not really, not at the level of ideas. Haskell or Erlang is, for example, as advanced, in terms of ideas, (or more advanced, depending on your pov) than Clojure, for e.g Where Rich has done great (,brilliant!) work is to turn these ideas (and others- see his bookshelf!-,e.g many from lisp, e.g meta programming with macros) into a workable, practical, and beautiful language which interoperates with tonnes of existing libraries. The combination of deep theoretical insight and a ruthless focus on practicality is what (I think) makes Rich Hickey unique. The one aspect of Rich's talk not covered is SICP is the use of persistent data structures, but if you have worked through SICP, you'll instantly understand why this is a great solution and what the potential tradeoffs are. The problems (and advantages!) of state in programming languages and its interwining with time (and therefore concurrency) is clearly laid out in SICP Ch. 3. (Eg. Section 3.4 is titled "Concurrency: Time is of the essence", 3.4.1 is "The Nature of Time in Concurrent Systems" while the language is very clear, it needs repeated reading and deep thougt (imo) to get a good grip on the ideas). Every functional language(e.g Haskell) deals with the "functional" view of time. Every language that allows modelling of local state and loss of referential transparency(all imperative and OO languages afaik) choose the "other path" (some would say the dark side!) of dealing with time in computation. Let me repeat, my post above was not claiming that Rich's talk is valueless or that he is only repeating what SICP said. My point was (only) that a good understanding of Chapter 3 of SICP would be a great background to understanding this talk. Eg: You will understand exactly what he means by OO needing to "stop the world", even without seeing the details on the succeeding slides.

IsaacL 17y ago
Thanks for your answer. I took another look at that chapter, though I'll definetly need to come back to it and try out some of the excercises for understanding. I should take a closer look at Clojure as well (tried a few Project Euler problems, but would like to try a large project in a Lisp dialect).