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

61–70 of 195 posts

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

#61

Post by valenterry »

WheelsAtLarge wrote: post #55
yjftsjthsd-h wrote: post #52

Earlier quoted context omitted.

> 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 what blocks to use Isn't that just libraries and APIs? There's friction when interfaces aren't standardized, but it's certainly a good deal of the way there.

Yes, very true, they are a big step forward but standardization is the real key to innovation. It lets society focus its limited resources as oppose to going all over the place looking for a way forward.

That's true - but standardization comes at a cost. If the standard is not good or not good enough (even after some time later) then it hinders progress. That's why even easy to standarise things such AC powercables are changed by some companies (Apple, OnePlus) to improve charging speed, because the standard isn't sufficient.

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

#62

Post by gjvc »

alexashka wrote: post #44

The problem this blog post describes, I've been working on for a few years - it's really not a hard problem per se, it's just a lot of meticulous work. I think that's in general the case - most problems in life are problems of you know what you ought to do, but is it what you want to do? Do you want to spend 5 years to try and solve a problem, with no promise of financial, social or personal reward? Do you want to sa…

a sort of conway's law in reverse, applied to society in general

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

#63

Post by pavlov »

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.

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

#64

Post by pshc »

Tyr42 wrote: post #30
pshc wrote: post #7

Codebases are, in my mind at least, a virtual space. I believe that one day programs will look like factory floors or cities. They will produce and consume physical analogues for values and types, which you can pick up and examine. Want to debug a function? Strap on your VR headset, teleport into its physically reified room and watch the execution. Tinker with the pipeline in real time. I’ve been dreaming about this…

I mean, pay Factorio and you can see it.

Satisfactory (the game) too!

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

#65

Post by pshc »

burrows wrote: post #56
pshc wrote: post #7

Codebases are, in my mind at least, a virtual space. I believe that one day programs will look like factory floors or cities. They will produce and consume physical analogues for values and types, which you can pick up and examine. Want to debug a function? Strap on your VR headset, teleport into its physically reified room and watch the execution. Tinker with the pipeline in real time. I’ve been dreaming about this…

In what way is a debugger not already this? Are you asking for better visualizations?

Yup. Visualizations that harness our brains' spatial memory and reasoning, specifically.

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

#66

Post by skybrian »

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?

Single-user systems are much easier to deal with, but they're just sandboxes that don't do every much.

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

#67

Post by bloaf »

hedora wrote: post #23
orbital-decay wrote: post #21

>Inherent, ubiquitous programmability: Currently, "doing programming" is a segregated activity from mainstream computing - separate software, command lines, specialist knowledge, clunky text-driven interfaces. This must end. Real expressiveness demands that every entity in the interface is inherently programmable - a table of data shouldn't just be a rendered picture of a table of data - it should be a table. Program…

> Almost every attempt at such an environment has failed for a reason. Basic and spreadsheets are notable exceptions. However, they don’t scale to complex programs.

Spreadsheets basically run entire massive companies. What is the standard of complexity which this fails to meet?

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

#68

Post by djrobstep »

catlifeonmars wrote: post #58
djrobstep wrote: post #16

Earlier quoted context omitted.

Author here, yes this is a big problem (the biggest?), as the incentives are all wrong. As I noted in the post: "Often ... apps will have features to integrate with other apps and the wider operating system - but not so much that they become invisible. Instagram still wants you to see its logo, consume its specific content and stay within its ecosystem. Once again, the implementation and architecture are driven by ec…

Obviously economic incentives have an impact on what problems get worked on, but economic incentives can’t reduce the complexity of problems. I think what we have here is a problem of irreducible complexity. The reason that abstractions like the “Image” or “Table” you described one your article are few and far between is because it’s really hard to implement these objects in a way that scales to fit a broad enough se…

You don't really need standardized implementations, or even fully standardized interfaces. What's missing most is any direct interface at all.

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

#69

Post by zinekeller »

catlifeonmars wrote: post #57
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.

Just curious, what (viable) state of the internet fits your definition of “happy”, or at least “not sad”?

For me at least, being able to use whatever software that adheres to the standard. This means that novice users can use a software that specifically targets them, while experienced users can use a swiss-knife program or even write their own program to handle it. For RSS specifically, most news sites do not have RSS now, which means that you need to visit them one-by-one or use an agregator that you can't modify much.

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

#70

Post by orbital-decay »

djrobstep wrote: post #25
orbital-decay wrote: post #21

>Inherent, ubiquitous programmability: Currently, "doing programming" is a segregated activity from mainstream computing - separate software, command lines, specialist knowledge, clunky text-driven interfaces. This must end. Real expressiveness demands that every entity in the interface is inherently programmable - a table of data shouldn't just be a rendered picture of a table of data - it should be a table. Program…

> The problem with programming is not the syntax and other particularities, but inherent complexity of explaining the task to a computer. Not really. A great deal of the the complexity is accidental, not inherent. Take the example from the post of adding up some numbers in a table. The inherent complexity is very low, the complexity comes from all the stuff not inherent to the problem itself.

Programming, in the traditional sense, has to be formal and unambiguous, that's the main issue. The complexity can arise from seemingly nothing. Here's an extreme math counterexample: Fermat's last theorem. Proving it seems easy on the surface because it's so trivially formulated, yet it took centuries for mathematicians to actually do it.

Commoditized programming faces the same problem: many problems seem easy at first, but when you are trying to solve them with your shiny low-entry-barrier interface, you are hitting a fundamental ceiling you never knew existed. There's never been a shortage of unsuspecting newbies trying to parse HTML with regular expressions, as an example.

There were plenty of attempts to make end users program things. LISP machines and Genera (and Emacs, which is IMO the closest existing thing to the "ubiquitous programmability" you propose). BASIC, which was the main user interface for many early personal/home computers. Visual programming environments. Spreadsheets. Some of them survived and are very useful for simple cases, like programming materials visually in Blender, or automating stuff in IFTTT, but all of them suffer from the same issue: [non-AI] computers are too dumb and expect more or less exact instructions. That leaves the complexity on users' shoulders. Once you go Turing complete (and often even without that), syntax or entry barriers don't matter much - you either train for years to be able to formulate the human-generated problem, encode it for a computer, and change it as the need arises, or you hit a wall with a low entry barrier tool.

Programming is easy to learn, sure, there's no reason it should be hard. But it's fundamentally hard to master. And it's not about syntax or high friction interfaces (which can often be more productive for a trained person solving a hard problem, actually).

Post reply on HN