Multiple different views and representations at every level - e.g. syntactic (coding to AST nodes, not characters), structural (imagine having editable class/module outline), semantic (editable views optimized for specific abstractions that allow you to e.g. edit anything resembling a state machine in a state-machine-specific view).
Views that give you a vertical slice though code, auto-inlining function calls when you need it, allowing you read and edit a large block of code, and propagating changes to their respective source locations - this is the solution for the "lots of tiny functions vs. few large ones" "clean code" pseudo-problem.
Views that let you control focus. No more constant dealing with exceptions vs. Result<T, E>, 50 shades of async, or how to mix logging into it all - problems to which modern solution seems to be all kinds of monadic bullshit that makes code completely unreadable, unless the language itself gives you some arcane syntax and semantics to hide it all. Instead, have your IDE hide all the things you don't care about - aka. cross-cutting concerns - from your view.
For example, are you working on the business logic, and focusing on what the code is trying to achieve, aka. the golden/success path? Have your IDE hide all error handling for you. Turn all the Result<T, E> return types into just T, making it look as if the code was using exception handling (and doing the handling somewhere else). Then do some vertical-slice auto-inlining to make a specific functionality more apparent. Too noisy with logging code? Turn display of that off. Conversely, if you're interested in error propagation, turn display of all the business code off.
(Think of it as Aspect-Oriented Programming on steroids, in an interactive form.)
This and much, much, more. It starts with a simple idea though: stop thinking in terms of source code as text in files. Start looking at it as semantic units (classes, functions, statements, expressions) in a database of some kind. Instead of opening a file and editing its text, you would query the database to get an abstract code graph, and feed it to a view that renders it the way you need it. "SELECT Foo Bar from Classes, JOIN Fields, JOIN Methods", feed it to an editable outline view. "SELECT" whatever else you care about, feed it through some transformer, to a different custom view. Edit it, and have it automatically apply changes/"refactorings" to affected code.
And yes, editing raw plaintext is something that's often very efficient and we have well-optimized tools for this. But this doesn't mean the plaintext in question has to correspond 1:1 with source code. Instead, you could have the class/module outline view be editable plaintext, so you could regex-replace half of it in 5 seconds, and then press a button, and it would rename and move methods and classes across the codebase, making it conform to your edited outline. Basically what dired mode does to filesystem in Emacs.
> This sounds like it would enable more complex systems. Is that the goal?
Enabling more complex systems, making it much easier and faster to create safe, stable and efficient systems at current complexity levels - both are really the same goal. Making current complexity level easier to deal with also means you can increase complexity level to the point the work is as difficult as it was before. Your favorite cake suddenly costing half as much means you can save half the cost, or... just buy two.
> The skeptic in me thinks these are fancy bandaids for failure to keep complexity under control.
To me, most of the recent programming language trends are such fancy bandaids. You can't optimize for every possible concern simultaneously in a single plaintext format, but $deity, people try. That's how you get special syntax for Result<T, E> handling (e.g. ?, ?!), or increasingly impenetrable abstractions at the intersection of typing and monads - all because you'd like to represent error handling and logging and futures and few other things in maximally easy/readable way, in the same text, at the same time.
You're fighting two limits here - "in the same text" and "at the same time". IMHO, we should give up on both, and accept that the final "single source of truth" form will become some sort of unholy blend between C and Haskell, serving the role of assembly above assembly. Expressing everything in one place, but not casually readable. For day to day work, you would use many specialized representations, each focused on its specific concern, and free from constraints of a single common text format.
> The optimist in me thinks this sounds like a fabulously interesting development experience.
That's what I think too. It's about raising the tooling to meet us at the level we think at, making it work the way we think about code and systems - instead of trying to project every possible way of thinking into single programming syntax directly.
Note: there is prior art for this, mostly in Smalltalk world (including, recently, the Glamorous Toolkit). The short time I spent playing with those tools tells me this approach has great potential, but could use a lot larger dev community giving it prolonged focus, to improve and streamline the tooling.
Views that give you a vertical slice though code, auto-inlining function calls when you need it, allowing you read and edit a large block of code, and propagating changes to their respective source locations - this is the solution for the "lots of tiny functions vs. few large ones" "clean code" pseudo-problem.
Views that let you control focus. No more constant dealing with exceptions vs. Result<T, E>, 50 shades of async, or how to mix logging into it all - problems to which modern solution seems to be all kinds of monadic bullshit that makes code completely unreadable, unless the language itself gives you some arcane syntax and semantics to hide it all. Instead, have your IDE hide all the things you don't care about - aka. cross-cutting concerns - from your view.
For example, are you working on the business logic, and focusing on what the code is trying to achieve, aka. the golden/success path? Have your IDE hide all error handling for you. Turn all the Result<T, E> return types into just T, making it look as if the code was using exception handling (and doing the handling somewhere else). Then do some vertical-slice auto-inlining to make a specific functionality more apparent. Too noisy with logging code? Turn display of that off. Conversely, if you're interested in error propagation, turn display of all the business code off.
(Think of it as Aspect-Oriented Programming on steroids, in an interactive form.)
This and much, much, more. It starts with a simple idea though: stop thinking in terms of source code as text in files. Start looking at it as semantic units (classes, functions, statements, expressions) in a database of some kind. Instead of opening a file and editing its text, you would query the database to get an abstract code graph, and feed it to a view that renders it the way you need it. "SELECT Foo Bar from Classes, JOIN Fields, JOIN Methods", feed it to an editable outline view. "SELECT" whatever else you care about, feed it through some transformer, to a different custom view. Edit it, and have it automatically apply changes/"refactorings" to affected code.
And yes, editing raw plaintext is something that's often very efficient and we have well-optimized tools for this. But this doesn't mean the plaintext in question has to correspond 1:1 with source code. Instead, you could have the class/module outline view be editable plaintext, so you could regex-replace half of it in 5 seconds, and then press a button, and it would rename and move methods and classes across the codebase, making it conform to your edited outline. Basically what dired mode does to filesystem in Emacs.
Etc.