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 implementation details
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
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?
Clutter,
In our previous episode, Jeremy Cowgar said:
Clutter, maintenance, and somebody has to do both implementation and
maintenance, addition to documentation tool, pretty printer etc.
I wonder how much maintenance would actually have to be done? Once a
language construct is present, does
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),
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 about
