Bytecode is not a novel idea and I wouldn't expect it to be difficult at all to map the well-known concepts to the particulars of the Emacs implementation.

Documentation of source code is often overrated IMO. Most software isn't difficult to understand if it's at least somewhat well-structured - and when the structure is poor, documentation doesn't help much.

It's usually the application domain that's hard to understand, because that's where global invariants and assumptions live.

(Don't get me wrong: documentation of module boundaries is great, particularly if there are many users of the module, up until you get to APIs, where documentation is essential for a decent experience. Documentation of the innards of software, not so much.)

It was probably a novel application when it was first implemented in emacs 1985-ish (going by the bytecomp.el header comment by JWZ). First editor bytecode? First lisp bytecode? First interpreter bytecode?

O-code predates it by a couple decades for general purpose compilation: https://en.wikipedia.org/wiki/O-code

Peter Deutsch published a paper on a compact Lisp bytecode in the 70s, http://www.softwarepreservation.org/projects/LISP/interlisp-.... IIRC the Smalltalk-80 bytecode was pretty similar, descended from Smalltalk-76.

The cell counts seem to be off by one in the Appendix examples (REVERSE and SUBST lambdas). I count 35 and 40 conses, respectively. :)

The context of my comment is of course in maintaining the source - the comment I was replying to was concerned with bus numbers.

By the time it was implemented for emacs, many, if not most CS students would have been familiar with p-code as used for UCSD Pascal etc.

This page is actually pretty good high-level documentation for the system. Between it and the source code you'll have little difficulty.

Of course, if you have Emacs you'll presumably also have the manuals. Chapter 16 of the Elisp manual seems pretty thorough.

Source code is the ultimate documentation. ;)

I've started doing literate programming these past two months, and I have to say that I believe this statement less and less.

That's true for a lot of software. Do you use any SaaS? That's the worse.

The only SaaS I use personally are websites I visit. I host my own ownCloud, file storage, contact backups, and when I move into my new place I'll be setting up my own email server as well.

Edit: If you consider DNS as SaaS then I also use that but I don't need it internally for my network to function so I won't call it a dependancy.

Statistically, death is not the danger. I can't think of a single case where a heavily relied-on project caused major issues from a handful of deaths.

On the other hand, developers losing will… The loss of Gmane, for instance, caused major link breakage for months.

That was one of the argue points in some of the recent emacs-devel drama about the object dumper.