Re: New Book: The School of Niklaus Wirth

Orlando Llanes wrote:
>
> Despite Pascal's lacks and quirks I love the language, but I can't honestly
> say that it is better than C/C++, nor can I agree that C and/or C++ are
> poorly designed.


Each is a tool with a designed with different purpose and has a
historical context of development. As such, there is no 'better'. But...




>
> I'm sorry, but I'm going to have to disagree here, Pascal was
> created as a language to teach structured(?) programming. Problem is
> that if you learn Pascal (or BASIC, but it's not as bad with BASIC)
> before learning C/C++, your C/C++ learning curve will increase
> tremendously.


I have to disagree. Pascal more clearly distinguishes between
different concepts than C and makes things much easier for the
beginner. The beginner, then with pascal behind them, can 'map' the
pascal concepts onto C's sometimes weird variations and odd syntax
without getting confused.


Prime example: an array is NOT a pointer, nor a contiguous range of
memory. It happens to be implemented as a pointer to a range of memory
in C and perhaps for good reason but if you fail to distinguish
clearly between the concept of a vector of addressable elements, and a
pointer aimed at some region of memory, your beginner will get
confused. I know what a beginner would expect if they wrote


"hello world" + '!'


but they would't get it. I'd say that the pascal clarifies concepts,
very deliberately and carefully. For pragmatic reasons, C doesn't.
I'm very impressed with the design of both; it's just that they have
different purposes.


> As for being able to adapt to customer demands, it would
> be more accurate to say that "Pascal is being extending to function
> more like C++".


As pascal got used for more than teaching, the very restrictive nature
meant that it had to be extended. Early pascal had no
'default/otherwise/else' construct on the end of its case
statement. That was a serious omission but that was actually
deliberate. It had to be added. Likewise it had full-evaluation for
logical expressions. That was because this mirrored the mathematical
properties of 'and' and 'or' and immediately gave them certain
well-understood behaviour. That meant it did NOT have the very nice
properties that short-circuit boolean evaluations had, and you had to
write more nested ifs to get the same result. Short circuiting was too
nice to miss, I think, and had to be added. No separate compilation,
too. No string types except string literals, IIRC No 'address of'
(everything came off the heap) No bitwise and/or etc. etc.


Pascal was a teaching language and shouldn't have been used for
otherwise IMO. Wirth produce or was involved in a slew of more pragmatic
languages:
pascal 2 (obscure - saw one advert in Byte for this, not another word
before or since)
modula (never released)
modula 2
modula 3
oberon
euclid (with C.A.R. Hoare? Castrated pascal, designed for formal proofs)
(others?)


> I also have to disagree here. C++ has its quirks, but when
> comparing C++ to OO Pascal, one of my pet peeves is that Pascal does
> not call its constructor or destructor automatically (it's
> incredibly annoying that your virtual functions cause a program
> crash because they were not initialized).


(NB I take your 'OO Pascal' to mean Delphi pascal)
I sort of see what you mean, but that is not major. In delphi, if you
define a class method:


function myclass.DogType: BarkClass


then all descendants of myclass overriding DogType have to be defined as
returning BarkClass - full stop. Not the YapClass subtype of BarkClass,
which is useful and completely type safe.
Now, I consider that serious.


Also in delphi pascal, all objects are heap allocated which makes it
inefficient. Also you have to manually destroy class-type local objects.
In C++ you define them as any other and they get cleaned up
automatically when the function exits, even in the presence of an
exception IIRC (it's been three happy years since I touched C++).


> Also, why on Earth would anyone want
> multiple constructors


// terrible, but for illustration
class StoreValue
{
bool StoreType; // true for string, false for integer
char* str;
int intgr;


StoreValue(char* s) { StoreType = true; str = s; }
StoreValue(int i) { StoreType = false; intgr = i; }
}


How else would you cleanly do this?


> or multiple destructors?


More difficult. Doesn't C++ require a placement delete corresponding to
each placement new?


Generally speaking,
> Pascal is strict on type checking which does not allow for
> overloading. One more Pascal pet peeve, why is there no unsigned
> integer (one of my biggest pet peeves)?


Don't you have a Cardinal type?
Depending on what you want to do with it, define your own:


type MyCardinal = [0..maxint];


> "{" and "}" or "begin" and "end" can make
> a program unreadable by nesting in as little as 3 levels.


Except in very regular code I don't get beyond about 3 levels. Too much
nesting is usually a good hint that something needs splitting off,
though that is just my style.


Regarding well designedness of C++:
I do believe that stroustrup said that he didn't like the size and
complexity of it - in 1995.
I have seen the word 'disgust' used by one of the people involved in C++
regarding the unification of structures and classes.
Stroustrup described C's syntax as a "mistaken experiment". It seems
that this has caused him some serious pain, both in use and writing a
parser for.
I once asked to his face
"Do you regret basing C++ on C?"
He said, verbatim:
"Do I regret basing C++ on C? Of coure I do"
He made it clear in that same talk that he really, really did not like
the type checking he inherited from C and mostly had adhered to.


> I wish there was a programming language like the script language
> I'm working on.


More than likely there is. Look around first. Off the top of my head
there, javascript, TCL, curl, python, perl, rexx, awk & sed. There's
surely something right for you in existence. Hope you find it.


- jan

Return to the comp.compilers page.
Search the comp.compilers archives again.