"Sterling Jacobson" <sterling at ilc-it.net> writes:
> I think this is what separates a "coder" and a "software engineer".
>> The typical coder without formal engineering training has learned
> the syntax of a particular language or similar language.
I object (mildly) to the concept of 'formal engineering training' as a
way to make a bad programmer into a good one. Although I'm behind the
idea in theory, 'software engineering' as a formal discipline is in
its infancy and many people fear it will never grow up. It's
certainly not anywhere near the formal discipline level of, say,
formal mechanical engineering training. And by 'formal', I mean that
there are agreed-upon practices based on sound theory that have been
proven to make reliable artifacts in a controlled fashion. That sort
of thing just doesn't exist for software right now.
What we do have is computer science, which is very much not software
engineering, but at least holds the promise of creating some
formally-verified tools for programmers who wish to have the
discipline of engineers. A well-trained computer scientist will see
right through the syntax of a language (though will probably have
strong opinions on the importance of syntax anyway) into the
semantics, and will be able to appreciate the subtle differences
(since there aren't any big ones) between the languages in common use
today. They will also be familiar with languages that /are/
significantly different from C in their semantics. What they may not
have, however, is any particular skill in building large programs with
those tools, though they are probably pretty good at solving
high-level problems.
What is left is, as the OP put it, software craftmanship. In the
absence of formal engineering methods, creating software is still very
much a craft to be pursued by skilled artisans. The difference from
carpentry is that the tools and the medium are intellectual, and
informed by Computer Science, so that a successful practitioner must
be at least a lay computer scientist in addition to a craftsman. In
this context, choosing the right tool certainly involves far more than
syntax; it is a choice involving pragmatics, syntax, and semantics.
Anyone who practices programming and doesn't understand these things
is missing out on really understanding the differences between tools,
which is vital to choosing the best ones.
> For the trained engineer it's all bits anyway. So I've seen good
> engineers learn the syntax in a few days and maybe have a reference
> manual handy. Then they switch languages like they switch clothes.
Differences in syntax covering a very similar semantics will indeed
make it fairly trivial for a skilled programmer to switch. It's not
the bits that matter here, though, it's the semantics of the language.
I defy you to take a programmer familiar only with object-oriented
procedural languages and have them work at the same speed in Haskell
without a significant learning curve. They all compile to bits, sure,
but they're fundamentally different languages.
> On the other hand I've seen programmers (often new "contractors")
> fail big time because they can't break away from the syntax they've
> learned. Maybe they picked up programming on the side somewhere and
> have a skill set. But they can't think on a lower level yet and
> don't recognize or have the ability to morph the syntax from one
> language to another.
Morphing one syntax or semantics to another is not a low-level task;
it's a high-level task. Understanding the low-level operation of the
machine is essential for other reasons, but not this one, unless the
language being translated to is a low-level one. What it's really
useful for is understanding the runtime resource usage of programs on
real machines, though it is behind complexity analysis for usefulness
in this regard.
--Levi