Live data from Hacker News

Purely Functional Data Structures (1996) [pdf]

cs.cmu.edu

91–98 of 98 posts

Re: Purely Functional Data Structures (1996) [pdf]

#91

I have a personal pet peeve about the misuse of terminology when dealing with such names, for which the only solution is to go read the original reference to figure out what they meant by it. E.g., in this case, to describe a data structure as "purely functional" makes zero sense to me intuitively at first. You need to go read the thesis and realise they're referring to data structures implemented as algebraic data t…

A data structure is a type, so "data-structure type" is a pleonasm. Please don't misuse terminology :)

Nominative determinism aside, was that second part really necessary?

Re: Purely Functional Data Structures (1996) [pdf]

#93

Why would we want to use purely functional data structures? When do the pros of functional data structures outweigh the additional complexity? Are there scenarios when a project would want to pivot from a regular data structure to a purely functional one?

There is no additional programming complexity in using Scala's Map vs Java's HashMap. They are both maps with keys and values. The Java one you update in-place

    var m = new HashMap()
    m.add(k, v)
the Scala one you "update" by creating new maps,

    var m = Map.empty[K, V]
    m += (key, value)
In practice it's mostly the same except you can share the immutable one around without being scared someone will mutate it, but it takes more memory per instance than the mutable version and creates more GC churn, which may or may not be an issue.

Re: Purely Functional Data Structures (1996) [pdf]

#94
post #39

It's weird that there are so many claims in here that the data structures and algorithms are perfectly performant yet there isn't even one look at generated assembly or any acknowledgement of the underlying system that is supposed to run the code. Proving things are Big O performant is neat, but at some point the code has to hit hardware.

How helpful would it be to see 30 year old generated assembly and benchmarks for an i486 with a tiny cache, no prefetching, and relatively tiny memory vs instruction latency compared to today’s CPUs?

Re: Purely Functional Data Structures (1996) [pdf]

#95
For me, the most mind-blowing part of Okasaki's book was the chapter on "numerical representations". Never looked at it like that before I read that chapter. While the other chapters certainly introduced material that was new to me at the time, this one took some things I knew and added a whole new dimension to them.

Re: Purely Functional Data Structures (1996) [pdf]

#98

Definitely read that headline as "Purely Fictional Data Structures". My disappointment is immense.

Purely Fictional Data Structures include: To Queue a Mockingbird The Call-stack of the Wild Tesselation of the d'Urbervilles One Flew Over the Cuckoo Hash The Data of the Woosters Brideshead Re-visitor The Catcher in the Trie Les Miser-tables The Nat-elim of Monte Cristo

> The Catcher in the Trie

https://en.wikipedia.org/wiki/Trie#History,_etymology,_and_p...

and the counterpart, Purely Fictional Languages:

   The Catcher in the *Try*
Post reply on HN