4 ms·

The problem is support. Even if you put big caution tape around it, if you break it or change it in a way that isn't backwards compatible users will complain l

The problem is support. Even if you put big caution tape around it, if you break it or change it in a way that isn't backwards compatible users will complain loudly about it. And if you have users paying lots of $$$ relying on it, it might force your hand. Building a plug-able system in a way that doesn't blow up in your face can be hard. Firefox got a lot of bad press for redesigning their plugin system.

enos_feedler 7y ago
This is a great point and something to consider when designing runtime programmable tools. It should mean moving slow, cautious with minimal surface area and opinions about the future is probably a way to go. Having strong isolation is probably good too. This is something that made me uneasy about highly programmable/hackable platforms. I like when the core maintainers understand _how_ a system wants to be extended and shaped and provides precise hooks for doing so.
funkymike 7y ago
It seems to me the key then would be to have that programmable interface be used to actually implement the features shipped as part of the project. It will be a lot easier to get the API right if the developers are using it themselves, plus that adds a lot more incentive to maintain backwards compatibility as well.
- nine_k 7y ago
  Yes, the fabled Emacs way.
arghwhat 7y ago
Arguably, it's not just about support: It's often just not a good idea, complicating the existing product, still only gives you pre-defined hooks. Jenkins is one of my favorite examples for why plugin systems are evil. As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks due to some unrelated/uninteresting/forgotten plugin somewhere doing something weird. Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features.
- ethbro 7y ago
  > Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features. This feels like microservices-for-everything as a product. Then you've designed a platform, with a reference combination. Which carries its own set of challenges and over-complications. There's something to be said for a clean, batteries-included product... with a way to hack the hell out of it.
  - arghwhat 7y ago
    Microservices is a polar extreme to monoliths. It's not about making each macro-service into 1000 micro-services. It's about making your macro-services smaller, instead of all-consuming monoliths. The problem is that monoliths will never be hackable. A LEGO-kit is hackable. A monolith just have hooks and connectors, but the product itself will always be static. You can get things shipped as pre-assembled LEGO kits (both metaphoric or not)?
- tcgv 7y ago
  > As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks I agree that most of the time it's best to give users only one way of doing things, so that they don't get creative and go down a rabbit hole. Nevertheless, if a product targets a specific type of user, which is expected to be knowledged about and follow certain best practices while using it, making the product more customizable can be a competitive advantage. We can't always blame the product for being "too complex" if it's purposely designed that way so that well-read users can take the most out of it.
  - arghwhat 7y ago
    Complex ≠ useful. A TV and a set top of your choice box is simple useful. A smart TV does the same thing, but is complex and inflexible.
    - saagarjha 7y ago
deleted 7y ago
[deleted]
Cthulhu_ 7y ago
Interesting you mention Firefox because, when you think about it, a web browser (just like an operating system) is a massive pluggable system. They changed the plugin system, but they haven't (as far as I know) broken web standards, so that 20 year old websites still work today. In that regard, browsers aren't that bad.

enos_feedler 7y ago

This is a great point and something to consider when designing runtime programmable tools. It should mean moving slow, cautious with minimal surface area and opinions about the future is probably a way to go. Having strong isolation is probably good too. This is something that made me uneasy about highly programmable/hackable platforms. I like when the core maintainers understand _how_ a system wants to be extended and shaped and provides precise hooks for doing so.

funkymike 7y ago

It seems to me the key then would be to have that programmable interface be used to actually implement the features shipped as part of the project. It will be a lot easier to get the API right if the developers are using it themselves, plus that adds a lot more incentive to maintain backwards compatibility as well.

nine_k 7y ago
Yes, the fabled Emacs way.

arghwhat 7y ago

Arguably, it's not just about support: It's often just not a good idea, complicating the existing product, still only gives you pre-defined hooks. Jenkins is one of my favorite examples for why plugin systems are evil. As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks due to some unrelated/uninteresting/forgotten plugin somewhere doing something weird. Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features.

ethbro 7y ago
> Instead of stuffing everything into a monolith with plugins, split it out into individual composeable units with minimal features. This feels like microservices-for-everything as a product. Then you've designed a platform, with a reference combination. Which carries its own set of challenges and over-complications. There's something to be said for a clean, batteries-included product... with a way to hack the hell out of it.
- arghwhat 7y ago
  Microservices is a polar extreme to monoliths. It's not about making each macro-service into 1000 micro-services. It's about making your macro-services smaller, instead of all-consuming monoliths. The problem is that monoliths will never be hackable. A LEGO-kit is hackable. A monolith just have hooks and connectors, but the product itself will always be static. You can get things shipped as pre-assembled LEGO kits (both metaphoric or not)?
tcgv 7y ago
> As users accumulate plugins, it all becomes a giant, unmaintanable monolith that ends up unable to perform even the most basic tasks I agree that most of the time it's best to give users only one way of doing things, so that they don't get creative and go down a rabbit hole. Nevertheless, if a product targets a specific type of user, which is expected to be knowledged about and follow certain best practices while using it, making the product more customizable can be a competitive advantage. We can't always blame the product for being "too complex" if it's purposely designed that way so that well-read users can take the most out of it.
- arghwhat 7y ago
  Complex ≠ useful. A TV and a set top of your choice box is simple useful. A smart TV does the same thing, but is complex and inflexible.
  - saagarjha 7y ago

deleted 7y ago

[deleted]

Cthulhu_ 7y ago

Interesting you mention Firefox because, when you think about it, a web browser (just like an operating system) is a massive pluggable system. They changed the plugin system, but they haven't (as far as I know) broken web standards, so that 20 year old websites still work today. In that regard, browsers aren't that bad.