The more I think about it, the more I feel like replacing text with another form of visualization isn’t going to be the solution. Text-based programming is better with an IDE that offers different visualizations for different tasks/contexts (hat tip to @Tudor Girba). So I think the question is not “What will replace text-based programming?” and instead “Which visualizations will enhance programming so much that we find ourselves preferring those over text in specific contexts?”

I totally agree with I Totally agree with “Which visualizations will enhance programming so much that we find ourselves preferring those over text in specific contexts?”

Especially when, say, 50% of statements are shared between branches.

I think it’s also important to distinguish between the way we write and the way we understand code. Whenever we talk about programming languages, we tend to conflate the two. The code is always consumed in the same shape it’s written in. I believe that is unnecessarily limiting. Interestingly, when you distinguish the two we realize that the writing relates to execution semantics, but reading is mostly a tool issue. That’s why I believe the development environment is an essential component in software engineering.

Very interesting point of view. I never actually realized this separation! I agree it is important to distinguish the two and the development environment is key. And for me the convergence point is what the environment shows to the developper. It is a representaton model (the code, be it mere text or something else) of something that a machine has to process, the model has to be understandable by the developper and the environment has to help him modify the model easily.

Separation also gives more freedom for implicit VS explicit fight. You can have extremely implicit write model while having explicit read view.

Somewhat related: I also believe that we should at the IDE not only as a tool, but mostly as a language that can be expanded.

Part of the problem is that no tool, language, or visualization will make programming intrinsically better. That's like trying to come up with a new kind of paint or paintbrush that will make better paintings. Regardless of the medium (e.g. text, language, etc.), it all comes down to clear communication of data & logic, good use of organization & abstraction, etc. An incomprehensible mess of boxes and arrows is not fundamentally better than an incomprehensible mess of text. In either case, program behaviors (use cases) are either made clear & obvious with a clean breakdown from high-level to low-level details; or you have to reverse-engineer the code (trace-out what happens when and what causes or responds to what) to even get a clear picture. (This often happens when "what the system is" (behavior) and "what the system does" (data) are conflated into the same hierarchical model). (The concept of visual layout in http://worrydream.com/MagicInk can be applied in terms of what information is immediately apparent, and whether you have to "interact" (dig around) to build a model in your head of the program, or whether it's laid out so that model is more immediately before you).

One intresting tool for discovering improvement for programming is that you allow yourself to write only minimal required information as your intention. Then use separate "mapping" code / metaprogramming for the rest. If you can make latter part reusable you may have discovered something.

And if the added complexity of that mapping is less than the complexity beforehand.

Part of the problem is that no tool, language, or visualization will make programming intrinsically better.

Indeed, no single tool will make programming better. However, custom tools will.

That’s like trying to come up with a new kind of paint or paintbrush that will make painting easier, or that will make better paintings.

I have a slightly different opinion. When visualization started to be applied on data more intensely and systematically, the productivity of people making decisions about that data grew significantly. That productivity grows only when the visualization is handcrafted to match the problem. I believe that is essential in software engineering as well.

HOWEVER, I do think that new tools / visualizations / etc. are a necessary means to that end.

It starts with asking what are the behaviors / data / etc, that need to be conveyed (to make the program), and then asking what is the best way to convey that thing. Sometimes the answer will be text, sometimes it will be a table, or flowchart, or shapes on a canvas. (That’s different from saying that any of those things are better for conveying programs in general, which is a dead-end).

Precisely that. We call this moldable development and from my experience it changes not only how I reason about programs, but also how I think about programming.

I meant that you cannot invent a paintbrush so good that it changes how good a person is at painting, just by their choice to use it, or that the same painting is somehow automatically better. Especially if paint is only the best medium 10% of the time, then improving the brush doesn't really fix anything. (That's also my sentiment towards most programming language development). But making it easier to use or identify (or create) the right tools for the right job, and fostering the practice and ability of doing so -- I think that's a real game-changer. I think you (Tudor) & I are on the same page in that view.

I am not exploring it right now, but I agree 100% with you. I like the idea that a "crafting system" can be used to craft itself and think it is the way to go.

If any of you are interested in a demo of Glamorous Toolkit, I’d be happy to show you what we mean by moldable development.

It's my plan tonight to finish watching all of your videos for Glamorous.

@Dan Cook The better paintbrush changes the painter?

No it does not, and that was my point. There's so much broken and unmastered in most software, and it's not going to be fixed with (for example) another new programming language. Most languages already offer sufficient tools for sane programming (i.e. proper use of abstraction and composition, etc.). But it's hard to see (or show) that working with just text, which is why we need better tools to make that more visible. It's confusing: tools won't fix the problems, but we need better tools to be able to see and address the real problems.

According to Marshall McLuhan, “we shape our tools and thereafter our tools shape us”. This implies that the tool does change the behavior. For example, did you check your phone this morning within 10 minutes of waking up? Many people do, yet this behavior did not exist 12 years ago because the tool was not around. So, we can look at it and say that the tool manufactured the need. I very much adhere to this school of thought. And I believe that we should choose consciously the kinds of tools we expose ourselves to. This also means that the characteristics of the tools are more important then their concrete features.

I meant that you cannot invent a paintbrush so good that it changes how good a person is at painting, just by their choice to use it, or that the same painting is somehow automatically better.

How about a paintbrush with undo? That'd certainly help a whole class of people, who are unable to make the right mark on the first try, but are willing to try and try again until they get it. How about a paint that immediately dries? So that you can judge the final appearance without needing to learn how to foresee how the wet painting will change appearance as it slowly dries. How about a canvas that you can make more or less transparent, so you can look through the canvas at your subject, and trace their form?

@Ivan Reese I like the line of reasoning. There is a point where a the paintbrush with becomes something distinct from a paintbrush. I just mean to say that there are limits to what the tool can do if you hold on to too many conventions and constraints.

limits to what a tool can do if you hold on to too many conventions.

Here's a quote from a blog post draft I'm perpetually chipping away at: Hammers can hit nails. That's their very purpose. But they can also hit screws, which is a great way to make a screw stay put while you reach for the screwdriver. They can also dent and deform sheet metal, which is useful for crafting a steel drum. They can knock loose a stuck fitting or lid, especially when hitting the free end of a long wrench on a stuck nut. They can punch a hole in drywall, making it easier to tear down. They can also smash your hand. Hammers are tools for working with nails. This is a conceptual constraint placed on hammers by their designers. Hammers are designed with this specific intent in mind. But sometimes, hammers are just tools for amplifying the force of your arm. Sometimes, hammers are but tools for surviving a forceful impact. To your humble author, hammers are tools for exploring ideas via metaphor, with a wink. But by design, hammers are for nails. You won't find them in the "force multipliers" aisle of your hardware store, nor the "impact surviving" aisle.

The real skill is knowing that a hammer-type force multiplier will help in a given situation.

Ah, yes. That's the crux of it.