🚀 go-pugleaf

In article <3226@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>Why do I drag all this in? Because I am utterly convinced that this
>entire mindset of forcing the user to be what s/he isn't (careful,
>conscientous etc) is an utter failure. You want a good program? Hire
>a good programmer. You want to become a good programmer? Ya gotta
>work at it. Sorry, ain't no short cuts.
>
>The solution is not to put more restrictions in programming languages
>in an attempt to control the incompetent at the expense of the
>competent. The solution is to teach good design. Design involves
>choices and rules, not removing all the sharp knives from the woodshop
>for fear that some turkey will come in and cut him/herself.
>
>Unfortunately, Pascal makes a false promise it has never been able to
>keep. In fact, it and its successors (at least as of this date) have
>been by and large a failure in practice. Very little code of any use
>has ever been written in them. This is due to the very poor design
>inherent in these. It is not surprising they appeal to those who
>discount careful design and effort as being the ultimate goal. In
>short, the "emperor" has no clothes.

Well, I may missunderstand what you mean, but to me it seems that you are
trying to say that type-checking languages like Pascal, Ada etc are inferior
to languages that are more relaxed at this point, like C. Also you seem
to imply that type checking is only for bad programmers. 

I happen to consider myself as quite a good programmer, and I think
checking of all possible kinds is compulsary. The more the compiler checks 
for me the less errors I have to search for when I test. As I said my program-
mings skills are good - still my own opinion - but unfortunately I make a
lot of carless mistakes. Take this example: (in Pascal)
PROCERDURE Modify(a : integer);
   a := 2*a;
END;
The compiler will accept this, but of course it won't work since I forgot
the "var". In Ada this is not possible. If I don't write anything "a" will
a in-parameter. In-parameters are constants in Ada so the compiler will
not allow me to modify it. If I make "a" an out-parameter, I can't read
from it. The only possible way is in-out.

Or do you think that I'm bad at design just because I make these mistakes?
Actually, I can't escape the feeling that the people who advocates 
relaxed checks are those who are bad at good design. The more of tricks you put
into it, the harder to understand it is. A good programmer don't feel
restricted by a checking compiler, he feels supported.

Finally, one note a bout Pascal since you mention this language. As we all
know, Pascal was never ment for "productive" programming, just for
education. On the other hand, the most compilers do offer extentions
for separate compilation, string handling etc. Of course these extentions
doesn't make Pascal very portable. By the way, as far as I know the most
of TeX is written in standard Pascal, but you perhaps would call that
useless software?

In article <1635@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes:
>As we all know, Pascal was never ment for "productive" programming,
>just for education. On the other hand, the most compilers do offer
>extentions for separate compilation, string handling etc. Of course
>these extentions doesn't make Pascal very portable. By the way, as
>far as I know the most of TeX is written in standard Pascal, but
>you perhaps would call that useless software?

