4 ms·

How can it be that we are still using plain text files for editing code? Wouldn't the grass be greener if a variable were stored as a unique key, making refact

by smokel 3y ago

How can it be that we are still using plain text files for editing code? Wouldn't the grass be greener if a variable were stored as a unique key, making refactoring trivial? Wouldn't the birds sing louder if formatting were just a view on the underlying data? And wouldn't the sun shine really brightly if diffs were to operate directly on the abstract syntax tree? I fear that this has to do with the great problem of interoperability, and of people not always wanting to work together. What would be a constructive way to coordinate ourselves out of this silliness?

zakary 3y ago
Those do sound like good ideas. Why don’t you try making a proof of concept? I’d definitely give it a go
PlunderBunny 3y ago
Not to mention that comments could point to bits of code without being in the code. We could show them to the user like tooltips (or like the sweet sweet balloon help from macOS Classic - how I miss it so much!)
suralind 3y ago
You may be interested in difftastic for doing diffs based on the AST. One problem with this approach is that when you have a lot of changes (tens of lines, maybe hundreds), it gets slow. The tool is great thou, and is my default diffing tool.
- eviks 3y ago
  Great potential tool especially when it adds structured data output for easier integration with other tools
- erik_seaberg 3y ago
  We need a way to not break the AST when we extend the language.
OkayPhysicist 3y ago
We're in a very, very strong local maxima with plain text source code. In order for a rich-data source language to work you'd need to implement, competitively with what we have for text, the language itself (which is already a hard sell, look at how difficult it is for even phenomenal languages to gain a foothold) including built-in macro and codegen systems, a compiler, at least one fully-featured editor, complete with linting and code suggestion and search and an input mechanism competitive with just typing out text, possibly more than one to support the wide range of opinions about editors ranging from IDEs to Vim, source control integrated with means for sharing and collaborating on said code, and every other convenience you get for free from choosing plain text. Basically, you need to sit down and build the greatest programming language ever conceived, complete with a world class ecosystem, and then convince people that this is truly a revolution software development, and you probably won't make a dime off it because proprietary programming languages are evil. Good luck?
jdougan 3y ago
Look up "Intentional Programming", but watch out for patents.
PaulDavisThe1st 3y ago
It's not about "not always wanting to work together". It's about "i want to be able to pick the tools i use", which in turn means "the underlying data we operate on needs to use a format/storage mechanism that any reasonable candidate for a tool can use" And the answer to that quandry is: plain text files.
reductum 3y ago
Here's an effort that explores a non textual format for code and tooling: https://dion.systems/gallery.html https://dion.systems/gallery.html

by smokel 3y ago

zakary 3y ago

Those do sound like good ideas. Why don’t you try making a proof of concept? I’d definitely give it a go

PlunderBunny 3y ago

Not to mention that comments could point to bits of code without being in the code. We could show them to the user like tooltips (or like the sweet sweet balloon help from macOS Classic - how I miss it so much!)

suralind 3y ago

You may be interested in difftastic for doing diffs based on the AST. One problem with this approach is that when you have a lot of changes (tens of lines, maybe hundreds), it gets slow. The tool is great thou, and is my default diffing tool.

eviks 3y ago
Great potential tool especially when it adds structured data output for easier integration with other tools
erik_seaberg 3y ago
We need a way to not break the AST when we extend the language.

OkayPhysicist 3y ago

We're in a very, very strong local maxima with plain text source code. In order for a rich-data source language to work you'd need to implement, competitively with what we have for text, the language itself (which is already a hard sell, look at how difficult it is for even phenomenal languages to gain a foothold) including built-in macro and codegen systems, a compiler, at least one fully-featured editor, complete with linting and code suggestion and search and an input mechanism competitive with just typing out text, possibly more than one to support the wide range of opinions about editors ranging from IDEs to Vim, source control integrated with means for sharing and collaborating on said code, and every other convenience you get for free from choosing plain text. Basically, you need to sit down and build the greatest programming language ever conceived, complete with a world class ecosystem, and then convince people that this is truly a revolution software development, and you probably won't make a dime off it because proprietary programming languages are evil. Good luck?

jdougan 3y ago

Look up "Intentional Programming", but watch out for patents.

PaulDavisThe1st 3y ago

It's not about "not always wanting to work together". It's about "i want to be able to pick the tools i use", which in turn means "the underlying data we operate on needs to use a format/storage mechanism that any reasonable candidate for a tool can use" And the answer to that quandry is: plain text files.

reductum 3y ago

Here's an effort that explores a non textual format for code and tooling: https://dion.systems/gallery.html https://dion.systems/gallery.html