Rich Hickey's Keynote: A deconstruction of object-oriented time [pdf]
wiki.jvmlangsummit.com
wiki.jvmlangsummit.com
It needs some deep thinking and slow and careful reading to understand all the implications (most students rush through these sections imo), but it provides a good foundation to understand what Rich's talking about.
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.
http://www.youtube.com/watch?v=zRTx1oGG_1Y&feature=chann...
I am thirsty to watch the talk! anyone? torrents?
Do these videos ever appear someplace for easy download, or will they forever be stuck on someone's walled garden?
I think the key to Rich's ideas is to realise them on non-volatile storage. This could revolutionise filesystems and databases.
http://www.mail-archive.com/tux3@tux3.org/msg00035.html
I assume that all "snapshotting" filesystems (NetApp, ZFS) have a similar structure?
Edit: ah, tux3 is alive: http://tux3.org/, it was tux2 which was quashed. Cool.
Generally these fall into two approaches: fat nodes and path copying. With fat nodes, each node maintains it's own independent history of update operations. With path copying instead we create a new modified node, and then walk the path from it back up to the parent creating new modified nodes as we go, finally resulting in a new root (uber/super block in a file system).
Traversing a particular snapshot in fat nodes is complicated, but is simple with path copying. With path copying however updates are more expensive and we tend to have more duplicate data (depending on the fan out of nodes).
Interestingly, we can do better than both of these approaches. I'm not aware of any filesystems that use this schemes, but you may find this paper interesting:
http://ocw.mit.edu/NR/rdonlyres/Electrical-Engineering-and-C...
Creating a consistent global view of time requires communication to achieve this consensus. Not just that, we know from FLP that we'll need to use failure detectors and timeouts to simulate a globally synchronous system.
This approach (namely Paxos) has such a high performance cost that it's important to understand alternative perspectives that do not require a global clock (in any form). This was the entire point of Rich's talk: that we gain advantages from having a more nuanced model of time.
"All of the Clojure collections are immutable and persistent. In particular, the Clojure collections support efficient creation of 'modified' versions, by utilizing structural sharing, and make all of their performance bound guarantees for persistent use." http://clojure.org/data_structures
What this does to cache locality, I do not know.
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.
But if I put lots of structs in a Java ArrayList, memory use goes down significantly, so clojure vectors are much less efficient regardless of boxing.
But the conclusions drawn seem to be yet another attempt at deriving a paradigmatic model (of reality) that is "simplistic" (to borrow his critique of OO). If the object is now to graduate to subject -- a fine idea -- then we should remember that sentient modality of being includes repose, as well as action.
Now there's a sentence that gives me a grad school flashback! What on earth (if not the fuck) is the "sentient modality of being"?
If you looking for new ideas to add to your language, then look at the world:
* hibernate mode decreased computer boot time from minutes to seconds. Is your new supper-pupper language supports that? Can you freeze your program and distribute it in that frozen mode?
* web-applications provide instant access to ready to work application. Is your new supper-pupper language supports that? Is your language support instant access, like built-in access to SQL data base or XMLRPC service?
* Is Map-Reduce supported directly by your language?
* Is your language has support for regular expressions in language?
* Can you create parallel constructs with ease, like "foo | bar" in shell?
* Did your language supports built-in tree system ("boxes", "DOM", file system, etc.) and ICRUD, XPATH, CSS for these trees?
* Can your language automatically take corrective actions in case of error? Like "on SQL error FooBar: rescue database OR restore database from backup OR switch to new database".
* Can your code depend on something? Can you write "Class FooBar. Requires application mysql >= 5.0, external resource myapp-application-scheme >= 1.2. Conflicts with module FooBarBaz. Provides fooBarBaz. Obsoletes FooB."?
* Can you upgrade your application on the fly without restart and losing data or breaking anything?
* Can you compose program without editing files, just by creating and copying of files and directories? (dot-dir pattern)
And so on.