It's because when you truly add a new capability to your toolset, like 100ms installs, or universal cross platform loading, this has ripple effects through every problem you solved before. Some things simply don't work in the new codebase, other things have regressed. Then you go back and one-by-one you fix everything to work in this new reality. This happens every time our aggregate software architecture gets a big new ability.
Of course if you're touching the same code over and over again, that's probably a sign you're not solving the problem well. Solving problems with a finality such that they don't have to be reopened again and again is the aim of good software engineering. That is true.
But in order to get there, you need to periodically add a major new capability—and thus a major new assumption—to your architecture. If you're not making these kinds of sweeping changes every now and then it's almost certain that you're not actually doing deep refactors that resolve longstanding challenges in lower energy ways.
Resistance to these kinds of sweeping changes amongst professional developers and their ambassadors at major platform companies is the reason why Windows, iOS, Oracle, and the like have stable interfaces and smaller audiences. On the web you don't need permission to write a whole new JavaScript framework, so people can take those first big steps, even though they are quite painful for the developer.
> ... that immediately after all the triplets have been
> evaluated the state of the memory as it stands is read out
> onto tape 8 as the new "base" image for the memory. ...
OK, if you promise to stay off my lawn, I'll explain the history behind undump. Back in the 70's, the big CS departments typically had DEC 36-bit mainframes (PDP-10, PDP-20) running the Tops10/Tops20/Tenex/Waits/Sail family of operating systems. These are what Knuth used to do all of TeX, McCarthy LISP, and Stallman and Steele EMACS. Not Unix; and Linus hadn't touched a computer yet.
Executable program files were not much more than memory images; to run a program, the OS pretty much just mapped the executable image into your address space and jumped to the start. But when the program stopped, your entire state was still there, sitting in your address space. If the program had stopped due to a crash of some sort, or if it had been in an infinite loop and you had hit control-C to interrupt it, the program was still sitting there, even though you were staring at the command prompt. And the OS had a basic debugging capability built-in, so you could simply start snooping around at the memory state of the halted program. You could continue a suspended program, or you could even restart it without the OS having to reload it from disk. It was kind of a work-space model.
Translating into Linux-ish, it's as if you always used control-Z instead of control-C, and the exit() system call also behaved like control-Z; and gdb was a builtin function of the shell that you could invoke no matter how your program happened to have been paused, and it worked on the current paused process rather than a core file (which didn't exist).
The OS also had a built-in command to allow you to SAVE the current memory image back into a new executable file. There wasn't much to this command, either, since executables weren't much more than a memory image to begin with. So, the equivalent of dump/undump was really just built into the OS, and wasn't considered any big deal or super-special feature. Of course, all language runtimes knew all about this, so they were always written to understand as a matter of course that they had to be able to deal with it properly. It pretty much came naturally if you were used to that environment, and wasn't a burden.
Thus, when TeX (and I presume the various Lisp and Emacs and etc. that were birthed on these machines) were designed, it was completely expected that they'd work this way. Cycles were expensive, as was IO; so in TeX's case, for example, it took many seconds to read in the basic macro package and standard set of font metric files and to preprocess the hyphenation patterns into their data structure. By doing a SAVE of the resulting preloaded executable once during installation, everyone then saved these many seconds each time they ran TeX. But when TeX was ported over to Unix (and then Linux), it came as a bit of a surprise that the model was different, and that there was no convenient, predefined way to get this functionality, and that the runtimes weren't typically set up to make it easy to do. The undump stuff was created to deal with it, but it was never pretty, since it was bolted on. And many of use from those days wonder why there's still no good solution in the *nix world when there are still plenty of programs that take too damn long to start up.
Sure you do (at least one from me)! You'd get more though if you somehow reintroduced this lovely way of doing things back into the mainstream. I guess we sort of have it again with VM snapshots, but that's not nearly as elegant. I love the idea of having a persistent memory state that can be examined or reentered. That's how it should be!
Emacs and Atom share the architectural aspect of implementing most of their functionality in a higher-level language inside of an execution environment. This has costs and benefits.
vi had a much simpler structure and much more limited feature set. vim is obviously a much more capable/flexible editor and has scripting support, but is still predominantly written in C.
Not necessarily. You might just be extra patient, or not use many plugins, or only use well behaved ones that down slow down startup that much. I remember years ago when I used Vim I had pretty slow start up time for a while but narrowed the problem down to one plugin I decided I could live without (can't remember which one it was, though).
Is Coffee-Script still a thing? Looking at Atom source code it's still 80% in Coffee-Script. Why hasn't someone rewrote (eg transpiled and than refactored) it in JS with hand-tuned optimisation? https://github.com/atom/atom/tree/master/src
Was listening to a podcast with one of the first Atom authors (Nathan Sobo) and he mentioned that all new code is in ES6 these days. The codebase is pretty big. They're doing a convert-on-touch approach he said.
Of course if you're touching the same code over and over again, that's probably a sign you're not solving the problem well. Solving problems with a finality such that they don't have to be reopened again and again is the aim of good software engineering. That is true.
But in order to get there, you need to periodically add a major new capability—and thus a major new assumption—to your architecture. If you're not making these kinds of sweeping changes every now and then it's almost certain that you're not actually doing deep refactors that resolve longstanding challenges in lower energy ways.
Resistance to these kinds of sweeping changes amongst professional developers and their ambassadors at major platform companies is the reason why Windows, iOS, Oracle, and the like have stable interfaces and smaller audiences. On the web you don't need permission to write a whole new JavaScript framework, so people can take those first big steps, even though they are quite painful for the developer.