Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #5997 > unrolled thread

unicode is a fail

Started byfir <profesor.fir@gmail.com>
First post2015-12-01 08:34 -0800
Last post2015-12-02 09:53 -0800
Articles 5 — 2 participants

Back to article view | Back to comp.programming


Contents

  unicode is a fail fir <profesor.fir@gmail.com> - 2015-12-01 08:34 -0800
    Re: unicode is a fail Mark Carroll <mtbc@bcs.org> - 2015-12-01 17:43 +0000
      Re: unicode is a fail fir <profesor.fir@gmail.com> - 2015-12-02 08:00 -0800
        Re: unicode is a fail Mark Carroll <mtbc@bcs.org> - 2015-12-02 16:32 +0000
          Re: unicode is a fail fir <profesor.fir@gmail.com> - 2015-12-02 09:53 -0800

#5997 — unicode is a fail

Fromfir <profesor.fir@gmail.com>
Date2015-12-01 08:34 -0800
Subjectunicode is a fail
Message-ID<4466b45b-1a0a-4b55-8d60-c8bee032b294@googlegroups.com>
Im personally still using asci in all my private apps and i shiver (a bit) to use unicode as i read from time to time text that says unicode is a pain (at least in some situations)

This directs me to think that unicode is in general a fail.. Unicode could go the way and become something maybe even simpler than ascii but gone a bit in a wrong way of making a lot additional mess

I thing then that maybe one posible recovery scenerio is to use damn utf-32 only, everywhere you coud and try to forget and deprecate the other part of the mess

what do ya think?

[toc] | [next] | [standalone]


#5998

FromMark Carroll <mtbc@bcs.org>
Date2015-12-01 17:43 +0000
Message-ID<87vb8i83oq.fsf@ixod.org>
In reply to#5997
On 01 Dec 2015, fir wrote:

> Im personally still using asci in all my private apps and i shiver (a bit) to
> use unicode as i read from time to time text that says unicode is a pain (at
> least in some situations)

Yes. There is a lot of complexity mixed in with it, rather entailed by
the problems it aims to solve.

> This directs me to think that unicode is in general a fail.. Unicode could go
> the way and become something maybe even simpler than ascii but gone a bit in a
> wrong way of making a lot additional mess

It's very widely used now though. For a lot of my workflows, via various
languages and libraries, they're cleanly Unicode all the way through,
requiring little work on my own part to achieve that. Waiting a while
was key, now there is all manner of free built-in stuff and third-party
libraries, like Pango's support for OpenType fonts, that will do much of
the common harder stuff for you. It's really only quite rarely, with
rather old software (like Basser Lout, which has been in maintenance
mode for years) or old protocols (e.g., Reverse Gossip Transfer
Protocol!) that are instead ISO-8859-based, where I find anything
lacking these days. I rarely have to think about it all except, for
instance, in small ways like when trying to support Python 2.7 scripts
that still need a u-prefix for literals, or remembering to use XeTeX
instead of LaTeX.

For a while now, the main software I work on has required a Unicode
database backend, and I don't recall any of our users complaining. (We
handle dimensioned units like µm and Å.)

> I thing then that maybe one posible recovery scenerio is to use damn utf-32
> only, everywhere you coud and try to forget and deprecate the other part of
> the mess
>
> what do ya think?

Yes, at least I usually see UTF-8 or UTF-16 in use, and I try to just
use those all the way through. Similarly, with other complications like
time zones, I like to just use UTC / Zulu all the way through and just
convert in the presentation layer.

Personally, I'd be happy with ISO-8859-15 plus arrows, but I'm not
having to handle text in Chinese, Arabic, etc. True l10n and i18n even
just in Western Europe come with all manner of tricky challenges
presented by the inconvenient complexity of the real world.

-- Mark

[toc] | [prev] | [next] | [standalone]


#6000

