> When making a tightly-integrated product (which people tend to expect these days)
Do they? It was my impression that the recent evolution of user-facing software (i.e. the web, mostly) was about less integation due to reduced scope and capabilities of any single piece of software.
> adding "just" one new feature (when you already have 100 of them) means touching several (if not all 100) things.
This sounds true on first impression, but I'm not sure how true it really is. Consider that I could start rewriting this as "adding 'just' one new program when you already have 100 of them installed on your computer"... and it doesn't make sense anymore. A feature to a program is like a program to OS, and yet most software doesn't involve extensive use, or changes, of the operating system.
The most complex and feature-packed software I've seen (e.g. 3D modelling tools, Emacs, or hell, Windows or Linux) doesn't trigger combinatorial explosion; every new feature is developed almost in isolation from all others, and yet tight integration is achieved.
And this is actually more rule then exception - once you have more then 2 plugins, the chance of plugins colliding or not allowing updates of the main software in the future are more or less norm.
Not an issue if there are no third party plugins. Its however hard to resist allowing third party plugins when you already have the architecture. Also hard to resist feature bloat when adding new features are seemingly free.
If there are no third party plugins, then you don't have plugins - its an internal architectural decision, not relevant for the end-users.
Having plugins means anybody should be able to create one.
I remember vagrant has support for all historic plugins versions no matter the current API version. This is rare goodness but prevents only one type of problem - inability to update the core.
Or, just think about your phone. If I put my head to the speaker, a sensor detects that, and the OS turns off the screen to save power. If I'm playing music to my Bluetooth speaker, and a call comes in, it pauses the song. When the call ends, the song automatically resumes.
KT's UNIX 0.1 didn't do audio or power management or high-level events notification.
> Pretty sure making emacs render smoothly in 2016 was not an isolated change--even if the code change were only a single line.
This was a corner case. What I meant is the couple dozen packages I have in my Emacs that are well-interoperating but otherwise independent, and can be updated independently.
> Or, just think about your phone. If I put my head to the speaker, a sensor detects that, and the OS turns off the screen to save power. If I'm playing music to my Bluetooth speaker, and a call comes in, it pauses the song. When the call ends, the song automatically resumes.
These each affect a small fraction of code that's running on your phone. Neither of them is e.g. concerned with screen colors/color effects like night mode, or with phone orientation, or with notifications, or countless other things that run on your phone in near-complete independence.
Buttery smooth emacs is not a corner case. When working on API-level things (for those who don't know--emacs is practically an operating system), if we care about not breaking things, one must be highly cognizant of all the ways that API is consumed. Even if the final change ends up being very small code-wise, the head-space required to make it is immense. That is why we have (relatively) so few people who make operating systems and compilers that are worth a damn.
Most emacs plug-ins aren't operating at that level of interdependence. This one is working on a text buffer at t0, and that other one is working on a text buffer at t1. Of course, the whole thing can be vastly simplified if we can reduce interdependence, but that is not the way the world works. Typical end user doesn't want emacs. Typical end user wants MS Word.
Even if I accepted the replacement of my word "feature" with your word "program" (not that I do), one only needs to look at Docker's prevalence to see the point still holds. Interdependence is hard, and sometimes unavoidable.
> Consider that I could start rewriting this as "adding 'just' one new program when you already have 100 of them installed on your computer"... and it doesn't make sense anymore.
Turns out when you chnage the words of a statement, it changes the meaning of that statement.
Do they? It was my impression that the recent evolution of user-facing software (i.e. the web, mostly) was about less integation due to reduced scope and capabilities of any single piece of software.
> adding "just" one new feature (when you already have 100 of them) means touching several (if not all 100) things.
This sounds true on first impression, but I'm not sure how true it really is. Consider that I could start rewriting this as "adding 'just' one new program when you already have 100 of them installed on your computer"... and it doesn't make sense anymore. A feature to a program is like a program to OS, and yet most software doesn't involve extensive use, or changes, of the operating system.
The most complex and feature-packed software I've seen (e.g. 3D modelling tools, Emacs, or hell, Windows or Linux) doesn't trigger combinatorial explosion; every new feature is developed almost in isolation from all others, and yet tight integration is achieved.