I am Andrey Ka, and I wrote that program that adjusts image colors mentioned by Robert. I must admit that writing this program was no different from most of other nowadays programs: the actual useful code is diluted in the useless application lifecycle management, UI and file handling code which performs:
- application start-stop-pause-resume,
- window management, transitions and focus,
- resources,
- controls, panels, views, event handling,
- internationalization and accessibility,
- data format parsing,
- file handling,
- versioning and sharing.
My program shows file selection dialogs, reads and writes various graphic formats, manages the GUI, and so on. The amount of code that actually adjusts image colors is whapping 3%. And this holds true for any application. And I don’t like this.
In fact, Robert wanted the application that adjusts image colors to be not a standalone application, but a plugin for a presentations slides editor. And to be honest I want the same. Unfortunately, most applications do not support plugins. And even if they do, I still have to implement plugin lifecycle management, data format conversion, and somehow integrate with the API of the host application. And since there could be many programs that need to edit image colors, I would have to re-integrate my code from scratch into each of those programs. Making plugins is no simpler than making stand-alone applications. But what’s really hard – is to create applications that support plugins. Such application must deal with several additional issues:
- complexity
- security
- compatibility
Complexity: Plugin-enabled application would be orders of magnitude more complex than a monolith one:
- it needs to have a plugin lifecycle management system
- it should define and maintain the object memory representations compatible across different languages and be stable across multiple versions
- it should provide interface call dispatching
- it needs an extensible file format that allows to inject information of arbitrary plugins inside the document
Security: a plugin is nothing but a third-party code working inside the someone else’s application domain, having full access to its data structures, to the full address space of the host application process.
Compatibility: when you open your application internals to the plugin code, you have to maintain stability of all your data structures, your API and architecture, which may quickly become unbearable burden even if you are a multibillion dollar corporation. That’s why plugin-enabled applications are so rare.
It would be good if an operating system provided some sort of language-agnostic API for creating such plugin architectures. And our industry knows a couple of such attempts. The most famous one was Microsoft’s OLE/COM. But nowadays no one actually uses it because of its extreme complexity.
There is another approach – a high level language, especially designed for plugin architectures. The best examples of this approach are Java and .NET. Both technologies allow application code to be implemented as packages of classes. And different classes from different developers can be dynamically loaded, linked and co-exist in one application domain in single address space. These architectures standardized memory data layouts, interop interfaces, method dispatch, and provide the unified ways and mechanisms to control object lifetimes (GC).
The only difference between what Robert wants and what .NET/Java architectures provide is the number of running applications. As it said in the Roberts post, users don’t want to deal with multiple applications. They don’t want to start/stop/switch them. They don’t want to remember what document is open in which application. Users want the computer to be controlled by ONE invisible application that provides access to all documents and provides tools to work with the current focused document.
And also the user wants even more – that all documents in the computer to be represented not by files in file system folders, but as just… documents. Yes, the documents that are nested into one another and having links between tham. Users don’t want to remember what document is associated to which file, and don’t want to keep saving it back to files, keeping track of backup copies in different files/directories. So this means that there should be no two separate entities – open documents and stored files, and there should be no two separate types of memory – RAM with applications and SSD with files, instead all documents should reside in one single system-wide “application” simultaneously and persistently.
The best known analog of this approach is Smalltalk environment, which tried to do so by saving snapshots of its RAM environments into different files. As we know from history it didn’t last. Fake file-less environments built atop file systems didn’t work well.
So bottom line is:
- Software developers are trying to reduce users’ pain of using files and switching application by integrating multiple applications in one and creating plugin architectures.
- This leads to monstrous architectures that harm performance, compatibility, and safety
- These plugin architectures have limitations – which ends up with:
- a small number of monstrous all-in-one apps (Office, Browser, etc.) hardly compatible and having near-to-nothing interoperability between one another
- a huge number of small tools representing the old: “single app, single file format, single feature” approach
- This all is painful both for users and for software developers.
- And btw these solutions do nothing to hide the fact that all documents should be manually loaded from and saved to files.
Something needs to be changed.