HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
Persistent Data Structures and Managed References

Rich Hickey · InfoQ · 38 HN points · 14 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention Rich Hickey's video "Persistent Data Structures and Managed References".
Watch on InfoQ [↗]
InfoQ Summary
Rich Hickey talks on identity, state and values. He explains how to represent composite objects as values and how to deal with change and state, as it is implemented in Clojure.
HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Jul 24, 2018 · 2 points, 0 comments · submitted by tosh
Immutable data does not necessitate copying the entire structure when it is shared or changed. I encourage you to take a look at persistent data structures[0]. Okasaki's "Purely Functional Data Structures"[1] is a good resource if you'd like to look at this in more depth. Rich Hickey's talk about the implementation of persistent data structures in Clojure is also a nice introduction[2].




Only skim-read so far but that's interesting stuff. I had no idea FP data structures were implemented like this: I consider myself duly educated, thanks!
Aug 08, 2017 · 2 points, 0 comments · submitted by tosh
Aren't these the same ideas that Rich Hickey has been talking about since his seminal 2009 talk about values, identity and state?

Joe Armstrong's proposal seems to boil down to this:

- Identities as UUIDs

- State as the payload of UUID URIs

- Values as SHA-1 URIs

Fast persistent data structures, combined with the idea of "reference types" that encapsulate mutation points when you really need them.

So yes in Om there is a single mutable point which then points to the current immutable tree to be used for rendering.

This is very fast. Clojurescript performance is not a bottleneck, most of the time is spent within React.

It makes a lot of sense in the context of programming when you look at the big picture. I think Rich Hickey articulates it best:
Well, I'm used to developing multi-MLOC projects in large teams; they don't switch a language so easily...

As for Clojure, I mean this: (basically: immutability, controlled state transitions via agents/atomic/STM)

Summary of the links shared here:

And here are them with titles + thumbnails:

how awesome are you? thanks
Thank you so much for this!
This is cool :) Btw. the first link was somehow (re)moved. The link is now:
I agree – anything from Rich Hickey. Especially "Persistent Data Structures"[1] and "Are We There Yet?"[2].

Though related to Clojure, they make you think about development in different ways.



'Simple Made Easy'[1] is one of my favorite Hickey talks.


Mar 20, 2013 · 1 points, 0 comments · submitted by llambda
Feb 22, 2013 · chongli on The Racket Way
One of Clojure's main selling points is that its vectors, maps and sets are persistent data structures with near-constant time operations (log32N).

May 04, 2012 · 2 points, 0 comments · submitted by espeed
Feb 03, 2012 · Mikera on Modern Language Wishlist
This is basically a desciption of Clojure, in particular:

