Juha Manninen schrieb:
> Please look at some old Pascal code from 80's. Lots of shortstring
manipulation with pointers. Very much comparable to C, and as prone to
errors as C.
Yes, new string types were needed. But why not doing it right in one
step? Instead we now have lots of different string representations which
all have their own peculiarities which everybody has to learn. To me it
seems that all these changes were hasty hacks and are now cast in stone
to live forever in the (object) Pascal language to annoy following
generations of Pascal programmers. If things are only added and nothing
is ever removed than the language becomes bloated.
> It is good to realize that Pascal would have died already without the
class/object additions made by Borland.
I doubt that. I don't see any merrit in objects. You can do all the same
with units that declare functions and data types. You can also build an
IDE that helps you finding functions/procedure that act on special data
types. There is no innovation in object oriented programming. Just the
opposite: If I create a button "object" on my form that does something I
would expect it to act when I click on it. But that does not happen
because in the background there is still the procedural processor that
goes through a sequential list of commands. Real objects would be able
to act independently and can interact. But this would require a core for
each object which I fail to see in the near future.
I am just thinking how a child or teenager who learns programming would
think about it. He may not unterstand why you need to add
"Application.ProcessMessages;" calls into loops to keep the button
responsive. This is hiding away important information. Instead of OOP it
should have been named DAF (Data Attached Functions) or so.
Also, why can operators be overloaded? Operators are fundamental parts
of a programming language and to me it makes no sense to irk programmers
by changing its meaning.
Also, why suddenly extend the meaning of := ? It should be a simple byte
movement, nothing else (only exception should be number type
convertion). Doing arbitrary complex things when using it does not make
a clearer code. And for what reason? Just to save writing a function
call? That cannot be the direction to go. Maybe we see BEGIN and END and
the semicolon doing things too. How can one read such code? And how much
does a new user have to learn to use the Pascal language?
It could also be that it's only a matter of documentation and learning.
As many others I don't have very much time to read about and test new
features. And I also don't have to. I never failed to do what I wanted
and it was very speedy (unless I had to use some obscure "library" which
was slow) and the code is still clear and readable.
> The challenge is to add only the RIGHT features.
That's true. But now the mark is overshot already.
> IMO the OP additions have been good so far. For example generics
containers eliminate ugly type-casts. It is an improvement, clearly.
I can't say anything about this because I don't know the concept.
> Closures seem like a powerful thing which can improve code.
Same as for closures, I don't know them.
> Now Florian mentioned that procedure variables could do the same
thing. I clearly don't understand the topic enough, I must learn more.
I see that many of these new concepts are added because people come from
other languages and want to do things the same way. But often it can
already be done with the existing language and even faster. I was able
to code everything I wanted in the past 25 years without objects and
without closures and all this other stuff. But if I now try to
understand foreign code I am totally lost because here these things are
used.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
