Re:Bryan Cantrill interviews Arthur Whitney (2009)
by bcantrill on Monday December 02, 2019 @04:27AM
(#21681024)
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...
Re:Bryan Cantrill interviews Arthur Whitney (2009)
by refset on Monday December 02, 2019 @01:03AM
(#21680181)
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].
Re:Bryan Cantrill interviews Arthur Whitney (2009)
by geocar on Monday December 02, 2019 @03:15AM
(#21680743)
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:
Re:Bryan Cantrill interviews Arthur Whitney (2009)
by aasasd on Monday December 02, 2019 @01:33AM
(#21680306)
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.”
Stronger contenders for the "software analogue" remain film, theater, music, and architecture.
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!
Does anybody know how array languages handle pointers and trees?
[0] https://github.com/Co-dfns/Co-dfns
[1] https://dyalog.tv/Dyalog18/?v=hzPd3umu78g
[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:
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...
As they say, “It's one dollar for hitting it with the hammer, a hundred for knowing where to hit.”
Usage of APL-related languages in finance, KDB in particular, is always exaggerated. Where it is used, it is amazingly slow.
When you say KDB is "amazingly slow" in real life, you're either talking about your own attempt at KDB, or make-believe KDB.
Expensive, terse, and 'amazingly slow' software would not be exist, let alone be competitive.