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

#151

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

djrobstep wrote: post #118

greggman3 wrote: post #111

Earlier quoted context omitted.

Microsoft already tried this in in mid 90s. It was called OLE (Object Linking and Embedding). You could embed a photoshop document live in your word document and if you clicked the embedded document the photoshop UI for editing would appear. It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue b…

Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world reference point for "no apps" is the terminal. Piping commands together is very powerful and intuitive (in this way they behave more like composable objects than applications). It works well, except for being unfriendly and reliant on low level text streams, which ar…

No, what they're describing is very much "no apps", unlike terminals. OLE is part of COM, which is all about individual classes, hidden behind interfaces, being available globally in the OS as building blocks.

In a COM model, you can imagine, say, a word processor being composed of UI, document model, document store and spellchecker components. In this reality, I could replace the UI with a touch-enabled one, and run the same spell checker on a remote computer, all with few changes in Windows registry. Think of it like OS-level dependency injection and microservices, with RPC and orchestration being handled transparently for you.

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

#152

Post by BlueTemplar » Sun, Nov 08, 2020, 12:50 PM UTC

bantunes wrote: post #144

BlueTemplar wrote: post #138

Earlier quoted context omitted.

This doesn't make any sense. Apps are what allows you to do any work on the data, starting with being able to display the data on a screen (or print it on paper). Data without apps is completely useless.

That's a bit reductive. Surely there could exist a model where work on data doesn't have to be mediated through "apps", and this is what the article refers to.

"work on data" is the definition of "app".

Unless you're willing to go through your hard drive platters yourself with a magnetized needle ? (or whatever the equivalent is for SSDs)

EDIT : Though even in that hypothetical case, you would need to follow an "app" (more commonly known under the term "algorithm") to be able to make sense of the magnetic domains that you're detecting !

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

#153

Post by tsimionescu » Sun, Nov 08, 2020, 12:54 PM UTC

djrobstep wrote: post #118

greggman3 wrote: post #111

Earlier quoted context omitted.

Microsoft already tried this in in mid 90s. It was called OLE (Object Linking and Embedding). You could embed a photoshop document live in your word document and if you clicked the embedded document the photoshop UI for editing would appear. It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue b…

Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world reference point for "no apps" is the terminal. Piping commands together is very powerful and intuitive (in this way they behave more like composable objects than applications). It works well, except for being unfriendly and reliant on low level text streams, which ar…

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 apps are designed to have human-readable output first, lots of options for controlling that output to make it as readable as possible etc. However, none of them exposes a rich model for its output that would make it possible to easily integrate it into more complex workflows. Instead, we rely on yet other apps, like sed, grep, xargs and essentially copy-pasting text between these apps (this is all that pipes really are, essentially).

This becomes even more obvious when you use stuff like gcc or gdb, which have extremely rich and potentially useful layers of representation that they refuse to expose at all, even as APIs - only text is allowed in the interaction.

