4 ms·

These ideas have mileage but as long as the source code is plain text, the way we represent changes is always going to be text based too. Wouldn’t a better sta

These ideas have mileage but as long as the source code is plain text, the way we represent changes is always going to be text based too. Wouldn’t a better starting point be to change the way we represent source code, then let the patch tools follow? Your editor knows exactly what steps you took to make your change. A semantic VCS like you describe sounds very similar to reaching eventual consistency in a distributed data structure by sharing streams of edits between peers. Personally, I’m a firm believer in text. Auto formatting code so that changes are line oriented helps a lot. So does a good culture of namespaces and separation of concerns. Conflicts happen when two people working on different things have to edit the same code. You can dodge that by more carefully structuring your project. There’s a reason why software projects aren’t just single-file piles of symbols. Code is primarily supposed to be human readable, and the more legible the project the better shape it is in for good ole line oriented diffing and patching.

pasc1878 3y ago
Hasn"t that been done 30 years ago - didn"t Envy work on the program structure. But it is Smalltalk so code was not stored as plain text. Now if only Smalltalk had changed with the times, e.g. added typing, used native GUIs and not set itself off in a walled expensive garden.
calgoo 3y ago
I think it’s possible to go to a function level, but you basically need to stop using the file system. We come back to the question of storing code in some sort of db based storage, which can then contain all these tools built in. I can see this type of system being used more and more with the lambda / edge / micro service systems where it simplifies data synchronization. However git / nextBestThing will keep on being used as long as we write code in text files.
- zzzzzzzza 3y ago
  i had been thinking something similar to this would different users have different schemas in their vcs db? would every pull request be a db migration XD?
lloeki 3y ago
Plain text is only storage, I happily posit plain text as storage is not the issue. It's the tooling above that's lacking. From editors to source control, it's all text/buffer/line/character oriented, which does have its benefits. Sure there's syntax highlight, folding, symbol search and whatnot but semantically these tools only superficially understand code itself and certainly don't operate on code, they only pretend to and are fundamentally text editors. We're getting there with LSPs and error-tolerant parsers but they still map back to text for us to interact. Tools like gofmt, black, ruby standard and such already kind of abstract away text as storage: you write code in whatever way and it gets transformed right under your feet. In some way as a dev you already don't care about the text, it gets handled for you, but it still maps back to text because editors can't handle anything else. Similarly LSPs are in my mind quite nerfed because they have to do a whole back and forth to text dance. Vim text objects kind of goes into that direction as well, where you think about higher level constituents than text (arguments, methods, etc). Imagine being able to bind the understanding of LSPs right into semantic Vim language objects without them having to go through text! I dream of an editor where I can open a bunch of functions or classes or namespaces (not files) in buffers that have understanding of the constituents, and it would all map back to files for storage behind the scenes. I believe it doesn't have to go full tilt Smalltalk-like; the Closure conf Overtone demo from years ago is almost there, although not quite.

pasc1878 3y ago

Hasn"t that been done 30 years ago - didn"t Envy work on the program structure. But it is Smalltalk so code was not stored as plain text. Now if only Smalltalk had changed with the times, e.g. added typing, used native GUIs and not set itself off in a walled expensive garden.

calgoo 3y ago

I think it’s possible to go to a function level, but you basically need to stop using the file system. We come back to the question of storing code in some sort of db based storage, which can then contain all these tools built in. I can see this type of system being used more and more with the lambda / edge / micro service systems where it simplifies data synchronization. However git / nextBestThing will keep on being used as long as we write code in text files.

zzzzzzzza 3y ago
i had been thinking something similar to this would different users have different schemas in their vcs db? would every pull request be a db migration XD?

lloeki 3y ago

Plain text is only storage, I happily posit plain text as storage is not the issue. It's the tooling above that's lacking. From editors to source control, it's all text/buffer/line/character oriented, which does have its benefits. Sure there's syntax highlight, folding, symbol search and whatnot but semantically these tools only superficially understand code itself and certainly don't operate on code, they only pretend to and are fundamentally text editors. We're getting there with LSPs and error-tolerant parsers but they still map back to text for us to interact. Tools like gofmt, black, ruby standard and such already kind of abstract away text as storage: you write code in whatever way and it gets transformed right under your feet. In some way as a dev you already don't care about the text, it gets handled for you, but it still maps back to text because editors can't handle anything else. Similarly LSPs are in my mind quite nerfed because they have to do a whole back and forth to text dance. Vim text objects kind of goes into that direction as well, where you think about higher level constituents than text (arguments, methods, etc). Imagine being able to bind the understanding of LSPs right into semantic Vim language objects without them having to go through text! I dream of an editor where I can open a bunch of functions or classes or namespaces (not files) in buffers that have understanding of the constituents, and it would all map back to files for storage behind the scenes. I believe it doesn't have to go full tilt Smalltalk-like; the Closure conf Overtone demo from years ago is almost there, although not quite.