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

Groups > comp.arch.embedded > #23449 > unrolled thread

Decimal Point vs. Decimal Comma

Back to article view | Back to comp.arch.embedded

Contents

  Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-02 17:49 -0400
    Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-03 06:23 +0000
      Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-03 02:59 -0400
      Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-03 23:14 +0000
        Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 07:18 +0300
          Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 07:48 +0300
    Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-03 09:45 +0300
    Re: Decimal Point vs. Decimal Comma Nils M Holm <nmh@ananda.local> - 2016-04-03 07:32 +0000
    Re: Decimal Point vs. Decimal Comma George Neuner <gneuner2@comcast.net> - 2016-04-03 05:25 -0400
      Re: Decimal Point vs. Decimal Comma Robert Wessel <robertwessel2@yahoo.com> - 2016-04-03 17:22 -0500
    Re: Decimal Point vs. Decimal Comma Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2016-04-03 14:05 +0200
    Re: Decimal Point vs. Decimal Comma Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-04-03 14:18 +0200
      Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-03 20:24 +0300
        Re: Decimal Point vs. Decimal Comma Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-04-03 21:05 +0300
          Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:00 +0000
        Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-03 21:16 +0300
          Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:17 +0000
            Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 12:46 +0300
              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 06:02 +0000
        Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-03 23:21 +0000
          Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-04 07:11 +0000
            Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-04 21:11 +0000
        Re: Decimal Point vs. Decimal Comma Robert Wessel <robertwessel2@yahoo.com> - 2016-04-04 00:13 -0500
          Re: Decimal Point vs. Decimal Comma "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2016-04-04 14:06 +0200
        Re: Decimal Point vs. Decimal Comma Nobody <nobody@nowhere.invalid> - 2016-04-05 03:32 +0100
          Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-05 09:56 +0300
            Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-05 10:03 +0000
              Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 21:42 +0000
            Re: Decimal Point vs. Decimal Comma George Neuner <gneuner2@comcast.net> - 2016-04-05 11:11 -0400
              Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-05 11:33 -0500
              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-06 12:50 +0000
          Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 07:15 +0000
            Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 21:50 +0000
              Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-06 01:18 +0300
                Re: Decimal Point vs. Decimal Comma Charles Allen <ccallen@iceland.freeshell.org> - 2016-04-06 15:20 +0000
                  Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-06 18:58 +0300
                  Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-07 07:04 -0700
                    Re: Decimal Point vs. Decimal Comma Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-04-07 23:40 +0200
                      Re: Decimal Point vs. Decimal Comma lasselangwadtchristensen@gmail.com - 2016-04-07 16:04 -0700
                        Re: Decimal Point vs. Decimal Comma David Brown <david.brown@hesbynett.no> - 2016-04-08 09:50 +0200
                          Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-09 01:01 -0400
                            Re: Decimal Point vs. Decimal Comma David Brown <david.brown@hesbynett.no> - 2016-04-09 13:48 +0200
                    Re: Decimal Point vs. Decimal Comma mac <acolvin@efunct.com> - 2016-04-11 18:52 +0000
                Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 23:11 +0000
                  Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-09 03:19 +0300
                    Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-09 15:04 -0700
                      Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-10 01:49 +0300
                        Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-12 11:48 -0700
                          Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-12 22:53 +0300
                            Re: Decimal Point vs. Decimal Comma Paul <paul@pcserviceselectronics.co.uk> - 2016-04-12 23:03 +0100
                              Re: Decimal Point vs. Decimal Comma David Brown <david.brown@hesbynett.no> - 2016-04-13 09:21 +0200
                                Re: Decimal Point vs. Decimal Comma Paul <paul@pcserviceselectronics.co.uk> - 2016-04-13 16:51 +0100
                    Re: Decimal Point vs. Decimal Comma mac <acolvin@efunct.com> - 2016-04-11 18:52 +0000
                      Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-11 23:39 +0300
        Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-07 06:39 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#23469

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Sun, 03 Apr 2016 20:24:10 +0300 schrieb upsidedown:
>> In fact it would be a great thing, if you could use UTF-8 in
>> programming,
>> e.g. Greek letters Alfa and Beta as program variables ? No need to do
>> any translitteration from any textbok variables.
>
>Forth-2012 with the Xchar wordset allows all XChar printable characters 
>as part of a Forth word (usually UTF-8).

