While 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

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