Kartik Agaram

Re a) and b), I replied below your comment about your Vim plugin.

> That is very close to my heart, though my theory is that reading code only becomes easier when the very representation of software projects undergoes a sea change: http://akkartik.name/about. I'd love to hear your thoughts!

I read the page you linked (though I didn't browse the other parts it links to - I'll have to leave that for later). Quite a lot of interesting ideas you have there. I've added the Mu project to check out later.

It seems we have similar general goals in mind, but different ideas of making it happen. You seem to be focusing on how to change the programming practice to facilitate understanding of large codebases. I am thinking more along the lines of tools that would help one explore and get the picture of existing codebases in current languages.

So far, I've briefly explored areas like:

- software for generating diagrams of the code

- software for generating runtime diagrams

- time travelling debuggers

- printing out code on paper (per edw519's advice) and annotating it

- annotating code in PDF readers and word processors

I think what resonates with me most in the text you linked is "Deemphasize abstractions in favor of traces". I actually went into the first three bullet points of mine because I had to refactor some code that I couldn't figure out the exact flow of. What I wanted was exactly the "trace" of execution I could inspect. Unfortunately, the time travelling debuggers I…

I find that sort of causality hard to draw, though. My choices are either to make it a hard correlation with a minor accomplishment (I tried programming in lisp, and came up with these few programs I found interesting: http://akkartik.name/lisp.html) or to make it a more fuzzy correlation with something bigger ("Everything I have done and everything I will do, would have been less good if you hadn't written what you did." http://akkartik.name/about. Or "When I write I try to imagine how you would react to each sentence." http://akkartik.name/?f=Me)

Neither seems satisfactory, especially since other people influenced these accomplishments as well. Let me attempt a middle ground -- using examples.

Eliezer, I still maintain an interest in blackboard systems to this day. For example, here's a program I wrote a couple of weeks ago: http://github.com/akkartik/brooks-ruby-warrior/tree/master. Thanks to reading Hofstadter and you and Brooks, I knew when I approached this problem that finding the heuristics to solve a particular AI problem is relatively easy. What is hard is finding an open-ended architecture to integrate lots of heuristics together. I ended up with a faint likeness of an idea others have explored in far harder domains.

PG, as I hinted above, inspired me to come to silicon valley 2 years ago. I do what I love. That was not something I could say a few years ago. Agh, this is more squirm-inducing. Here's a program that came out of conversations when I spoke to PG at…

Thinking about the state of the software world in the last several years always makes me think of Vernor Vinge's notion of a "Mature Programming Environment" from _A Deepness in the Sky_ (1999),

"The word for all this is ‘mature programming environment.’ Basically, when hardware performance has been pushed to its final limit, and programmers have had several centuries to code, you reach a point where there is far more significant code than can be rationalized. The best you can do is understand the overall layering, and know how to search for the oddball tool that may come in handy"
(Longer excerpt with an earlier bit about rewriting things always eventually just moving around the set of bugs, inconsistencies, and limitations rather than improving them here: http://akkartik.name/post/deepness )

And and Danny Hillis' idea about the Entanglement ( excerpt from a 2012 interview with SciAm) -

"But what's happened though, and I don't think most people realize this has happened yet, is that our technology has actually now gotten so complicated that we actually no longer do understand it in that same way. So the way that we understand our technology, the most complicated pieces of technology like the Internet for example, are almost like we understand nature; which is that we understand pieces of them, we understand some basic principles according to which they operate, in which they operate. We don't really understand in detail their emerging behaviors. And so it's perfectly…

Thanks for the thoughtful response, but I don't think I can say I agree with your conclusion. One example I cited was Knuth's Adventure. Even knowing C well enough, I'm not struck by how Knuth's presentation makes it easier to understand in the way he desires.

Knuth very much seems to advocate for programs that can be read cover-to-cover (e.g. while, say, sitting in your favorite chair). I think the failure in his literate programs come down to the blindspots he's developed working on his own programs, from having focused so much on the trees in their respective forests. You can see something similar at play in Graham Nelson's struggles to make Inform 7 appropriately "literate", which funnily enough exhibits the opposite of expectations of familiarity with the original implementation language. <http://inform7.com/talks/2020/06/07/narrascope-ii.html> Have a look at this slide in particular: <http://inform7.com/assets/images/NS2/slide036.jpg> Here's an excerpt:

"Once The Historian is done, the instructions are passed to Instruction::read, which parses them more fully (see below) and returns an intest_instructions object".

It goes on in that style. This is reminiscent of every bad attempt I saw during Java's heyday to ensure that a given codebase was 100% commented. People just end up writing "documentation" that consists of low-level repetition of what the code is doing, but without explaining why it's doing those things, and that why is key. It's the only real…

Once there were three tribes. The Optimists, whose patron saints were Drake and Sagan, believed in a universe crawling with gentle intelligence. Surely, said the Optimists, space travel implies enlightenment, for it requires the control of great destructive energies. Any race that can't rise above its own brutal instincts will wipe itself out long before it learns to bridge the interstellar gulf.

Across from the Optimists sat the Pessimists, who genuflected before graven images of St. Fermi and a host of lesser lightweights. The Pessimists envisioned a lonely universe full of dead rocks and prokaryotic slime. The odds are just too low, they insisted. Too many rogues, too much radiation, too much eccentricity in too many orbits. If the galaxy were alive with intelligence, wouldn't it be here by now?

Equidistant from the two tribes sat the Historians. They didn't have many thoughts on the probable prevalence of intelligent, spacefaring extraterrestrials. But if there are any, they said, they're not just going to be smart. They're going to be mean. The reason wasn't merely Human history, the ongoing succession of greater technologies griding lesser ones beneath their boots. No, the real issue was what tools are for. To the Historians, tools existed for only one reason: to force the universe into unnatural shapes. They treated nature as an enemy, they were by definition a rebellion against the way things were.

Technology is a stunted thing in benign environments, it never…

One of the things I find myself needing to push both junior _and_ senior developers to do is "if you are thinking about code being anywhere adjacent to 'subtle' or 'weird,' or think that something might become a design pattern for future code, or something that was copied from other code but differs subtly, or you consulted StackOverflow... write the comment that's in your head/leave a breadcrumb as an actual comment in the codebase." And, frankly, this sometimes means commenting-out rather than deleting code, if the historical code was necessary to understand the context for why the improvement is warranted.

I wholeheartedly agree with the OP that "churn" can result not only from staff members leaving, but also from them shifting focus to other projects or even just growing in skillsets over time. Which is why it's vital to document the mindset you had as you were coding.

One of my favorite books, Vernor Vinge's Hugo-winning _A Deepness in the Sky_, uses the term "programmer-archaeologist" - https://akkartik.name/post/deepness is a great (spoiler-free) quote on the notion. Writing for your future archaeologists - who may very well happen to be your future self! - is a great mental model to have.

(And read Deepness - despite its branding as book 2 in a series, it's arguably best to read it standalone first! It's simultaneously an action-packed popcorn novel and a mind-bending set of discussions on linguistics and cultural relativism as they pertain to mechanisms for…