Live data from Hacker News

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

djrobstep.com

111–120 of 195 posts

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

#111

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…

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 because things like UI, when you click the embedded document, what should happen? How much of photoshop's ui should be shown vs Word's (the outer app). It was also a nightmare because unless every user had the exact same apps on the exact same version nothing worked.

Your embedded photo uses filter XYZ but that's only in version 7+ of whatever app edited it, etc...

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

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

#112
World is moving in the opposite direction. Reality check:

* it would be nice if we could fix own device.

* it would be nice if we could install own software.

* it would be nice if we could fix own software.

* it would be nice if we could combine programs.

* it would be nice if data was not tied to application.

Most of the users could not utilize their freedoms. UNIX users could create and share programs, glue them with pipelines, beyond "user" level now.

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

#113

This is a very old-school way of thinking, without any mention of privacy or how to share data safely between different users. As soon as you have multiple users, especially when they don't trust each other, things get much more complicated. Should you really be able to do anything you like with your bank account or DMV record? And do you really want the people you interact with to download all the photos you share?…

There's prior art for all of that, including object and method-level security, in Microsoft's Distributed COM (DCOM). It can be made to work.

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

#114

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 falls apart when confronted with the messy reality of the real world and actual code. That's why you see a lot of those posts, and never anything that goes significantly beyond some toy examples, if at all. Compare the author's misconception that there's little inherent complexity in summing a range of cells in a spreadsheet [1], an idea that won't be entertained for long if you actually implement a general-purpose spreadsheet application.

@djrobstep: Sorry for the harsh words. I've heard too many of those visionary ideas (including my own), and have never seen them amount to anything (see also Alan Kay's vision of software inspired by biological cells and systems – lots of talk, no non-trivial proofs of concept).

I would be delighted to be proven wrong, so please don't let this post bring you down. Start building! If you succeed, feel free to rub it under my nose :-)

[1] https://news.ycombinator.com/item?id=25020363

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

#115
post #85
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.

Windows 95, with OLE, which became ActiveX, which is pretty isomorphic to OpenDoc.

There's also the wider Component Object Model (COM), which does pretty much everything the author of this article wants, and then some more (e.g. remote objects with network transparency, deep security), and it all works within Windows to this day - but, for some reason, app developers seem to avoid it like fire.

I blame COM being a bit annoying to use on developer side, and economic incentives mentioned.

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

#116

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…

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…

Not even mentioning the insane amount of security issues with OLE components.

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

#117

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…

Exactly - for example, resizing photos. Imagine a resizer object, that could be used: - to implement resizing in various interfaces for image objects - in a script (think unix pipes but operating over real image objects, not streams of bytes) - wired up to various events and data sources for automation (when my aunt emails me a picture, resize it and put it in this folder) The resizer wouldn't be hidden behind some a…

One of the big problems I've seen with multi-vendor systems that co-operate is if something didn't work. It was never clear where the problem was because the system incorporated multiple products from multiple vendors. So if your resizer object didn't work for some images after upgrading Photoshop, but it used to in the old version, how do you get that fixed?

In a single-vendor program, it's clearly a bug in the program and you can hand it back to the vendor to fix it. When multiple vendors are involved, it gets way more complicated. Each has a tendency to blame the other, and not take responsibility for the problem. Each will claim that they are coding to the interface specification. And they might be, it's just that the specification isn't tight enough to make all interactions bulletproof.

I don't really have a solution (apart from "write a really, really, tight interface. No, tighter than that"), but I've seen the problem enough to be skeptical that we can have this.

edit: I should add that I wish we could have this.

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

#118

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…

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 are both surmountable problems.

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

#119

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…

Yes, open source sounds like the right place for ideas like this, for the reasons you mention.

Consider Emacs, whose hundreds of extensions give you this mix-and-match setup, or something similar to it.

I think I might really like working with a system that works in this way, with a bit from here, a bit from there -- but I'd want access to the code, because it would take a lot of tweaking to make things nice.

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

#120

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…

...and you've just turned Phtoshop into a slightly worse version of Gimp. Congratulations. Without adjustment layers and other non-destructive editing features, Photoshop becomes a whole lot less useful as a professional tool.
Post reply on HN