Fromfir <profesor.fir@gmail.com>
Date2015-12-02 08:00 -0800
Message-ID<6a401998-fed6-4dd9-ac7f-4778e47cf8ff@googlegroups.com>
In reply to#5998
W dniu wtorek, 1 grudnia 2015 18:44:00 UTC+1 użytkownik Mark Carroll napisał:
> On 01 Dec 2015, fir wrote:
> 
> > Im personally still using asci in all my private apps and i shiver (a bit) to
> > use unicode as i read from time to time text that says unicode is a pain (at
> > least in some situations)
> 
> Yes. There is a lot of complexity mixed in with it, rather entailed by
> the problems it aims to solve.
> 
> > This directs me to think that unicode is in general a fail.. Unicode could go
> > the way and become something maybe even simpler than ascii but gone a bit in a
> > wrong way of making a lot additional mess
> 
> It's very widely used now though. For a lot of my workflows, via various
> languages and libraries, they're cleanly Unicode all the way through,
> requiring little work on my own part to achieve that. Waiting a while
> was key, now there is all manner of free built-in stuff and third-party
> libraries, like Pango's support for OpenType fonts, that will do much of
> the common harder stuff for you. It's really only quite rarely, with
> rather old software (like Basser Lout, which has been in maintenance
> mode for years) or old protocols (e.g., Reverse Gossip Transfer
> Protocol!) that are instead ISO-8859-based, where I find anything
> lacking these days. I rarely have to think about it all except, for
> instance, in small ways like when trying to support Python 2.7 scripts
> that still need a u-prefix for literals, or remembering to use XeTeX
> instead of LaTeX.
> 
> For a while now, the main software I work on has required a Unicode
> database backend, and I don't recall any of our users complaining. (We
> handle dimensioned units like µm and Å.)
> 
> > I thing then that maybe one posible recovery scenerio is to use damn utf-32
> > only, everywhere you coud and try to forget and deprecate the other part of
> > the mess
> >
> > what do ya think?
> 
> Yes, at least I usually see UTF-8 or UTF-16 in use, and I try to just
> use those all the way through. Similarly, with other complications like
> time zones, I like to just use UTC / Zulu all the way through and just
> convert in the presentation layer.
> 
> Personally, I'd be happy with ISO-8859-15 plus arrows, but I'm not
> having to handle text in Chinese, Arabic, etc. True l10n and i18n even
> just in Western Europe come with all manner of tricky challenges
> presented by the inconvenient complexity of the real world.
> 
tnx for comment 

i think general convention of using utf-32 everywhere could repair this mess maybe though 1) some maybe can see this crazy as utf-32 is probably now least used 2) im not sure (if utf-32 is as simple as it should i mean one letter is one 32-bit int in memory and no other things do  occur)

[toc] | [prev] | [next] | [standalone]


#6001

FromMark Carroll <mtbc@bcs.org>
Date2015-12-02 16:32 +0000
Message-ID<87h9k0stf1.fsf@ixod.org>
In reply to#6000
On 02 Dec 2015, fir wrote:
(snip)
> i think general convention of using utf-32 everywhere could repair this mess
> maybe though 1) some maybe can see this crazy as utf-32 is probably now least
> used 2) im not sure (if utf-32 is as simple as it should i mean one letter is
> one 32-bit int in memory and no other things do occur)

If one's typically working with text that ISO-8859 could handle,
UTF-32 is a fairly wasteful way of storing such text.

-- Mark

[toc] | [prev] | [next] | [standalone]


#6002

Fromfir <profesor.fir@gmail.com>
Date2015-12-02 09:53 -0800
Message-ID<1e65e38b-8282-4c12-b639-2194dcadf471@googlegroups.com>
In reply to#6001
W dniu środa, 2 grudnia 2015 17:32:24 UTC+1 użytkownik Mark Carroll napisał:
> On 02 Dec 2015, fir wrote:
> (snip)
> > i think general convention of using utf-32 everywhere could repair this mess
> > maybe though 1) some maybe can see this crazy as utf-32 is probably now least
> > used 2) im not sure (if utf-32 is as simple as it should i mean one letter is
> > one 32-bit int in memory and no other things do occur)
> 
> If one's typically working with text that ISO-8859 could handle,
> UTF-32 is a fairly wasteful way of storing such text.
> 
not really wastefull imo (same wastefull is working on ints or 'wide' pointers when often you use smaller range)
bit wastefull maybe it could be in socket communication but cannot commpesion be convenient to use here? (im not sure maybe that would be a bit of burden)

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web