In fact I was thinking of writing a blog post about it along the lines of "The plain-text tragedy".
A program is so much more than a flat collection of lines of text stored on a filesystem.
Our tools force us to "reduce" a program and dumb it down to a bunch of flat files.
This in turn increases the cost of representing information (syntax clutter).
It also adds cognitive overhead for naming things and so on.
As a result we get ourselves into a fight with the compiler. On one hand we want to give it as much information as possible so it can help us solve the problem.
On the other hand we don't want to overwhelm ourselves so we awkwardly compromise somewhere in between (terse syntax, short weird variable names, "def" for define "fn" for function, symbols and so on).
As a result, and believe me I could write a book of rants about this, what we call "IDE" is anything but integrated.
Imagine an editor that allowed you to easily view and modify "objects" in your programs.
Instead of the project tree representing the files on a filesystem it would be representing components of your project.
You could view a function, select it in the editor and right click on its name and click "Write documentation", or "View entities calling this function", "View tests involving this function", "View authors".
In a way similar to, for example, how stored procedures are stored as objects in a database that you can fiddle around with.
And you could have custom attributes attached to these objects. You could tag them with domain-specific stuff.
Imagine the possibilities for version control. If the units of our programs where tracked and edited as first-class-citizen objects in a smart database you would automatically get "git on steroids".
We already "have" some of this stuff but they are not integrated. We first throw away information then come up with parsers that try to make sense of it again like fancy auto-complete intellisense stuff. As a result they become expensive to write and maintain and they become fragile and unreliable. You can't trust them blindly because their accuracy varies wildly. Good luck getting intelligent intellisense in a large project with dynamic languages and transpilers and so on.
We need a development environment that is not hostile towards the humans. It should actively encourage the programmer to provide and specify things about the domain.
We need programming languages that allow and encourage the programmer to provide information. The flat-file ASCII syntax that we are so used to punishes that.
In the "real world" there's so much meta-data associated to each object/entity/unit of the program.
Consider a simple function that adds two numbers together.
While from a mathematical standpoint it's nice to be able to write "function add(a, b) { return a + b; }". From a industrial real-world team-effort software engineering point of view that is incomplete.
Ideally we would want documentation (purpose, arguments, return value, etc), tests, history/version-control and some more context-specific things such as logging that can be turned on-off depending on the context.
We need languages that recognise these concepts and editors that allow us to keep these things in a way that doesn't get reduced down to meaningless text (like documentation crammed in comments that later needs to be pulled out and parsed awkwardly).
If we don't "throw away" the information suddenly so much of the stuff that we work so hard to do today becomes available for free (such as much more accurate documentation that stays up to date with the project, version control that operates at the program level not lines of text).
You could "tag" the components of your program with various attributes.
Then your IDE could auto-generate a report that says "Hey 57.2% of your functions related to authentication currently do not have a test case associated with them. Would you like to create a test case for checkUserLogin function now? click here".
As I said right now we have a lot of this stuff but they are not integrated and fall apart easily, they rely on fragile mechanisms to keep them accurate so you can never let your guard down and trust what you see on the screen you have to actively fight to keep things in sync with each other and so on.