Thanks for a very interesting perspective! Some points (or more like associations) fresh after reading:

• Maybe, a triad like semantics, syntax, pragmatics describes better than Saussure’s dualistic notion of signs? (the idea is not mine, but I do not remember where it originates from).
• I do not agree that math is void (or abstracted away) of meaning. It’s symbolic manipulation side is a perfect “transport system”, which one can use to arrive at the desired destination and then reunite it with the meaning at the exit. However, that system developed for most of its part as a response to the practical needs. Plus “developing” math forward is not formalizable process. Here Chaitin omega comes to mind, and that math is actually “random”.
• With the previous point, the difference is in programming we do not have the luxury (or attention span, or cognitive abilities) to dive into transport system for longer periods. It means, that we keep symbols and their semantics in the model of the real world close to each other. Exceptions just confirm the rule: Sorting algorithm does not need to keep the meaning of the data it sorts, provided key comparison function “makes sense”. And of course proofs are very important in math while formal verification of the programs (despite all recent advances) is not economically feasible except for very important cases.
• I also recalled Cognitive dimensions of notations (Green, Petre) — for measuring usability and even setting a framework for speaking about notation systems (and programming languages in particular).
• Curry-Howard correspondence makes functions we program and proofs we do in math (theoretically) isomorphic… Of course, from the “user” point of view this deep connection of the code and mathematics makes very little sense.
• I immediately recalled Donald Knuth’s Literate Programming. So the problem is an old one. This and for example BDD (Behavior-Driven Development) and it’s tools make attempts to close the gap of design documents (you seem to have problems with on the ground they are not “executable”): Code can be used at different levels of the design. Also reference to Model-driven engineering can be useful here. Those design methodologies are out there trying to prove you wrong…
• Nobody is limited by the language at hand. For complex domains it’s ok (economically feasible) to develop and use Domain-Specific Languages. So once again syntax can become your friend.

There are so many directions you ideas collected together may lead to.

I have some minor points I disagree with. UML is just one of many modelling languages, but more widely used; OOP is not inherently good or bad — but industry treated it poorly to the point Alan Kay pointed out he imagined it differently (citation needed). I bet you have heard of DDD, and even without that there are no theoretical problems having methods and data together. I’d said OOP as a programming paradigm and OOD as design paradigm are not that black and white. Before you start to write a book (unless it’s just a stream of consciousness like my comment here) you would most likely make a Table of Contents. And some enterprise systems are so complex, that there is a need for Table of Contents of Contents, etc… This is not something that can be solved by simply pairing domain expert and (programming language) solution expert: Too high levels of abstraction.

Now, I am mostly intrigued by the often discussed topics whether math can help software developers. I’ve seen debates pro et contra, but am of the firm opinion that solid math background can actually help be a better software developer. And your article provided food for thought. A lot of it. The main problem of (beginner) programmers is not to understand the meaning of the domain. Combined with poor symbolic manipulation it’s a total waste of time. Math at least dramatically improves the symbolic manipulation part, so there is hope meaning and meaningful problem decomposition will follow. Form and content as philosophers put it sometimes.