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

Ask HN: More “experimental” UIs for editing/writing code?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 137 posts

Re: Ask HN: More “experimental” UIs for editing/writing code?

#71

Post by watercooler_guy »

tjchear wrote: post #4

This is not what you're asking for, but I think city as a visual metaphor for certain class of programs could work. Imagine literal factories for manufacturing certain class of objects, highways and roads to represent connections between component buildings, warehouse as databases or storage, office buildings as manager objects, etc and code editing is just moving buildings around (probably hard to do fine grained ed…

That’s a really neat idea, what better way to intuitively understand what a program is doing than a familiar physical environment in front of you.

Reminds me of the esolang Taxi, where you perform computation by giving directions to a taxi driver carrying “passengers” (data) around a city [1]

The city metaphor would probably create a whole new genre of software-art too, where you can optimize for beautiful layout/architecture as well as efficiency.

[1] https://bigzaphod.github.io/Taxi/

Re: Ask HN: More “experimental” UIs for editing/writing code?

#72

Post by rvdginste »

PainfullyNormal wrote: post #10

Have you heard of dion? https://media.handmade-seattle.com/dion-systems/ It's still in the category of "inserting text with the keyboard", but the underlying representation of the "program" isn't raw text. The text is just a user interface for a more complicated representation.

I've been thinking about this before that you can do more when you work with the abstract syntax tree instead of the plain text and I was wondering whether someone actually did something with this. It's really cool to see their work.

I don't know whether they went that far, because I didn't watch the video on the site completely yet, but when you work with the abstract syntax tree, every change becomes a manipulation on that syntax tree. When you think about source control, you can use that concept in there too and store the changes on the syntax tree instead of individual edits. And when you do that, you would get a lot smarter merging, rebasing and conflict resolving.

For example, suppose you have a variable and branch 1 renames that variable and branch 2 introduces a new use of the variable. If you merge branch 1 and 2, or you rebase branch 1 on top of branch 2, you will not get a conflict, but the code will be broken. If you work based on the abstract syntax tree, the merge would automatically do the correct thing.

Another example would be that branch 1 renames the variable to x and branch 2 renames it to y. In that case, you would get a conflict upon merge, but not upon rebase. (for rebase: last committer wins) In the case of the merge, the system would know that the conflict is the rename of a variable to 2 different names, and the user would be able to decide on which name must be used.

I think it's really an idea worth exploring further and could have a big impact on the quality of code and on the efficiency when working in teams.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#73

Post by allday »

This thought crosses my mind a lot too. When we're working with code, we're shaping information into structures and patterns. And so our brains are tasked with translating those structures and patterns into text, making sure that text is written exactly right, and reconciling the difference in the observed output of structures and patterns with the text we've written. What if we could stay at that higher level of abstraction?

My de facto example of this that I keep coming back to is syntax highlighting. It's immensely useful, and yet once you get used to it, the brain is able to skip the (conscious) step of breaking it down e.g. "this text is green so it means it is a function name, so the next text should be blue because they are function parameters", etc. It's more like "okay, green, blue, bunch of stuff between the braces, checks out". Indentation, squiggly line error highlighting, etc. all serve a similar purpose. They rely on our minds' fundamental ability to recognize visual patterns without having to fully process them through our language centers.

So I feel like there is a huge unexplored space there for more efficient and natural programming. VR with 3D representations of code as, I dunno, pipes, gears, something like that? Function declarations in specific colors and then call sites in mixed colors when one function is called from another? Anything to reduce the friction from thought to working software without having to worry about syntax.

This is all very abstract and I probably haven't explained it well, but it's one of those things I can't shake because I'm fairly sure there's something there.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#75

Post by pasc1878 »

sitkack wrote: post #68
efortis wrote: post #24

Here's a nice document with many programming interfaces by Johnathan M. Edwards 1948 Plugboards 1949 Keypunch 1963 Teletype 1970 VT05 1980 Symbolic Lisp 1980 Smalltalk 1986 Boxer 1987 Self 1987 HyperCard 1987 Alice Pascal 1991 Visual Basic 1991 AgentSheets 1994 SK8 1996 Squeak/eToys 2001 Eclipse 2003 Flash MX 2005 Scratch … https://docs.google.com/presentation/d/e/2PACX-1vSPuf3eQ2tlC...

The original refactoring browser/editor was https://en.wikipedia.org/wiki/VisualAge it was later Open Sourced as Eclipse but it predates it by over a decade.

I don't think Eclipse is Open Source Visual Age for Java. Both came from IBM but...

When the IBM rep cam to our company explaining the change he explained what changed and 3 of the points were why I used VAJ and Eclipse did not have them (at the time 10 years later it nearly had them).

VAJ worked with an included JRE that allowed you to edit code as it ran. VAJ included a GUI builder VAJ was organised around code structure and not files e.g. you chose packages and classes and methods and not by files.

VAJ was based on the VA Smalltalk environment.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#76

Post by operator-name »

jlarocco wrote: post #19
SilvanCodes wrote: post #18

Have you heard of the Unison Codebase Manager (ucm)? In Unison ( https://www.unison-lang.org/ ) all code is stored as its AST and then you can 'chat' with ucm asking it for specific type signatures for example. Also the text you write as code really is just an intermediate representation and theoretically ucm could give you all sorts of different views on your code.

So it's Lisp with uglier syntax?

The syntax looks more like haskell to me.

Re: Ask HN: More “experimental” UIs for editing/writing code?

#77

Post by nkuttler »

allday wrote: post #73

This thought crosses my mind a lot too. When we're working with code, we're shaping information into structures and patterns. And so our brains are tasked with translating those structures and patterns into text, making sure that text is written exactly right, and reconciling the difference in the observed output of structures and patterns with the text we've written. What if we could stay at that higher level of abs…

> Anything to reduce the friction from thought to working software without having to worry about syntax.

The syntax complexity will just be moved into a visual layer, it doesn't disappear.

> VR with 3D representations of code as, I dunno, pipes, gears, something like that?

Those 3D representations will just generate some code again, adding another layer of complexity to the debugging process?

Re: Ask HN: More “experimental” UIs for editing/writing code?

#78

Post by samsquire »

I wrote a living document interface. Nowadays it's probably similar to notion.

The idea was you could write code into it and see all the data structures of the code you wrote. There's a screencast and the code is available but broken. It's written in Angular 1. There was a cool feature where you could select different things on the screen for searching for an operation for them to merge them together.

Screenshots of version 1 (Jena fuseki, sparql, d3)

https://camo.githubusercontent.com/3064a94d00812c1373c4eb3b2...

Screenshots of version 2 in this document (angular, couchdb, pouch, paperjs, masonry, ruby, python, javascript) https://github.com/samsquire/liveinterface

Links to screencast https://github.com/samsquire/ideas#4-living-documents

Re: Ask HN: More “experimental” UIs for editing/writing code?

#79

Post by drekipus »

melony wrote: post #15
josephcsible wrote: post #13

Earlier quoted context omitted.

Quoted post unavailable.

If you don't want open source developers to starve, you damn well put your money where your mouth is. High quality open source software is worth paying for. The times when open source software is a niche cottage industry powered by volunteers are long gone. Time is not free, and software does not grow on trees (despite what overprivileged lisp users may claim).

I think lisp users are more for code growing from lists, not trees
Post reply on HN