https://djrobstep.com/posts/programs-are-a-prison

We often hear that Apple's ecosystem of apps (or Microsoft's, or Google's) are "walled gardens". But what about the individual applications themselves?

This seems like such a basic category error I don't know where to begin. It's like saying that human languages are prisons because other languages exist.

Right, but people want to talk to the computer, ideally talk through the computer, not learn a new language everyday. And human languages can be prisons, people have written about such feelings throughout history. The argument is that we should put (user-generated) data first, and not get locked down in particular representations, which is much easier said than done, but is a goal I'm amenable to. Notice that in any relatively well integrated system, no one refers to the component programs as programs—they are scripts at best, although there's really no essential difference (for example, all the random stuff bundled in emacs and available to add, is just "emacs")—these categories are socially constructed and not essentially properties of the system. All that said, that header line is kinda misleading I agree, but I think focusing on that is missing the point. @Kartik Agaram

I'd love to see examples of human languages compared to prisons! Not stuff like Orwell which is about some languages, but with universal quantifiers attached. Yes, gaps in interop have been lamented before, and they're reasonable. I guess I'm wondering what's new and good here. Everyone here is probably familiar with the idea that when you use a computer you're in conversation with its creators. That's where sentiments like "write first for human readers rather than the computer" come from. Maybe this is a crucial thing to teach non-programmers? Except the author seems to be a programmer. I think I just don't understand his point. To me it seems like multiple isolated zones of interop are just a law of nature. There's lots else you can lay at the door of economic incentives (God knows I've done enough of that), but not this. Early Unix was almost utterly idealistic, and we still got the split between ATT and BSD. Early Lisp had zero economic incentives, and we still got Lisp 1.5 vs MacLisp.

The thing with languages is that mostly one language is sufficient to go about your daily activities in most contexts. Imagine if you had to switch languages and bring translators with you because the grocery store uses one language but the coffee shop use another, and so on. That's the kind of shuffling it seems we're doing with apps? Import, export, save as, dance and repeat! We don't really care about the 'apps' but really care about the 'objects' under those apps - music, video, audio, code, etc. I agree there will be fragmentation either way. But can we have the dominant paradigm be objects, not apps? Here's another write-up I think along a similar sentiment: https://humane.computer/killing-apps/

I'm totally on your side there. As I wrote a couple of months ago:

One implication of fitting in a single head: Mu constrains the number of supported languages. Languages have a way of growing into isolated universes, and interoperation between languages adds its own complexities. It seems better for future readers if the stack minimizes the number of such boundaries, even if writers are inconvenienced somewhat.

(http://akkartik.name/post/mu-2019-1)

People like Alan Kay and many other designers and builders of systems of his time had a very different goal than most programmers today. When they learned programming that was the only UI for computers, and they thought hard about how to create a better UI for programming — a UI for the power of making computers do anything you want them to, not limited to any specific domain. But commercialization forcefully shifted incentives towards less generic and more domain specific solutions. It was much easier to sell a program for spreadsheets. And one for text processing. And one for presentations. It was easier to sell because it was easier to see what specific problem these programs solved. And it was easier to use because you’d only have to know about that particular problem domain. And it was easier to build as you cut down complexity significantly and no longer had to try to make everything possible, but just a slice of a much smaller problem space. It’s so easy to fall into the trap of specializing too early too quickly, losing that generality early in the process. Systems like Smalltalk that some of us admire kept that generality alive in the system by representing many things with just a few powerful concepts. It wasn’t just that everything was an object, it was also that almost everything was represented by almost the same kind of object. Today, we often want to get rid of too much generality as quickly as possible and favor distinguishing things from each other so we know what we’re dealing with. Life gets so much easier if you know exactly what you’re dealing with. And that’s when we end up with specific data structures representing specific things in specific apps solving specific problems (and specific people with their specific backgrounds making specific design decisions) — isolated universes. And so we spend most of our time writing algorithms to convert between them to make them work together again. When we start representing a specific thing in our code, we take that power away from our user who will now have to live with that thing as we designed it. The solution can’t be to design all the possible things for them individually — what we are clearly trying very hard currently. What we need to do is to give our users as few things as possible, just enough so they can design whatever it is they need to get their job done.

@Kartik Agaram Languages as prisons, no, I can't remember such a comparison, but human languages as silos, creating barriers between people, is a common theme, both at the individual and at the social group level. Many migrants have experienced that different languages give them access to different aspects of their lives, as far down as in their dreams (so it's not just who you can talk to). At the social group level, an interesting story is the one told by Ludwik Lejzer Zamenhof, the inventor of Esperanto. He grew up in a trilingual city in which the three linguistic groups had little contact. Which prompted him to invent a bridge language to enable communication. Similarities to today's software world are not accidental, in my opinion.