Programs are a prison: Rethinking the building blocks of computing interfaces • Hacker News Board

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#161

Post by TeMPOraL » Sun, Nov 08, 2020, 1:30 PM UTC

jcelerier wrote: post #91

shalabhc wrote: post #84

A lot of replies are missing the point. It's not "apps integrate better with each other". It is "there are no apps". So what would Adobe sell, if not the "Photoshop app"? It would sell the Photoshop "menu of filters", the "selector toolbox", the "color histogram view" and such. But the workspace where you see the image and apply the selectors or filters would be outside Photoshop itself. It would be a standard part o…

It would likely mean losing lots of integration and special features though. If it's outside of the app how would you have a modal UI which would change what's in the right click menu of the canvas ? You would also have to wait for your OS to implement 10-bit support for it - I'm pretty sure that e.g. Krita had 10-bit canvas before MS Paint :) Also enjoy teaching students or even learning to do anything. With big sof…

> If it's outside of the app how would you have a modal UI which would change what's in the right click menu of the canvas ?

Simple. The object that owns the "modal UI" part would own, or at least aggregate, a right-click menu. The canvas shouldn't be busy handling right-click menus anyway, it should provide an interface to access and manipulate the underlying bitmap. The "modal UI" would own the right-click handler, and would populate the context menu with a filtered choice of options, including functionality provided by different objects.

It's more complex than naive approach with everything being owned by a single one, but fundamentally not that different from a design you'd arrive to if you were intended to allow for plugins in your application - except now the "plugin manager" isn't in your app, but in your OS.

> You would also have to wait for your OS to implement 10-bit support for it - I'm pretty sure that e.g. Krita had 10-bit canvas before MS Paint :)

Krita people could provide a 10-bit canvas implementation that offers an 8-bit canvas-compatible interface. Alternatively, your UI could require canvas objects implementing a 10-bit canvas interface, but you - or a third party - would also provide an adapter (polyfill, as the kids say today) that wraps the MS Paint 8-bit canvas behind a 10-bit canvas interface.

--

The teaching point you bring up is a strong one, and I don't have a good answer. I think Microsoft's COM, the Emacs ecosystem and every game with a large modding scene (e.g. Kerbal Space Program) all provide evidence that a fully interoperable system turns users into sysadmins. You don't need to code to use such a system, but you'd better be prepared to be aware of all the components, and do a bit of configuring, if you want anything other than the defaults.

