Software is now organized into static machines called applications. These applications (“appliances” is a better word) come equipped with a fixed vocabulary of actions, speak no common language, and cannot be extended, composed, or combined with other applications except with enormous friction.
Applications can and ultimately should be replaced by programming environments, explicitly recognized as such, in which the user interactively creates, executes, inspects and composes programs.
Applications are failing at even their stated goal, but they do worse than that. Yes, an application is an (often terrible) interface to some library of functions, but it also traps this wonderful collection of potential building blocks in a mess of bureaucratic red tape.
No one piece of software ‘does it all’, and so individuals and businesses looking to automate or partially automate various tasks are often put in the position of having to integrate functionality across multiple applications, which is often painful or flat out impossible. The amount of lost productivity (or lost leisure time) on a global scale, both for individuals and business, is absolutely staggering.
As a civilization, we would be better off if software could be developed by small, unrelated groups, with an open standard that allowed for these groups to trivially combine functionality produced anywhere on the network.
The problem is, I don’t want a machine, I want a toolkit, and Google keeps trying to sell me machines. Perhaps these machines are exquisitely crafted, with extensive tuning and so forth, but a machine with a fixed set of actions can never do all the things that I can imagine might be useful, and I don’t want to wait around for Google to implement the functionality I desire as another awkward one-off ‘feature’ that’s poorly integrated and just adds more complexity to an already bloated application.
I really like the toolkit metaphor. Feels closer to the original intent of the UNIX philosophy. It would be really interesting if that baseline was built upon richer objects and data types.
I don’t think this is just a case of big companies like Google or Apple hindering the obvious good way to do things. An open standard that everybody agrees to use consistently is a level of organization humanity has never managed. And attempts to achieve it lead to monopolies like Google and Apple, so I tend to even mistrust the urge.
I think the Tower of Babel is a powerful parable about human nature. People were not designed to have a single language, or a single protocol, or a single open standard. At best we can hope for multiple regimes that interoperate poorly with each other.
Indeed, and I suspect this is due to complex environments not being navigable with a single perspective. A single language, or a single computing platform, would be the equivalent of monoculture. Insufficient resilience, insufficient adaptability.
But multiple toolboxes with bridges looks achievable. It’s in fact what we have in the desktop and server markets.
That said, apps are great in many situations. I want apps as an option. Just not the only one.
I think we’ve talked about this before so I don’t want to repeat myself too much…
I feel like Unix, x86, and the web are already bases that end-user computing is sitting on. As far as I can tell none of those have the traits I would like to see in a malleable system built in. I wouldn’t want to lead with a standards-first mindset for the reasons mentioned above. If there’s a low level of interoperability between tools, I fear that it will just cause network effects to cause centralization around harmonious systems.
Rather than have a prescriptive forward standardized approach, I hope that we’ll move towards having more declarative systems and build tooling that allows for richer interoperability while allowing for system/protocol evolution. I agree with @khinsen on a single perspective not being enough, but I feel like currently, we’re not differing on the essential complexity between perspectives but on towers of incidental complexity.
In the front of toolkits that are already exposing their building blocks while providing programming environments for the user to change them, I would put the rich tradition of Smalltalk systems that do precisely that, particularly its current evolution in environments like Pharo and Glamorous Toolkit (GToolkit).
The think that, for me, the issue is more cultural that infrastructural. We already have programming environments that convey more powerful visions and practices of informatics than the hegemonic ones, popularized by Big Corp Inc. But such powerful already present uses are marginal. In my case, a way to bridge such gap was to build tools like Grafoscopio and put them in grassroots communities like the local hackerspace, HackBo. And now I’m porting the lessons from Grafoscopio (build on “plain” Pharo) to GToolkit via MiniDocs.
So, a more compelling question, for me at least, is to tackle the cultural part of moldable infrastructures. And aspect that I have seen consistently overlook in more technocentric discussions (more about that in a future post).
BTW, talking about infrastructure and culture: I don’t know which is the policy regarding old threads. One of the things I like the most from Discourse forum software is this sense of serendipity and being able to revive something old and making it anew, so nobody arrives never “late” to the conversation and can sync him/herself with the community memory at his/her own rhythm. Let me know if there is another policy regarding retaking old threads.
I don’t think we have any particular policy in this community, so I’d just try what seems natural to you.
The threads in the “catalog” category (such as this one) are playing two roles as both a wiki entry for a particular work (the top post is editable by all and eventually published to the website) as well as also hosting comments on that work. For more general discussion that isn’t about a single work specifically, a new thread in some other category is probably the right choice.
