Haven't read the paper thoroughly yet, looking forward to it. The idea here seems to be very type driven and I think there is something to it.
The general goal reminds me of Unison[0], which takes a different approach. It sees code as kind of a database where the functions are immutable entries. So it is less granular, but likely more semantic.
What I immediately thought of reading your comment is paredit. I know of the Emacs mode[1] and the Calva VSCode plugin[2]. One could work from there, see code evolution as collection of structured editing units.
And then, some languages are extremely terse like APL or Forth. Haven't yet found time to study them, but maybe their representation and semantics are more suitable for this type of thing?
But yeah, just text might just not be the right medium for code in the first place. Not when we start thinking about what code actually is.
We're manipulating structures indirectly by manipulating text. Something is not right here... I know there have been many attempts to move away from it, some are successful but only for specific use-cases and I don't think anything succeeded in the general purpose space. Maybe someone will succeed though. There is no reason to believe otherwise. I feel like it would have to be a very cross disciplinary collaboration. People who make games, databases, art, science. Different perspectives to break out of what we think programming is or should be.
I watched this talk[3] some months ago. One of the cool things is the discussion near the end of the video at around 1h11m: look what Sussman does, when he talks about stratification and code structure - he closes his eyes. What is he seeing there? He explains it sure, but he _sees_ something. That's what the program _is_, not the text, not the bits and bytes. It's a deeply connected, complex, flowing structure - I think they talk about forests in there.
When we program, we manipulate this structure and the text we write is kind of far away from the actual mental model we have. Yes, I see code in my inner eye too, but that is when I think about implementing it, or when I navigate actually written code from memory. But it's not _the thing_.
The general goal reminds me of Unison[0], which takes a different approach. It sees code as kind of a database where the functions are immutable entries. So it is less granular, but likely more semantic.
What I immediately thought of reading your comment is paredit. I know of the Emacs mode[1] and the Calva VSCode plugin[2]. One could work from there, see code evolution as collection of structured editing units.
And then, some languages are extremely terse like APL or Forth. Haven't yet found time to study them, but maybe their representation and semantics are more suitable for this type of thing?
But yeah, just text might just not be the right medium for code in the first place. Not when we start thinking about what code actually is.
We're manipulating structures indirectly by manipulating text. Something is not right here... I know there have been many attempts to move away from it, some are successful but only for specific use-cases and I don't think anything succeeded in the general purpose space. Maybe someone will succeed though. There is no reason to believe otherwise. I feel like it would have to be a very cross disciplinary collaboration. People who make games, databases, art, science. Different perspectives to break out of what we think programming is or should be.
I watched this talk[3] some months ago. One of the cool things is the discussion near the end of the video at around 1h11m: look what Sussman does, when he talks about stratification and code structure - he closes his eyes. What is he seeing there? He explains it sure, but he _sees_ something. That's what the program _is_, not the text, not the bits and bytes. It's a deeply connected, complex, flowing structure - I think they talk about forests in there.
When we program, we manipulate this structure and the text we write is kind of far away from the actual mental model we have. Yes, I see code in my inner eye too, but that is when I think about implementing it, or when I navigate actually written code from memory. But it's not _the thing_.
[0] https://www.unisonweb.org/
[1] https://www.emacswiki.org/emacs/ParEdit
[2] https://calva.io/paredit/
[3] "Stratified Design: A Lisp Tradition" https://www.youtube.com/watch?v=BoGb56k2txk