

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

======
zb
_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.

~~~
cemerick
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.

~~~
zb
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_.

~~~
cemerick
I agree that that's how things are _now_. My argument is that software
development today is not an engineering discipline. You're right that I know
almost nothing about "real" engineering. However, what I do know seems to
suggest that commercial software development, even in the best of
circumstances and with the best people, does not possess necessary
characteristics that are relied upon in commercial engineering.

The thing is, so much of what software developers do _could_ be systematized,
or at least codified into what would often manifest as what we'd call "tools"
that are then used to far more productive effect by those domain experts.

I've mentioned Matlab and Mathematica elsewhere as an example of delivering
domain-specific notation, but they're also a great widespread example of
delivering a domain-appropriate environment. What if these tools didn't exist,
and any time someone needed to do some math, they had to cajole some
programmers somewhere to help them get the job done? That'd be a disaster in
relative terms, but that's the status quo of so many other "domains" where
software development is regularly involved.

------
ddewey
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.

~~~
cemerick
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.

