Re: How to - SDI
I used FORTRAN and COBOL for many years on mainframes. I thought both were
decent for what I was doing at the time and, mostly, it was available. I
don't do any work with those these days, but I have fond memories of card
decks, overheated data sections, and, eventually using PL/1 when I no longer
could decide whether to use COBOL or FORTRAN any longer.
BTW, I think it's fair to teach "opinion". They do it in all college
classes these days (even science). I think it's fair to present all of the
information, then give the students the benefit of your experience.
Tom
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:b55ll5tjm490icfopbe178grka9h25v7u4@4ax.com...
Actually, I am not.
All this touchy-feely "don't limit what people can do" stuff doesn't work
in reality. In
reality, we have to create robust, maintainable programs at minimum cost.
Some people
interpret this as meaning "every variable that is shared has a global
definition; all
global definitions appear in the same header file that is used
everywhere", "every public
method must be available at every level to every component" [so every
object has a global
variable, and every global variable gets used everywhere, and there is no
abstraction].
This is sort of the "We don't need no stinkin' subroutines" model that bad
FORTRAN
programmers believed in back in the 1960s.
I programmed in FORTRAN. It is a Really Bad Language, but when you need
"global"
variables shared with subroutines, you have to put them in COMMON. I
learned to put each
variable in a block of named common, something like
COMMON /variable/ variable
so every variable was in a named COMMON which was its name (they were in
different
namespaces). A FORTRAN programmer was taught to put all the variables
into a single,
unnmaed COMMON. By limiting their mindsets by excluding unnamed COMMON
from their
programming model, they could create programs that were easier to maintain
than those
written by people who had the freedom to use bad techniques.
Of course, you could equally argue that traffic signals are fascist, and
we should have
the freedom to drive however we want through intersections. And that
notion of driving on
the right of the road in most countries, or on the left of the road in
other coutries, is
too restrictive. That pilots should not be subject to "air traffic
control". That laws
about safety and purity of food unfairly limits the freedom of
slaughterhouses and other
food vendors. Has it occurred to you that most of the rules that make
society work (theft
is bad, murder is bad, pulling your little sister's hair is bad) are
limiting people's
mindsets? Why is it different when teaching programming? I HAVE to be
able to say what
is bad design, bad implementation, bad style. Failure to do so means that
the unlimited
freedom gets us totally crap software, vulnerable to malware attacks, that
works only when
the input is perfect, and...oh, wait a minute, I just described most Unix
software (I'm
allowed to say this; I used Unix for 15 years, and fount the software was
slovenly, to say
the nicest thing possible about most of it). Telling people strcpy is bad
is GOOD.
Telling them that they should be fired for using it is even better.
Putting an official
company policy into place that they WILL be fired for using it is still
better. The
result is more reliable, more robust software. What's not good about
that? Sure, their
mindsets are limited. They are constrained to write better code. I
somehow fail to find
that sad.
Anyway, I'm off tomorrow for eight days in The Netherlands (an
international conference in
Maastricht), so this debate can continue without me.
joe