[clarry]

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...

[marcus_holmes]

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]

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]

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?

[skohan]

> Can we have a Vim that understands (e.g) scopes natively rather than files?

Sure we can have a vim that does that. But as I say, it would require tighter binding between the tooling and the code representation.

Right now vim only has to understand code as lines of text separated by spaces, newlines, and tabs. The semantics of that code are the business of the build system and the compiler. The same goes for git. As a result, tools like git and vim can operate on code of any language which is represented as text. That could be an popular language like Java or Go, or some weird experimental language you dream up yourself.

If, as you suggest, the storage representation of the language were tied to the semantics of the language, rather than some external format, then all the tools need to have a deeper understanding of the language itself in order to operate on that storage.

You could try to make it general: i.e. design an organizational structure based on "scopes" which should apply to all languages, but then what if a language comes along which doesn't fit neatly into the "scopes" paradigm? Now you put yourself into a position where you might be making language design decisions which are based on what's possible with the tooling, rather than what's the best possible choice for the language?

Decoupling the storage method from the semantics of the language obviates these problems.

[marcus_holmes]

thanks for the answer, that's interesting.

We do have this to a certain extent now, though - file scope is a thing in some languages.

I'll give up my plan to write a neovim plugin for scope management, though ;)

[TeMPOraL]

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]

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

Papers: https://confluence.jetbrains.com/display/MPS/MPS+publication...

[vfinn]

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]

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.

[satyrnein]

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