I've been pondering how to define a metric for how programmable a user's overall environment is. One thought I've had is to add up, for each application used in an average day, the percent of time it is used times the percent of features that can be programmed. Call it something like Overall Average Programmability. I know this doesn't account for differences in how easy it is to use the programmability of a given app (mailx is much easier to automate than Gmail) or the importance of individual features that can or cannot be automated, or the ease of integrating applications with different built-in scripting languages, but I think this is a relatively well-defined metric that might still contain some meaning. Does this sound like a meaningful and/or useful concept? Would you estimate, over the course of your career, that your environment's Overall Average Programmability has trended upwards or downwards? Any thoughts on the forces that may have impacted the trends? Personally, I think mine has trended downwards, and I suspect it has something to do with the increasing roles played in my life by mobile apps, web apps, and services that make their money from advertising and want to maximize user engagement rather than productivity. Thoughts?

I don't think it's a trend I've noticed. I would say the programmability of almost everything has stayed consistently low.

Things did feel more programmable 20 years ago. I spent more of my computer time on a Unix server that encouraged more scripting. Now I do more on devices (phones) that I can't program. I've made changes to my mail client when it used to be Pine. I can no longer do that now that it's a webmail client. Even on programmable devices the picture feels worse. Every single open source project has gotten larger and more complex and harder to build over the last 20 years. Pine is defunct, but observe: mutt mail client: 41kLoC in 1998 -> 95kLoC now. required perl in 1998, now also requires python. tmux window manager: 24kLoC in 2009 -> 64kLoC now. Required perl in 1998, now also requires awk and yacc. One confounding factor: I wonder how much of things seeming worse has to do with me just burning out on this sort of hacking activity over the years.

My experience is much the same as @Kartik Agaram's. The one environment that feels as programmable today as it did 15 years ago is Emacs. I suspect Emacs itself also grew bigger, if only for GUI improvements such as better rendering. But from the point of view of add-ons and customization, it's constant.

That was tantalizing enough that I did some more digging. Emacs in 1997 (v20.1): 152kLoC C, 386kLoC lisp, 1010 lisp DEFUNs defined in C, 15k defuns defined in lisp Emacs in 2022: 405kLoC C, 1.25MLoC lisp, 1780 lisp DEFUNs defined in C, 42k defuns defined in lisp This is pretty blunt, of course. I'm just counting

DEFUN

in the

src/

directory and

^(defun

in the

lisp/

directory. Let me know if there's a more accurate approach. But my impression is that Emacs pays so much attention to backwards compatibility that you are able to ignore new affordances for add-ons and customization until you need to go find something. For completeness: Vim: 275kLoC in 2006 (v7.0) -> 390kLoC now Neovim: 167kLoC in 2015 (v0.1.0) -> 238kLoC now Very interesting that Neovim is smaller now than Vim was in 2006. tl;dr -

sloccount

is a useful tool!

My point is that I don't really care about the size of Emacs. I do look at Emacs source code (the Lisp part) quite often, but I get there by navigating from my own code to layers below. As long as the number of layers I have to go through doesn't increase, the size of the Lisp code is irrelevant for me. As you note, Emacs values backwards compatibility highly, which is something I do care about. Perhaps even more importantly, Emacs values programmability, and therefore offers good support for exploring its own source code. So a good metric would perhaps be "number of navigation steps until you hit a primitive" (which for Emacs would be a function implemented in C)>

I'm kinda handwaving that the amount of elisp growing at the same pace as C above suggests there's no difference between C and Lisp once you start poking at the internals of the elisp. But if you're just using the elisp primitives, the surface area of names (which I'm estimating by counting `defun`s) does seem to grow a bit slower than the total volume of Emacs code.

Surface matters more than volume, indeed, but any simple metric misses the importance of modularity. I suppose Emacs' size made a jump when org-mode was adopted into the core distribution, but this had no impact on people not using org-mode. They could (still can) simply ignore it.

Now you're making me wonder why we can't just all pile into the Emacs spaceship 😄 What does Emacs know that tmux or mutt does not, when it comes to modularity?

I can only speculate, but my favorite hypothesis is Conways's law: Emacs is modular, in spite of lacking any explicit support for modularity (it's just naming conventions), because its developer community is structured as subgroups working on specific aspects. I don't know anything about how tmux or mutt are developed, so I cannot really test my theory against those two examples.

Now I want to go back in time and see how things looked in 1995..

Many of the people involved in 1995 are still around to talk to. As are mailing list archives. That could make a nice topic for a PhD in sociology.

https://corpora.tika.apache.org/base/docs/bug_trackers/ocrmypdf/ocrmypdf-LINK-325-0.pdf is a great read from 1988 (via Google: 'emacs retrospective') I'm not sure if this running back and forth is still on topic, though. @Personal Dynamic Media?