undefined | Better HN

0 pointssolarkraft3y ago0 comments

Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text.

The editor I'm imagining looks and works a lot like your typical code view, but has a better understanding of the semantics and makes things there are keyboard shortcuts for more visible. From the top of my head: First-class code folding and commenting and actions primarily on blocks rather than lines. e.g. if you disable ("comment out") an if-statement, either disable the whole block or the wrapping of the inside code with the condition. It's very rare that you want to do something in between and in textually based languages this action is much harder than it needs to be without producing a syntax error.

An important part of GUI design is to avoid the possibility for invalid states, but text-based code editing in its current form produces a lot of them, totally unnecessarily and annoyingly so, in my opinion.

I'm sure that tools with features like this already exist, but they're certainly not popular.

0 comments

nuancebydefault3y ago

There is a big problem with graphical programming: it is very hard to diff graphs in a graphical way. How can you even give review comments on changes? How would an automatic merge work? Also, the benefit of graphic representation of an algorithm is that it gives an overview that is easier to understand. But the whole graph with the real details, is just harder to understand. But the details are necessary, they make simplistic software smarter and better.

derefr3y ago

You can do all that at the text level, if it makes the tooling easier; the tooling would just be operating on a canonically-chosen textual projective representation of graphical code (think: `go fmt`, but as a FUSE mount!), rather than against canonically textual code.

Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents.

As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even.

But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.

shakow3y ago

Honestly, I'm under the impression that you have basically just reinvented Lisp ;)

Or any homoiconic language.

solarkraftOP3y ago

You're right: The tooling ecosystem for text-based programming is already very mature, which is why I wouldn't want to replace it. Current programming languages are stored as text anyway (trying to replace an entire established ecosystem without any steps in between doesn't really work, see Microsoft's constant failures attempting to bundle new things).

That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.

__MatrixMan__3y ago

Sounds like emacs paredit mode. I tried to learn it, but in the end I waved the white flag and went back to vimming through invalid states to achieve the next valid one.

derefr3y ago

In other words, text should be a projective UX for modifying an underlying graphical model; not a canonical storage format for code.

solarkraftOP3y ago

I'd go exactly the other way around since every programming tool under the sun already knows how to deal with text.

Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.

derefr3y ago

The problem is that there's always a valid textual projection for any graph, but there isn't always a valid graphical projection for any text.

Think like: your syntax highlighter has no idea what your code when you're in the middle of typing, because once you type an opening parenthesis without yet having typed a closing one, your code no longer has any possible valid parse.

Ideally, you shouldn't be able to modify the text in ways that don't represent an atomic graphical operation in the first place. But if you enforce that, you can't really say that the textual representation is the canonical one. It's just a storage projection.

j / k navigate · click thread line to collapse

0 pointssolarkraft3y ago0 comments

Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text.

I'm sure that tools with features like this already exist, but they're certainly not popular.

0 comments

nuancebydefault3y ago

derefr3y ago

Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents.

But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.

shakow3y ago

Honestly, I'm under the impression that you have basically just reinvented Lisp ;)

Or any homoiconic language.

solarkraftOP3y ago

__MatrixMan__3y ago

Sounds like emacs paredit mode. I tried to learn it, but in the end I waved the white flag and went back to vimming through invalid states to achieve the next valid one.

derefr3y ago

In other words, text should be a projective UX for modifying an underlying graphical model; not a canonical storage format for code.

solarkraftOP3y ago

I'd go exactly the other way around since every programming tool under the sun already knows how to deal with text.

derefr3y ago

The problem is that there's always a valid textual projection for any graph, but there isn't always a valid graphical projection for any text.

j / k navigate · click thread line to collapse