NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/c/18961

Text File | 1992-12-29 | 5.3 KB | 120 lines

Newsgroups: comp.lang.c
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: Pascal as road to C (was Re: Newbie Wants Advice on C-Programming)
Message-ID: <[e-mail]>
Summary: There are things worse than none at all ...
Organization: :
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 28 Dec 1992 15:12:37 GMT
Lines: 108

(I've put the history at the _end_ where it's out of the way.)

> >> Pascal has the following advantages over C:
> >>    1) It has structured syntactic blocks for constants, types and
> >>       variables.

> >...  Would you require a cook to measure out all the ingredients specified
> >by tablespoons before measuring any ingredient specified by cups?

> No, but I would require the cook to do the following in order:
>     1) Purchase the ingredients
>     2) Prepare the courses
>     3) Serve the meal

And I think one should design the program, then write the program, then
compile the program, then run the program!

Would you put whipped cream on the berries for dessert before you serve
the appetizers?  Or dress a salad before the beef when you will serve it
after (its proper place, BTW)?  Or flame the dessert before ladling out
the soup?

> ...  you're arguing that it's better to clump related definitions
> together, even though some may be constants and others types or
> variables, such as:

> #define BUFFER_SIZE 10000
> char buffer[ BUFFER_SIZE ];

> I.e., do not have "constant blocks" and "variable blocks".  There are
> strong arguments for both ways, _but_ the Pascal organization is better
> than none at all.

And a dictionary is better for finding words, but an encyclopedia better
for finding knowledge: if the only structure you can find yourself is the
individual declaration, then the Pascal order has an argument, but if you
have a larger structure to your work (and in C you should; in C++ you'd
better) then the Pascal order discards information.  If you are constrained
to it, you'll never learn to raise the level at which you program.

> >The classical Pascal expression of a loop-and-a-half cannot be written
> >as a while() because Pascal's expression syntax is too weak.  ...
> >What results is a circumlocution ... more ... control flow and temporary
> >variable managing than ... problem; This is a very bad form of incohesion:

> >    if not X
> >        manage the loop
> >    else
> >        solve the problem

> Actually, it's a good use of nested procedures.  In C, we have:
>
> while ( TRUE )  {

Actually, it's not.  Typically, the idiomatic C is one half to one
tenth the length of the Pascal style, and more direct, to boot.  Quoting
Kernighan and Plauger, ``How can code that is an order of magnitude too
large be considered reliable?''  And again, ``Jumping around has proved
to be a fruitful source of errors.''  Whether it's done by goto's or
by circumlocutions of a language whose hobbled statement syntax prevents
you from dealing with its stillborn expression syntax, you are still
forced to connect disparate units of code and verify yourself that
they are activated together correctly under the correct circumstances.

That is _not_ structured programming.  Dijkstra to the contrary, there
are only two fundamental constructs in structured programming: Governs
and Invokes.  Governs relates a block of code to the single condition
that activates it as a unit; Invokes relates a block of code to the
remote request that activates it as a unit.  These allow you to trace
efficient causes forward and final causes back; the ability to trace
both kinds of cause is the essence of understanding a program.

Deliberately scattering the statements activated under a single
circumstance across several levels of control structure does not
structure a program; it scrambles it.

> ...  "break" and "continue", as well as mid-function "return"s are nothing
> more than "goto"s in disguise.

Many problems structure themselves quite nicely as a linear set of
cases; many tests will not structure themselves well in any other way.
Like it or not, the loop-and-a-half exists in well-formulated problems.
And the best thing to do with a case that has been handled is to throw
it away (return) and get on to the next case.

> ...  It's a prime example of how C gives beginners enough rope to hang
> themselves.  Someone who's suffered through the strictness of Pascal
> can appreciate exactly when to use "break"s, "continue"s, "goto"s, and
> mid-function "return"s.

Negative training is bad for dogs and bad for people.

The proper training is not fettering and scourging by Pascal but the
discipline of annotating code with provable assumptions and assertions.


(Here follows a sad and weary history ...)

In article <[e-mail]>, [e-mail] (Michael Malak) writes:
> In article <[e-mail]> [e-mail] writes:
> >In article <[e-mail]>, [e-mail] (Michael Malak) writes:
> >> In article <[e-mail]> [e-mail] (Wayne A. Christopher) writes:
> >> >In article <[e-mail]> [e-mail] (Michael Malak) writes:
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