Hi Jon,
I respectfully disagree. These aren't bricks; they're complex tools that
potentially have the ability to impose compile-time requirements on
structure and organization. You certainly CAN shoot, stab, poke, crush, or
mangle yourself in the foot with any instrument, but some instruments are
built with safety measure to discourage it or to help you remember not to.
I can't give you any credit for this one. While some languages are better
than others in a qualitative way, such as strong typing, etc., this does not
make any language safer to use than another one. My allegory of a brick was
a simplification. A brick is a component used to build a structure. A
programming language is a set of components to build logical structures. The
complexity is of no importance; hence, I used the simplest allegory I could
think of, for the sake of clarity. Conceptually, with regards to the point I
was making, they are the same. Both are components used to build structures.
Any component used to build any structure can be used well, or poorly. The
"safety measures" in the C# language, and in other languages, are there to
aid the developer in the process of building a good structure. This does not
in any way prevent the developer from building a poor structure. For one
thing, you would have to eliminate certain components from the tool set in
order to make this assertion. The "safety measures" you speak of do not
apply to all components of the entire language. In addition, it is not the
individual components of the structure that determine the quality of the
structure; it is the Gestalt of the components that comprises the quality of
the structure. A process is not a collection of unrelated separate elements;
it is the combination of elements in complex relationships with one another.
Hence, we have the disciplines of design and architecture.
Taking the analogy of the brick as a simple example, let us imagine that a
brickmaker designed a new kind of brick, with a "magnetic" component that
caused it to snap to the nearest 90-degree increment with any brick layed
prior to it. This would prevent misalignment of bricks in a rectangular
structure. However, of course, not all structures are rectangular. So, the
brickmaker includes a configurable aspect that allows the angular increment
to be adjusted on a per-brick basis, or perhaps to an entire group of bricks
at a time.
Along comes a mason, and he happily proceeds to build a tower. However, he
designs the tower as a single column that is the same width at the bottom as
the top, 10 feet wide, and the height of the tower is 1000 feet. While the
bricks are most certainly aligned in perfect angular fashion, before the
tower is finished, it falls over. The ratio of the width of the tower to its
height is the reason for the failure. Bricks have little tensile strength,
and are heavy. A brick may seem like a very solid building block, but it is
the combination of them that causes the tower to fall, because it is not a
brick. Neither is it a collection of bricks. It is the sum total of all the
bricks that comprise its structure, combined with their arrangement, and the
resulting characteristics of the whole. In fact, no pair of bricks in the
tower has the same qualities as any other pair of bricks, due to its
placement in the structure. The relationship of each brick in the pair to
the other brick is affected by the relationship of that brick, and that pair
of bricks, to the entire structure. There is more force, for example,
pressing down on bricks that are lower in the tower. The lateral force on
each brick depends also upon its position within the tower.
Now, considering the brick again, we may agree that a brick is about the
most simple analogy one could make for a programming language, and that a
simple tower is the most simple analogy one could make for an application or
process written in a programming language. But you have already made the
assertion that a programming language is a set of "complex tools" that is
far more complex than a set of identical bricks. As my Uncle Chutney sez,
"Complex things are made up of lots of simple things." When you combine
components into a structure, the complexity of the structure increases
exponentially with each component added. New points of failure are
introduced, sometimes in the most unexpected of places. If the components of
the structure are complex, how much more complex is the resulting structure!
The World Trade Center in New York was designed to withstand the impact of
an aircraft the size of each aircraft that flew into each tower, and in
fact, it did. But both towers fell into a pile of "bricks." Both of them.
Why? Because the architects did not anticipate *all* of the factors that
were caused by the impact, and the remaining residence of each plane within
the structure. The planes, the fuel in the planes, and the resulting and
lingering fires, introduced factors which eventually caused a chain reaction
of events, which caused the towers to fall.
As for anecdotal evidence, I don't know how much C# code you've seen. You
mention that you have seen a lot of VB and VBScript. Well, I have seen a lot
of very poorly-written C#. And as for people being "taught to become
sloppy," well, I'm going to have to respectfully disagree with that
assertion. The language doesn't teach the developer to be sloppy. The
developer does that all by him/herself. One can write good VB and VBScript
in just the same way that one can write good C#. It is not the language that
determines the character of the developer. On the contrary, it is the
character of the developer that determines the quality of *anything* that
developer does, regardless of whether it is the writing of an application,
or the maintenance of the home, finances, or relationships.
--
HTH,
Kevin Spencer
Microsoft MVP
Professional Numbskull
Hard work is a medication for which
there is no placebo.
