Re: Send me a sample prgm in ADA for linked list using access type

[Georg Bauhaus <bauhaus@futureapps.de>]

On Sat, 2006-05-13 at 09:50 -0500, Larry Kilgallen wrote:

> I would suggest sticking to ASCII (values 32-127) for maximum clarity.

I agree that 7 bit character sets guarantee low probability
of misrepresentation on today's machines. On the other hand,
I spend many hours finding serious, unnerving, and costly
character handling bugs in "standard" software packages.
Most of these bugs demonstrate that many programmers somehow
believe that 7bit is anywhere near sufficient. (Maybe for
themselves?) This is why I'd like to question your advice in
two ways.

Fostering 7 bit ASCII habits (32-127) in usenet will invite two
shortcomings of programs, or, pardon me, their programmers,
because you learn that you can get away with it in usenet:

(a) meeting the requirements of real world software,
    on the technical side
(b) software professionalism,
    on the human side


(a) Few computer users find a seven-segment LED display agreeable,
so to speak. These have no 1:1 relation to ASCII but you get the
picture. Usually, 7 bit Text is a serious hindrance, even when
English is the language. For example, shops, insurance companies,
etc. cannot spell Spanish, French, Canadian, Polish, Danish ...
names, titles, addresses etc. Sørensen is not the same person as
Sorensen. [**] (And these all use Latin scripts.) Searching will
not work properly. [*]

(b) lack of true character support is really strange. Many times
programmers have taken pride in algorithms that arrange bits in
a well defined and efficient manner. But when these bits represent
characters, not so. A fair amount of irrationality is added
to what is considered arguments.

"It's slow!"
"It wastes memory!"
"It's too much work!"
"Who needs it?"
"Learn how to read!"

Is any of this backed up with convincing data, measurements,
business requirements, etc.?
At the same time, users are annoyed when they cannot write currency
symbols like £, or €. (Zip codes are rejected if the style is British.
Phone numbers can not be entered using alphabetic characters.
Passwords cannot contain accented characters. Same symptoms?)

Programmers spend hours trying to find ways of rendering or combining
pieces of data encoded differently, or at least find the most likely
applicable encoding. Is this where we should be spending our time?

So, No! It is time to consider that VAX, Alpha, Motorola 68030, x86,
PowerPC, SPARC, etc. have 32 bit words in registers.
We can see that placing 8bit quantities in x86's AL (8 bits wide)
will *not* in general make our programs run faster.
One should think that people who write sophisticated sorting
algorithms, or operating systems' process schedulers for N CPUs
are capable of providing functions for plain text rendering.
All the more when the algorithms have already been published,
and when libraries are freely available, with or without support,
for free or not.
It is time to consider the capabilities of the computers of
today^H^H^H^H^H yesterday.
These can be programmed to handle much more than 127 - 32 + 1
character positions. There are standards and collections,
there is supported software.
ISO/IEC 10646:2003, Unicode >= 3.1, TRON, Mule, whichever.

Santé !


 [*] This is still real, see for example the Oxford Advanced
Learner's Compass, which is the electronic edition of OALD,
an otherwise very good program: When I want to find "master" and
start typing "mas" into the search box, the Find As You Type lookup
gets stuck because seemingly it runs into "maître", and stops
there. (That's ma^itre, if your news reader can't display
Western international plain text.)

 [**] A famous example is the mix-up of surnames Tuttle and Buttle
in the film "Brazil". A bug in a typewriter causes terror.
;-)