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.
Do these videos ever appear someplace for easy download, or will they forever be stuck on someone's walled garden?
http://www.youtube.com/watch?v=zRTx1oGG_1Y&feature=chann...
I am thirsty to watch the talk! anyone? torrents?
Deleted comment
As far as pseudo-philosophical, I would direct you immediately to SICP. From the very beginning it points out that the computer can (and SHOULD) represent a beautiful philosophical, even metaphysical, exercise- the understanding of "how things are done".
Mr. Hickey isn't pulling things out of the air here, there's a long tradition of scientists (and hackers) attempting to communicate to their peers - "Hey, start treating your practice with some goddamn respect. PLs are not religions. Like music, really, truly, like any art, like any civilization worth continuing - let's keep striving for something better". Perhaps I'm being overly poetic. But if there's no poetry in your work, then what the f&%k is the point of doing it?
EDIT: original poster deleted his post. As much as I like Hacker News, I find the fact that people can "game" the karma system by deleting comments clearly destined for down modding lamentable. Perhaps the algorithm for karma should be tweaked so that if you have karma, bravely accepting a brutal down modding for a flawed viewpoint should count for something. That is, if you can't accept being wrong, you probably aren't a hacker worth her/his weight in salt- acceptance of the fact there's always something new to learn should be rewarded after the punishment ;)
I often use HN in this way. Something bothers or puzzles me, I don't know what it is, so I write about it until it's out of my system. On rare occasions, I then delete it.
Google indexed it, so perhaps my "flawed viewpoint" can be brought back from cache someday for that "brutal down modding".
http://www.google.com/search?hl=en&q=gruseom+hickey+pret...
Obviously I wouldn't have deleted my comment if I had seen yours.
The main problem with Hickey's presentation is that it is unclear how well he actually understands the philosophy he cites and especially how thoroughly he investigated the alternatives to that philosophy. He presents a single view and doesn't debate it, while it warrants a book of its own.
Something you can see clearly in students of philosophy, psychology and those 'softer' subjects, where multiple truths seem to exist, is that they tend to change opinions and general outlook along with what they learned last. The last thing they read made an impression and it is the first thing on their mind. This lasts until they reach the point of enlightenment, where they notice this fact and start to integrate their knowledge. But not everybody reaches that point, by having studied enough philosophy.
Now you can be a world class physicist or computer scientist: that doesn't make you a good philosopher. In fact, great scientists have been known to espouse some pretty strange philosophies, whose implications they obviously didn't fully grasp. In light of that, Hickey's talk brings to mind the crackpots waving Kuhn's 'paradigm shift' around, without actually understanding it.
It is also unclear how relevant the philosophical grounding is for the actual contents of his talk. If he left all the Whitehead quotes out, wouldn't it be a better presentation? If so, then he's guilty of basically an argument-by-authority: trying to prove his notions about time in programming are good, because he can call upon someone of the stature of Whitehead. I'm not convinced that isn't the case here, although I'm sure it was not the intent.
I think all this 'philo-babble' detracts from the actual point he is trying to make. You're bound to get into endless debates about Whiteheads notion of time and such, while losing sight of the fact that Hickey makes a few practical points that most people probably agree on. A thorough analysis of time in object oriented programming does not need to be a full fledged philosophy and it definitely seems like hubris to present it as such. Hickey should stick to what he knows best and perhaps give some pointers as to philosophies supporting him, instead of making that his main point.
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.
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.
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).
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.