Also it'd be nice to have something that is more spatial. A famous memory technique is remembering where things are in space[1], but I've never seen a code browser that works spatially. (I have no idea how to actually do this.)
Self's environment was a panning desktop where you would inspect an object's slots and as you kept opening things, they would exist in some space nearby. You could, in theory, keep these things open and have a much more spatial feeling about the system.
I don't remember there being any way to collapse and re-expand this context so that it could persist yet be out of the way when you didn't want to look at it.
The paper printouts on the table are a kind of simple spatial browser. Thanks to this, we have UNIX (at least it explains how they were able to create anything at all with just a teletype back then).
To add to this, a quote from an article about the editor ed:
It’s important to realize that in ed you were usually editing a file you had already printed beforehand. If you only wanted to fix a few small things in a multi-page listing, you simply entered the corrections in ed on the relevant lines, added something here and there, and at the same time you would just write the simple minor fixes directly into the printout by hand-without having to tediously retype everything.
You had the files on paper, which is a very pleasant and ergonomic medium for reading. You can literally surround yourself with it, cover your desk, and easily move your eyes between dozens of functions. If you learn to keep order and stay oriented in that mountain of paper, you can be very effective.
Moreover, from an ergonomic point of view you wouldn’t be doing badly at all. Printed paper in natural light is definitely easier on the eyes than low-refresh-rate screens in the years that followed. Paper lets you quickly add notes, sketch a little graph, basically work in a very natural way - one people were used to back then from the moment they first held a crayon.
Most of the time a programmer isn’t writing code but reading it. In that respect, people back then may actually have had it better than we do today. When it did come to writing, the only truly more complicated part was essentially making corrections. The history of everything you’d done was right there on paper. I don’t want to idealize the way they worked back then, but all of this explains how they were able to work effectively even with such primitive tools.
This is why a lot of people like Vim.When you can target precisely where you want to edit, it becomes effortless instead of being a chore. With windows (panes), you can easily arrange buffer (contents of files mostly) spatially like you would on a desk. Even with vi (which lacks windows), you can make do with marks (bookmarks on lines)
Same with Emacs. You bring a whole toolset for each buffer (major and minor modes). And then you got to editing. Like imenu for automatically finding interesting places like functions, structure,… declarations, outline mode that use regex to provide an outline tree that you can then edit, view-mode that adapt the keybinds for scrolling,…
> You had the files on paper, which is a very pleasant and ergonomic medium for reading. You can literally surround yourself with it, cover your desk, and easily move your eyes between dozens of functions. If you learn to keep order and stay oriented in that mountain of paper, you can be very effective.
That only works if your printouts aren’t too long, and contain the majority of the logic in your programs.
Today, the latter rarely is the case. Maybe, we need a way to print code with t selected documentation of called functions added?
That ‘selected’ would be a tricky problem, though. What I need to understand the code may not be what you need, or what I need a month from now.
> That only works if your printouts aren’t too long
It depends on what you mean by "too long".
A few folks in my office have binders with dog-eared code printouts for some of the more stable internal libraries in our codebase. A 3" thick 3-ring binder can hold a little over a million lines of code. I wouldn't use it for Firefox (~21M LOC) or Linux (~40M LOC) because you'd need to dedicate several shelves and print it regularly to be useful. And there's no grep. But for things like a stable, versioned library it can be very useful.
I use the pdf view of Literate Programming projects uploaded to my Kindle Scribe in a similar fashion --- at need I've augmented this by switching to my MacBook for coding and using my Samsung Galaxy Book 3 Pro 360 as a second pdf view (which never fails to cause comment from my spouse).
Don't remember that, but I do remember the one for Gupta SQLWindows. I had a discussion about with its designer on reddit some years back, and he admitted it was a horrible mistake. Programs are text, folding is not a great way to represent text.
Close enough. I had a copy of MacOS Apple Smalltalk from the 1985 training course I took, and had started a job using Objectworks. Squeak 1.0 is quite close to ST-80.
Smalltalk offers several excellent features for LLM agents:
- Very small methods that function as standalone compilation units, enabling extremely fast compilation.
- Built-in, fast, and effective code browsing capabilities (e.g., listing senders, implementors, and instance variable users...). This makes it easy for the agent to extract only the required context from the system.
- Powerful runtime reflectivity and easily accessible debugging capabilities.
- A simple grammar with a more natural, language-like feel compared to Lisp.
Edit: I suppose the next step would be to teach an LLM about "moldable exceptions", https://arxiv.org/pdf/2409.00465 (PDF), have it create its own debuggers.
No, they used a tool (SystemTracer) running inside the original Smalltalk that enumerated all the objects in the running image and serialized them in a new image format into a new image file. Every time the image file format changed, it was transformed like this. Smalltalk is very close to a biological system.
reply