- Explicit model of time ( - Homoiconic / Extensible syntax (shared by most Lisps) - Math-oriented numeric types (Clojure maths is arbitrary precision by default, and it has nice things like rational types) - Immutable (Clojure data structures are all immutable) - Garbage collection (inherited from the JVM) - String manipulation (Regular expressions are a built-in type)

Most of the other features actually seem more like libraries than language features, but given that Clojure can access the entire Java ecosystem I think you can do all of it from Clojure with relatively little pain.

Clojure is awesome, but does struggle on the "Good error messages" requirement, which is a problem when you're starting out.
I find it interesting that two of the most exciting languages that exist right now are built on top of the VM for one of the worst ones.
The strength of Java for many years has been the platform, and indeed the surrounding ecosystem, not the language. In that sense it's no surprise that there is a lot of effort going in to providing better languages on that platform.
The reason I'm not using Clojure is that it's based on the Java platform. I keep hearing that JVM is nice because there are good libraries, but I haven't figured out what the good libraries are. Sure, there are some nice platform independent abstractions for common operating system interfaces like file and network I/O, but it still lacks lots of stuff.

The problem with Java libraries w.r.t. modern high level languages is that Java libraries are built on Java abstractions. It doesn't matter how high level the new language is, but when interfacing with Java libs, you have to stick to single dispatch object oriented programming. So in the end, there are many cases where you use the Java library through some wrapper layer written in Clojure or your Clojure code ends up looking a lot like Java.

Once you add a wrapper layer shim between your preferred language and the platform, it doesn't matter what's underneath. That's why I like to stick to languages that are built on native code and libraries, C and Posix and Unix API's with some Linux and/or BSD additions. Of course, if you want to run on Windows, all the code has to be duplicated since Win API's are different.

Jan 17, 2012 · 5 points, 0 comments · submitted by bitops
I don't know about 15-30 minutes, but for anyone interested in learning Clojure, I have collected these links that I found interesting:

Visit them roughly in order.

As for books, there are a few good ones, but I acutally recommend the documentation on more than any book. It's clear and compact.

The talk of Rich Hickey (Clojure) on Persistent Data Structures and Managed References gives a very interesting view on programming in general.

Dec 20, 2010 · 7 points, 0 comments · submitted by closure
Dec 02, 2010 · ivank on Hammock-driven Development
Last year Rich gave a great talk about Clojure's approach to persistent data structures (but really identity and state):
Everyone should watch that talk. It's the most compelling I've yet seen for the relevance of applicative programming. I was not convinced, but I was closer than I've ever been to being convinced.
Nov 27, 2010 · 5 points, 0 comments · submitted by ivank
> Java is pass-by-reference. Pass in object foo, call smash_with_hammer on foo in the called function, and the caller finds that his foo was smashed by a hammer when control returns to him

In agreement here, the state of the object changes according to a message passed to the object. In this case, the value we passed is a pointer to the object. We can't, however, change what object the pointer points to in Java, which is why I call it "pass by value". E.g., I can't do equiv of this Perl code.

sub bar { my $foo = Foo->new(a => "a"); foo(\$foo); }

sub foo { my $arg = shift; $$arg = Foo->new(a => "b"); }

On the other hand, in Perl even though I am passing a reference by value, I can still mutate the state of the object:

sub bar { my $foo = Foo->new(a => "a"); bar($foo); }

sub foo { my $foo = shift; $foo->set_a("b"); }

(Please excuse my Perl, I haven't written OO Perl in over a year now).

In any case, I think this is a pedantic point. Both of us agree that other than in few cases (algorithms/data structures that are difficult to express in a functional way), objects shouldn't be smashed by hammers: whether internal or external.

I also don't understand why Java's standard library authors didn't do what Scala did and provide both mutable and immutable versions of collections. Java 5+ added great lock free data, concurrent data structures, but much like they have a ConcurrentMap, they could have added a "ImmutableMap"/"ImmutableList" interfaces (especially given the fact that some data structures e.g., CopyOnWriteArrayList behave like this internally). I really like Scala's "functional objects": objects that upon receiving a messages, create new objects. In Java, an object may be final, but it will still (as you put it) "be smashed by a hammer" as long as the hammer smashing was invoked by a message. Same thing happens in C++ with const methods, in objects passed as const& references which contain objects that mutate their state upon a message being passed. Rich Hickey discusses this much better than I do in his famous talk: (although I may not agree with all of his conclusions)

> seems like everything useful takes a StringBuffer instead of a String

That's a textbook example of premature optimization :-) The compiler will convert string concatenation to StringBuilder. See: It does makes sense to use a StringBuilder when you are doing concatenation inside a loop (and don't want the overhead of allocating a new StringBuilder inside), but otherwise there's no advantage to it.

(Oddly enough, in this example the default optimization level did not unroll the loop itself. OCaml, on the other hand, despite having a much more compiler-friendly type system than Java, doesn't perform the equivalent optimization on string concatenations with the '^' operator. I am pretty sure g++ will do both, despite C++ being lower-level and having weaker typing than OCaml and Java).

For another example of this kind of premature optimization, see people using inline in C++ code when the gcc/clang will have a much better idea than the developer on when to inline a function call and when not to :-)

Here's a very quick dump of some things waiting to be read/digested/whatever in my Firefox tabs and other notes:

Learning Clojure:

The best concise intro I've come across:

You can't go wrong starting with the introductory stuff on the site:

This looks like a good longer intro, but I haven't more than glanced at it:

A longer Wikibook:

Monad tutorial (site currently broken):

And there's one Clojure v 1.0 book out, only $20 for the ebook version:

(Note that a whole lot of learning material assumes you're coming from a Java background ... which I'm not (in fact, I learned MACLISP before C and never had a chance to go beyond C++ to C# or Java).)

Setting up your EMACS Clojure development environment (VIM and various IDEs are also supported): and

And there are a bunch of videos, Rich Hickey does them well; note that most of the quotes below are from someone else that I then cut and pasted into my TODO file for future reference:

Clojure for Lisp Programmers Part 1 of 2:

Part 1 of a presentation by Rich Hickey at the Boston Lisp meeting. A fairly extensive introduction to Clojure, with a presumption of prior knowledge of Lisp. Transcript available at:

Clojure for Java Programmers - 1 of 2:

Part 1 of a presentation by Rich Hickey to the NYC Java Study Group. A gentle introduction to Clojure, part 1 focuses on reader syntax, core data structures, code-as-data, evaluation, special operators, functions, macros and sequences. No prior exposure to Lisp is presumed.

Persistent Data Structures and Managed References: (very good).

Clojure Concurrency:

A presentation by Rich Hickey to the Western Mass. Developers Group on Clojure and concurrency. Brief overview of Clojure, discussion of concurrency issues, locking, and immutabiity. In-depth look at Clojure's refs, transactions and agents. Demonstration and review of code for a multithreaded ant colony simulation.

Clojure Sequences:

An informal introductory talk/screencast covering Clojure's sequences by Rich Hickey, the author of Clojure. Covers the motivation behind sequences, their relationship to cons, iterators/enumerators and collections, the sequence library, and laziness.

Clojure Data Structures - Part 1:

Part 1 of an informal introductory talk/screencast covering Clojure's data structures by Rich Hickey, the author of Clojure. Covers numbers, symbols, keywords, lists, vectors and maps.

At the 2008 JVM Language Summit he gave a talk, at the 2009 a keynote, "Are We There Yet?":

Check Infoq for other items as well.

The Full Disclojure videos have helped [ the author if this note ] understand some of the features new to clojure in 1.1:

Holy crap thank you.
Thanks, this should help in figuring out if Clojure is the way forward for me!
I've bookmarked your comment, thanks a ton.
Oct 02, 2009 · 14 points, 0 comments · submitted by crc
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.