leledumbo wrote:
OK, I've read http://wiki.freepascal.org/Modernised_Pascal this (and the
FAQ as well). I disagree with any statement saying that for .. in loop is
only a type-saver. It's a good language extension and should be included
(since Delphi already have this, it will also be a good id
Vinzent Höfler wrote:
Jürgen Hestermann wrote:
Mantra: First make it work, then make it fast.
In general that's true from the programmer's viewpoint. But this does
not apply to adding language details because there is no 'first make
it work'. Why obscure important implementation details if th
On 08 Jan 2009, at 19:01, Jürgen Hestermann wrote:
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 abou
>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 debugge
Marco van de Voort wrote:
In our previous episode, Jeremy Cowgar said:
What is the negative of adding it?
Clutter, maintenance, and somebody has to do both implementation and
maintenance, addition to documentation tool, pretty printer etc.
I wonder how much maintenance would actua
In our previous episode, Jeremy Cowgar said:
> > However IMHO that doesn't meant you are right. One single case of an
> > optimalization advantage, and then in a border case like iteration over a
> > constant set does not justify a language extension.
>
> What is the negative of adding it?
Clutte
Marco van de Voort wrote:
In our previous episode, leledumbo said:
The latter one has iteration overheads, while the former can be optimized to
loop as many as needed. I'm not saying I'm the best Pascal programmer, but
in case there's a (better) solution to this (rather than extending the
la
Vinzent Höfler schrieb:
> Jürgen Hestermann wrote:
>
>>> Mantra: First make it work, then make it fast.
>>
>> In general that's true from the programmer's viewpoint. But this does
>> not apply to adding language details because there is no 'first make
>> it work'. Why obscure important implementat
> 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.
Jürgen Hestermann wrote:
Mantra: First make it work, then make it fast.
In general that's true from the programmer's viewpoint. But this does
not apply to adding language details because there is no 'first make it
work'. Why obscure important implementation details if the only benefit
is sa
P.S. Honestly, Pascal (and especially ObjectPascal) already hides quite
some stuff from the programmer. Properties, for example, can hide
potentially costly procedure calls in simple assignment statements.
That's true. But I am not happy about that approach. In the last years
lots of things we
the nice thing about pascal, is that compile support different code
compilers syntax: {$mode ...}
if anyone likes, he/she can implement additional {$mode} for the
compiler, right? this new {$mode} can be included into compiler
packages, and if necesssary anyone can rebuild the compiler to support
Jürgen Hestermann wrote:
I disagree with any statement saying that for .. in loop is
only a type-saver. It's a good language extension and should be included
(since Delphi already have this, it will also be a good idea).
Consider the
following example:
for d in [Monday,Wednesday,Friday] do ;
I disagree with any statement saying that for .. in loop is
only a type-saver. It's a good language extension and should be included
(since Delphi already have this, it will also be a good idea). Consider the
following example:
for d in [Monday,Wednesday,Friday] do ;
// versus
for d:=Low(TDa
leledumbo schreef:
OK, I've read http://wiki.freepascal.org/Modernised_Pascal this (and the
FAQ as well). I disagree with any statement saying that for .. in loop is
only a type-saver. It's a good language extension and should be included
(since Delphi already have this, it will also be a good
In our previous episode, leledumbo said:
> The latter one has iteration overheads, while the former can be optimized to
> loop as many as needed. I'm not saying I'm the best Pascal programmer, but
> in case there's a (better) solution to this (rather than extending the
> language) please tell me.
16 matches
Mail list logo