>Vinzent Höfler schrieb:
> I won't judge on the "only save some writing" here, but generally it
> *does* apply to language features: If a particular language feature
> helps you writing correct code faster (by supporting you to make it work
> instead of relying on your abilities to use the debugger), then it does
> apply.
What I fear (from observing the last decade or two) is that the language
becomes bloated by adding one gimmick after the other just to say "me
too". Every new feature is something that a (new) user has to learn
about. And the more types of FOR loops you add the more confusing it gets.
> Let me take a rather extreme point of view: After all, all those for-,
> while-, and repeat-until-loops are only there to save you from some
> typing work[0], because Pascal already has a perfectly good
> loop-construct with which you can do all that: goto. Would you agree
> here? Probably not.
Of course not. But would you on the other side agree with adding each
and every gimmick mankind can think of? Probably not either.
>> Maybe, but you started talking about performance. ;-)
> Nono, you did: "Everything that obscures what's going on under the hood
> has the potential to generate performance problems."
You are right that not you started talking about performance but
"leledumbo" in his starting post about this topic where he assumed a
performance gain:
"The latter one has iteration overheads, while the former can be
optimized to loop as many as needed."
So none of us started talking about it. ;-)
> So to get to the point, finally: The argument that some particular
> language construct has the potential to generate performance problems is
> NIL. IMNSHO.
I doubt that. I often stumble over programs which are awfully slow
(Novell Salvage Dialog for examples sometines needs many minutes to sort
80 "objects"!). And that compared with the everywhere heard statement
"You don't need to think about performance, it's only important that it
runs at all" makes me thinking. Many programmers simply don't know about
how their mighty language functions perform and what they do in the
background. But without knowing this you don't even have an idea of how
fast it will be.
I also had such experience with Virtual Pascal where the
FindFirst/FindNext API functions are obscured by an extra layer to
support multiple platforms (which I didn't know at first). I only
wondered why my simple scan program for the creation date of files took
2 days on our server. After removing all the overhead by directly using
FindFirst/FindNext from the windows API it boosted up to 6 hours only.
Sure, many people don't care whether a program runs 2 days or 6 hours
but I do.
Jürgen Hestermann.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
