3 ms·
I think the whole notion of programming language as pure text and even using "files" as a unit is veering towards obsoletion. We do it that way because that's t
by mhomde 10y ago
I think the whole notion of programming language as pure text and even using "files" as a unit is veering towards obsoletion. We do it that way because that's the way it's always been done, but I can see plenty of cases where an IDE that uses a more hybrid graphical approach would be beneficial, and we wouldn't have arguments like this :)
- tmzt 10y agoI feel like WASM could be a first step in that, a binary AST/graph-like format with a preferred textual representation. It even has a bidirectional codec.
- Klathmon 10y agoWhile I agree in some senses, i'm terrified of this idea in others. A business-basic style language i work with (second time i've talked about it in a few days... it's weird) saves it's files in a strange not-compiled-but-not-plaintext format that only it can read. That means you can't use your VCS of choice, you can't use your favorite editor, you can't even grep through the codebase to find where a variable name is used. Technically you could write something to get it working in a more "normal" editor, but that is a path I don't want to run down. Ignoring encoding, text is about as accessible as it gets. You can always layer more tooling on top of it, but you can't take it away from a non-text representation easily. Personally I like the way that the go team handles it. Source files are "plaintext" (again, ignoring encodings for the sake of discussion), but there is one (and only one) canonical format for the layout of the code, and a tool which will apply it. Then like you said, you can have IDEs which can layer more visual representations on top of that if needed, and there is a chance that some people could program without actually seeing the "plaintext" source code.