Actually Forth-2012 falls slightly short of actually guaranteeing that
this works, because it does not require that the Forth system supports
UTF-8.

Fortunately, UTF-8 is designed to be compatible with existing code, so
if the system is 8-bit clean and does not do funny things for
recognizing white space, it will pretty much work with UTF-8.  An
example is old versions of Gforth (long before anybody thought about
the Xchar wordset), where everything but command-line editing works
with UTF-8.

An example of UTF-8 variables in Forth (and other languages on the
same page) is shown on
<http://rosettacode.org/wiki/Unicode_variable_names#Forth>.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#23488

Am Mon, 04 Apr 2016 07:11:32 +0000 schrieb Anton Ertl:

>>Forth-2012 with the Xchar wordset allows all XChar printable characters
>>as part of a Forth word (usually UTF-8).
> 
> Actually Forth-2012 falls slightly short of actually guaranteeing that
> this works, because it does not require that the Forth system supports
> UTF-8.

In the rationale, we recommend implementing support for UTF-8.  It's a 
weak recommendation, not a strong requirement, so it's up to observation 
what kind of common practice will emerge.

Most systems that have been tried with UTF-8 sources have no special 
support for it, e.g. the amForth programs in VF 2015/03-04 is compiled on 
an amForth without any xchar extension.  VFX and SwiftForth also don't 
come with xchars compiled into the default image, and yet, UTF-8-based 
source code works on both.  There are some minor issues in the command 
line editor when you try editing that stuff, which doesn't exist in an 
xchar-aware command line editor like Gforth's, though.

But we have to implement a good locate before complaining about VFX 
again ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#23467

On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown@downunder.com wrote:

>On Sun, 3 Apr 2016 14:18:56 +0200, Hans-Bernhard Bröker
><HBBroeker@t-online.de> wrote:
>
>>Am 02.04.2016 um 23:49 schrieb rickman:
>>> I know that roughly half the world uses a period to separate the
>>> fractional part of a number from the integer part.  Roughly half the
>>> world uses a comma for the same purpose.  But what about in computer
>>> languages?
>>
>>In computer languages we have barely enough punctuation letters 
>>available as it is, to express all the necessary things without being 
>>overly verbose.  Wasting one on a luxury item like that would IMHO be 
>>unjustifiable.
>
>Some computer languages like COBOL and FORTRAN could be written with 6
>bit codes (like FIELDDATA).
> 
>Unfortunately languages like C and Pascal used characters from ISO-686
>character sets, including characters reserved for national variants.
>
>
>>Programs need to be able to handle localized formats on input and 
>>output, but not in the source itself.
>
>What is the problem of using Latin-1 (ISO 8859-1) in a programming
>language ?
>
>In fact it would be a great thing, if you could use UTF-8 in
>programming, e.g. Greek letters Alfa and Beta as program variables ?
>No need to do any translitteration from any textbok variables.


You've always been able to do that in Java, although it's UCS-2 (old
versions) or UTF-16 (current), not UTF-8.

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

#23474

Op Mon, 04 Apr 2016 07:13:44 +0200 schreef Robert Wessel  
<robertwessel2@yahoo.com>:
> On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown@downunder.com wrote:
>> On Sun, 3 Apr 2016 14:18:56 +0200, Hans-Bernhard Bröker
>> <HBBroeker@t-online.de> wrote:
>>> Am 02.04.2016 um 23:49 schrieb rickman:
>> [...]
>>
>> In fact it would be a great thing, if you could use UTF-8 in
>> programming, e.g. Greek letters Alfa and Beta as program variables ?
>> No need to do any translitteration from any textbok variables.
>
> You've always been able to do that in Java, although it's UCS-2 (old
> versions) or UTF-16 (current), not UTF-8.

javac has the -encoding option, so you can use anything you want.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

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

#23492

On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:

> What is the problem of using Latin-1 (ISO 8859-1) in a programming
> language ?
> 
> In fact it would be a great thing, if you could use UTF-8 in
> programming, e.g. Greek letters Alfa and Beta as program variables ?
> No need to do any translitteration from any textbok variables.

The problem is that it raises the bar for any system needing to touch the
code. It creates problems for printing the code using non-graphical
printers, editing the code on a character-based terminal, transmitting it
through a 7-bit channel, or embedding it in any data format with a limited
character set.

