2 ms·

I do believe that text in files isn't the ideal way of expressing and structuring program instructions. But the friction to get something else established is s

I do believe that text in files isn't the ideal way of expressing and structuring program instructions. But the friction to get something else established is so huge - all tooling would need to change ... unless perhaps one develops a way to translate between the internal format and text.

kmoser 3y ago
You've hit the nail on the head: any code written as a series of text files will lack the overall structure needed to easily navigate, refactor, and perhaps most important of all, render as different "views." For example, if the development environment automatically ingested the code and understood which modules were related to each other, it should be trivial to ask it to sort the functions by name, and/or group them by module, or anything else you can think of. When moving a function to a different module (e.g. moving bar() from foo::bar too baz::bar), the development environment should automatically change all references to foo::bar() to baz::bar(). And this is just the tip of the iceberg of what the development environment should do for you. The problem is, developers have come up with all sorts of clever hacks to do this searching and refactoring, including IDEs which do much of the heavy lifting, but at the end of the day they still fall short of what should be a simple task for the developer. As for additional metadata that would be required to make this work: objections that programmers would be reticent to provide this info are similar to objections to writing good documentation, and my response is: you reap what you sow. If you really want good, structured code, you have to write it, and you have to do so in an environment that accepts such structured data. You can't get blood from a stone. In short, for large, complex projects, our current method of writing code as textfiles is unwieldy. Unfortunately developers' visions are clouded by their hard-earned ability to parse those textfiles, and don't see this as a problem.

kmoser 3y ago

You've hit the nail on the head: any code written as a series of text files will lack the overall structure needed to easily navigate, refactor, and perhaps most important of all, render as different "views." For example, if the development environment automatically ingested the code and understood which modules were related to each other, it should be trivial to ask it to sort the functions by name, and/or group them by module, or anything else you can think of. When moving a function to a different module (e.g. moving bar() from foo::bar too baz::bar), the development environment should automatically change all references to foo::bar() to baz::bar(). And this is just the tip of the iceberg of what the development environment should do for you. The problem is, developers have come up with all sorts of clever hacks to do this searching and refactoring, including IDEs which do much of the heavy lifting, but at the end of the day they still fall short of what should be a simple task for the developer. As for additional metadata that would be required to make this work: objections that programmers would be reticent to provide this info are similar to objections to writing good documentation, and my response is: you reap what you sow. If you really want good, structured code, you have to write it, and you have to do so in an environment that accepts such structured data. You can't get blood from a stone. In short, for large, complex projects, our current method of writing code as textfiles is unwieldy. Unfortunately developers' visions are clouded by their hard-earned ability to parse those textfiles, and don't see this as a problem.