Hell, the MS Office suite is a better example of a no-apps workflow, since each of the Office UIs has a deep understanding of the data produced by the others, and you can combine these in meaningful ways - much more so than terminal apps (for example, Word can show a portion of a spreadsheet without you having to guess at what contents it might have and how to parse it, like you would if you want to expose a portion of ls's output to a file).

Interfacing code is hard, it requires well-thought-out APIs and much more work even with the best APIs. Interfacing apps with extremely minimalistic APIs (copy/paste, share) is much easier for everyone.

[0] https://www.youtube.com/watch?v=o4-YnLpLgtk&t=6m0s

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

#154

Post by TeMPOraL » Sun, Nov 08, 2020, 12:55 PM UTC

sriku wrote: post #148

I think to some extent at least, having an open-to-extension capability like what Julia offers (open multiple argument dispatch) could help with this. This isn't at loggerheads with the idea of an application, but let's such applications share concepts - where app2 can extend app1's concepts by defining more specialized methods. So if Instagram exposed an "image" concept (which might be named Abstract image in Julia)…

Microsoft's COM shows that you don't need any magic features in your language - just regular late binding for functions. You can interface with COM components - the one mainstream implementation of what this article is describing - in programs written in C. Because underneath, the whole thing works by asking the OS to give you an array of function pointers in exchange for a UUID.

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

#155

Post by artem247 » Sun, Nov 08, 2020, 12:56 PM UTC

adwn wrote: post #114

1penny42cents wrote: post #105

This is a great idea that would change computing for the better. That said, one angle I sense here is blaming. It's easy to dream and blame, it's harder to build and lead by example. It'd be great if this post was a "why XXX" page in the documentation for a new platform which implements the said ideas.

> It's easy to dream and blame, it's harder to build and lead by example. It'd be great if this post was a "why XXX" page in the documentation for a new platform which implements the said ideas. That's because these grandiose visions are just that – dreams. It's one thing to imagine a user's utopia of infinite possibilities and write a blog post, and a completely different thing to go and implement it. It typically f…

> (see also Alan Kay's vision of software inspired by biological cells and systems – lots of talk, no non-trivial proofs of concept).

I just wanted to say that actually Kay's vision was implemented in something very non-trivial, both on the hardware side - Alto, and the Smalltalk operating system. They were used by real people and exhibited lots of traits that this article talks about. And some of their ideas were hugely influential in mainstream computing.

I love the demo of one of the Smalltalk programs in this talk by Alan Kay [0], starts at around 40:30

[0] - https://www.youtube.com/watch?v=p2LZLYcu_JY

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

#156

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

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…

Apple already tried this in in mid 90s. It was called OpenDoc. You could embed a drawing document live in your word processing document and if you clicked the embedded document the drawing UI for editing would appear.

It turned out to be absolutely horrible. Maybe it was before it's time with computers having only a few meg of memory and being slower than today but it seemed more of an issue because things like UI, when you click the embedded document, what should happen? How much of the drawing's ui should be shown vs word processor's. It was also a nightmare because unless every user had OpenDoc and the exact same components on the exact same version nothing worked.

https://en.wikipedia.org/wiki/OpenDoc

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

#157

Post by walterbell » Sun, Nov 08, 2020, 1:16 PM UTC

thotsBgone wrote: post #104

johnisgood wrote: post #48

Earlier quoted context omitted.

> the death of things like RSS feeds This is really sad[1]. RSS feeds are amazing. Thankfully they are not completely gone! [1] Actually, the whole state of the Internet is sad.

RSS feeds are common, but most readers are mediocre. I'm stuck between some proprietary "pay to remove ads and subscribe for premium" crap, an emacs mode that randomly sometimes takes up to an hour to open, and Thunderbird, which recently deleted all of my RSS feeds.

NetNewsWire has been reliable.

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

#158

Post by johnisgood » Sun, Nov 08, 2020, 1:20 PM UTC

thotsBgone wrote: post #104

johnisgood wrote: post #48

Earlier quoted context omitted.

> the death of things like RSS feeds This is really sad[1]. RSS feeds are amazing. Thankfully they are not completely gone! [1] Actually, the whole state of the Internet is sad.

RSS feeds are common, but most readers are mediocre. I'm stuck between some proprietary "pay to remove ads and subscribe for premium" crap, an emacs mode that randomly sometimes takes up to an hour to open, and Thunderbird, which recently deleted all of my RSS feeds.

I use newsboat on Linux, and Feeder on Android.

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

#159

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

tsimionescu wrote: post #153

djrobstep wrote: post #118

Earlier quoted context omitted.

Sounds terrible, but what you're describing seems to still fall in the category of "integrating apps" rather than "no apps". I think the best real world reference point for "no apps" is the terminal. Piping commands together is very powerful and intuitive (in this way they behave more like composable objects than applications). It works well, except for being unfriendly and reliant on low level text streams, which ar…

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, or filterable GUI table view with Out-GridView), but you can also then filter the objects by properties and call methods on them.

For example, to find and kill all instances of notepad.exe, you'd write:

   Get-Process | ForEach-Object { if($_.ProcessName -eq "notepad") { $_.Kill(); } }

A bit verbose (and that's generally a problem with day-to-day PowerShell usage), but relatively trivial to turn into a cmdlet and alias it to "killall".

Of course, the above example was trivial, but the same principle works for more complex ones - instead of streams of text, you have streams of objects, which you can filter and run methods on, without doing any parsing.

--

[0] - Them being aliases to PowerShell's Get-ChildItem and Get-Process, respectively.

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

#160

Post by SilasX » Sun, Nov 08, 2020, 1:27 PM UTC

belugacat wrote: post #90

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…

The big issue here being that Adobe has zero interest in selling this, and this kind of model would not lead to a $250B market cap business. Adobe wants to tightly control the experience, record how you use the software, display their own branding, try to upsell you on their other products and services, etc etc. Software businesses care about controlling the UX/branding/etc. tightly, because that's where the money is…

That is exactly my thinking. This model goes contrary to the needs of propriety software, to lock you into a whole system you can charge for.

(And FWIW, I don't have the vendetta against proprietary software like a lot of HN seems to, so I'm sympathetic here about breaking the incentives for production of software that legitimately needs paid devs and can't get enough via donations. But if Open Source teams can make it work, I'm all for that!)

OTOH, as a general model ... I can see why it has failed to pick up, at least with typical devs and prevailing software practices. It requires a level of care about interfaces and interoperability that is not very common.

More often, you see APIs broken willy-nilly with no functional need to. Stable standards for exchange of data require a lot of work and are the exception -- even when you have them, there will be the warts that reveal abstraction leakage. (Another comment mentions how HTML was quickly broken.[0]) The no-app approach with basically be that fight, but for every external touch point, of every module.

I do hope the dev world can make that work ... but also: understand what you're fighting against.

[0] https://news.ycombinator.com/item?id=25021180