Most computer systems only allow a small number of characters to be
entered without having to resort to numeric codes or searching through
tables for something to be clicked with the mouse. Homoglyphs create
confusion.

Even regular punctuation is bad enough, as most of it requires using the
little fingers or reaching for the top row, possibly along with the use of
the shift (or even AltGr) key.

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

#23498

On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
wrote:

>On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:
>
>> What is the problem of using Latin-1 (ISO 8859-1) in a programming
>> language ?
>> 
>> In fact it would be a great thing, if you could use UTF-8 in
>> programming, e.g. Greek letters Alfa and Beta as program variables ?
>> No need to do any translitteration from any textbok variables.
>
>The problem is that it raises the bar for any system needing to touch the
>code.

Windows NT has supported Unicode from the beginning in the 1990's
(UTF-16) and Linux for a long time (UTF-8). Smart phones also have
some kind of support.
 
> It creates problems for printing the code using non-graphical
>printers, 

Can you still buy printers with built in character ROMs ?

>editing the code on a character-based terminal, 

Anybody using VT-100 terminals for program development ?

>transmitting it
>through a 7-bit channel, 

Latin-x (8859-x) character sets support most European languages and it
requires 8 bit characters. If insisting of using 7 (or 6) bit
channels, some encapsulation methods are needed to carry the 8 bit
Latin character sets. The same encapsulation method should be able to
carry UTF-8.

>or embedding it in any data format with a limited
>character set.
>
>Most computer systems only allow a small number of characters to be
>entered without having to resort to numeric codes or searching through
>tables for something to be clicked with the mouse. Homoglyphs create
>confusion.

I have done (with code pages) bilingual (Latin/Cyrillc and
Latin/Arabic) systems. Usually you had a special key for toggling
between languages, no big deal. These days any touch screen virtual
keyboard it is even more trivial.

>Even regular punctuation is bad enough, as most of it requires using the
>little fingers or reaching for the top row, possibly along with the use of
>the shift (or even AltGr) key.

Your arguments might have been valid in the beginning of this century,
but these days they are non-issues.

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

#23501

upsidedown@downunder.com writes:

>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>wrote:

>>On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:
>>
>>> What is the problem of using Latin-1 (ISO 8859-1) in a programming
>>> language ?
>>>
>>> In fact it would be a great thing, if you could use UTF-8 in
>>> programming, e.g. Greek letters Alfa and Beta as program variables ?
>>> No need to do any translitteration from any textbok variables.
>>
>>The problem is that it raises the bar for any system needing to touch the
>>code.

>Windows NT has supported Unicode from the beginning in the 1990's
>(UTF-16) and Linux for a long time (UTF-8). Smart phones also have
>some kind of support.
>
>> It creates problems for printing the code using non-graphical
>>printers,

>Can you still buy printers with built in character ROMs ?

>>editing the code on a character-based terminal,

>Anybody using VT-100 terminals for program development ?

>>transmitting it
>>through a 7-bit channel,

>Latin-x (8859-x) character sets support most European languages and it
>requires 8 bit characters. If insisting of using 7 (or 6) bit
>channels, some encapsulation methods are needed to carry the 8 bit
>Latin character sets. The same encapsulation method should be able to
>carry UTF-8.

>>or embedding it in any data format with a limited
>>character set.
>>
>>Most computer systems only allow a small number of characters to be
>>entered without having to resort to numeric codes or searching through
>>tables for something to be clicked with the mouse. Homoglyphs create
>>confusion.

>I have done (with code pages) bilingual (Latin/Cyrillc and
>Latin/Arabic) systems. Usually you had a special key for toggling
>between languages, no big deal. These days any touch screen virtual
>keyboard it is even more trivial.

>>Even regular punctuation is bad enough, as most of it requires using the
>>little fingers or reaching for the top row, possibly along with the use of
>>the shift (or even AltGr) key.

>Your arguments might have been valid in the beginning of this century,
>but these days they are non-issues.

All the above arguments are eminently valid. I'm a productive programmer
which implies I'm a ten finger blind typist. That means that I restrict
the language I type in to the keyboard layout I'm used to.
Using a touch keyboard on a notepad is already a great slow down.
Remember, when I'm typing, I'm not typing, I'm thinking. I can't
have the distraction of " how was the theta symbol again" if I'm
trying to define a class for computation of continued fractions.

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#23516

