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

Gallery of Programmer Interfaces

drive.google.com

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Gallery of Programmer Interfaces

#11

Post by scroot »

Crinus wrote: post #6
feiss wrote: post #3

Phenomenal compendium, I love it. There always have been a lot of visual approaches to programming, but only a few had a relative success, and always restricted to a very limited domain. There is no competition to raw text editing when dealing with big, general problems and projects (yet). Why? Information density, convenience and fast editing may be the main factors, imho..

I think a more likely reason is keyboards. The main input device we use to interact with computers is a typewriter descendant, optimized for typing text. Mice are flexible but keyboards allow for more complex input. Touch devices (like touchscreens or touchpads) could have helped with more direct manipulation of visual elements but they are always used on very limited (in terms of functionality and form factor) syste…

This must be a big part of it. Another is the kinds of computing environments that the majority of users, developers, and even CS researchers live and work inside of. For there to be truly new UIs the question of "what is symbolic representation in the medium of computing" (that is beyond written text) needs to be taken seriously, and that's just not going to happen when everything is Unix

Re: Gallery of Programmer Interfaces

#13

Post by barrkel »

It's interesting to see how many focus on the nested, recursive representations of expression and statement syntax.

It's understandable for teaching the concepts of syntax to people learning programming for the first time, but I don't think it tackles any of the essential complexity, or what makes programming hard.

It keeps getting reinvented in different guises, often with an air of democratizing coding, taking it out of the hands of the high priests (IT) and into the hands of the people. But what's hard about programming isn't if-statements, loops and assignments. It's incorrect assumptions and broken invariants, usually in runtime data, generated by code which is often distant.

Relatively few interfaces seem to deal with manipulating data rather than code. I think working with data is more likely to be useful and successful. Look at things like Visual Basic - a form designer is effectively manipulating a stored data structure which defines how a runtime data structure is going to get constructed.

Re: Gallery of Programmer Interfaces

#14

Post by pjc50 »

barrkel wrote: post #13

It's interesting to see how many focus on the nested, recursive representations of expression and statement syntax. It's understandable for teaching the concepts of syntax to people learning programming for the first time, but I don't think it tackles any of the essential complexity, or what makes programming hard. It keeps getting reinvented in different guises, often with an air of democratizing coding, taking it o…

> I think working with data is more likely to be useful and successful. Look at things like Visual Basic - a form designer is effectively manipulating a stored data structure which defines how a runtime data structure is going to get constructed.

I think data manipulation interfaces are a good line of reasoning to investigate, but form designers aren't that, they're just for controlling visual placement of controls. The real MVP of dataflow manipulation programming for non-programmers is Excel.

Re: Gallery of Programmer Interfaces

#15

Post by FraKtus »

Is it only my bad memory or some of the dates are wrong:

Tinker 1981, showing a color Macintosh interface.

ProGraph 1983, also using an interface using colors.

Pecan 1984, the year the first Macintosh was released.

Re: Gallery of Programmer Interfaces

#16

Post by barrkel »

pjc50 wrote: post #14
barrkel wrote: post #13

It's interesting to see how many focus on the nested, recursive representations of expression and statement syntax. It's understandable for teaching the concepts of syntax to people learning programming for the first time, but I don't think it tackles any of the essential complexity, or what makes programming hard. It keeps getting reinvented in different guises, often with an air of democratizing coding, taking it o…

> I think working with data is more likely to be useful and successful. Look at things like Visual Basic - a form designer is effectively manipulating a stored data structure which defines how a runtime data structure is going to get constructed. I think data manipulation interfaces are a good line of reasoning to investigate, but form designers aren't that, they're just for controlling visual placement of controls.…

Form designers are editing a data structure. It's not just visual placement of controls; it's the settings on those controls: content, appearance, behaviour, event bindings. And not just controls, also components.

VB and Delphi have components, non-visual controls that live on design surfaces, where their properties can be edited. Things like database connections and table connectors, which can further be linked up with data aware controls. Whole simple form-based CRUD applications can be built without any code at all, merely by wiring together components.

The wiring is data.

Re: Gallery of Programmer Interfaces

#17

Post by Narishma »

FraKtus wrote: post #15

Is it only my bad memory or some of the dates are wrong: Tinker 1981, showing a color Macintosh interface. ProGraph 1983, also using an interface using colors. Pecan 1984, the year the first Macintosh was released.

I think they just picked random screenshots. For example they show Visual Basic with a Windows 95 interface but it predates it by several years.

Re: Gallery of Programmer Interfaces

#18

Post by westoncb »

barrkel wrote: post #13

It's interesting to see how many focus on the nested, recursive representations of expression and statement syntax. It's understandable for teaching the concepts of syntax to people learning programming for the first time, but I don't think it tackles any of the essential complexity, or what makes programming hard. It keeps getting reinvented in different guises, often with an air of democratizing coding, taking it o…

So I wrote a projectional/structure editor[1] that does this sort of nested tiles representation. The reason for it wasn't to teach syntax though, it was to provide users with bigger, easier to interact with UI elements (reasons below).

I wanted the basic elements of the interface to be at a higher level than individual characters. The nested squares style rendering is highlighting grammatical structures in the language—not to teach syntax, but just to indicate where an interactable UI element is, the same way you have rectangular bounds around a button etc.

My motivation for this was to make it easier to manipulate code with lower-precision input devices (e.g. the microsoft kinect / leap motion), but I think there is general interest because a lot of the people writing these editors start from the premise that interacting with the AST directly (as opposed to character sequence) opens up doors, and nested squares is just kinda the most natural/obvious way of rendering an AST. It's also a more natural pairing with the input style of many of these interfaces (e.g. Lamdu[2] or Fructure[3]) which also operate at a higher level than character sequences.

The alternate rendering in itself isn't world-changing, it's the underlying change to directly manipulating a model that then gets rendered (as opposed to parsing the interface—i.e. character sequences—in order to arrive at the model) that's important.

(And even it probably isn't the most important revision to programming tools in general—but that doesn't make it not worth working on if someone's interest is in that direction.)

[1] http://symbolflux.com/projects/tiledtext

[2] https://www.lamdu.org/

[3] https://github.com/disconcision/fructure

Re: Gallery of Programmer Interfaces

#19

Post by jonathanedwards »

phoe-krk wrote: post #7

Previous discussion: https://news.ycombinator.com/item?id=14290909 Copying erikj's comment from over there: ----------------- I think Symbolics' Dynamic Windows and CLIM could be added to this gallery as well, as early examples of presentation-based user interfaces: https://dspace.mit.edu/bitstream/handle/1721.1/41161/AI_WP_2... . ftp://publications.ai.mit.edu/ai-publications/2004/AIM-2004-005.pdf

I actually have an old Genera manual, and added some figures from it: https://docs.google.com/presentation/d/1MD-CgzODFWzdpnYXr8bE...

Re: Gallery of Programmer Interfaces

#20

Post by jonathanedwards »

FraKtus wrote: post #15

Is it only my bad memory or some of the dates are wrong: Tinker 1981, showing a color Macintosh interface. ProGraph 1983, also using an interface using colors. Pecan 1984, the year the first Macintosh was released.

Yeah, the dates are an approximation of when it was developed, but many screenshots come from much later, especially for pre-web tools.
Post reply on HN