I'm just going to spill some thoughts here:
There are multiple aspects to making programming more comprehensible, or perhaps even properly doable in the first place.
The first obvious one is language. But even if you could have the perfect language, textual code is not the best for comprehending and manipulating complex models.
So then there's presentation & modeling: perhaps some things are much better represented in a visually, or much easier to edit or build if working with a direct structure (rather than a typed out one). But if your program-flow is a mess or the abstractions are bad, then it's going to be hard to follow regardless.
So then there's the actual form of the program itself: does it lay out what it is and what it does in a fairly straightforward and obvious way? How big of a gap is there between a human understanding of the software, and how it reads? Do you have to reverse engineer the code to make sense of it?
All these things are essential: the presence of one cannot compensate for the absence of the other. For example, you can have a horrible mess of code, but that horrible mess can be diagrammed in a way that makes the exact nature / layout of that horrible mess immediately obvious. And having the flow and components of a program be obvious at a glance, does not mean that that flow itself is not convoluted and hard to follow in it's own rite. And likewise, a mass of textual code may do a horrible job of making a program easy to understand by looking at it, but the components and flow of the program may be laid out well and very easy to follow.
I have a couple points about this, but I'll have to save it for a follow-up post