Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

djrobstep.com

Post reply on HN
Print view View original

141–150 of 195 posts

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

#141

Post by anoncake »

vincnetas wrote: post #124
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…

There is a reason why some apps dont use external camera app but take pictures themselves. Security. You want to be sure (as much as possible) that taken picture was real and not provided to intent by "use any picture as cammera output"

If the user wants to provide a "non-real" picture, there is no legitimate reason to stop them.

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

#142

Post by BlueTemplar »

thibran wrote: post #89

I'm thinking about those ideas since years. For me it is strange that it seems for many such a hard concept to grasp, since the advantages are huge and obvious. Today some tasks like mass renaming of files of a certain type require an extra tool for a casual users, which is in most cases not available and the task therefor not doable. This is a pity and wastes a lot of potential/productivity. If programs where things…

This would require standards, and then competitors would eat their nice, fat margins.

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

#143

Post by rakoo »

Cloudef wrote: post #96
rakoo wrote: post #24

Earlier quoted context omitted.

Indeed, it sounds like the author is looking for the UNIX of the 21st century: * Widely reusable meaning: everything behaves like a file. The types of files we can have are defined by specs: an Image can be described as a PNG file, which every process can understand. A table can be a CSV or a SQLite file. A Conversation can be a maildir folder. We might not have the best descriptions of "things" but we do have someth…

The "everything is a file" in UNIX is bit of a lie. And plan 9 went on fixing that. UNIX has many files that aren't actually files but special devices that you access with non-standard interface (mainly ioctl). In plan 9 everything truly is a file and all communication happens with read/write system calls.

I might be uninformed but it seems to be "everything is a file" was more or less true when UNIX was created, and then it evolved outside of the academic garden, especially Linux which was a hobbyist project and never strove to have a cleanly designed, rigorous architecture.

Plan 9 does fix this, and I wish so much it managed to be a dominant OS. So many things seem correct. Maybe it's exactly because it isn't used for real use cases that it can maintain its appearance of good design

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

#144

Post by bantunes »

BlueTemplar wrote: post #138
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…

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.

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

#145

Post by wcoenen »

BlueTemplar wrote: post #136

This is one weird article. What it wants is standards, but the word is never used. What it wants is the Unix philosophy-like micro-programs, that "Do One Thing And Do It Well.", but no mention of that either, except in drive-by disparaging text-driven interfaces that most of these currently use…

The article also made me think about the Unix philosophy of text pipes.

I think Powershell is a step further in that direction, as it it allows you to pipe typed objects between scripts and cmdlets. It's just not clear to me how to extend that idea to a GUI-centric environment like a smartphone.

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

#146

Post by davidkell »

The two places I’ve seen this working best today:

- Open source data science/scientific computing ecosystems. Notably python, where all the libraries interop seamlessly via numpy/pandas/arrow and Jupyter is the visual coding platform. But also R/tidyverse and Julia.

- Modern “no-code” tools, where the visual coding is Notion/Coda/Bubble, interfaces via Zapier/Integromat/Autocode and data models in Airtable/Sheets. (Many of these tools use the word “block” as part of the UX)

And ofc, we take it for granted but the concept of a “file” is the ultimate building block for applications.

In my experience, commercial disincentives aside, the main trade off for this power/flexibility is the complexity. It is intimidating for new users, and hard to design well for because of the combinatorial explosion of interactions. Users need to be strongly motivated to get over this complexity hump - whereas most users, most of the time want a single happy path. Personally I don’t see this as a negative thing - you are essentially coding best practices into the tool.

As an aside, the instant feedback coding in python looks fantastic! Could be a fantastic extension eg for Jupyterlab or VSCode.

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

#147

Post by Nextgrid »

vincnetas wrote: post #124
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…

There is a reason why some apps dont use external camera app but take pictures themselves. Security. You want to be sure (as much as possible) that taken picture was real and not provided to intent by "use any picture as cammera output"

This is essentially DRM and experience tells us that it's not foolproof (a quick search on a piracy website will surface the latest media even though it's heavily DRM'ed).

It's better to just accept this as being impossible than to lure people into a false sense of security (where a minority that does know how to work around the DRM is then given more leverage since the majority believes it's impossible).

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

#148

Post by sriku »

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) , Photoshop should be able to run with the provided capabilities and specialise a custom notion of image as paint on canvas" or illustrator can add "vector drawing" capabilities. Then, depending on how the specialization is done, it would be possible for Instagram to post vector drawings. (Simplifying a bit to illustrate)

This is a common enough pattern between libraries in Julia dedicated to doing very different things and yet cooperate beautifully.

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

#149

Post by icebraining »

vincnetas wrote: post #124
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…

There is a reason why some apps dont use external camera app but take pictures themselves. Security. You want to be sure (as much as possible) that taken picture was real and not provided to intent by "use any picture as cammera output"

Why? I see very few use cases for this requirement. For example, my banking app lets me take a picture for only one purpose: OCR'ing payment info, instead of manually inputting it. But I usually get these as pictures from other people! Heavily reduces the utility of this feature for no good reason.

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

#150

Post by Jugurtha »

davidkell wrote: post #146

The two places I’ve seen this working best today: - Open source data science/scientific computing ecosystems. Notably python, where all the libraries interop seamlessly via numpy/pandas/arrow and Jupyter is the visual coding platform. But also R/tidyverse and Julia. - Modern “no-code” tools, where the visual coding is Notion/Coda/Bubble, interfaces via Zapier/Integromat/Autocode and data models in Airtable/Sheets. (M…

>And ofc, we take it for granted but the concept of a “file” is the ultimate building block for applications.

Yes. I love me some abstraction and building blocks. We constantly think about them because it helps the product be flexible by design in situations we haven't thought about.

Similar abstractions and building blocks or "units of computational thought", although not "perfect": Docker containers, Jupyter notebooks.

>In my experience, commercial disincentives aside, the main trade off for this power/flexibility is the complexity. It is intimidating for new users, and hard to design well for because of the combinatorial explosion of interactions. Users need to be strongly motivated to get over this complexity hump - whereas most users, most of the time want a single happy path. Personally I don’t see this as a negative thing - you are essentially coding best practices into the tool.

I agree. Complexity is not going anywhere, it just is a matter to decide who inherits it and at what level. For example, we're making our machine learning platform[0] after years of custom ML products to help us. We have different profiles: some of them can move between training a neural network, building custom connectors for esoteric data sources, setting up infrastructure, and running cable. Others live and breathe in a notebook who have trouble setting up the proper environment.

What we do is that we build a product that handles most things for the latter profile, but gives the possibility for advanced users to tweak things. One of the reasons we haven't adopted other products is that because they were way too restrictive. Point and click, no API, use custom non time proven abstraction, etc. It's also because in our years of actually shipping machine learning products for paying enterprise customers, the problems we faced in machine learning projects were not for lack of snappy CSS or animations. In other words, the products we had seen were solving non problems for us. We keep an eye out for products made by people who actually shipped ML products, though.

That's one of the reasons we built functionality on top of JupyterLab, like near real-time collaboration, scheduling long-running notebooks, and automatic tracking, instead of wanting to re-create the wheel with "Our Way (TM)".

- [0]: https://iko.ai

Post reply on HN