From: Alfie Costa (agcosta@gis.net)
Date: Fri May 05 2000 - 07:03:34 CEST
On 4 May 2000, at 22:23, Miguel Angel <mulinux@sunsite.auc.dk> wrote:
> Ok. So using pointers is faster
Maybe it is safer to say "sometimes faster"?  We shouldn't rush to forget that 
the previous test always had pointers slower.  It could be that pointers are 
only faster when there is a lot going on in the loop, or that it depends on the 
particular overhead of the loop itself.  In my usage of pointers in 'hexd', 
it's uncertain, (without more testing), if pointers were any faster.
> But I still have to recommend to use pointers only when this is a real 
> advantage against clarity (i'm very pascalized :-))
Agreed.  This is also one of the main reasons I like interpreted languages such 
as shells, Forth or even BASIC.  They're slower, but the user can know more.  
In a way clarity is one of the best things about assembly too.  When you say 
"MOV AX, BX", it means only what it says.  It's almost as if optimizing 
compilers have the same disadvantages as complex windowing GUIs -- the same 
standardized user interface everywhere, but you never really know when 
something hidden going on backstage will surprise people, or require some 
unexpected new fee.  Maybe that's not a good analogy though, so here's another: 
a complicated power tool can save time doing the job at hand, but sometimes 
maintaining or understanding the tool is much more work that having no tool at 
all.
On this topic of tools that decrease leisure:  I have an out of print 
translation of an essay by a German named Friedrich Georg Juenger, "The Failure 
of Technology".  It's not obvious when it was written, though it's certainly 
20th century and the US copyright is from 1949.  Juenger, if I haven't misread 
him, seems to believe that all complicated tools make more work than they save!
I bring this author up in hopes of making my complaint about compilers appear, 
in contrast, less radical.
---------------------------------------------------------------------
To unsubscribe, e-mail: mulinux-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: mulinux-help@sunsite.auc.dk
This archive was generated by hypermail 2.1.6 : Sat Feb 08 2003 - 15:27:14 CET