Lambda the Ultimate

Recently, it has occurred to me that much of language design - I believe both many theoretical efforts as well as in practice - focuses on developer phenomenology - the experience of individuals (sometimes groups) when writing code, verifying correctness, reading and modifying (maintaining) someone else's code, breaking a program into parts (for a variety of reasons) and so on.

I'd place the everyday developers' near obsession with syntax - and "convenience" in general - squarely in this class of concerns, but this class of concerns more or less informs many other concerns with the design of programming languages. For example, concerns with "productivity" or with the lesser or greater "obviousness" of program correctness. These are also concerns with the developer(s) experiences during program construction.

Clearly these are important concerns.

But my question is whether or not any inquiry into language design has instead started from the "end goal" - the more-or-less opaque (compiled, etc.) artifacts produced by a development effort - and worked backwards toward a language design based primarily upon requiring these artifacts to possess some set of desirable qualities.

This is not intended to be a "real world" example, but only illustrative. We might desire for all I/O to be highly abstracted and fully parametrized in our programs. Maybe we are in a mainframe shop planning a very expensive 10+ year migration of a giant code base from VSAM to DB2, and we anticipate future similar migrations of any new programs we write in the future. We want to make any future migrations much cheaper and less time consuming. Here we might be willing to drive developers nuts with "high language ceremony" surrounding all I/O portions of their code, decrease our normal measures of productivity and so on just in order to bless all of our new programs with this attribute (cheaply and more quickly migrating from one I/O and storage mechanism to another).

While I don't think the distinction can be made fully rigorous, I believe that myriad "artifact (code) reuse", parametrized modules, dependency injection, literate programming and other enforced documentation regimen, language enforced "library" or "module" (whatever those mean for different languages) versioning and other efforts at least have one-foot, as it were, in this "working backwards from the artifacts" approach to language design.

Are there any general papers - not just about specific desirable artifact attributes or mechanisms to achieve them - along these lines about this approach to programming language design?

Many thanks in advance!

- Scott