3 ms·

I wish for a future where we can have more than one concurrent view of the same code. Structure need not be derived from from mere files and newlines and a han

by clarry 7y ago

I wish for a future where we can have more than one concurrent view of the same code. Structure need not be derived from from mere files and newlines and a handful of semantic organizational elements (function, class, module). The current way of doing things forces us to make a compromise between prioritizing the forest over the trees, or vice versa. Programming languages are largely concerned with the trees' bark. But to make good software, you need to see and understand both, so the compromise is always a problem. The solution probably needs large-scale re-imagining of how compilers, languages, version control, and editors/ides work (which also requires one to accept that working with a simple flat-file text editor won't work -- a bitter pill to swallow for someone like me who likes the simplicity of simple text editors). I have some (very vague) ideas, but gosh, how do I find the time to experiment and refine or reject them...

vfinn 7y ago
Future programming languages will be graphical in one way or the other, I think. As you said, the programmer needs to have a clear way of visualizing the big picture. I think this can be achieved without forcing people to go visual. You could have the code on the one hand, and the metadata for the presentation of the code on the other, in a separate file. You could also just hide the graphical metadata for the code view.
- clarry 7y ago
  Separate metadata/markup for presentation + code sounds sounds like a straightforward choice, but I'm concerned that it'll incur a lot of maintenance overhead, and the programmer working with the code still needs to keep it up to date and relevant somehow. Dunno, I feel like it'd feel like code + doxygen boilerplate comments (a pain in the butt if you ask me) but worse. I'm thinking that we need language level support for higher level semantic constructs and relations. Right now code is somewhat analogous to raster graphics or very simple vector graphics. You can construct anything with it, but it is very rigid and there's only so much high level structure that tools can try to infer and dump out of it. (Think call graphs, dependency graphs, flow charts, index of class hierarchies.. all of them somewhat useful for certain purposes, but none of them really good for high level design work or reasoning about systems at a level above the plain code). We could slap some metadata on vectors or raster images but I think that's a far cry from ideal. I think that, with sufficient support from the language, we can provide most of the visual structure for alternate views by simply graphing with help of the semantics that are laid bare in the code. I wouldn't mind some additional hints for presentation, but if we're adding lots of markup and metadata, I think we're going in the wrong direction.
marcus_holmes 7y ago
I love this. Currently working on a file storage system that gets away from folders, and that's hard because everyone has folders hard-wired into their brains because history. Functions shouldn't live in files, for a start. Files are an artefact of storing code in a file-based storage system, and have nothing to do with code architecture. Creating a code editor that stopped working with files and only worked with functions would be interesting as a start on this, I think...
- skohan 7y ago
  File systems aren't without their advantages. One huge advantage is that text files are extremely un-opinionated about how they're used. If my project exists as a tree of directories with text files inside, there are a ton of tools which can operate on them without any knowledge of my program or even programming language. I can open them in vim or my favorite IDE, dump them to the console with cat, manage versions with git and so on. Basically text files are one of the fundamental building blocks of *nix so having my project represented as files means I can leverage decades of tooling. It's not to say that it couldn't work to have a program represented as some kind of a database or API, but that would imply much tighter binding between tools and their storage representation.
  - marcus_holmes 7y ago
    interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools? Can we have a Vim that understands (e.g) scopes natively rather than files?
    - TeMPOraL 7y ago
      It would have to not just understand scopes, but their sequential relationship. In most languages, scopes don't just exist, they are loaded, in a particular order. There are "top-level" effects that happen from loading a piece of code into compiler/runtime until the end. Maybe this is different in purely functional languages (though I suspect not at compilation level).
minxomat 7y ago
All these ideas have been implemented in JetBrains MPS. Terms to look up are structural/projectional editing and language workbenches. Here's a concise demo (although you should read the original paper and the documentation to really grasp this concept): https://youtu.be/pVIywLXDuRo https://youtu.be/pVIywLXDuRo Papers: https://confluence.jetbrains.com/display/MPS/MPS+publications+page https://confluence.jetbrains.com/display/MPS/MPS+publication...
satyrnein 7y ago
https://darklang.com/ https://darklang.com/ appears to share some of those goals.

by clarry 7y ago

vfinn 7y ago

Future programming languages will be graphical in one way or the other, I think. As you said, the programmer needs to have a clear way of visualizing the big picture. I think this can be achieved without forcing people to go visual. You could have the code on the one hand, and the metadata for the presentation of the code on the other, in a separate file. You could also just hide the graphical metadata for the code view.

clarry 7y ago
Separate metadata/markup for presentation + code sounds sounds like a straightforward choice, but I'm concerned that it'll incur a lot of maintenance overhead, and the programmer working with the code still needs to keep it up to date and relevant somehow. Dunno, I feel like it'd feel like code + doxygen boilerplate comments (a pain in the butt if you ask me) but worse. I'm thinking that we need language level support for higher level semantic constructs and relations. Right now code is somewhat analogous to raster graphics or very simple vector graphics. You can construct anything with it, but it is very rigid and there's only so much high level structure that tools can try to infer and dump out of it. (Think call graphs, dependency graphs, flow charts, index of class hierarchies.. all of them somewhat useful for certain purposes, but none of them really good for high level design work or reasoning about systems at a level above the plain code). We could slap some metadata on vectors or raster images but I think that's a far cry from ideal. I think that, with sufficient support from the language, we can provide most of the visual structure for alternate views by simply graphing with help of the semantics that are laid bare in the code. I wouldn't mind some additional hints for presentation, but if we're adding lots of markup and metadata, I think we're going in the wrong direction.

marcus_holmes 7y ago

I love this. Currently working on a file storage system that gets away from folders, and that's hard because everyone has folders hard-wired into their brains because history. Functions shouldn't live in files, for a start. Files are an artefact of storing code in a file-based storage system, and have nothing to do with code architecture. Creating a code editor that stopped working with files and only worked with functions would be interesting as a start on this, I think...

skohan 7y ago
File systems aren't without their advantages. One huge advantage is that text files are extremely un-opinionated about how they're used. If my project exists as a tree of directories with text files inside, there are a ton of tools which can operate on them without any knowledge of my program or even programming language. I can open them in vim or my favorite IDE, dump them to the console with cat, manage versions with git and so on. Basically text files are one of the fundamental building blocks of *nix so having my project represented as files means I can leverage decades of tooling. It's not to say that it couldn't work to have a program represented as some kind of a database or API, but that would imply much tighter binding between tools and their storage representation.
- marcus_holmes 7y ago
  interesting. But if you assume functions don't intrinsically live in files, they just do that because we have a file-based storage system, and that functions actually live in, say, scopes, then what does that do to your tools? Can we have a Vim that understands (e.g) scopes natively rather than files?
  - TeMPOraL 7y ago
    It would have to not just understand scopes, but their sequential relationship. In most languages, scopes don't just exist, they are loaded, in a particular order. There are "top-level" effects that happen from loading a piece of code into compiler/runtime until the end. Maybe this is different in purely functional languages (though I suspect not at compilation level).

minxomat 7y ago

All these ideas have been implemented in JetBrains MPS. Terms to look up are structural/projectional editing and language workbenches. Here's a concise demo (although you should read the original paper and the documentation to really grasp this concept): https://youtu.be/pVIywLXDuRo https://youtu.be/pVIywLXDuRo Papers: https://confluence.jetbrains.com/display/MPS/MPS+publications+page https://confluence.jetbrains.com/display/MPS/MPS+publication...

satyrnein 7y ago

https://darklang.com/ https://darklang.com/ appears to share some of those goals.