Re: ASCII and Unicode lifespan

From: Peter Kirk (peterkirk@qaya.org)
Date: Wed May 18 2005 - 05:07:20 CDT

  • Next message: Hans Aberg: "Re: ASCII and Unicode lifespan"

    On 18/05/2005 06:15, Doug Ewell wrote:

    >Peter Kirk <peterkirk at qaya dot org> wrote:
    >
    >
    >
    >>>It's usually considered better engineering practice to assume that a
    >>>building, a bridge, or a standard will be in existence for a long
    >>>time, and to build it so as to allow incremental upgrades such as
    >>>earthquake retrofitting, than to assume its imminent obsolescence and
    >>>underengineer it.
    >>>
    >>>
    >>True enough, although one needs to be realistic about such things.
    >>There is no point in designing a car to last 50 years when its design
    >>is likely to be obsolete in 10.
    >>
    >>
    >
    >"Its design" is probably where you and I differ. There's no doubt that
    >the internal workings of a car have changed and improved over the years.
    >We have catalytic converters today, not carburetors. But as far as the
    >user-visible parts are concerned, I tend to agree with Curtis; once you
    >close the hood (bonnet), there isn't much
    >difference other than styling between today's cars and those of 50 years
    >ago.
    >
    >

    I was thinking mainly about styling, also about all those internal
    workings which have improved. Try making new automobiles to a 1950s or
    even 1980s design and see how well they sell! For a start you would not
    be allowed to because of all sorts of legally enforced safety etc
    improvements. And then no one would accept the old car for its
    performance, fuel consumption, lack of modern electronic gizmos, etc
    etc, and for its styling.

    >The Cubans, by the way, are probably pretty glad that at least some cars
    >were designed to last 50 years. :-)
    >
    >
    >
    Well, different factors apply in places like Cuba, also Russia where a
    1960s Fiat design is still the best-seller, although even this Lada has
    had many small-scale improvements over the decades. But I am talking
    about the situation in the free and prosperous Western world.

    And perhaps your government's policy towards Cuba would have been more
    successful if all their cars had fallen apart decades ago!

    >>And one needs to allow for necessary incremental upgrades instead of
    >>sticking to over-restrictive stability policies.
    >>
    >>
    >
    >I thought Unicode did allow for incremental upgrades. Isn't that what
    >4.1 was?
    >
    >

    Yes, but it only allowed adding things to the standard, not changing
    most things that were already defined. I am no expert on earthquake
    engineering, but I can imagine that one thing that might be necessary
    would be to cut out part of a long inflexible girder to insert a
    flexible joint. There is no point in adding extra parts if the old
    inflexible part is not removed or modified. Similarly, in a standard it
    may be necessary to cut out certain inflexible parts, or perform major
    surgery on them. But some of the necessary things are not permitted by
    the stability policy.

    >To continue the car analogy, radical design changes in the automotive
    >user interface don't seem to meet with much success or popular approval.
    >You don't see a joystick or a Game Boy-style plus-shaped button in place
    >of the steering wheel, even though our future drivers (and many of our
    >current ones) are most familiar with that UI.
    >
    >
    >
    I wasn't talking about the UI - although someone offlist made the point
    that the UI of an automatic car is significantly different from that of
    an old stick shift. I was talking mainly about what is under the
    bonnet/hood.

    >>After all, when that earthquake comes, flexible structures are
    >>likely to survive, but the inflexible ones which rejected retrofitting
    >>are likely to collapse catastrophically.
    >>
    >>
    >
    >I'd be interested to know what part of Unicode you think is in danger of
    >this type of obsolescence. (You too, Hans.)
    >
    >The ITU alphabets and BCDIC were ill-suited to data processing because
    >of their limited repertoire and non-contiguous letters and digits. ...
    >
    >

    Same problem in Unicode with certain scripts. This probably won't be
    fatal for Unicode, but doesn't help it.

    >...
    >Now, in keeping with this, what problems does Unicode present that will
    >lead to its replacement by something better? ...
    >

    Good question. Well, some of the problems are well-known to those of us
    on this list: wrongly chosen character names, bad combining classes,
    characters defined which should not have been defined, etc etc. But I
    accept that none of these are necessarily fatal to Unicode, although
    they remain an obstacle to its current takeup. But then I am sure the
    designers of ITU, BCDIC, FIELDATA etc were unaware of the problems which
    their standards presented which led to their replacement. And I would
    expect that similarly problems with Unicode will gradually become
    apparent as technology advances.

    >... How will the "something
    >better" solve these problems without introducing new ones? How will it
    >meet the challenge of transcoding untold amounts of "legacy" Unicode
    >data? ...
    >

    In exactly the same way as Unicode has met the challenge of transcoding
    untold amounts of data in what we currently call legacy encodings - i.e.
    by conversion tables, and gradual introduction of the new standard.

    >... How will it respond to the inevitable objections from supporters
    >of other encoding systems as Unicode has done?
    >
    >

    Again, as Unicode has done. Any change will of course be controversial,
    but the time will come (I don't know when, but it is certain to come if
    this planet and civilisation survive) when the pressure for change
    becomes irresistible.

    -- 
    Peter Kirk
    peter@qaya.org (personal)
    peterkirk@qaya.org (work)
    http://www.qaya.org/
    -- 
    No virus found in this outgoing message.
    Checked by AVG Anti-Virus.
    Version: 7.0.308 / Virus Database: 266.11.12 - Release Date: 17/05/2005
    


    This archive was generated by hypermail 2.1.5 : Wed May 18 2005 - 05:10:19 CDT