4 ms·

Such a system sounds nice in theory. In practice it leads to a byzantine nightmare of configurable interfaces, support systems, and so on, with a result that is

by sidlls 5y ago

Such a system sounds nice in theory. In practice it leads to a byzantine nightmare of configurable interfaces, support systems, and so on, with a result that is ultimately fatter and harder to maintain.

CraigJPerry 5y ago
I disagree with that - what i’d call a plugin architecture - leads to a very nice separation of components.
- interactivecode 5y ago
  plugins works for things that are plugins. Most people seem to equate separation of concerns with everything should be a plugin. Otherwise you get massive issues actually working across each plugin (or package). So unless your component is actually used in multiple core products it's not a component, it's just a part of your monolith. Making it a separate component usually, just spreads your monolith across several git repo's
Jtsummers 5y ago
I don’t know. It sounds similar to a lot of IDEs. Produce an interface that plugins can make use of, then people can extend the system to support new languages and capabilities. Seems to work well in a lot of cases.
mysterydip 5y ago
That was my first reaction, but I think it can work in some cases. Take for example plugins in a paint program, or dissectors in wireshark. Both of those can have any number of user-created extensions for different packet types or editing that the general populace doesn't need. However, to your point, when wireshark changes their API every few versions, all the plugins have to change as well or you either break your dissectors or are stuck on an old version. The base program should be designed with extension maintainability in mind.
jcelerier 5y ago
As an user, all the software that I take actual pleasure in using and make me productive, are large plug-in based software. As a developer of a mainly plug-in based application, the iterating ability it gives is pretty incredible - nowadays for a large majority of my feature requests, I don't have to touch the original codebase at all, just create a small plug-in for the feature.
vendiddy 5y ago
If the interfaces are defined poorly, it can result in what you are describing. But I've seen systems do this well and the result is something far less complex. I agree with the author's view that good interfaces require iteration. So expect that several irrational will have incorrectly drawn boundaries and poorly defined interfaces. This kind of design takes time, but if you expect the system but if you expect that it will need to evolve over the years, it pays for itself.
7952 5y ago
Well it depends on the level of abstraction you use. You could think of the operating system as the platform, and each piece of software as a plugin. That can work well enough. I can save a PNG in photoshop, and then open it in other programs and it just works. But the file paradigm has lost popularity and there are probably some good reasons for that.
fouric 5y ago
Emacs is a system that adheres to this theory, being a small C core that implements an elisp runtime, and then the rest of the built-in functionality (as well as the entire plugin ecosystem) implemented as easily-tweakable elisp on top of that - but has not turned into "a byzantine nightmare of configurable interfaces, support systems, and so on". It's quite the counterexample to this claim.
- taeric 5y ago
  I'd argue that emacs is more monolithic in is main focus of text editing and elisp execution. It doesn't just build a plugin architecture. It literally built a platform and does most of it's work in the same way that user code can run.

by sidlls 5y ago

CraigJPerry 5y ago

I disagree with that - what i’d call a plugin architecture - leads to a very nice separation of components.

interactivecode 5y ago
plugins works for things that are plugins. Most people seem to equate separation of concerns with everything should be a plugin. Otherwise you get massive issues actually working across each plugin (or package). So unless your component is actually used in multiple core products it's not a component, it's just a part of your monolith. Making it a separate component usually, just spreads your monolith across several git repo's

Jtsummers 5y ago

I don’t know. It sounds similar to a lot of IDEs. Produce an interface that plugins can make use of, then people can extend the system to support new languages and capabilities. Seems to work well in a lot of cases.

mysterydip 5y ago

That was my first reaction, but I think it can work in some cases. Take for example plugins in a paint program, or dissectors in wireshark. Both of those can have any number of user-created extensions for different packet types or editing that the general populace doesn't need. However, to your point, when wireshark changes their API every few versions, all the plugins have to change as well or you either break your dissectors or are stuck on an old version. The base program should be designed with extension maintainability in mind.

jcelerier 5y ago

As an user, all the software that I take actual pleasure in using and make me productive, are large plug-in based software. As a developer of a mainly plug-in based application, the iterating ability it gives is pretty incredible - nowadays for a large majority of my feature requests, I don't have to touch the original codebase at all, just create a small plug-in for the feature.

vendiddy 5y ago

If the interfaces are defined poorly, it can result in what you are describing. But I've seen systems do this well and the result is something far less complex. I agree with the author's view that good interfaces require iteration. So expect that several irrational will have incorrectly drawn boundaries and poorly defined interfaces. This kind of design takes time, but if you expect the system but if you expect that it will need to evolve over the years, it pays for itself.

7952 5y ago

Well it depends on the level of abstraction you use. You could think of the operating system as the platform, and each piece of software as a plugin. That can work well enough. I can save a PNG in photoshop, and then open it in other programs and it just works. But the file paradigm has lost popularity and there are probably some good reasons for that.

fouric 5y ago

Emacs is a system that adheres to this theory, being a small C core that implements an elisp runtime, and then the rest of the built-in functionality (as well as the entire plugin ecosystem) implemented as easily-tweakable elisp on top of that - but has not turned into "a byzantine nightmare of configurable interfaces, support systems, and so on". It's quite the counterexample to this claim.

taeric 5y ago
I'd argue that emacs is more monolithic in is main focus of text editing and elisp execution. It doesn't just build a plugin architecture. It literally built a platform and does most of it's work in the same way that user code can run.