Conrad's ALFS comments

Bill Maltby LFS Related lfsbill at
Wed Aug 28 02:49:32 PDT 2002

On Wed, 28 Aug 2002, Heinz Kirchmann wrote:

> I knew I shouldn't have answered. Now I'm getting involved into one of 
> those discussions...:-)

Ah, they make life worth living! :)

> > Oh, there are plenty of good reasons! :)
> >  1) Who has time to learn emacs when vim will do?
> >  2) Who has time to learn vim when ed will do?
> Well, don't forget about 'cat'! Real men use 'cat' as editor 
> exclusively.

I like the one I saw on here that Klingon programmers do *not* annotate
their code!

> ><snip>

> >  4) For interpretive languages, like shells, the script at the end of this
> ><snip>

> Nice one! I reanimated my old 486 yesterday (about 33 bogomips) and 
> really could reproduce your results. I admit that I was a little surprised
> by the result, so I agree that all those shell scripts containing 1000
> variables or more should use variable names shorter than 50 characters.
> I think you will see only very few difference in a real functional shell 
> script between using abbreviated versus long-version variable names.

Yes - in *most* real applications and most equipment. The exceptions are
where this would be an issue.

> If performance is an issue, you shouldn't use bash scripts in conjunction
> with heavy variable use anyway.

That's an arbitrary statement. When you need a Q&D (quick and dirty) pro-
cess, the economics (time, money, resources, expertise, beer) available
may dictate that an interpretive language be used. Performance may have
lower priority.

If economics permit, I agree some other language (gawk, C, assembly...) is

My point was only that the increased maintainability of longer names in-
volves a trade-off in performance. So, if you need to do an interpretive
implementation and it is on slow or heavily loaded equipment, you can help
performance by using short names. Maintainability can be helped by in-
creased commentary since it has much less effect (no memory management
needed for comments) and comments can be removed for the production ver-

These same considerations could apply for any non-compiled/assembled im-

> Heinz

Bill Maltby
billm at

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list