Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote:
>
> >On Wed, 21 Feb 2001, Bart Lateur wrote:
> >
> >> Actually, it's pretty common. Only, most languages are not as
forgiving
> >> as perl, and what is merely a warning in Perl, is a fatal error in
those
> >> languages.
>
> >Examples? I know you're not talking about C or C++.
>
> Visual Basic, for one, or any other BASIC in history. It looks like a
> compiled vs. interpreted thing. C doesn't do any runtime error
checking,
> because of speed reasons. There's no array bounds checking. You can use
> a null pointer when copying a string, which results in an untrappable
> program error ;-). Virtually all interpeted languages, where safety
> reigns over speed, do all of those. Anything out of the ordinary is a
> fatal error.
Ah... point of order:
C doesn't do these checks because it expects you to do so; not because of
language limitations, but because of language level (i.e. "low"... one
step above assembler). VisualBasic actually does surprisingly little,
though it (and Delphi/Pascal) does a bit more than C: otherwise you
wouldn't need an On Error Goto Label in every other function to avoid one
of those hopelessly meaningless MicroSoft-style errors popping up for no
better reason (your code is still good) than that MS is not capable of
providing good libs despite their horriffic overbloat.
Perl was designed to be non-annoying, not inherently correct. A mistake is
still a mistake, just far less likely to totally crash the program (and
the operating system). Actually, in many places, it was designed to make
decent assumptions. This is what's scaring me about all this talk about
exceptions... it can break this mold and make Perl into a "complainer
language" belching up uncaught (don't care) exceptions forcing try/except
blocks around every piece of IO or DB handling. The style
try {
open(FOO, "./foo");
}
catch FileOpenException $e {
die "Drat:" .$e->Message. "\n";
}
is horrifying to me over the normal
open(FOO, "./foo") or die "Drat:$!\n";
The first is just plain unnatural. Geez, it's outright Pythonic (or
Javanic). I'll take (C++):
if((f=open("./foo","r"))==NULL) { ... exit(1); }
over
try {
f = new MyFileClass(f, "./foo", "r");
}
catch ExFileOpenError e {
... exit(1);
}
catch ExFileExistError e {
... exit(1);
}
catch ExFilePermissionError e {
... exit(1);
}
catch ExOpSysError e {
... exit(1);
}
catch ExBadDesignError e {
... exit(1);
}
catch ExMeaninglessError e {
... exit(1);
}
anyday. This doesn't "get error checking out of your way" it shoves it in
your face.
FWIW Perl doesn't do bounds checking because it assumes that if you go out
of bounds then you want to go out of bounds and it creates new bounds. Or
at least that's how I see it. That's not so subtle a difference. The
languages that I've seen do this follow Perl's lead (not the other way
around), and those are very few from what I've seen.
One of my longstanding points of advocacy for Perl has been "I learned
more from perl by experimenting than by reading: no matter what I threw at
Perl, it almost always did it right anyway. I made up bits and pieces of
grammar as I went along." Try that with another interpreted language.
Please don't ascribe angelicity to VB. It's just a bad toy language behind
a wizard gui. It may do bounds checking, but makes up for that by erroring
out at runtime at the stupidest places imaginable and giving no clue
what's wrong without an entire string of GOTO's, and even then it's
doubtful you'll get an error message worth the CPU cycles to display.
p
