
Rich Hickey's Keynote: A deconstruction of object-oriented time [pdf] - swannodette
http://wiki.jvmlangsummit.com/images/a/ab/HickeyJVMSummit2009.pdf
======
plinkplonk
Not to take anything away from Rich's wonderful presentation, but Chapter 3 of
SICP covers a lot of this with great clarity and in depth, specifically the OO
and functional nature of time and associated subtleties (SICP does not deal
with persistent data structures etc).

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.

~~~
IsaacL
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
"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
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).

------
zaph0d
I think Rich Hickey is all set to become one of the most influential figures
of Computer Science. The process has already started :)

------
jayded
Brilliant use of ANW's "Process and Reality" (considered by many as a meta-
physical text) providing philosophical mappings to Clojure's approach of
state, time etc.

~~~
vdm
<http://en.wikipedia.org/wiki/Process_and_Reality>

------
icey
Does anyone know if they recorded this as well? I've heard the Q&A session was
also quite good.

~~~
scottdw
From the conference page
(<http://openjdk.java.net/projects/mlvm/jvmlangsummit/>) it seems like the
talks were recorded by infoq who recorded last year's talks. If they follow
the same method as last year these talks will slowly trickle onto the infoq
website over the next few months. See <http://www.infoq.com/JVMLanguageSummit>
for last year's talks.

~~~
jamesbritt
" ... these talks will slowly trickle onto the infoq website"

Do these videos ever appear someplace for easy download, or will they forever
be stuck on someone's walled garden?

------
vdm
While I haven't had the opportunity to watch the talk, those slides are
fantastic.

I think the key to Rich's ideas is to realise them on non-volatile storage.
This could revolutionise filesystems and databases.

~~~
jbert
See the 'tux3' linux "phased tree" filesystem which was implemented (and then
quashed by NetApp) some time ago (2001):

<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.

~~~
jasonwatkinspdx
They're all generally similar yes. They're also similar to the naive
approaches for tree like persistent data structures.

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...](http://ocw.mit.edu/NR/rdonlyres/Electrical-Engineering-and-Computer-
Science/6-854JFall-2005/5092B349-E943-409B-BF53-703BAEF3D8E3/0/persistent.pdf)

~~~
jbert
I'm currently looking at something which falls under the 'fat node' category
(with a few wrinkles/complications) at the moment, so this is of great
interest, thanks.

------
joechung
Time is a global variable (and hence an implicit parameter) to any function
that manages state.

~~~
pmjordan
Except the point is that in most languages, it's more than an implicit
parameter (like 'this') - it mutates away while the function is running.

~~~
joechung
I don't think that our points are mutually exclusive (why "except").

~~~
pmjordan
As I understand it, the point of the presentation was highlighting the
incidental complexity arising from the implicit instability of mutable state.
If an immutable snapshot of the whole program state was an implicit parameter
to functions, that wouldn't be so bad. It's the fact that anything can pull
out the rug from under your feet at any time that creates the need for
paranoid constructs in most classical concurrent programming.

------
baxter
I found this fascinating. Does anyone have any knowledge of any other
programming languages/environments that focus on time in a way comparable to
that suggested in the presentation?

~~~
zaph0d
Clojure, of course :)

~~~
baxter
Wow, it seems I have underestimated Clojure! Thanks for enlightening me :)

------
xtho
OMG programming language design is going postmodern.

------
fauigerzigerk
I just wish all the good things were a little bit more memory efficient. Maybe
we're getting there eventually...

~~~
vdm
That's the idea of Clojure's persistent data structures. Values share the
parts of themselves which haven't changed, so they are not copied.

"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.

~~~
fauigerzigerk
I know. I read Stu Halloway's book and I read some articles about how the
persistent data structures work. But I also did some tests myself. Performance
isn't great but that's not so much the issue for me. Memory use is a problem
though. I can't have a list of a million integer pairs take 160MB of RAM.

~~~
jrockway
_I can't have a list of a million integer pairs take 160MB of RAM._

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.

~~~
fauigerzigerk
Well, I have played around with this for some time and I found that boxing is
just one reason. Another one is that clojure structs seem to always act as
generic maps even if only predefined elements are actually stored. This seems
like an easy one to optimize.

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.

~~~
pmjordan
Have you poked around the (Java) source for clojure's data structures? It's
very readable, and if you have any ideas for improving their memory footprint,
I think a lot of people (including myself) would appreciate hearing about
them.

------
lucifer
His observations on the conflation of identity/state/value in OO are very
insightful (and I agree with them with the reservation that they apply nearly
equally to simple structs of non-OO languages, as well).

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.

~~~
gruseom
_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"?

~~~
khafra
I think the light-bringer's saying that, if we extend the analogy between
computer language constructs and real-world stuff, we should remember that
sometimes people do stuff, and sometimes we don't do stuff.

------
vlisivka
I saw no new terms to add to my dictionary in that presentation.

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.

