It is always better to start with simple, dumb and reliable code, with minimal architecture, and then grow organically.
With experience, I tend to write the less smart code possible, I felt in love with the power of brute-forcing everything.
I'm always amused by the hn threads patting ourselves on the backs for in depth technical discussions[1], when so often the top comments are basically non-specific thought leader tweets.
For those that got this far, the article is well worth reading about a design space with difficult tradeoffs, and there are comments actually engaging with the content below this.
[1] today brings us multiple instances in https://news.ycombinator.com/item?id=23664067
I guess my point is he was trying to "correctly solve" a hard problem, which does require engineering. He didn't seem to set out to solve a dumb problem that didn't need solving (Yet Another Text Editor).
I love Emacs, and it continues to be my editor of choice, but it doesn't seem the design is amenable to adding good threading primitives. NeoVIM seems like a success story in this regard, though VIMScript is a much less pleasant extension language than Elisp, which is not perfect, but is at least a real programming language.
There may be a way forward for Emacs, building a sandbox that looks like a full Emacs instance to existing Elisp, and slowly factoring out the whole-editor blocking issues; but that might be almost as complicated as starting fresh, with fewer benefits.
No, but if that's the only criteria, we already have plenty of those.
I think the pagers - less - is somewhat ok with long lines? Not much else that deals gracefully with multi megabyte lines.
I've rarely seen a worse example of absurdly over-engineered code than the Android codebase...