Decimal Point vs. Decimal Comma

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.

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/

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/

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/

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/

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

On Sunday, April 3, 2016 at 1:24:08 PM UTC-4, upsid...@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.

Regarding greek letters and otehr characters, APL had them. (I think
it predates UTF-8 though and just used an extended ASCII set.)

When I used APL it required a special terminal keyboard with the
additional characters it used (like the unary minus).

I do not remember if it could take comma as the decimal separator.
I suspect not.
ed

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

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.

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