A couple of posts about hating programming

A post last week, "I want to fix programming," suggests that declarative programming (keeping around the "why" of what you're doing instead of the "how") would be a step up from what we're doing, and adds a couple of neat magic keywords that indicate how it might be done. Color me unconvinced, though, because just saying what you're doing and hoping the compiler is going to get it right might require a little too much from the compiler.

His specific case is a sort algorithm - he just specifies what he wants from the sort, and the compiler would do the sort. Well, I still think the answer there is to tell the compiler: "sort this stuff". Now I don't have to look at his constraints and say, "Well, wait a minute, that's a sort." If I were talking to a colleague, I wouldn't say, "All the elements of this list should match those in the other, with the constraint that each element in the list is less than the one after it." I'd say, "We'll sort this list." Then I'd look up a sort algorithm, and later, down the road, if it turned out that sort was a performance bottleneck, I'd maybe look for a better sort algorithm.

Just specifying the constraints is not enough. You're still losing information if you don't have a machine-readable set of semantics of what you're doing. (I say that as though this was already achievable with today's tools, when of course it mostly isn't, but you see my point.)

This week, we have a response, "Yup, programming is borked," and makes the cogent point that formalization of requirements is the key - and then still goes off the rails with brand-new syntax that's not human language or anything like it. He's got some interesting ideas, and is looking at authoring systems for non-programmers, which I find pretty fascinating, but I think he's still getting lost somewhere along the way.

I remain convinced that a hierarchical set of semantic views, preserved in the final program, is the way to go. Each part of the program not only has formal syntax defining it, but a conceptual framework indicating what it does, why it's done that way, changes that were made along the way, related tests (which can be seen as constraints) or even constraints (which can be seen as tests) - the whole ball of wax is right there and amenable to software manipulation. Changed requirements can then drill down right to the code that must be changed, and with sufficient sophistication, you could imagine that tools could make suggestions or even rewrite the formal syntax to conform to the requirements.

That's the goal.