Am Tue, 05 Apr 2016 10:03:07 +0000 schrieb Albert van der Horst:

> All the above arguments are eminently valid. I'm a productive programmer
> which implies I'm a ten finger blind typist. That means that I restrict
> the language I type in to the keyboard layout I'm used to.
> Using a touch keyboard on a notepad is already a great slow down.
> Remember, when I'm typing, I'm not typing, I'm thinking. I can't have
> the distraction of " how was the theta symbol again" if I'm trying to
> define a class for computation of continued fractions.

The way to deal with symbols is to have an IME.  fcitx supports 
Quickphrase LaTeX for symbols:

https://fcitx-im.org/wiki/QuickPhrase_Latex

Or math-latex(m17n), there the same names apply, but instead of using \ 
to switch into the symbol mode, you can use the mode hotkey to get there.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#23502

On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:

>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>wrote:
>
>> [Unicode] creates problems for printing the code using non-graphical
>>printers, 
>
>Can you still buy printers with built in character ROMs ?

Yes.  There are dot matrix printers still available from a number of
vendors.  Lasers cannot handle multi-part forms. 


>>editing the code on a character-based terminal, 
>
>Anybody using VT-100 terminals for program development ?

A lot of people develop scripts using terminal editors.  Does that
count?

George
[I still have two working Okidata dot matrix, one original and one
with the IBM character ROM.]

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

#23505

In comp.lang.forth George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:
> 
>>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>>wrote:
>>
>>Anybody using VT-100 terminals for program development ?
> 
> A lot of people develop scripts using terminal editors.  Does that
> count?

Not really, no.  Xterms seem to work fine with UTF-8, and so does the
GNOME terminal emulator.  I think we're just about done.  And being
able to use real symbols in programs is very nice.

Andrew.

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

#23523

George Neuner <gneuner2@comcast.net> writes:
>On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:
>
>>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>>wrote:
>>
>>> [Unicode] creates problems for printing the code using non-graphical
>>>printers, 
>>
>>Can you still buy printers with built in character ROMs ?
>
>Yes.  There are dot matrix printers still available from a number of
>vendors.

Matrix printers are graphical.  As for "character ROMs", pretty much
every printer can print plain text and has a "character ROM" for that.
There used to be dumb printers (aka GDI printers or Winprinters) that
just took some bitmap prepared one the PC; I don't know if these still
exist, but in my experience they do not play a noticable role.

Anyway, the existence of a "character ROM" does not make the printer
non-graphical.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#23500

Nobody <nobody@nowhere.invalid> writes:
>The problem is that it raises the bar for any system needing to touch the
>code. It creates problems for printing the code using non-graphical
>printers

Welcome to the 1990s.  Daisy-wheel printers, chain printers, drum
printers and the like have long died out.

> editing the code on a character-based terminal,

Also have died out quite some time ago.

> transmitting it
>through a 7-bit channel

The same, but if you really have one, there are various ways of
recoding 8-bit stuff into 7-bit bytes.

>or embedding it in any data format with a limited
>character set.

The nice thing about data is that it's just bits, and it does not know
how it is interpreted.  That's why UTF-8 works so well.

The lack of knowledge about the interpretation is actually the real
practical problem with UTF-8: If I set up an xterm to interpret
characters as Latin-1-encoded, UTF-8 won't come out right, and vice
versa.  There are ways to deal with that, but they are cumbersome.
But that's the transition pain.

>Most computer systems only allow a small number of characters to be
>entered without having to resort to numeric codes or searching through
>tables for something to be clicked with the mouse.

So what?  Most users have ways to input the kind of data they need to
input.  If a programmer wants to write programs with greek letters, he
probably has a way to input that relatively easily, and he will ensure
that his collaborators have that, too, or he will see their numbers
dwindle, or his beautiful greek letters searched and replaced with
something that his collaborators can type in easily.

