Once Apple and other companies showed what the world looks like when a phone is a giant touch screen + giant battery, phones with buttons become a niche, not the norm.
I don't know what the programming paradigm is that completely changes that, but I do know that I haven't seen it yet and everything we've done so far seems to completely miss the mark.
Someone is going to come along with some other radical assumption about what designing/implementing software really is about.
I know that it is not about static vs dynamic, functional vs. imperative, etc. like we've traditionally thought. Maybe it will be more like using Excel or Gmail. Maybe it will be more like flowcharts, or maybe just like sketching out a structure and the machine knows how to wire it together for you. Maybe humans won't be involved at all.
Speculation is endless, but nobody has had the iPhone unveil of new programming paradigms yet.
I'll suggest an alternative approach that might stimulate your neurons. Look back at the ways that your life is improved reading code today compared to twenty years ago. When I look back, the highlights for me are:
a) version control, and
b) automated tests
Forget all their benefits to the people writing code. For me, the guy with one afternoon to make a tweak to an alien codebase, it has been invaluable to have not just the current snapshot of a codebase but a story of its evolution so that I can see what the skeleton of the program used to look like in a simpler time, and gradually play enhancements forward atop it. It has also been invaluable to be in situations where I can go, hmm why do I need _, why don't I just rewrite it as _, try it, and find a failing test with an enlightening name.
What's common to these two ideas is that they are additive. You don't have to give up programming languages. You just need new ways to share information between programmers besides just the code that runs "in production". My current favorite candidate for the next augmentation for codebases is logs. More info: http://akkartik.name/post/tracing-tests. If that whets your appetite feel free to get in touch. My email is in my profile.
 More details of how this helps: http://akkartik.name/post/wart-layers
Programming as it is now is a 2 way communication mechanism, we are writing code for other humans to understand, but for a machine to translate into what we intend for the machine to execute.
So, your point of making code a better human to human communication mechanism is absolutely correct.
What I really wonder about is what set of tools could exist that could solve whole sets of low level problems that we are specifying now that we shouldn't. Sort of like, right now we have blueprints and so on, and then humans look at those and build a house. Yet, with 3-D printed houses, you feed a set of materials and specifications into a machine, and you get a house built for you.
What is the programming equivalent that would allow us to "3-D print" software, so to speak? For physical things, it seems to be the combination of 3-D CAD systems, 3-D printers, and maybe some thought about how things need to be designed to fit this approach.
I have no idea exactly, but I could see a future where instead of paying people to hand craft all the code, that a series of features, modules, structure, etc. are specified, and the software is just "built". There would be more effort in the specification, but less on the build.
I think "naked objects" or "apache isis" are the best examples we've got for that for now , but they are rooted in somewhat complex java code, instead of being rooted in an easy to use tool, such that lets the business analyst who had some course , sit with the client and fully define a running system , step by step. In some cases the auto-generated UI would be good as it is , and the system will be used as-is.
In other cases , we might need easy tools to customize the UI.
When you think about it, the job of a designer is often quite systematic. You have some entities/data you need to communicate to the user, through whatever interface/device that's available to him. A touchscreen, a keyboard, knobs, LEDs, microphone, speaker, paper, etc.
When your "user" is a computer, JSON (while not perfect) seems to do the job as an interface. In the case of humans, JSON does a poor job at efficiently communicating information.
- A calendar is better than "2012-11-05"
- A color is better than "#FF3300"
- An image is better than "http://example.com/image.png"
- A clickable link is better than "http://example.com/document.html"
The list goes on. We can easily generate a basic UI based on complex entities, and map specific types to custom/reusable templates if needed.
Now that your UI can automatically be generated from data, you can build an app (business model) once, and make it usable (and actually look and feel good/native) on any device. A smartwatch, a smartphone, a smarttv, etc.
Basically, the core of software development should be knowledge representation. Describe the world semantically (with RDF or similar technologies), and let the UI-compiler generate a UI for any given target platform, language, culture, user preferences. That's what responsive design should be all about.
It seems that there's something missing from all the existing implementations of your suggestion. Perhaps it is that the UI and data flow primitives that we have aren't flexible enough to express a lot of business models, thus requiring custom implementations.
Regardless, that was kind of my point - all these systems are only good as long as you stay within their constraints. The unfortunate thing is that the constraints always end up being way too tight in practice.