My comment was based on the concept and my interpretation of those concepts in the future. Not necessarily on the reality right now.
The problem with people who seek to replace our glorified text editors that we use for source code editing is not that they don't understand the disadvantages of the format... it is that they don't understand the advantages. Consequently, proposals for replacement tend to throw away huge swathes of functionality without realizing it, then start from a functionality deficit nearly impossible to recover from. It's actually hard to beat text. There's a reason we're communicating in text right now, and it isn't a lack of creativity or lack of attempts at other solutions to the problem or any of the other memes trotted out every time this topic comes up.
Take the simple case of naming. In plain text, the name of a function is its unique ID, more or less. Some language cultures love long descriptive names like BattleResourceMediator.getMediatorInstance(). Well such names can be broken up into tags. [Battle Resource] [Mediator].[get][Mediator][Instance]. Then when you don't need to know it's a mediator instance you'll see [Battle Resource].[get]. If you need to see what's a mediator and what's a factory, turn on some deeper editing mode and swim in verbose boilerplate.
You're not going far from text, just augmenting it with simple ideas we use in bookmarking. You can go further, add tags to sections of code to rate and label it as readable, hand optimized, quick & dirty, reviewed, etc. Simply a better UI for documentation, so in a zoomed out view of a project you can see at a glance how much is hand optimized.
Also watch this video https://vimeo.com/36579366 and notice the sorting code walkthrough. A simple case of refinement where you put output side by side next to the code and format it properly. We'll need a lot more refinements like this, which means more attempts, more creativity.
Agreed. I think this has something to do with the fact that programming is not about the objects on screen themselves, it's about the interaction that occurs between those objects and the mind of the person looking at them. The objects are not real, but mere representations.
Therefore, the interaction I have with a block of code is defined by my experience wrestling with the problem at hand in the language of that block, during which my brain has "mapped" from the text to a sort of abstract visualization of its value (or "serialized", as you put it).
I don't think a tool that makes a "picture-block" for me will ever help. My brain has to do the work of understanding those blocks by compressing each text block into a form (block? graph node? neither?) that I can hold in my head.
Strangely enough, if the above is correct, that means that there is more value in implementing a tool like this (for the implementor) in $LANGUAGE than there is for a potential user. Perhaps this is why programmers keep writing them, and users keep on not using them.
As the user, I need to learn something either way, and learning is usually hard/expensive. Therefore, why learn the (imperfectly-mapped) "picture-block" abstraction at all?
It'd be interesting to see if programmers feel the need to keep using these sorts of tools them once they've written them. My guess is no.