Actually, TeX is written in WEB, which provides much of what is
needed to make Pascal usable.  TeX makes extensive use of a default
case, which is not standard (and indeed not available in Berkeley
Pascal: people using the Berkeley Pascal compiler on Vaxen must
first run the Pascal output from Tangle through `pxp -O', at a cost
of 15% slower execution than with a modified compiler).  TeX also
uses a handful of extensions for `real I/O', all coded as WEB macros
so that the system-specific version may be inserted in line in the
many places it is needed.  Interestingly, TeX does NOT use `new'
and `dispose', probably because these are not properly implemented
in many `standard' and even `extended' Pascals!

The one major extension WEB cannot provide is separate compilation,
and I sorely miss it whenever I work with the TeX sources.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

In article <1635@enea.UUCP> sommar@enea.UUCP (Erland Sommarskog) writes:
>Well, I may missunderstand what you mean, but to me it seems that you are
>trying to say that type-checking languages like Pascal, Ada etc are inferior
>to languages that are more relaxed at this point, like C. Also you seem
>to imply that type checking is only for bad programmers. 

Let the compiler do the type checking... so long as it stays there. Pascal
puts in a lot of code for array overruns, etc., that are unnecessary for
a well-designed program. You could turn all this off on the Pascal I learned
on, which made it tolerable. But I don't want anything in the program I didn't
put there -- if I'd wanted subscript checking, I would have added it.
-- 
....!ucbvax!hplabs!amdahl!drivax!holloway
"What do you mean, 'almost dead'?" "Well, when you stop breathing, and moving
around, and seeing things... that kind of almost dead."

Building on a followup by sommar@enea.UUCP (Erland Sommarskog):
>
>In article <3226@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>>The solution is not to put more restrictions in programming languages
>>in an attempt to control the incompetent at the expense of the
>>competent.

  Who said we were trying to control the incompetent? You know, I wear
boots when I use my axe, even though I have a lot of experience
with axes.  I like to protect myself against mishaps.

>> The solution is to teach good design.

  This is a very funny argument; a "good design" will be largely independent
of language.  The more powerful (i.e. permissive) the language, the
weaker its compiler.  The "highness" of a language determines the
strength of its compiler, and deals primarily with PROGRAMMING, not DESIGN.
The fact that I typed = when I meant == in C is NOT a design issue,
it's a programming issue.

>> Design involves
>>choices and rules, not removing all the sharp knives from the woodshop
>>for fear that some turkey will come in and cut him/herself.

Even the "competent" wordworker wears safety glasses.

>>
>>Unfortunately, Pascal makes a false promise it has never been able to
>>keep. In fact, it and its successors (at least as of this date) have
>>been by and large a failure in practice. Very little code of any use
>>has ever been written in them.

Got Data?  I've done a lot of real-time image-processing code in
Pascal (perhaps 100,000 lines of source delivered), and wonder how
much of a failure it was.  I don't claim Pascal is the Platonic
programming language; there is no such thing.  But more often than not
it's my language of choice, because it will allow me to do the job
more quickly, and with fewer errors, than the other contenders.  I've
had great success with Pascal programs which call occasional assembly
language or C routines when low-level machine access is required.

>Well, I may missunderstand what you mean, but to me it seems that you are
>trying to say that type-checking languages like Pascal, Ada etc are inferior
>to languages that are more relaxed at this point, like C. Also you seem
>to imply that type checking is only for bad programmers. 

  That's what I read from the argument too.  And that's precisely the
opposite of my opinion.  My rule is "Use the highest level language
which will do the job, because that brings the most powerful
compilation tool to bear and reduces the number of errors which hit run-time.
  The egos of a lot of programmers cause them to miss an important
point:  beyond a fairly short start-up, a programmer's error rate does
not substantially decline as a function of experience.  This is partly
due to psychological learning issues, and partly because task load
often increases with experience, with reduced attention masking any
improvement in the error rate.

>Or do you think that I'm bad at design just because I make these mistakes?
>Actually, I can't escape the feeling that the people who advocates 
>relaxed checks are those who are bad at good design. The more of tricks you put
>into it, the harder to understand it is. A good programmer don't feel
>restricted by a checking compiler, he feels supported.

Right-on.  I regard programming as a means to an end, and thus take
an "engineering" point of view (as opposed to a "for the fun of it"
point of view).  When I write a program (even for my own use only)
I want to minimize the amount of time I have to spend scrutinizing the
code (let a strong compiler do that), and maximize the likelihood that
I'll be able to read and understand the program a year or more later.
This is even more important when developing software for others.
Since there is an inverse relationship between the power of the
language (i.e. what it lets me do) and the strength of the compiler
(i.e. what mistakes it won't let go by), I choose the WEAKEST language
that will still do the job, and thus use the most POWERFUL compiler
I can.  Remember, fans, even K&H assert that C is only a "relatively
low level language" ["The C Programming Language", Kernighan and
Ritchie, Prentice-Hall 1978].  Is it a powerful language? YES (and fun,
if that's what you want)!  Does it have a strong compiler? NO, it
can't!  So many things are legal in C that erroneous code often goes
by, because it looks like some other legal construct.

Steve Frysinger
****
Remember what the doormouse said: "Feed your head!"
		-- Jefferson Airplane

Be careful when you use terms like "high level" and "strong typing".
Just because a language is called by some people "strongly typed" by
some people doesn't mean much.  Pure Pascal, which doesn't even let you
write a function to manipulate strings without knowing their lengths,
is strongly typed by some definitions (and a good example of why by
those definitions strong typing is a bad thing), but is not strongly
typed by other definitions because you can convert values from one type
to another with unions.  Sure, argument checking is good, but if you
take the philosophy a bit further and eliminate anything like casts you
have made the language useless.  You have to be able to protect the
user against inadvertent errors without preventing him from doing just
about anything he wants when he really wants to...

	Wayne

In article <745@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes:
>
>Pascal puts in a lot of code for array overruns, etc., that are unnecessary for
>a well-designed program. You could turn all this off on the Pascal I learned
>on, which made it tolerable. But I don't want anything in the program I didn't
>put there -- if I'd wanted subscript checking, I would have added it.

Turning off compiler checking after the program is debugged is like 
throwing away your lifeboats after the maiden voyage.

	-Adam.

In article <492@gec-mi-at.co.uk> adam@gec-mi-at.co.uk (Adam Quantrill) writes:
>Turning off compiler [array bounds] checking after the program is
>debugged is like throwing away your lifeboats after the maiden voyage.

Let me be the first to responed to your letter.  I am not sure
about you, but I would rather have a program that runs faster, and
in one chance in a couple thousand `goes down in flames' than a
program that runs slower and in one chance in a couple thousand
says something to the effect: `FATAL: array overflow'...
Also, I think your analogy is a bit off. `My boats DONT sink',  8->
therefor, why WASTE money on lifeboats? :-)
-- 
Mike Stump, Cal State Univ, Northridge Comp Sci Department
uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs

>In article <745@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes:
>
>Pascal puts in a lot of code for array overruns, etc., that are unnecessary for
>a well-designed program. You could turn all this off on the Pascal I learned
>on, which made it tolerable. But I don't want anything in the program I didn't
>put there -- if I'd wanted subscript checking, I would have added it.

I hope you use  Berkeley Pascal Bruce because it doesn't have 
complete bounds checking. I was held up for ages a few months ago
when I was trying to find this a bug that suddenly appeared after a mass
of bug fixes ( I know I should have done them one at a time ).

However what was happening was that the program was reading into a 
character array in a record, reaching the end and reading into the
next data area. The checking worked fine if the next area was an integer
or such like because a type clash error would come up. However if the
subsequent was of type char or an array of type char the program kept
on reading in with no warnings.

The bound checking may be on but don't ever take it for granted.

Gareth



-- 
" I am a doughnut "  JFK

UUCP:  ...!seismo!mcvax!ukc!dcl-cs!gareth
DARPA: gareth%lancs.comp@ucl-cs	  JANET: gareth@uk.ac.lancs.comp

In article <492@gec-mi-at.co.uk>, adam@miduet.UUCP writes:
> In article <745@drivax.UUCP> holloway@drivax.UUCP (Bruce Holloway) writes:
>>Pascal puts in a lot of code for array overruns,etc., that are unnecessary for
>>a well-designed program. You could turn all this off on the Pascal I learned
>>on, which made it tolerable. But I don't want anything in the program I didn't
>>put there -- if I'd wanted subscript checking, I would have added it.
> Turning off compiler checking after the program is debugged is like 
> throwing away your lifeboats after the maiden voyage.
> 	-Adam.
Bruce never said anything about debugging the program.  He said well designed.
The verb 'debug' does not really have a past tense as it is never possible to 
be sure you are done.

Of course, if Bruce really doesn't want anything in the code he didn't put there
then he really ought to be programming in assembler.

The pascal(*) I program in on a regular basis allows you to turn this off for
selective portions of the code.  I use this quite often to reduce the
space and improve performance of the code.  However, I have to thoroughly
convince myself that this bit of optimization is safe before doing it.

--j.a.tainter

*UCSD Pascal is one of the best pascal supersets around, the only serious flaw
is 16 bit pointers