| Monday
January 5, 2003 As usual,
there was a fair amount of good stuff over the weekend. And for that matter
all of last week. You might start there. (Last
weekend
Last week).
There is
considerable discussion of The Language Wars. I
haven't really time to comment on all this at length, so I'll let some the
participants speak and try to reply to the whole issue later. To skip all
this click here.
One general point: Pascal was written
as a teaching language, and lacked many of the features (particularly IO and
good libraries) that important commercial compilers would need. When I say
"Pascal" I mean it as a shorthand for "A commercial version of Pascal
written for micro-computers." Modula-2 was a good step in that direction.
Note also that there were working Pascal and even Modula compilers for small
computers before there was a C compiler for micros: the first C programs for
micros were written on cross compilers run on larger machines.
A second general point: I don't think
anyone has ever seriously said that a large program written in C is easier
to understand than one written in a Pascal-like language (including Ada);
and I have had few dispute the notion that it is often easier simply to
rewrite the program than to try to understand the old one if the original
programmer is run over by a bus before completing the program.
C compilers support type checking just as strong as
anything Pascal ever had, and they have supported this for about the last
decade.
However, C compilers don't force you to use these
features. If you don't declare your functions with all arguments
specified, and instead declare your functions with the old C syntax, you can
get functions that will not check their arguments. You will face many
warnings from the compiler, however.
C has always allowed you to "cast" a variable from one
type into another type. This is handy; for example, you need not write both
a PrintInt() function and a PrintShortInt() function; you can just write
PrintInt() and cast short integers into long ones. C even has built-in type
conversion rules which would probably take care of that for you in this
example anyway. A badly-written cast can disguise an error; a cast
essentially tells the compiler "trust me, I know what I'm doing" and when
you don't really know you have a problem. But the lack of type casting
was a huge problem in Pascal.
Unlike Pascal, C allows you to declare functions
with a variable number of arguments... with absolutely no type-checking of
the variable arguments. This allows for functions like printf(), but
that brings us to another point: older APIs, including the standard C
library itself, may contain lots of non-type-safe stuff. Such as "printf()".
By the way, I'd like to see the strcpy() function
removed from the C library. It copies a string to a string buffer without
checking to see whether the string is longer than the buffer! This one
function is the source of many "buffer overrun" errors. It's more efficient
than a length-checking function, but at this point it's causing more trouble
than it's worth.
I don't know any C compilers that support any run-time
checking of array bounds. There is little point to it anyway, as it is
common practice to dynamically allocate a raw chunk of memory and simply use
it as an array. It would be difficult to write a compiler that could create
run-time code to check that!
The real reason why Pascal lost out to C was that C
was a tremendously practical language, much more practical than Pascal.
Pascal was designed as a teaching language, and some of the features of the
language make it easier to write a Pascal compiler. But the Pascal standard
was broken in several important ways, and different compiler vendors solved
the broken parts in different (incompatible) ways. C worked, and worked
everywhere (it was easy to bring up a C compiler on a new platform, and your
could would actually compile).
C++ provides ways to write completely type-safe
programs. You can write classes that validate their inputs, with array
bounds checking as a trivial example. But C++ is a rather large thing to
grok in fullness.
I haven't done much with C++, and I have done even
less with Java, so I'm not the best expert. But Java appears to offer much
of the benefit of C++ (at least with respect to type safety) and to be
easier to really learn.
P.S. For my own projects at home, I'm very partial to
Python. -- Steve R. Hastings "Vita est" steve@hastings.org
http://www.blarg.net/~steveha
[Emphasis added by JEP]
I think you have made my point: the
compiler doesn't force good programming practices, but allows you to think
you have correctly simulated the compiler in your head and you know what you
are doing. From my past experience I can say emphatically that if you are
not forced to do all your declarations of both type and range, you'll put it
off until "later" while you are in the throes of creation, or you'll be so
certain you did nothing wrong you won't bother.
Brian Kernighan wrote an essay about Pascal and what's
wrong with it. If you read this, you will better understand why C defeated
Pascal. Many of his complaints were addressed in specific versions of Pascal
(e.g. Borland's Turbo Pascal), but C provided a more practical language
without locking you in with a specific compiler.
http://www.lysator.liu.se/c/bwk-on-pascal.html
-- Steve R. Hastings "Vita est" steve@hastings.org
http://www.blarg.net/~steveha
Sure he did. I reviewed it in the old
Byte. The essence of my review was "He doesn't like Pascal because it isn't
C," and I see no real reason to change that view.
Hi Jerry
Happy new year to you and yours.
I'm a professional developer. Over the last 18 years
or so I've worked extensively with C and C++. I've also worked quite a bit
with Pascal, COBOL, FORTRAN and BASIC (and its derivatives) plus many
others. I've also taught C, C++, Pascal, Modula II and COBOL at University
(Bachelor and Masters) and Tertiary College (Diploma) level.
I find myself in almost complete agreement with your
correspondent David H. Lynch Jr.
I've inserted my comments amongst yours, which I know
you don't much like, but I think it makes it easier to respond to particular
comments. I've included your entire comments (nothing is missing). I hope I
haven't misrepresented you in any way.
> I suspect that both Kernighan and
Wirth would be astonished to find > that C and Pascal are highly similar,
As languages go, they are reasonably similar - both
being descended from Algol. Certainly closer to each other than to FORTRAN
or COBOL. Modern BASICs have become very similar to Pascal, but early BASICs
were very different.
> and if there is strong type checking
in modern C compilers that must > be rather recent.
Strong type checking has been available in C compilers
since the mid '80s - but you can turn it off. Even strongest type
checking is available in C++, but you can get around it if you try.
(Not that I'm recommending that you do.)
The "lint" program has been available to perform
strong type checking on C programs for longer than I can remember. Good
practice has always included "linting" a program.
> And it may be squirrelly to say that
programmers simulate the compiler > in their heads as a means of testing for
potential bugs, but in that > case some of the best known C programmers must
be squirrels, since I > didn't make up that phrase, I got it from the people
at Digital > Research quite a few years ago.
In the early '80s (and probably the '70s) C
programmers wrote some obscenely ugly code to maximise performance on slow
machines with little memory. Such hacks needed intimate knowledge of the
compiler output to work properly. If somebody wrote such code in the last 15
years, they should be hung. (But of course, some people have).
Even into the late '80s, you could gain significant
speed and space optimisation by understanding the way the compiler works.
Today's optimising compilers are so complex that few
programmers can predict what they will do with a particular piece of code.
> It may be that using languages that
look for logic flaws, out of range > inputs, and unexpected type changes
wouldn't result in better code so > long as the programmers are the same,
and thus only people who really > understand what is going on can be
programmers, but I suspect that > letting the computer do a lot of the work
is a better way to go.
If you want a little utility program for yourself,
tools like VB or Delphi are perfect - and they need minimal skill levels to
achieve quite reasonable results. If you want to build large, complex
programs then you really need skilled developers, no matter what language
you use. C is hard. If you want to use it, you need to be properly trained.
An amateur will make a big mess, but a skilled programmer can produce robust
powerful software. Unfortunately, too many employers don't want to pay for
experts, so they hire half-trained programmers and they get what they paid
for - half-baked software.
> Good languages force you to write
programs that work as you expected > them to.
My C/C++ programs almost always work as I expect them
to. If they do not, my testing department returns them and I fix them. The
message here is to thoroughly understand your tool - whether it is BASIC,
Pascal or C.
> That was the whole point of the old
language wars,
I never really saw a point to those :-)
> and the efforts to prove programs,
Proving programs is a very good way to produce good
software. The trouble is, it is extremely hard to do. Some good results have
been achieved, particularly with life-critical software. However you need
**very** good people, and it takes a long time.
Prof. Ken Robinson at Uni of NSW (Australia) was
researching the automation of proofs. A friend of mine did a PhD with him in
the '80s. I haven't heard about that in a long time and I don't know how (or
even if) it is going.
> and even the military's move
to ADA which was in fact a good idea > badly executed.
I've never worked with ADA, so I am limited in what I
can say. I've known a number of skilled developers who have worked with it,
and they generally hated using it - but produced reasonably good results. I
guess that one can draw one's own conclusion from that.
The fundamental point is that good people will produce
good results with almost any tools, but under-trained people with powerful
tools can make a big mess.
Sorry for the rant - it is a bit of a hobby horse of
mine. :-)
The old adage: We produce software - Fast - Correct -
Cheap (Choose any two)
------------------------------------------------------------------- Michael
Smith, Senior Software Engineer michaels@sw.oz.au Aurema Pty Limited Ph: +61
2 9698 2322 PO Box 305, Strawberry Hills 2012, Australia Fx: +61 2 9699 9174
79 Myrtle Street, Chippendale 2008, Australia
www.aurema.com
[Emphasis added by JEP]
I repeat: if you can turn off an
important requirement like type checking, someone will, and in fact one of
the problems with security in some pretty famous programs turns out to be
that someone did.
I make no doubt that your programs
work as you expected them to. I doubt seriously that the Microsoft
programmers intended their programs to include the security holes that
Windows was riddled with: many of which would have been impossible if strong
type and range checking had been applied.
As to the "good people make for good
results" argument, that was the entire point of Henry Ford and the US
Industrial Revolution. Hitler was certain that the United States would not
make a big different in World War II because there was simply no way to
automate craftsmanship, and it took a long time to train people to
sufficient skill to make military optics like tank gunsights and the Norden
bombsight. The point of proper tools is to compensate for having people of
reasonable intelligence using them, rather than requiring geniuses and
experts.
That was what the language wars were
all about: would we continue down the UNIX path of guru-friendly programming
and operating systems, or would we try to make things user-friendly by
letting the computer do most of the work, and forgive me for saying it, but
I am not at all surprised that you never understood the point.
Experts seldom did. And some
understood perfectly and fought like hell to protect their turf.
In comparing C and Pascal you could argue that they
are "more similar" to one another than either is to FORTRAN, COBOL and LISP
based on the fact that C and Pascal are block structured languages and the
others are not. At this point you could argue that PERL and C are almost
identical as PERL borrowed very heavily from C's syntactical rules.
"C succeeded as a systems programming language and
eventually an applications programming language because Pascal failed"
I would argue that C gained popularity due to its
availability on UNIX systems found at schools around the world. Borland's
Pascal compilers continue to have some following and I would think of them
as a success. Other languages continue to become more Pascal like in
practice. C "won" because it gathered a following, not because it was the
better (or worse) language.
Is it easier to write bad code in a given language? I
would argue that it is. Few languages require the programmer to maintain the
attention to detail the C language does. The greatest hazard is requiring
the programmer to correctly manipulate memory with allocation and release of
memory done with direct pointers. Languages built on C remove these
requirements and seem to have fewer errors that result in exploitable
situations.
The Pascal family of languages require such features
as array bounds checking to be part of the emitted machine code. While
programmers should still check for errors, the compiler will always create a
correct test that will catch the error. Making sure the test is correct
becomes the problem for the compiler to solve and eliminates one of the most
popular mistakes that result in a security exploit.
--- Al Lipscomb
==========
And finally:
Regarding writing safer code:
This whole mess with computer viruses derives from a
decision to merge the call-return stack with the stack of parameters and
local variables. Separate those two, and 99% of viruses have no way to get a
grip. Buffer overruns could cause errors - but could not set the instruction
pointer by modifying a return address.
Who came up with the single-stack scheme, anyhow? I'm
pretty sure that the first microprocessor designers must have simply copied
the idea from existing CPU designs, probably assuming that it was just the
way you had to do it.
In any case, it's something that COULD be fixed in the
hardware.
Tom Craver Chandler, AZ
Or even with better code generators...
==========
But See Below
=========End of
Language wars
One of your correspondents said (Currentmail, Jan 2):
> What about going after the companies who use
spammers? Some might say > that those companies don't know how the spammers
operate, even if it's > illegally. I say that's crap. If we were to start
slapping fines on > the companies who hire the spammers, I'll bet we'll see
a reduction in > spam. Maybe start listing those companies that use spam and
organize > boycotts?
Boycotts? How many of them are selling anything any
sane person would want to buy anyway? Companies use spammers, I presume,
because they are selling crap and can't find enough mugs by any other means.
Excluding the porn sites and, ahem, personal
enhancement products, most of my spam seems to be (a) dubious "debt
reduction", "instant loan", "guaranteed credit card" and related financial
offers; (b) dodgy-sounding cheap software deals, and (c) even
dodgier-sounding pharmaceuticals (codeine, weight-reduction products).
I'm not going to boycott, say, IBM software just
because someone offers me a probably-pirated copy of ViaVoice. Most of the
rest of what's on offer is of zero interest anyway: I won't buy it, but
that's because I don't want it rather than because it was spamvertised.
Happy New Year!
FB
==============
Cheery News:
Pharmaceutical giants hire ghostwriters to produce
articles - then put doctors' names on them
http://observer.guardian.co.uk/uk_news/story/0,6903,1101680,00.html
Although IANA Doctor, would it seem appropriate, when
a physician prescribes to you a *new* drug or presses samples on you (which
are almost always *new* drugs IIRC), that involved patients look into the
*number* of studies published lauding that drug, and look for a diversity of
sources... or is that likely to be ineffective in scouting out medi-flack?
This greying post-boomer would like to hear from a doc on this.
-- John E. Bartley, III john@503bartley.com
503-BAR-TLEY (503-227-8539) K7AAY This post quad-ROT13 encrypted; reading it
violates the DMCA. ..We're living in a collaborative SF novel... and now, of
course, it's Philip K. Dick's turn. In a back room somewhere, Vernor Vinge
and George Orwell are currently arguing about who gets to take over in 2025.
(Ross Smith)
Well, Vernor's not dead yet. We just
heard from his this morning.
On the substance
of the article, see below.
And in that grim
vein:
Dr. Pournelle:
According to a report on CBS's 60 Minutes of 1/4/04, a
police search is justified if a "well-trained and reliable" dog [standard
set by the Supreme Court] alerts to drugs.
A high-school student was removed from class because a
dog had alerted to drugs in her car. No drugs were found. The dog alerted
improperly (false positives) for drugs 71 of 72 times. The student's parents
were informed by letter that their daughter "had been" in contact with an
illegal substance. The parents protested, whereupon the school changed the
letter to read, "may have been in contact . . ."
The student's parents, having apparently a firmer
grasp of the contents of the 4th amendment than did the school district,
sued. (They were represented by an ALCU lawyer.) The school district
settled, agreeing to refrain from the use of drug-sniffing dogs, and to
remove references to drug possession from the student's record.
There is no licensing or certification program for
drug-sniffing dogs. How can a dog be proven reliable?
I now wonder whether the use of drug-sniffing dogs
could lead to as many opportunities for inequity, injustice, and corruption
as the drug-possession asset-forfeiture laws. Whatever the behavior the dog
uses to "alert"--barking, sitting, scratching at the purported hiding
place--it would be easy to train the dog to perform this behavior when cued
by a command or a hand signal. Then, the dog's handler would have, it seems,
cart blanche to search any home or vehicle for anything, without a warrant,
on the grounds that the dog had 'alerted' to the presence of a controlled
substance.
At this point, I think we've solved the energy crisis.
Just hook a turbine to the graves of the Founders. Washington, Madison,
Adams--they must all be spinning in their graves. Rapidly.
But of course no trainer would be
corrupt, and the incentive to have a Mercedes to drive would never tempt any
policeman, particularly if he knows this is a bad guy. Never.
And for some really
good news:
Subject: QuickTime VR Panorama of NASA Spirit's
Landing Site on Mars
Very cool. Didn't have anything like this in the days
of Viking. The TV said the whole program cost $750 million.
http://www.spaceref.com/news/viewsr.html?pid=11443
Rich
Cool!
=================
Army Uniforms
Mr Pournelle:
The 29DEC03 issue of Army Times has an article on a
military website where soldiers can send in their opinions on the current
Army Class A uniform and post their opinions on what a new Class A uniform
should look like. Some of the examples may surprise you as one looks rather
like something often seen at Star Trek conventions.
https://peosoldier.army.mil/classa/default.asp is the website for
the polling. The polling is conducted anonymously.
-SFC Brian Huss brian.huss@ us.army.mil
Thanks. A good army should have good
dress uniforms. Wearing battle dress doesn't cut it.
C. Northcote Parkinson had much to say
about that.
=====
Jerry,
On a more serious note, in response to Mr. Bartley’s
question about “new” drugs and the implied question about how gullible we
physicians actually are….well, I’m hopeful that I’m not terribly gullible. I
can argue best by analogy. If I build houses and I’ve used lumber to build
houses for years and years, I’m not likely to begin to build houses with
compressed earth just because an article suggest that I do it. In similar
fashion, I don’t prescribe drugs because an article suggests that I do it.
It takes years, in almost every setting, to change my pattern of prescribing
and it takes lots of articles. Even then I’m wary. Of course, the other side
of this is that some sensational new drugs are very slowly adopted because
we doctors don’t change easily.
I’d also humbly suggest that we be a little leery
about an article written in the “Guardian Unlimited” which claims that
“hundreds” of articles in the “medical” journals are written by ghostwriters
and then cites two articles...without asking either the New England Journal
or the Journal of Alimentary Pharmacology to comment. I’ve no doubt that
such articles have been published, and no doubt that scum exists in every
profession, but I’d suggest that the ratio of scum/good guys is heavily
weighted toward good guys in medicine.
Of note, I’ve had the chance to work on articles over
the years and haven’t had anyone offer me “handsomely” or even
“unhandsomely” to ghostwrite said articles. Perhaps my success rate of
publication would have been higher!
Mark Huth (in my role as MD-PhD, FACC and loyal
pournelle reader).
Of note, I saw your request for real data about Mad
Cow disease, but don’t really have the background to comment. If some
pharmaceutical company would like to ghostwrite an article for me and pay me
handsomely to publish it on your site, I’d probably be willing to accept
(with appropriate disclaimer, natch). Heck, we might even be able to get a
nice little cottage industry going here!! Lets say our price is...12 million
dollars a paragraph. I’ll keep you posted if someone responds….grin.
Thanks for the most uncommon sense.
On a lighter vein, same subject, Dr.
Huth says
Subject: On the
subject of snakes, ladders, and spin
Jerry,
One of your recent correspondents wrote about ghost
writers and medical articles. Here is a very useful article from the British
Medical Journal!
http://bmj.bmjjournals.com/cgi/reprint/327/7429/1442
==================================
J
TOP
CURRENT
VIEW Monday |
CLICK HERE for
a Special Request. 