(But, as every game with a large modding scene demonstrates, it's not necessarily that hard for regular non-tech-savvy users either.)

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#162

Post by tsimionescu » Sun, Nov 08, 2020, 1:32 PM UTC

TeMPOraL wrote: post #159

tsimionescu wrote: post #153

Earlier quoted context omitted.

The terminal is exactly an example of an app-centric workflow and why it is easier to build and/or easier to use than an API focused one. If you want to see a no-apps workflow, something like the Genera LISP OS was probably much closer[0]. People choose to use apps like ls, cat, less, echo, touch, find instead of using the FILE* object directly with readdir(), stat(), read(), write(), open(), creat() etc. All of the…

In context of terminals, if you want to see a modern API-based instead of app-based CLI experience, check out PowerShell. The underlying principle is that all commands like "ls" or "ps"[0] return their results as .NET objects, and not unstructured text. If you just call "ps" in the shell, you'll get the default visual representation you'd expect - but you can also choose a different one (e.g. list view by Format-List…

Right, should have mentioned PS as well.

However, it's still important to note that it's easier in some sense, especially for simple tasks, to use Bash than PS, and I think that this is deeply tied to the reason why we fall back to apps rather than rich objects as the fundamental interactions.

I believe that human capacity to massage data together is still very hard to replicate in the kind of formal manner required by programming tools (for now, at least). That is why it is significantly easier for someone to copy data from one web UI to another than it is to write the rules for copying backend-to-backend automatically (up to some amount of data). This is a problem much more fundamental than the economic incentives for app creation. It's similar to the observation that, for small amounts of data, it is easier to run a select * from table and visually search, rather than go though the trouble of mentioning which columns and rows you want to see.

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#163

Post by TeMPOraL » Sun, Nov 08, 2020, 1:43 PM UTC

BlueTemplar wrote: post #139

ptx wrote: post #13

> We need computing environments ... without the concept of applications appearing at all. Platforms keep trying to enable this, but application vendors want to control the UX and branding, so they're not going to provide these generic reusable building blocks. Android, for example, lets apps make use of views from other apps and securely delegate a task (e.g. take a photo, pick a file, etc.) to the user's preferred…

Platforms are completely antagonistic to this goal, as the definition of a "platform" is pretty much "something that lives in its own world, and so doesn't care about following outside standards".

Platforms are very much in favor of this goal within the platform, but antagonistic outside. But then, every app within the platform is very much antagonistic to this goal - it also wants to have full control over user's data and interactions. So structurally, it's the same problem - but it manifests itself separately at every level of the stack - at least where commercial software is involved.

It's all a matter of culture. Proprietary software wants to take control, so it's opposed to general interoperability. Contrast that with e.g. the modscenes of games like Kerbal Space Program, where mod authors (i.e. authors of what are essentially apps, running on the platform of the game) go out of their way to be interoperable with everything else, often implementing compatibility features inside their own work that target other popular mods.

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#164

Post by TeMPOraL » Sun, Nov 08, 2020, 1:46 PM UTC

Someone wrote: post #97

pavlov wrote: post #63

OpenDoc was a mid-‘90s Apple software framework that basically did this. It was also adopted by IBM on OS/2 as part of the technology exchange that also resulted in Apple and Motorola using IBM’s POWER CPU architecture. Steve Jobs killed OpenDoc when he returned to Apple in 1997 because it wasn’t NeXT software. The IBM side of the project had already died at that point as Windows 95 trounced OS/2.

I don’t think he killed it “because it wasn’t NeXT software”. I think he killed it because the market didn’t support it (MS Office showed that an ‘everything but the kitchen sink” solution could conquer the market, leaving only breadcrumbs for smaller parties) and to focus the company.

But MS Office is sort of the implementation of what the article describes, with it being thoroughly COM based. You can embed pieces of Office in your software, or pieces of your software in Office (including saving its state in the MS Office's documents).

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#165

Post by TeMPOraL » Sun, Nov 08, 2020, 1:47 PM UTC

magicalhippo wrote: post #51

vortex_ape wrote: post #6

Earlier quoted context omitted.

Thank you for the links! > A common use of COM was scripting with Visual Basic in the 1990s ... This sounds nifty!

It is used for a lot more. Want to integrate Windows Explorer in your application? COM. Custom property pages in Windows Explorer? COM. Custom folder view ala zip folder? COM. Want Windows Explorer to be able to extract metadata from your custom file format, or Windows Search to search it? COM. Want to play or manipulate video using the installed codecs? COM. Want users to be able to drag an attachment from Outlook a…

I'd also add:

Want to play video games? DirectX is a COM API too.

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#166

Post by Poefke » Sun, Nov 08, 2020, 1:55 PM UTC

I like where this is going, I have been thinking about similar problems lately and, inspired by a talk from Alan Kay, started writing down a research direction for a solution. I'm looking for feedback and other people interested in this. You can read the whole thing here: https://hackmd.io/kafpxBeqQua_rcrncP14tQ?view

TLDR: I'm thinking of building on top of the browser a universal document standard, which allows for interactive documents that contain the application you need to render it, but also to get data from it and link it to other documents. I'm thinking of using IPFS as a storage mechanism to get stable links. Iframes to securely compose documents, using a bootstrap javascript line as the only requirement for any document format. A message bus system, using iframe postMessage api, to connect all documents.

I'm in the pre-design phase, there is no code, just thoughts.

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#167

Post by phkahler » Sun, Nov 08, 2020, 1:56 PM UTC

I'm not entirely sure the author understands what software is or how it works.

Photos are stored in standard formats. Your web browser can probably save images for you that could be opened in photoshop's. If you want drag and drop that could be done (browsers dont allow you to drag out AFAICT). But filters are software, not data. Someone could try to create a standard way to define filters but then each program would need to understand that. I like the idea of dragging a filter onto an image in any program and having it apply there, but that means the filter has to be some independent piece of code implementing "the image filter API". Would every app need to know how to apply those, or would the UI toolkit have means of presenting images that all apps use and that knows how to apply filters?

Not only does this require extremely good design of abstractions, it requires a very open system that seems to go against commercial interests. In the long term I think commercial software has other similar issues, but we need an alternative means of paying developers before that can change.

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#168

Post by mmphosis » Sun, Nov 08, 2020, 2:08 PM UTC

jcelerier wrote: post #94

WheelsAtLarge wrote: post #49

OOPs was suppose to help with the issue of programming lock in but for the most part it has not advanced to the point where you can interchange program pieces. I think we need to go back to the idea that software can be like building a building where there are basic building blocks that can be purchased from many vendors and let each vendor decide how to improve the blocks and let the architects and engineers decide…

> but for the most part it has not advanced to the point where you can interchange program piece Hasn't it ? I have no trouble e.g. replacing a hash map or container by another implementation in C++. We live in an era where we have libraries for everything and it takes seconds (okay, sometimes minutes) to introduce them in a codebase and swap them. What more do you want ?

C++ libraries are baked in, broken, or missing. C++ class hierarchies are not objects. To me, objects are like biological cells that can poly-transform and communicate on the fly. Both libraries and class hierarchies are not just jails, but dependency hells.

Want and more are problems. What do we need?

Everything including functions can be abstracted as live data. I want to connect objects live, changing on the fly. The "C++ text -> compile -> link -> install / run" pipeline is way too clunky.

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#169

Post by eternalban » Sun, Nov 08, 2020, 2:44 PM UTC

A suite of data format standards will achieve all this without having to resort to a (hand-wavy) half-baked notion of standardized set of data processing modules (aka “applications”). And we’re already doing this, and I am certain the OP has also modified data created by one application with an entirely distinct other application. Overall, OP fails to provide a lucid and compelling reason for speculating about a half-baked notion that supposedly solves some poorly defined problem. (Repeat: interop is optimally done via data translation. Local coupling that allow for eco-systems of loosely coupled (via data) applications.)

Re: Programs are a prison: Rethinking the building blocks of computing interfaces

#170

Post by BlueTemplar » Sun, Nov 08, 2020, 2:45 PM UTC

TeMPOraL wrote: post #163

BlueTemplar wrote: post #139

Earlier quoted context omitted.

Platforms are completely antagonistic to this goal, as the definition of a "platform" is pretty much "something that lives in its own world, and so doesn't care about following outside standards".

Platforms are very much in favor of this goal within the platform , but antagonistic outside . But then, every app within the platform is very much antagonistic to this goal - it also wants to have full control over user's data and interactions. So structurally, it's the same problem - but it manifests itself separately at every level of the stack - at least where commercial software is involved. It's all a matter of…

Yes, and focusing on the inside compared to the outside makes things exponentially worse for the outside.