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

171–180 of 195 posts

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

#171

Post by thomastjeffery »

rubyn00bie wrote: post #42

Oh yeah; we have/had this-- it is called HTML and none of us got the idea behind it (I certainly didn't); so, instead we re-created the prisons we were, and are, trying to escape. It also is really hard to profit from ONLY meaningful data thus the death of things like RSS feeds. Can't shovel advertisements, trackers, and spyware down someone's throat just sending a nicely formatted HTML table that the client decides…

> Oh yeah; we have/had this

Not quite.

They are still stuck in a browser. The DOM is still largely impossible for users to parse and interact with. Web pages are still separate from each other.

> none of us got the idea behind it (I certainly didn't); so, instead we re-created the prisons we were, and are, trying to escape.

That's true for two reasons.

1. The reason you gave: we made it this way.

2. HTML isn't naturally leading us in a different direction than that.

I would say Emacs is a better implementation, though it still has faults.

Really, there is nothing that truly encapsulates this ideal. It's something that I still have difficulty articulating.

I think the most significant walls we have made are in user interface. We make programs that expect users to interact in a predetermined fashion instead of allowing users to make that decision themselves. In designing these programs, we wall the user away from engineering their own interfaces.

I think the second most significant wall is the floor. Take Emacs for example: Sure, you can alter every variable. You can change the keymap. You can change the fonts. But fundamentally, every variable has a default that the user must confront. There is no Emacs-from-scratch configuration option. This gets especially messy because default variables are organized in a carefully designed structure. They are codependent. It's trivial to make small changes, but significant refactoring requires planned cohesion with what is already there.

This topic is something that is vitally important to software design, and yet we don't even talk about it. We just keep rolling with the status quo until someone breaks down a wall and becomes a hero.

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

#172

Post by thomastjeffery »

I made an analogy in another comment that I think is a really great expression of this problem:

Programs are like houses. They are made of walls.

Traditional UI gives users doorways and windows, but users are not allowed to pass through walls.

Even the most liberal programs that allow users to redecorate or even move walls do not give the user ultimate and immediate freedom.

Say a user wants to make a new room. They can move some walls around and shove the room in the space left over, but where do the doors in that room lead?

In order to make deep refactoring UI changes, the user must undo the careful design that developers gave them.

The ultimate freedom would be for the user to rebuild from scratch, but that's too much work, right?

What if the house was entirely configuration? What if every wall was optional? What if our program was fundamentally just an empty floor with an optional example house built on it?

That's what we almost get with shell commands. That's what we almost get with web browsers. That's what we almost get with Emacs. That's what we almost get with tiling window managers.

I've never seen an ultimate instance of this. I have, however, seen a trend away from it, and that trend is frustrating.

This topic is something that is vitally important to software design, and yet we don't even talk about it. We just keep rolling with the status quo until someone breaks down a wall and becomes a hero.

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

#173

Post by djrobstep »

TeMPOraL wrote: post #151
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…

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 ru…

What is in question is the UX, not the literal code.

Obviously terminal programs are literally programs and COM is literally objects.

However, terminal programs often have a single purpose, along with inputs and outputs that function as a crude interface allowing them them to be combined in a reasonably flexible way by the end user, who can use them to construct functionality of their own.

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

#174

Post by sriku »

TeMPOraL wrote: post #154
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.

I'm familiar with COM and I do think the kind of interoperability you get with open multiple dispatch is of a different character altogether. There has not been any theoretical reason why this has to be true yet, but empirically it has been surprisingly powerful in Julia. I guess Common Lispers would relate to it too.

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

#175

Post by adwn »

artem247 wrote: post #155
adwn wrote: post #114

Earlier quoted context omitted.

> 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 hu…

In what way does Smalltalk embody the concepts underlying biological cells and systems? Note that objects sending messages to other objects has very little to do with that – it would look more like lots of identical objects emitting lots of identical messages into a shared medium, and lots of objects receiving none, some, or many of those messages (a stochastical process) and reacting in a more or less deterministic manner.

Such a system would be hell to develop, debug, and maintain. Which is why we don't design systems that way. Which is exactly my point.

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

#176

Post by theamk »

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…

I disagree. I think one of the big reasons for this is limited functionality of common interfaces that platform provides.

WhatsApp client implements its own photo picker, instead of using system one. Why? So it can add "crop" and "comment" functions. It would be objectively worse for me, the user, if they had stuck to platform features.

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

#177

Post by galaxyLogic »

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

Earlier quoted context omitted.

> 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 fi…

> There were plenty of attempts to make end users program things. LISP machines and ...

I would say Lisp-machines were designed for professional programmers not end-users. First of all they were so expensive that only Bill Gates could afford them :-)

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

#178

Post by galaxyLogic »

valenterry wrote: post #60
djrobstep wrote: post #31

Earlier quoted context omitted.

What's vague and hard to define about adding up some numbers in a table?

The question shows that you have a hard time to understand the complexity of it. Maybe the reason is that you are an experienced developer who deals with all the complexity quite naturally and automatically. So why is this task complex? Well, what happens if there are no numbers in the table to begin with? Is the sum of no numbers a zero or is it supposed to be some error? And are all the numbers supposed to be natur…

> The problem with these questions is not that they are necessarily hard to answer (often they are) but that people don't even know, that they need to be asked in the beginning.

Right. And what makes it even more problematic is that answers to these questions affect what answers are possible to other questions. So it is not the sum of the difficulties of the answer to each question but their product, the combinations of different possible answers.

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

#179

Post by whiw »

A list of requirements to help make the OPs vision a reality might be:-

1. Separation of concerns (ie, make it trivial to separate the Data and the View components from the surrounding html clutter). Currently it can be a pain to extract data from the DOM.

2. Allow the Data component to express arbitrary data shapes, including at least: - 2-D tables - n-dimensional data tables - groups of related tables and schema (for a relational database) - sparse data sets - lists - trees - graphs

A lisp-like representation of data would provide adaptability to arbitrarily shaped data.

3. Make it easy to use:- The webpage coder would write ...lisp-like-data-structure... ...view-code...

If no View-code was provided in the html then a default OS/browser View would be used.

3. Ideally HTML would provide native support for the Data and View primitives. Failing that then it could be provided by a script (hosted on a single website, to ensure consistency of interpretation).

4. Ideally the OS would provide support for the Data and View primitives, in the GUI and in the command line. Failing that then these could be provided as user programs.

5. Encourage webpage developers to use the new and primitives by deprecating ;)

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

#180

Post by jcelerier »

mmphosis wrote: post #168
jcelerier wrote: post #94

Earlier quoted context omitted.

> 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.…

> C++ class hierarchies are not objects.

who cares ?

> Both libraries and class hierarchies are not just jails, but dependency hells.

sounds like you had some severe trauma. I wonder how much better our profession would be if we had code psychiatrists, that would help people move past the bad experiences they had with $LANGUAGE.

> Everything including functions can be abstracted as live data. I want to connect objects live, changing on the fly.

well, you can use puredata or max/msp for that, and then when your program ends up being too slow and clunky because of the lack of optimizations, you can mail me for rewriting it in C++ at a cost :-)

Post reply on HN