Here's something published by Brian Kernighan (the "father" of the C programming language) where he rips Pascal. Interesting reading, considering some of it is still true. I had to laugh though -- it's from 1981.

It's a bit long too...

http://www.lysator.liu.se/c/bwk-on-pascal.html

And here is a anwer to that (from an ISO pascaller though)

http://www.employees.org/~samiam/notpascal.html

Whoops, wrong link:

http://www.employees.org/~samiam/clang.txt

It's funny to see, how some things that BWK points out as "flaws" in Pascal, are nowadays considered good and necessary... :-)

Of course there are things that are true, but I am not going to start a C vs. Pascal war here, because it would be pointless (they both have their good and bad sides) and the wars have already been fighted (too) many times before in other forums.

=- ccr/TNSP^pWp
] | http://www.tnsp.org/
] Show me your "realtime raytracer in Java"
] and I'll show you my CBM 8032, 2 MHz!

Quoting Marco van de Voort :

should that not be:

http://www.employees.org/~samiam/clang.txt

Marco, thanks very much for that link.

And about the 'Why Pascal...' etc, I feel now happier, as I see that all (or most) of the problems that the author points up about Pascal seem to be now updated, after BorlandPascal (and FreePascal).

My intention with this message is never a war, but just a reflexion. If someone has something to add, please, do it, and make the thread useful, but please, no wars, no people angry or offended, therefore no saying 'this is better than that'. I am just interested in knowing if you consider that most of the problems that the author pointed about Pascal are outdated. Just for a brief summary:

(1) The following are simply outdated, if I recall correctly
- Lack of initialisation (const a: byte = 5)
- strict order of acceptance (const, type, var...)
- lack of separate compilation (unit, interface, implementation, ...)
- lack of typecast (there is typecast)
- problems with control flow about C's break (there's exit)
- reset/rewrite do not return status/error (solved with IOResult)
- lacks bitwise boolean operators (they exist: OR, AND, XOR, etc.)
- lacks file inclusion ({$I})
- case has no default (there is else)

(2) The size of an array is part of its type: well, there are unbounded arrays as parameters: this is not the same, but after all, this is needed for writing generic array control functions (this is the example the author gives) (but for the 'global' case, you would need to know how much space do you need to allocate, isn't it?)

The author also mentions the problem with eoln/eof. Perhaps this is as the author describes, but I think that good implementations can override this. As for personal experience, I have never had problems with this.

=====

About 'why C...', I am not following the different flavours of C out there, but it seems that the 'features' the author points up haven't been modifided but other different implementations. Personally, I agree with the author, and I would add as well the lack of function hierarchy, which I find very convenient. I mean, you can't do this:

function mybigfun (...);
   function subfunction (...);
   ...
   begin
   ...
   end;
begin
...
end;

and the fact that the switch/case statement looks like an assembler feature rather than a high level programming feature.

===

I would also like to recall a good feature that is proper from FreePascal, and was not implemented in BP, which is the function/procedure/operator overloading.

===

And just to make this message somewhat complete, a superficial comparison with Modula-2, makes these two, in my humble opinion, small disadvantages that I would miss in Pascal. But of course, some (or all) of you may prefer things as they are now.

(1) a stupid one, but I don't like it (conceptually speacking, in practice they are very comfortable ;-)) that the 'read' and 'write' (or +Ln) need 'compiler magic', as they can have a variable number of parameters. In my opinion, this is against portability, as I can't just rewrite a SYSTEM.PPU unit with these two. Of course, I know I can write my own: 'WriteChar', 'WriteString', etc,... (as in Modula-2) And I can't also write a one-parameter generic 'write' statement. The compiler could either give the possibility of multiple parameters, but I know this would give a lot of troubles with the procedure/function overloading.
Therefore, there's not much that can be done about this, never mind...

(2) the possibility of encapsulation. I think this has been addressed with a different name that I can't recall. I miss this as a nice feature, and I would be grateful if someone could give reasons why this has not been implemented (if different from 'lack of time' ;-)), or why do you think it shouldn't be implemented. And I know this can be done in OOP with the public/private directives and property, but I mean this in 'plain' Pascal.
What I mean is:

UNIT Complex;
INTERFACE
TYPE Complex;

PROCEDURE WriteComplex...
PROCEDURE AddComplex...
...

IMPLEMENTATION
TYPE Complex = RECORD Re,Im: real END;

...

Thanks in advance for your attention, patience and information.

Aitor

___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES
Haz clic en http://www.terra.es/correo/

(1) The following are simply outdated, if I recall correctly - lack of typecast (there is typecast)

IMHO pascal's

  a := TStateRec( AStateRec );

is better than a

  a = (b) * (c);

(In C/C++ that can really be a typecast!)