So, one interesting detail about this interview: audio was recorded. The version in print is abridged, and I would love for the ACM to release the audio -- if only for the incredibly long (and mind-blown) pause after Arthur told me that he felt that the closest analogue to software is poetry...
I believe Aaron Hsu's work on tree processing for Co-dfns [0] is a novel example of tree handling - a data parallel compiler for efficient compilation on a GPU using extensive tree-oriented "nanopass" transformations [1].
If you have cycles in your graph, you can build a tree out of a vector of indices, or as a table of parent/child node keys. The former is what John Scholes does[1], and the latter has plenty of common SQL examples.
If you have a non-cyclic tree (e.g. a 256-trie) you can nest it directly: @/ will traverse to nodes, and COW keeps updates from trashing memory too much.
However trees are rarely the best data structure: Binary search on a sorted list can beat b-trees simply because the end of the search will already be in cache, so for a routing table of IP address ranges, I use something like:
I can sort of sympathize with that sentiment. I'm not a C guy, but I've become so tired of setting up the stack for a new freelance project and/or running the log-and-debug dance, that it's often easier to just read through the code carefully, ‘running’ it in my head―the problem might jump out at me and I'll know where to dig. (Also helps with estimates before anything is done, and with filtering questionable projects.)
As they say, “It's one dollar for hitting it with the hammer, a hundred for knowing where to hit.”