I type on a US-layout keyboard.  My favourite editor has support for
inputting Umlauts etc. easily (latin-1-prefix).  I found that Windows
8.1 uses the same convention (maybe because it knows where I live, but
it's still cool).

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#23517

Am Tue, 05 Apr 2016 07:15:20 +0000 schrieb Anton Ertl:

>>Most computer systems only allow a small number of characters to be
>>entered without having to resort to numeric codes or searching through
>>tables for something to be clicked with the mouse.
> 
> So what?

There are input method editors for that, it's much easier than "resort to 
numeric codes or searching through tables".  It is no surprise that the 
best IMEs for Linux come from the Chinese speaking world: without IME, 
they couldn't use their native glyphs.  SCIM is from Taiwan, and the "C" 
originally was "Chinese", before it got modular, and the "C" became 
"Common".  fcitx (more modern and IMHO better) is from mainland China, 
and the C also stands for "Chinese", though some renaming discussions are 
going on, as fcitx is also modular.  Windows has its own IME, which can't 
really compete with the Linux IMEs.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#23518

On 06.4.2016 г. 00:50, Bernd Paysan wrote:
> Am Tue, 05 Apr 2016 07:15:20 +0000 schrieb Anton Ertl:
>
>>> Most computer systems only allow a small number of characters to be
>>> entered without having to resort to numeric codes or searching through
>>> tables for something to be clicked with the mouse.
>>
>> So what?
>
> There are input method editors for that, it's much easier than "resort to
> numeric codes or searching through tables".  It is no surprise that the
> best IMEs for Linux come from the Chinese speaking world: without IME,
> they couldn't use their native glyphs.  SCIM is from Taiwan, and the "C"
> originally was "Chinese", before it got modular, and the "C" became
> "Common".  fcitx (more modern and IMHO better) is from mainland China,
> and the C also stands for "Chinese", though some renaming discussions are
> going on, as fcitx is also modular.  Windows has its own IME, which can't
> really compete with the Linux IMEs.
>

Not contradicting anything in your post, just my thoughts.

While various symbols and languages obviously need to be supported for
the time being (we have not yet switched to Galactic Standard
universally), I see no need at all of that thing in programming.

The only benefit of adding these is more confusion.

If someone cannot create his/her software using ASCII text writing
comments in plain English (or Galactic Standard once we are that far...)
no additional character sets will make his/her life any better.

To the original issue of the decimal point vs. decimal comma - well,
I have grown up in a country where I was taught to use decimal comma.

Guess what, I can't do that nowadays even if I use a pen, I have
completely switched to using decimal point.

IOW there is absolutely no point to switch languages in our heads
while programming, our energy will be better spent on the task at
hand.
So programming is done using English (or Galactic Standard once we
are there), period. If someone can't learn English well enough to
do programming, read/write datasheets etc. he is in the wrong
line of work anyway.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

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

#23529

Dimiter_Popoff:
> While various symbols and languages obviously need to be supported for
> the time being (we have not yet switched to Galactic Standard
> universally), I see no need at all of that thing in programming.

Quite a bit of programming, especially in the sciences, is done by
domain specialists (including students) rather than professional
programmers.  Writing code that visually maps a bit more closely to
the formulas and algorithms described in articles can reduce the
effort to translate between the two.

-- 
Charles Allen

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

#23532

On 06.4.2016 г. 18:20, Charles Allen wrote:
> Dimiter_Popoff:
>> While various symbols and languages obviously need to be supported for
>> the time being (we have not yet switched to Galactic Standard
>> universally), I see no need at all of that thing in programming.
>
> Quite a bit of programming, especially in the sciences, is done by
> domain specialists (including students) rather than professional
> programmers.  Writing code that visually maps a bit more closely to
> the formulas and algorithms described in articles can reduce the
> effort to translate between the two.
>

The help this would offer would be outweighed by the amount of
time wasted to sort out all the inconsistencies and overlooked
settings/options.
Mathematical formulae are a negligible part of programming, and if
someones "programming" is just to implement the calculation of
an expression by entering the expression this person is a computer
user, not a programmer. So my comment on the usefulness of
various languages/character sets applies to this case.

Then drifting slowly away from all the Greek characters etc. we use
in science would also be a good thing in the long term, however
impossible it may seem now.

Dimiter

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

#23575

On Wednesday, April 6, 2016 at 11:30:22 AM UTC-4, Charles Allen wrote:
> Dimiter_Popoff:
> > While various symbols and languages obviously need to be supported for
> > the time being (we have not yet switched to Galactic Standard
> > universally), I see no need at all of that thing in programming.
> 
> Quite a bit of programming, especially in the sciences, is done by
> domain specialists (including students) rather than professional
> programmers.  Writing code that visually maps a bit more closely to
> the formulas and algorithms described in articles can reduce the
> effort to translate between the two.
> 
> -- 
> Charles Allen

And using a domain specific language may be the way to go in that case.
There is a reason FORTRAN is still around. And there are other languages
even better (MATLAB?).

One thing missing in this discussion is that there are a LOT of
programming languages out there. You may find this feature if you
REALLY need it.

The comma/period difference is such a small issue.
If your native language uses the comma as the fractional separator,
it can be tough to learn how to read numbers using the period.
BUT you don't read the rest of the program in the same way that
you read a letter from your mother. Even the prose-like COBOL
language is not written like regular prose.

I guess my conclusion is that making this a language feature just
adds a headache for the maintenance programmer. Even if the
change in configuration from period to comma is clear in the
source file, the mental change in view can be difficult.

I have less of a problem with a program written with German
names for example, because it does not change the syntax of
the program. I can still tell the difference between
Blech as a variable and Blech as a function. So going to a
multilingual character set would not necessarily be as hard.

ed

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

#23579

Am 07.04.2016 um 16:04 schrieb Ed Prochak:

> I have less of a problem with a program written with German
> names for example, because it does not change the syntax of
> the program.

Good thing you missed one of Microsoft's silliest decisions ever, then, 
which was what they did with WordBasic (i.e. before Office 97).

They actually thought it would be a clever idea to translate the entire 
language(!): keywords, operators, standard library functions, the whole 
thing.  So if you had a document created in a US version and printed out 
the macro source, then repeated that step in a German version of Word, 
the printout would be totally different ... only commented-out code 
would still look the same, because it didn't undergo auto-translation.

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

#23580

Den torsdag den 7. april 2016 kl. 23.40.32 UTC+2 skrev Hans-Bernhard Bröker:
> Am 07.04.2016 um 16:04 schrieb Ed Prochak:
> 
> > I have less of a problem with a program written with German
> > names for example, because it does not change the syntax of
> > the program.
> 
> Good thing you missed one of Microsoft's silliest decisions ever, then, 
> which was what they did with WordBasic (i.e. before Office 97).
> 
> They actually thought it would be a clever idea to translate the entire 
> language(!): keywords, operators, standard library functions, the whole 
> thing.  So if you had a document created in a US version and printed out 
> the macro source, then repeated that step in a German version of Word, 
> the printout would be totally different ... only commented-out code 
> would still look the same, because it didn't undergo auto-translation.

I remember being hearing stories about that. 

Did code written in one language run on Word in a different language?  

-Lasse

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

#23582

On 08/04/16 01:04, lasselangwadtchristensen@gmail.com wrote:
> Den torsdag den 7. april 2016 kl. 23.40.32 UTC+2 skrev Hans-Bernhard Bröker:
>> Am 07.04.2016 um 16:04 schrieb Ed Prochak:
>>
>>> I have less of a problem with a program written with German
>>> names for example, because it does not change the syntax of
>>> the program.
>>
>> Good thing you missed one of Microsoft's silliest decisions ever, then, 
>> which was what they did with WordBasic (i.e. before Office 97).
>>
>> They actually thought it would be a clever idea to translate the entire 
>> language(!): keywords, operators, standard library functions, the whole 
>> thing.  So if you had a document created in a US version and printed out 
>> the macro source, then repeated that step in a German version of Word, 
>> the printout would be totally different ... only commented-out code 
>> would still look the same, because it didn't undergo auto-translation.
> 
> I remember being hearing stories about that. 
> 
> Did code written in one language run on Word in a different language?  
> 

I believe that the storage format is tokenised, and the editor
translates back and forth between token number and local language
keywords, so that code can work on different systems.  But I don't know
for sure - my experience with MS Office is very minimal (the last
version I had on my own systems was Word for Windows 2, on Win 3.11.  I
use LaTeX when I can, LibreOffice otherwise).

Excel does the same thing - function names are different in different
languages, and are a real pain to deal with.  You can't copy and paste
easily, you can't look at examples on a web page in a different language
and expect them to work.  You can't even get the idiotic thing to import
or export text formats if the file's idea of decimal comma vs. decimal
point differs from your Window's setup.  It might be workable for people
who work solely in a single non-English language and don't understand
English, but it is annoying for mixed language usage.  MS really should
look at LibreOffice to learn how office software should work.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web