Decimal Point vs. Decimal Comma

Op Mon, 04 Apr 2016 07:13:44 +0200 schreef Robert Wessel =

:

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:

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

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/

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.

It turns out that that's the case in mainstream Forth systems.

fig-Forth used the highest bit for marking the end of the stored part of the name in a dictionary entry, but that practice apparently died out together with the practice of being able to store only a part of the name.

- 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/

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.

Can you still buy printers with built in character ROMs ?

Anybody using VT-100 terminals for program development ?

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.

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.

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

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

Also have died out quite some time ago.

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

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.

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/

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

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

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.]

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:

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

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:

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/

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

------------------------------------------------------

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/

Dimiter_Popoff:

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

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

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

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:

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.

er:

I remember being hearing stories about that.

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

-Lasse