Rich Hickey's Keynote: A deconstruction of object-oriented time [pdf]

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.

Calling (transient x) gives you a mutable copy of x which is created in O(1) time. You can then use functions like conj! and assoc! to modify the data structure in place. When you've finished, call (persistent! x) which returns you to a pure data structure (another O(1) operation).

This doesn't have much to do with sharing. Rather, it is the overhead of boxing the integers.

If you want a byte array that you'll interpret as an array of machine integers (as an int * would be in C), then you need to use that type instead of a "list of integers" that your language provides. That "list of integers" is optimized for something other than space (integer math not overflowing, O(1) insertions, etc.). Conversely, arrays of machine ints have many annoying quirks, but the underlying hardware can process them really quickly, and they are very frugal with respect to memory use. (No overhead, basically.)

As it stands now, most language implementations are not smart enough to see that you just used lists because you like the syntax, but meant to use byte arrays. (Or, you used Integers instead of ints.)

Tracemonkey, GHC, and probably other languages have code to help optimize this case. dons wrote a nice article about how GHC's codegen produces code that uses unboxed types even though the programmer used boxed types.

As far as I know, Clojure is not really smart enough to optimize much right now (beyond the JIT that the JVM does), so this is probably a problem. The solution is to fix Clojure or to use the native types. I don't know how to do this, as I don't use Java or Clojure, but it sounds like a Simple Matter Of Programming to expose a shared array of unboxed integers. (There are a lot of papers on this.)

Functional programming is a "new idea" in terms of people using it for "Real Work", so there is a long way to go in terms of writing excellent optimizing compilers. It is getting better very quickly, though.