Okay so I made the mistake of posting about #emacs and got a dozen variations of the joke "a great operating system, lacking only a decent text editor"[1]. I just want to set the record straight on this one: Emacs is a really good text editor bolted on to the side of a pretty terrible operating system. It's a cooperatively-multitasking mess where one small bug crashes the whole thing, powered by an undulating pulp of interconnected shared state where everything is global by default
don't get me wrong, this comically slapdash approach to factoring everything — itself an inevitable consequence of GNU's pervasive "surely nobody would write a program with *bugs* in it, everything should be programmable all the time" ideological perspective — is *great fun*, you can change the behavior just about everything in hilariously dangerous ways. kind of like a web browser, but even more so.
> surely nobody would write a program with *bugs* in it, everything should be programmable all the time
I don't see the reasoning. I would agree that everything would be better off being more programmable, but don't see how average(?) bugginess of programs can be part of an argument for/against that. Could you elaborate?
> So does (let ((whatever …))), albeit temporarily.
Ouch. Yes, this explains the terribleness about Emacs.
However, I still don't see how this is caused by assuming that nothing is buggy. Even if all code is bugless, this environment makes for a terrible interface; did you mean to say that they are assuming all code is bugless, regardless of how complicated the boundary conditions are made (and thus they don't make them simple)?
@robryk If all code is bugless, then everything works and everyone is happy; all architectures are equivalent if nothing ever fails. The question is, what happens when things *do* fail?
@robryk This means that the conflict surface of different elisp applications are the full cartesian product of every piece of state maintained by every other piece of state. You have to manually prefix every variable and function, the user has to manually inspect for keymap conflicts, and so on.
@robryk Also, since it runs in-process in emacs, any mistake that results in an infinite loop results in an editor crash. (Not quite, C-g works sometimes, but, not always.)
@robryk Sure.
The issue here is that the way you program emacs is to modify the program *of* emacs, as a whole, by adding lisp code to it. All of this code has not just theoretical access but easy, default access to every structure in the entire application. (setq whatever …) sets whatever globally. So does (let ((whatever …))), albeit temporarily. The ways to *not* do this, like (lexical-let), are never the default.