4 ms·

Explanation? You could put code elsewhere than in flat files? Elsewhere that is neither VBA nor PLSQL ;)? I'm interested. Otoh, if you're going to suggest bina

by aragot 13y ago

Explanation? You could put code elsewhere than in flat files? Elsewhere that is neither VBA nor PLSQL ;)? I'm interested. Otoh, if you're going to suggest binary structures, I wont be able to approve you if they're not easy to manage in Git.

hackinthebochs 13y ago
Roughly it would be some sort of structured text, markup that represents the structure of the code rather than having a flat text file which then requires parsing to reconstruct structure. There are a couple of motivations here: structured representation allows editors to much more freely handle custom visual representations. Debates about tabs, spaces, braces, semicolons, parenthesis, etc etc are painfully outdated. These simply become properties of your chosen visual representation. It also allows more meaningful transforms without requiring a compilation pass, as a meaningful intermediate language is already present. This would have a few benefits: semantic text highlighting, straightforward semantic changeset merging, enhanced error highlighting and more semantic error detection (if I insert a line of code somewhere, the error is readily marked as the inserted line as the surrounding code is still semantically valid), sharing the semantic representation between IDE plugins. I'm sure this is just scratching the surface. I'm reminded of the project I recall reading about from steve yeggie regarding a language agnostic IDE framework (whatever happened to that anyways?). A language agnostic, semantically rich file format would allow entire classes of transforms to apply across all languages that could be marked up by the language agnostic file format. There are so many possibilities here, and yet a non-trivial amount of programmers are still anchored by the supposed benefits of editing code from the console! Programmers should be the first to be looking forward rather than being tied down to the past.
- aragot 13y ago
  I thought you were going to suggest something crazy and imaginative issued from Big Data, like introduce some concept of Big Code, where you'd map-reduce your execution path, have non-consistent executions spread over thousands of servers, with the explicit target of singularity ;) The option you suggest could have been done since long and it hasn't: I'm inclined to wonder why. Probably text-file editing has reached the good-enough level where we've got enough tooling to cope with the drawbacks, and the basics of open source is, it has to be the most urgent solution for the one who takes the initiative.

by aragot 13y ago

hackinthebochs 13y ago

Roughly it would be some sort of structured text, markup that represents the structure of the code rather than having a flat text file which then requires parsing to reconstruct structure. There are a couple of motivations here: structured representation allows editors to much more freely handle custom visual representations. Debates about tabs, spaces, braces, semicolons, parenthesis, etc etc are painfully outdated. These simply become properties of your chosen visual representation. It also allows more meaningful transforms without requiring a compilation pass, as a meaningful intermediate language is already present. This would have a few benefits: semantic text highlighting, straightforward semantic changeset merging, enhanced error highlighting and more semantic error detection (if I insert a line of code somewhere, the error is readily marked as the inserted line as the surrounding code is still semantically valid), sharing the semantic representation between IDE plugins. I'm sure this is just scratching the surface. I'm reminded of the project I recall reading about from steve yeggie regarding a language agnostic IDE framework (whatever happened to that anyways?). A language agnostic, semantically rich file format would allow entire classes of transforms to apply across all languages that could be marked up by the language agnostic file format. There are so many possibilities here, and yet a non-trivial amount of programmers are still anchored by the supposed benefits of editing code from the console! Programmers should be the first to be looking forward rather than being tied down to the past.

aragot 13y ago
I thought you were going to suggest something crazy and imaginative issued from Big Data, like introduce some concept of Big Code, where you'd map-reduce your execution path, have non-consistent executions spread over thousands of servers, with the explicit target of singularity ;) The option you suggest could have been done since long and it hasn't: I'm inclined to wonder why. Probably text-file editing has reached the good-enough level where we've got enough tooling to cope with the drawbacks, and the basics of open source is, it has to be the most urgent solution for the one who takes the initiative.