Emacs was famously used by “secretaries” (as they were referred to in those days) not only to write documents and mail but to write macros to make their lives simpler. Of course none of them could “program” (which was considered quite intimidating) but they didn’t consider writing Emacs macros to be “programming”.
Back then Emacs was written in TECO so writing actual libraries was pretty arcane and not as easy as it is today.
But I’m glad the learned helplessness around programming has largely ablated, in part through improved tools and in part through simple acceptance.
As a law student in 1980-81, I wrote a custom user manual for the law review editors and our admin to use Emacs and Brian Reid's Scribe formatter (on the Computer Science Department's TOPS-20 machine using a VT-100 terminal over a 9600 bps line). I was the only even-remotely technical person on the editorial board, but even so, we were all in heaven: Once manuscripts were typed into Emacs / Scribe by our admin, we didn't have to literally cut, paste, hand-mark, retype, etc., on paper as the editing process progressed. And it speeded up the production process because we sent "clean" edited manuscripts to the printer, as opposed to manuscripts with significant pen-and-ink proofreader marks; this dramatically reduced the time we spent reading and correcting galley proofs. (Electronic transmission to the printer was next on the experiment list but we graduated and left.) I'm sure that's why I've been an Emacs user ever since, and wrote keyboard emulators for WordPerfect and MS Word.
But its very possible -- I never interacted with any non-programmer Multics users.
As for time sharing: ITS stands for “Incompatible Timesharing System” (a joke on CTSS), with memory protection, etc used by multiple users on terminals and over the net starting around/before the Multics project (all of which preceded Emacs of course)
ITS version 1 is counted from 1967 as well (first mentions of PDP-6 ITS), simply because Project MAC couldn't deliver computing resources needed by other groups, not to mention AI Lab tended to modify the hw all the time (a fate AFAIK common to all ITS systems).
The anecdote about secretaries extending Emacs came from RMS, describing a group that used the shared "utility" computing resources provided by Project MAC (later turned into LCS) and who used a manual that didn't mention the word programming, compiled by who-knows-who, which showed how to modify Multics Emacs (which was the second Lisp-based Emacs) to user's liking.
But there was a time when interfaces were unified, sometimes to an absurd level (e.g. applications having a File menu when they had nothing to do with files) but IMO that is still better than every app being its own thing.
The rise of electron as an 'acceptable' (to some people) substitute for platform-native applications and the myth of the possibility of the "cross platform UI" has accelerated this, really. It's quite unfortunate.
I haven't paid much attention to the Electron world myself so I don't know to what extent anybody is taking advantage of this, but even if they're not, I expect it would be easier than with alternatives.
If this year's Emacsconf is anything like the last one, you are a good candidate for watching/attending it. I know whenever Emacs is brought up on HN inevitable comparisons with IDEs and VSCode are made, but if you browse last year's talks, you'll see that most talks are not related to SW development. Emacs has a lot of enthusiasts who like it not for SW development but as an ecosystem.
I've used it on both Linux and macOS; for whatever reason, my Emacs has always been snappier on my Linux machine, and that's still true with native compilation, but now the macOS experience is also pretty solid.
Actually, can I convince you to share your experience and submit a talk proposal? User stories were a well-received part of EmacsConf last year, and lots of people liked Pierce Wang's talk on learning Emacs as a high school student who's passionate about music. I think people would love to hear about how you wandered in, how you climbed up that learning curve, and how you've been tweaking things to fit you. =)
In emacs I get my freedom, it's cool. And in 2020.. it's the 2nd or 3rd lightest choice.
Like everyone, I’m finding that I’m in an increasingly disparate set of tools with diverging interface design choices to get my jobs done. The cognitive dissonance that all these different interfaces presents me with feels like it’s getting out of hand, and is growing non-linearly.
Emacs is a arcane tool, and is dated in so many ways, but I don’t know that I can find another solution that allows me to counter the ever-growing complexity of software productivity solutions that I presented with both in my personal and professional life. I know I’m not alone.
As someone who’s not a developer nor a full-time product person, (actually a doctor that wandered into tech), I often wonder why I can’t choose my own front end, and why am forced to use interfaces that don’t work very well for me. Emacs helps me escape some of that (at the cost of a huge relative learning curve, granted)