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?
It goes without saying, but I’m saying it anyway: if you disagree with me on this, I want to hear it.
Terence Eden@samir have you seen the DRAKON programming language?
https://shkspr.mobi/blog/2023/04/why-arent-there-more-visual-programming-languages-an-ode-to-drakon/
I find it useful for a certain class of algorithm design.
https://shkspr.mobi/blog/2023/04/why-arent-there-more-visual-programming-languages-an-ode-to-drakon/
I find it useful for a certain class of algorithm design.
Why aren't there more visual programming languages? (An ode to DRAKON)
I think the computer programming industry is about to reach a reckoning. No, not because ChatGPT can poorly plagiarise buggy code - but because a whole generation of kids have grown up with Scratch. And they'll want professional tools which have Scratch's level of usability. Hand-coding YAML files is a mug's game; one wrong whitespace and everything is broken. Left a semi-colon off the end of a…
@Edent That’s very cool! I’ll check it out.
Josh Grams@samir lol. On the fediverse, yeah, it goes without saying. Good luck stopping people, in fact. 🙃 😬
But since you asked... I don't know that I've thought about this recently enough to have good thoughts or links off the cuff but... in my head this has come to live in the same place as nuclear fusion: people keep thinking "wouldn't this be cool?!" and people keep being excited and convinced that they've cracked it ...and it's been "just 5 years" away for the last 40 years.
Or maybe a better analogy is Lisp or Smalltalk. Tons of programmers have this attitude that woah, they're so cool, but how many of them actually USE them as their daily driver? For most people, even in their hobby projects, other things outweigh the cool ideas those languages and environments have.
@samir I do think there's cool work that could be done here (and *is* being done, in some cases). But I've come to believe that the majority of the work of turning it into something that the average person would *want* to use on a daily basis is mostly a vast quantity of the kind of "unglamorous" people-facing work that the folks who are excited about the ideas would never in a million years be willing to do (or even see/admit that it *needs* to be done).
@JoshGrams Yup, this is why I’m not actually doing it. 😄
Caoilte O'Connor@samir it wouldn't surprise me if #unisonLang represents code that way internally. It's certainly wrestling with escaping the same local optimum problem.
Logging has some interesting parallels. #DBus famously discarded text for its own proprietary binary format and now you can't read #Linux logs without using its tools.
@caoilte Oh, that’s interesting, I expect it’s very important to be able to convert to text to be able to use text-based tools such as grep.
I’m sure the Unison folk have thought really hard about this, and honestly, I hope they do it. They’re probably the most qualified people to tackle these kinds of problems.
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.
@samir I don't think this proposal is a stable point in a design space — as long as medium and short term storage and communication protocols are both oriented around sequences of bytes, I'd posit that something like a text editor is going to be the most stable way to ensure that data is interpretable by humans in different systems.
also, the system you imagine is almost certainly best prototyped as "encode the graphs as pick-your-own-serialization-format and encode the graph that way."
@simrob I think you’re right. Perhaps making a typed graph transfer format/protocol would be a better starting point!
Irenes (many)this is where we went with our version of it also
which brings you back to the self-describing data problem. the challenge there is that essentially the same thing keeps getting reinvented every five to ten years with superficial changes, which suggests to us that it's solving the wrong problem. we think the right problem is schema formats, the part everyone punts on
@samir @simrob (and it's dependently typed because we've evaluated a lot of schema formats, and basically everyone wants to add idiom features on a case by case basis hoping to keep it small while still meeting everyone's needs, and they universally fail to do either of those things, so we'd rather go straight to Turing-completeness in a deliberate way rather than an accidental one)
@ireneista @simrob There is so much right about this that I don't know where to start.
The only worry I have is that it sounds hard for someone else to create a competing implementation, and I think that we need more of that from our protocols (and our compilers).
Regardless, if you ever get the time and energy to write it up, I would really love to read more about it!
@ireneista @simrob *smashes the Subscribe button*
Niklas Lochschmidt@samir thanks for writing this down. I think in some regards this is what we have been doing at bryter.com, however as a closed platform…
I can recommend googling for “projectional editing”. There are a couple of fun things out there. One of the interesting experiments is https://www.lamdu.org.
See also https://github.com/yairchu/awesome-structure-editors
@Niklas_L Amazing, thanks for sharing! It doesn’t surprise me that per-language approaches have been taken, and I would expect that if someone did this, it would be people who’ve already done it once, but niche.
I was definitely inspired a bit by Darklang.
@samir I definitely share the love for darklang-classic💜
I find it sad, that they turned their back on their editor. I don’t quite understand where they are now going with darklang, but this broke my programmer heart a little:
From https://blog.darklang.com/gpt/
“…a non-freeform editing experience that our users have rated somewhere between "Ok I guess" and "probably the worst part of Darklang”
😭
Darklang is going all-in on AI
Like an aging rock star making a final stab at glory, I'm delighted to announce that Darklang is going all in on AI/GPT. As everyone knows, the folks over at OpenAI produced a magic box that writes code. And it even produces quite good code – not perfect, not by
@Niklas_L It's a whole new team now, isn't it? Makes me sad that it didn't work out. I agree that their editor was a pain but I think it was a pain in the right direction.
@samir oh - well we had a version of this idea some years ago and got it into a pretty coherent form, but
we had it in a manic episode, and to be something people would be willing to use, it would need to build out its own equivalents of all current development tooling
@ireneista Very cool!
I agree. This isn’t the 1980s any more, and we’re past the point that one person can build an operating system. And this is a large chunk of an operating system.
This is why I’m not even trying. But if people were willing to try with me, and I trusted them, I might change my mind.
(Unrelated: I am working on another pair of “terrible idea” articles and if you don’t mind, I’d like you to review them once they’re drafted.)
@samir oh yes please, yes we'd definitely like that!
@samir and that makes sense. maybe someday we'll feel up to trying to build our thing again, now that we understand the use of unification in type checking better, and now that Rust solves the ABI challenges we ran into. if that happens, we'll try to remember to loop you in
Tom Carlson@samir I think you'd enjoy CSP (occam-pi!), if you want zoomable views on a program...
Editors that work on an AST and happen to render text, or graphs, sounds fun though :)
@twigathy I definitely would enjoy learning more about this stuff. Do you have any good places to start?
@samir It is, unfortunately, quite thoroughly link-rotted, but https://www.cs.kent.ac.uk/projects/ofa/kroc/#occampi has some places to start. Think go before go was a thing, or erlang but with blocking channels....
The part about it being "zoomable" - basically if you define a process with some inputs and outputs, and then glue it together with a few others, you can treat the whole thing as one black-box with some ins and outs and forget about its internals.
Go is, probably, the closest modern thing to it.
@twigathy Aha, I get you now! This is the best thing about proofs (I feel the same way about dependently-typed programming). The more information you can convey in a signature or type, the less you need to look inside.
I'm surprised you say that Go is close to it, though; is this because of culture? I'm sure that Rob Pike shouting “don't do anything clever" every time you open a .go file helps.
@samir More the channels / communicating processes than anything :)
I bet if you could treat blocks of your AST-program as a black box (Thanks to the mysteries of CSP), it would make reading the whole thing way easier!
alcinnz@samir Exactly the sort of things I like to read, & to write!