Programming and software development, medium-rare

http://muckandbrass.com/web/display/~cemerick/2010/07/15/Programming+and+software+development%2C+medium-rare

by ggualberto • 16 years ago

21 6 16 years ago

ddewey• 16 years ago

I don't quite understand the "blueprint:building :: X:code" idea. It helped when I saw (in a comment at the bottom) that the author doesn't consider regular expressions, SQL, or other DSLs to be code.

Is this article really just a call for the splitting of Turing-complete languages into software "materials", a group of DSLs that provide constraints? Programming in universal languages would become like materials science or industrial R+D.

cemerick3• 16 years ago

See my reply to zb here, that addresses this more.

Associating general-purpose programming languages with materials science seems reasonable. Building the systems that are used to build systems, etc.

Though DSLs are the most common manifestation of declarative, often constraint-based directives, thinking about all such things as text-based is another blind assumption made by most. Far higher-bandwidth "interfaces" for defining systems will simply be necessary in so many fields that suffer under the yoke of mostly-ASCII text. Just look at mathematics and e.g. Matlab and Mathematica for a super-simple example. More broadly, data, design, and process visualization continues to be a growing "trend" (more like an inevitability, but whatever) -- why shouldn't those visualizations function as the model for the relevant domain experts (whereas they are so often simply presentational)? The sooner they make that transition, the better.

zb2• 16 years ago

Roughly, I think the point is to solve for X: blueprint:building :: X:code

This is exactly backwards. The answer is: blueprint:building :: code:software

Failure to understand this is the reason why most comparisons between software and engineering are, as the author has correctly identified, nonsense.

He is unable to recognise this error due to a lack of experience with engineering, as evidenced by this statement:

If my grandfather had responded "It depends" to a question about how to produce a 1-ton spool of 2mm-thick copper strip, he'd have been fired on the spot.

To a first-order approximation "It depends" is the best answer to any engineering question, not just any software engineering question; the author's grandfather may well have agreed with this. Don't get me started on the footnote.

If the author wishes to actually learn something about engineering instead of just repeating erroneous clichés about it, I would recommend he start by reading anything by Henry Petroski.

cemerick3• 16 years ago

What I was driving at with the "it depends" part is that, in the real (commercial) world, there's only so many reasonable ways to get something done. There will always be a variety of important details, but the fundamentals don't change much because of the natural constraints that exist. The same cannot be said of just about any software development activity.

I stand by the blueprint:building :: X:code concept. Brian posted a comment on the actual post along the same lines as your rebuttal:

"With regard to "blueprint:building :: X:code", I think code is the blueprint. If not code, then a specification that's precise enough that it may as well be code."

And I'll repeat here that if precise specifications required code, then you wouldn't have regexes, SQL, or any of the other common (and uncommon) DSLs that flit about. If you think those things are code, then what about BNF grammars? RDF triples that inform expert systems? There are a lot of things that system behaviour that don't suffer from the problems of software as I described, and they often are far closer to the relevant domain than any "code" that would be required to implement the desired behaviour directly.

zb2• 16 years ago

Thanks for the reply; I wasn't sure if you were following this thread. So, if I understand your argument correctly, you're advocating that domain experts create software in high-level languages so that we don't have to write code.

The problem with this theory is that it relies on what I've seen best expressed as "the neat separability of ends and means." This is also the fundamental principle of top-down design, and it's the reason people hire armies of (<cough>Java<cough>) programmers, give them no domain knowledge and ask them to construct the code while waffling about how projects are like houses.

In the real world that's simply not true. Engineering is where ends and means meet and overlap and are reconciled through the process of design. The result is, for civil engineers, blueprints; for software engineers, code. That's why I think you have code on the wrong side of the relation: because code embodies both ends and means it cannot be merely constructed, it must be designed.

Programming and software development, medium-rare

Related Stories