samir, a terminally deprecated methodAn idea that may or may not be terrible, written down so I can get it out of my head and into someone who can do something about it.
What if we started from scratch with code represented as graphs, not text?
Henrik Jernevad@samir I think the ideas are very interesting!
To me everything on the "computer side" of that graphs seems "easy". We have a lot of graph algorithms to play with. That is the kind of stuff computer scientists would love to work on. But what would an effective UI for humans look like?
An AST for a text-based language is typically much harder to work with as a human. The text representation is more condensed and "human-like".
@samir Perhaps we should need to move to something CAD/3D-like where you cannot truly see the full object at any time. You can only see some projection. On the other hand, you can choose the viewing angle as it fits the current need. You can display it as a wireframe or with textures. And so on.
@henrikjernevad I love the way you think. I would be quite happy with editing as text, manipulating as a graph (like we did in the good old days with Eclipse), but I really hope someone cracks this tree visualisation problem one day.
Tom Renner@samir @henrikjernevad
Can you give me an example of what you could do in Eclipse that fell under "manipulating as a graph"?
I've had a (less-well-articulated) version of this idea before, but I always get stuck on what the UI would look like to the end user.
@trenner @henrikjernevad I mean the refactoring tools were way ahead of the time. David Green even built a plug-in which exposed a JavaScript interface to the refactoring API, so you could write custom refactoring operations. These were all based on the code-as-semantic-graph, not code-as-text.
@samir @henrikjernevad ooh refactoring API… yeah ok I want that
I find the CAD example really interesting -- one of my friends is a chartered MechEng who is now working on AI tooling to help industry.
His take on CAD is that the data format it encodes could be manipulated much more effectively _without_ the UI it currently uses. The UI is only that way because it matches to the old draftsmanship methods, and so was an onboarding mechanism for MechEngs to digital design.
It tickles me that it's an example we look at from the CS world as a more intuitive and powerful way of working with digital data, but within his field it's an archaic throwback to manual methods that he'd like to optimise away!
@samir Also a more minor thing, but I'm not sure I think "Autoformatters become unnecessary." Why wouldn't you need an auto layout tool for the graph? Or at least for a particular (persisted?) view of it. And most formatters lean into linting and bug detection. I suspect you would need to lint your graph too.
@henrikjernevad Agreed, it’s the concept of auto-formatting on save that goes away, not the tech.
Rob@samir @henrikjernevad still entirely reasonable that I'd want to manipulate a graph to the "standardized" format on save the same way that autoformatters do
@simrob @henrikjernevad I think that would just be the only format. Autoformatters don’t (shouldn’t) modify the syntax graph.