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

21–28 of 28 posts

Re: Gallery of Programmer Interfaces

#21

Post by zokier »

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…

It's not that clear cut. Large portion of programming activity already involves keyboard shortcuts etc rather than straight out typing code. I'd expect any good non-text based code editor to still be fully keyboard driven, or at least as much as current-day editors

Re: Gallery of Programmer Interfaces

#22

Post by tbabb »

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 one reason is self-selection bias: Because all programming languages are text, everyone who is a programmer is necessarily adept, comfortable, and intimately familiar with representing programs as text.

There is a whole other kind of programmer which doesn't exist yet— a visual coder— all of whom are doing something else right now, because there are no tools for them. It takes a large leap of imagination for a text-coder to empathize with these still non-existent visual-coders and make the tool that they need, and a large leap of imagination to envision a complete visual coding system from the ground up which can be used to solve actual problems and compete with the very mature text code tools that are already out there.

In short, "massive amounts of cultural inertia".

Re: Gallery of Programmer Interfaces

#24

Post by curtis »

Some of these interfaces might be really fun to implement, but there are very few of them that I think I'd want to use.

For me, writing code is about the easiest thing I do. Other than identifier completion, I don't need much beyond a basic text editor.

On the other hand, understanding code -- not just exploring it, but understanding it -- is the the hardest thing I have to do, and that's where a good UI could be helpful. I only made a superficial scan, but it didn't really seem like any of these UIs were designed to do that.

I don't really need a map to a code base so much as I need a tool for making my own maps (not just one!) into the codebase as I try to understand it. Or understand at least enough of it to do my current task.

Re: Gallery of Programmer Interfaces

#26

Post by jerf »

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…

I've come to think that one of the other problems non-textual approaches need to solve to win at scale is that they need to somehow get rid of their coordinates. Right now, most of the non-text oriented approaches I see mean that I have to not only understand the same thing I'd have to understand in a textual representation, but I also have the additional complexity of all of my code having coordinates in a 2D space, and then if you start drawing lines on the screen for relationships, additional accidental complexity in the state of the lines too.

The more I think about it, the more I think the people who tend to make criticisms about textual representations and then argue in favor of visual representations are not just wrong, but usually have things actively backwards; almost every criticism they make about text is actually a positive aspect of it. Not having a literal line appear from a call site to what it is calling, for instance, is a net positive, not a problem. I think this is why visual stuff has been bubbling slowly for decades and just never seems to get anywhere the way its advocates hope.

Re: Gallery of Programmer Interfaces

#28

Post by la_barba »

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

Maybe the solution is that we need to get away from general purpose languages for most software. There could be very powerful visual languages that one could develop given a specific domain. I work in pharma and I see a ton of scope for this, especially for the automation of daily work. Scientists might not be the best with C but they could be amazing given a DSL in a domain that they completely grok. I've begun working more and more with Siemens' S7 GRAPH language for sequential process control and its bloody amazing how it lets me visually represent complicated state transitions, loops and conditional logic in a very easy to understand intuitive way. It also lets you establish pre/post invariants, etc. I used to scoff at PLCs thinking I could trivially write than in C, but even ladder logic has humbled me more than a few times.
Post reply on HN