4 ms·

That actually makes me think that a lot of potential invention/innovation is locked away behind cumbersome user interfaces. Imagine if all email clients were sp

That actually makes me think that a lot of potential invention/innovation is locked away behind cumbersome user interfaces. Imagine if all email clients were split between models and controller + view. People who want to improve the UI would be able to do so without necessarily affecting people who like the way things currently are. Once a sufficiently effective and intuitive user interface comes along, then a user would be able switch to that at their own pace. If the model part of the email clients had an common API for manipulating said model, then the same controller+view code could be used across multiple email clients e.g. a Eudora interface to the latest version of Outlook for those who want it, and the same Eudora interface for Thunderbird. In addition, it would be possible to both have OS-specific versions of the controller+view if someone wanted a truly native experience, or have OS-agnostic versions using Java, QT, or Electron if someone wanted to ship something faster and/or have a common code-base for controller+view. NB. I might have confused MVC a little in my idea above.

joepie91_ 7y ago
The model as you describe it wouldn't make a lot of sense. To simplify the description of what you're suggesting: it's to have the 'core' and 'UI' be separate. But if the cores of different applications are interchangeable anyway (which they need to be, to make this model work), then why would multiple cores exist in the first place? It could just be reduced to a single one, and there'd be little incentive to start a new one if you can't deviate from the API anyway. The closest real-world model to what you're describing, is an "implement once" public commons model; a shared commons of open-source / public domain libraries that implement a given responsibility or solution for a given problem, and that can then be used forever by everything, and that problem never needs solving again. For that to work, the implementations in question need to be highly granular, so that using them is a no-brainer and you don't pull in additional complexity that you don't need. An "e-mail client", for example, would then effectively just be a UI, and all the business logic would be provided externally by a collection of loosely-coupled libraries. Such a granular ecosystem, in turn, requires a dependency model where adding a dependency is (in and of itself) free and cannot cause dependency conflicts; otherwise people would start grouping complexity together again to reduce conflicts, as can be seen in the dependency ecosystems of many languages today. The only ecosystem that is currently at a point where it can support the "implement once" model, is that of JS, due to everything being highly modular and interoperable. Rust is also moving in that direction, but its ecosystem is nowhere near mature enough yet. Unfortunately, people are too busy complaining about meaningless dependency counts to understand what a highly-granular dependency model makes possible.
SCM-Enthusiast 7y ago
Essentially, Microsoft/ Gmail/ whoever implemented your idea would develop an ecosystem of user generated content. So many different GUI's developed using a specific API to that platform (E.G. Outlook). I can download Outlook, and pick whichever GUI I want, some free, some I pay some outside developer. This 'Saves' Microsoft from ever becoming irrelevent some how, cause it has infinite addaptability. Kind of like Wordpress for email.

joepie91_ 7y ago

The model as you describe it wouldn't make a lot of sense. To simplify the description of what you're suggesting: it's to have the 'core' and 'UI' be separate. But if the cores of different applications are interchangeable anyway (which they need to be, to make this model work), then why would multiple cores exist in the first place? It could just be reduced to a single one, and there'd be little incentive to start a new one if you can't deviate from the API anyway. The closest real-world model to what you're describing, is an "implement once" public commons model; a shared commons of open-source / public domain libraries that implement a given responsibility or solution for a given problem, and that can then be used forever by everything, and that problem never needs solving again. For that to work, the implementations in question need to be highly granular, so that using them is a no-brainer and you don't pull in additional complexity that you don't need. An "e-mail client", for example, would then effectively just be a UI, and all the business logic would be provided externally by a collection of loosely-coupled libraries. Such a granular ecosystem, in turn, requires a dependency model where adding a dependency is (in and of itself) free and cannot cause dependency conflicts; otherwise people would start grouping complexity together again to reduce conflicts, as can be seen in the dependency ecosystems of many languages today. The only ecosystem that is currently at a point where it can support the "implement once" model, is that of JS, due to everything being highly modular and interoperable. Rust is also moving in that direction, but its ecosystem is nowhere near mature enough yet. Unfortunately, people are too busy complaining about meaningless dependency counts to understand what a highly-granular dependency model makes possible.

SCM-Enthusiast 7y ago

Essentially, Microsoft/ Gmail/ whoever implemented your idea would develop an ecosystem of user generated content. So many different GUI's developed using a specific API to that platform (E.G. Outlook). I can download Outlook, and pick whichever GUI I want, some free, some I pay some outside developer. This 'Saves' Microsoft from ever becoming irrelevent some how, cause it has infinite addaptability. Kind of like Wordpress for email.