HAKMEM (1972) [pdf]

> The phenomenon of professionalization has probably made computing less of an intellectual activity, and more of a routine business. Is that what your perception is?

Not just computing. Compared to my childhood in the 60s/70s (I'm gen X, though my early childhood was not in the US), life is highly professionalized. Sport used to be played by everyone, now even school kids specialize and have fancy training. Music is less ad hoc though admittedly that had become a factory product by the 60s.

And it was easier to tinker. Nowadays people talk of "building" a PC when they are just gluing together lego blocks. That is great in that it opens up the opportunity for many more people to program, but at a cost of hardware tinkering. It used to be obvious by looking at a car motor what was going on. Now they are boring.

When video games were starting they were a gateway to programming for lots of kids. Now they are part of an ecosystem of toys that play with the kids (rather than the kids playing with them) and are generally part of an integrated marketing ecosystem ("franchise") that has characters and storylines that integrate film, video, toys...where is open ended imagination? Fandom is more consumption of someone else's thinking now than it used to be.

I know, sounds like a curmudgeon's lament.

> It doesn't help that the signal-to-noise ratio is now much lower.

I am not sure that's true. There's a survivorship bias in that we still read the work of the greats, while most of the crud is lost. I recently tossed out several shelves worth of old CS papers from the 60s-80s that I knew I'd never look at again. Dead end CPU designs, absurd (in retrospect) claims, all sorts of crud.

There is lots of fabulous thinking from the ancient Greeks, but what's survived is an infinitesimal portion of what was produced...I assume none or hardly any of what perished was worth re-reading.

He certainly loves series! I’ll see him tonight and I’m sure he will bring the topic up.

I wasn't using the debugger at all, and Gosper showed me what a great tool it was (note: Plauger disagrees). What was great about the Lisp debuggers (MACLISP, MIT lispm, and Interlisp-D were the only Lisp ones I ever used extensively, though I also found this functionality really handy in PARC Smalltalk) is that they were part of the environment so from the debugger (or another window, like your editor, in the case of the Lispm and D machines) you could write little routines to explore the problem and, update a buggy function, and the continue from wherever you wanted in the stack.

In this they were like the assembly debuggers, like DDT which was our "shell" on the ITS machines.

Compare this to the Unix paradigm where you have to explicitly decide to run under debugging (or at best dredge through a core dump): you often can't really look at what caused the problem since whatever caused it (open files, network connections and the like) are gone; your debugger runs in a different environment (process) from the program you're debugging, and doesn't have the same program affordances, i.e. no programming language. You can't imaging how many people were blown away in the 90s by the ability in gdb to simply call a function in your target program when stopped at a breakpoint. To me that has always been basic functionality.

It's rather shocking and frustrating to me that the development environments today are in many ways much more primitive than we enjoyed in the 1970s! I bang my head against the limitations of VScode and Xcode and go back to Emacs which at the end of the day is sadly just as powerful.