[fpc-pascal]OT: Blast from the past

[AITOR.SM]

> > 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
> 
> Whoops, wrong link:
> 
> 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/