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.”
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...
...which explains his language design choices.
Stronger contenders for the "software analogue" remain film, theater, music, and architecture.
The pdf is easier to read and contains photos: https://dl.acm.org/ft_gateway.cfm?id=1531242&ftid=316753&dwn...
A thread from 2014: https://news.ycombinator.com/item?id=8476120
A couple from 2009: https://news.ycombinator.com/item?id=650149
https://news.ycombinator.com/item?id=561443
I remember seeing that at the time but didn't notice who was the interviewer!
https://news.ycombinator.com/item?id=561443#562884
Does anybody know how array languages handle pointers and trees?
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].
[0] https://github.com/Co-dfns/Co-dfns
[1] https://dyalog.tv/Dyalog18/?v=hzPd3umu78g
Holy crap, that video is mind-blowing. Thank you! I was vaguely aware of Co-dfns before, but now it's squarely on my radar.
John Earnest also details how trees are handled in K (an array based language invented by Arthur Whitney). https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Trees.m...
I also wrote a paper about recursive combinators which touches on these ideas a bit: http://archive.vector.org.uk/art10501740
And I translated some of Aaron Hsu's APL ideas into k5. With a little massaging they work just as well: https://github.com/JohnEarnest/ok/blob/gh-pages/examples/key...
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.
[1]: https://youtu.be/DsZdfnlh_d0
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:
"In C I never learned to use the debugger so I used to never make mistakes,"
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.”