Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

wiki.jvmlangsummit.com

Post reply on HN
Print view View original

41–46 of 46 posts

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

#41

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

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

#42

Post by pmjordan »

fauigerzigerk wrote: post #29
jrockway wrote: post #28

Earlier quoted context omitted.

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 tha…

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.

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.

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

#44

Post by jasonwatkinspdx »

joechung wrote: post #13

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

Except that it's not. Time is relative to each observer.

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.

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

#45

Post by jasonwatkinspdx »

jbert wrote: post #23
vdm wrote: post #18

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.

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.

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

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

#46

Post by jbert »

jasonwatkinspdx wrote: post #45
jbert wrote: post #23

Earlier quoted context omitted.

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.

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…

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.
Post reply on HN