«

On 2011-02-16, Xah Lee Â*wrote:
│ Vast majority of computer languages use ASCII as its character set.
│ This means, it jams multitude of operators into about 20 symbols.
│ Often, a symbol has multiple meanings depending on contex.

On 2011-02-17, rantingrick wrote:
…

On 2011-02-17, Cthun wrote:
│ And you omitted the #1 most serious objection to Xah's proposal,
│ rantingrick, which is that to implement it would require unrealistic
│ things such as replacing every 101-key keyboard with 10001-key
keyboards
│ and training everyone to use them. Xah would have us all replace our
│ workstations with machines that resemble pipe organs, rantingrick,
or
│ perhaps the cockpits of the three surviving Space Shuttles. No doubt
│ they'd be enormously expensive, as well as much more difficult to
learn
│ to use, rantingrick.

keyboard shouldn't be a problem.

Look at APL users.
http://en.wikipedia.org/wiki/APL_(programming_language)
they are happy campers.

Look at Mathematica, which support a lot math symbols since v3 (~1997)
before unicode became popular.
see:
〈How Mathematica does Unicode?〉
http://xahlee.org/math/mathematica_unicode.html

word processors, also automatically do symbols such as “curly quotes�,
trade mark sign ™, copyright sing ©, arrow →, bullet •, ellipsis …
etc, and the number of people who produce document with these chars
are probably more than the number of programers.

in emacs, i recently also wrote a mode that lets you easily input few
hundred unicode chars.
〈Emacs Math Symbols Input Mode (xmsi-mode)〉
http://xahlee.org/emacs/xmsi-math-symbols-input.html

the essence is that you just need a input system.

look at Chinese, Japanese, Korean, or Islamic. They happily type
without requiring that every symbol they use must have a corresponding
key on keyboard. Some lang, such as Chinese, that's impossible or
impractical.

when a input system is well designd, it could be actually more
efficient than
keyboard combinations to typo special symbols (such as in Mac OS X's
opt key, or
Windows's AltGraph). Because a input system can be context based, that
it looks
at adjacent text to guess what you want.

for example, when you type >= in python, the text editor can
automatically change it to ≥ (when it detects that it's appropriate,
e.g. there's a “if� nearby)

Chinese phonetic input system use this
extensively. Abbrev system in word processors and emacs is also a form
of
this. I wrote some thought about this here:

〈Designing a Math Symbols Input System〉
http://xahlee.org/comp/design_math_symbol_input.html

Xah Lee

Chris Jones wrote:
«.. from a quite different perspective it may be worth noting that
practically all programming languages (not to mention the attached
documentation) are based on the English language. And interestingly
enough, most any software of note appears to have come out of cultures
where English is either the native language, or where the native
language is either relatively close to English.. Northern Europe
mostly.. and not to some small extent, countries where English is well-
established as a universal second language, such as India. Always
struck me as odd that a country like Japan for instance, with all its
achievements in the industrial realm, never came up with one single
major piece of software.»

btw, english is one of the two of India's official lang. It's used
between Indians, and i think it's rare or non-existent for a college
in india that uses local dialect. (this is second hand knowledeg. I
learned this in Wikipedia and experience with indian co-workers)

i also wondered about why japan doesn't seems to have created major
software or OS. Though, Ruby is invented in Japan. I do think they
have some OSes just not that popular... i think for special purposes
OSes, they have quite a lot ... from Mitsubishi, NEC, etc... in their
huge robotics industry among others. (again, this is all second hand
knowledge)

.... i recall having read non-english comp lang that appeared
recently...

Xah Lee

On Fri, Feb 18, 2011 at 06:40:17AM EST, Steven D'Aprano wrote:
> On Fri, 18 Feb 2011 02:50:11 -0500, Chris Jones wrote:

> > Always struck me as odd that a country like Japan for instance, with
> > all its achievements in the industrial realm, never came up with one
> > single major piece of software.

> I think you are badly misinformed.
>
> The most widespread operating system in the world is not Windows. It's
> something you've probably never heard of, from Japan, called TRON.
>
> http://www.linuxinsider.com/story/31855.html
> http://web-japan.org/trends/science/sci030522.html
>
> Japan had an ambitious, but sadly failed, "Fifth Generation Computing"
> project:
>
> http://en.wikipedia.org/wiki/Fifth_generation_computer
> http://vanemden.wordpress.com/2010/0...killed-prolog/
>
> They did good work, but unfortunately were ahead of their time and the
> project ended in failure.
>
> Japan virtually *owns* the video game market. Yes, yes, Americans publish
> a few high-profile first-person shooters. For every one of them, there's
> about a thousand Japanese games that never leave the country.
>
> There's no shortages of programming languages which have come out of
> Japan:
>
> http://hopl.murdoch.edu.au/findlangu...hich=ByCountry
> http://no-sword.jp/blog/2006/12/prog...out-ascii.html
>
> The one you're most likely to have used or at least know of is Ruby.

Food for thought.. Thanks much for the links..!

cj

On Feb 18, 7:55*am, Steve Schafer <st...@fenestra.com> wrote:
> On Thu, 17 Feb 2011 20:47:57 -0800 (PST), rantingrick
>
> <rantingr...@gmail.com> wrote:
> >What is evolution?
>
> >Evolution is the pursuit of perfection at the expense of anything and
> >everything!
>
> No, evolution is the pursuit of something just barely better than what
> the other guy has.

You fail to see from a larger perspective. You still see through the
eyes of part and not a whole. Each cog that is part of a machine is
just a means to an end. You are attempting to elevate one cog above
all other cogs, heck, you want to elevate one cog above the machine.
You are nothing, and until you accept your nothingness, only then will
you understand your place in the greater game.

> Evolution is about gaining an edge, not gaining
> perfection.

Evolution is about one cog gaining an edge over another, yes. However
the system itself moves toward perfection at the expense of any and
all cogs.

> Perfect is the enemy of good.

No. Perfect is the enemy of YOU. You are not able to be perfect
therefor you claim that perfection is evil to justify your meaningless
existence. And who are YOU to weigh good an evil? What do YOU know
about the Universe that gives you these powers of judgment? Do you
think with your measly 60-100 years of lifetime you can contemplate
the meaning of good and evil in a Universe that has existed for eons?
Get REAL! We only see and know a small fraction of what the Universe
really is. A huge portion of the Universe cannot even be accounted
for. And you parade around like some all-knowing being with all the
answers and full of selfishness and vanity. Ha!

If perfection is evil then what is the pursuit of perfection: AKA:
gaining an edge?

On Feb 18, 8:22*am, rantingrick <rantingr...@gmail.com> wrote:

> > Perfect is the enemy of good.

Do you think that just because something has a negative impact towards
you (or your existence) that the *something* is then evil? Take a
animal for instance: We kill animals for sustenance. The act of
killing the animal is negative from the viewpoint of the animal
however it does not make the killing evil.

Of course if the animal could speak i am sure it will tell you that
you are evil for ending its life. However the animal would be speaking
from a selfish viewpoint. The animal fails to see that the human is
more important than itself in the evolutionary chain. And by consuming
the flesh of the animal the human can continue to evolve more
knowledge. However the animal's life was not in vain for it's flesh
contributed to the life of an intelligent agent who then was able to
further the knowledge base of evolution far beyond what the animal
could have ever achieved!

Likewise *we* as intelligent agents are the tools of an intelligent
evolution. When the human becomes insufficient (from the rise of AI)
then the human will become the consumable. You are like the animal,
not understanding your place in the universe. You fail to see the
Universe from OUTSIDE your *own* selfish interpretation. You cannot
wield the meanings of good and evil from a selfish and naive
interpretation of the Universe. You must look much deeper.

"You are not *something* unless you first realize you are *nothing*."

On 18/02/2011 7:43 AM, Xah Lee wrote:
> On 2011-02-17, Cthun wrote:
> │ And you omitted the #1 most serious objection to Xah's proposal,
> │ rantingrick, which is that to implement it would require unrealistic
> │ things such as replacing every 101-key keyboard with 10001-key
> keyboards

What does your classic unsubstantiated and erroneous claim have to do
with Lisp, Lee?

On 2/17/11 7:42 PM, Littlefield, Tyler wrote:
>>My intention was to educate him on the pitfalls of multiplicity.
> O. that's what you call that long-winded nonsense? Education? You must
> live in America. Can I hazard a guess that your universal language might
> be english? Has it not ever occured to you that people take pride in
> their language? It is part of their culture. And yet you rant on about
> selfishness?

This is an old-rant, there's nothing new to it. Rick's racist and
imperialistic anti-Unicode rants have all been fully hashed out months
if not years ago, Tyler. There's really nothing more to say about it.

He doesn't get it.

--

Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)

iQEcBAEBAgAGBQJNXouOAAoJEKcbwptVWx/lM1IH/RHWv2B0NcNfejFndwqfoPhN
k1NJ9ETbht54k43dgaS46owmQzqoMlVszMlUVqyW8h2af0ddrD xKprdy2kt0HtCD
LogZRFAxnEO6CpY+E8jYYxWOP9JQhPilPAP+1IeSrRiGTXaFuj jrG2D565+NcERZ
P8VFTAfvApzzI2u/vH1cyFdz77KJmV1q5aKFC6tvVfK5nHbHWi1FP8yKgmxcauOp
lr+DjJFYYaV2SYWFDeYcFtmYXpOIAvRUywKhTErjpI65pLPMI+ LhU3GCtTfMNPDC
SPao/J5WNr+d3JXGJNLm3ixHwjgcPPSzlZ4TvLh3qki15obVHjh9hHh rkuX3iVI=
=0/Om
-----END PGP SIGNATURE-----

On Fri, 2011-02-18 at 04:43 -0800, Xah Lee wrote:
> On 2011-02-16, Xah Lee wrote:
> │ Vast majority of computer languages use ASCII as its character set.
> │ This means, it jams multitude of operators into about 20 symbols.
> │ Often, a symbol has multiple meanings depending on contex.
>
> On 2011-02-17, rantingrick wrote:
> …
>
> On 2011-02-17, Cthun wrote:
> │ And you omitted the #1 most serious objection to Xah's proposal,
> │ rantingrick, which is that to implement it would require unrealistic
> │ things such as replacing every 101-key keyboard with 10001-key
> keyboards
> │ and training everyone to use them. Xah would have us all replace our
> │ workstations with machines that resemble pipe organs, rantingrick,
> or
> │ perhaps the cockpits of the three surviving Space Shuttles. No doubt
> │ they'd be enormously expensive, as well as much more difficult to
> learn
> │ to use, rantingrick.
>
> keyboard shouldn't be a problem.
>
> Look at APL users.
> http://en.wikipedia.org/wiki/APL_(programming_language)
> they are happy campers.
>
> Look at Mathematica, which support a lot math symbols since v3 (~1997)
> before unicode became popular.
> see:
> 〈How Mathematica does Unicode?〉
> http://xahlee.org/math/mathematica_unicode.html
>
> word processors, also automatically do symbols such as “curly quotes�,
> trade mark sign ™, copyright sing ©, arrow →, bullet •, ellipsis …
> etc, and the number of people who produce document with these chars
> are probably more than the number of programers.
>
> in emacs, i recently also wrote a mode that lets you easily input few
> hundred unicode chars.
> 〈Emacs Math Symbols Input Mode (xmsi-mode)〉
> http://xahlee.org/emacs/xmsi-math-symbols-input.html
>
> the essence is that you just need a input system.
>
> look at Chinese, Japanese, Korean, or Islamic. They happily type
> without requiring that every symbol they use must have a corresponding
> key on keyboard. Some lang, such as Chinese, that's impossible or
> impractical.
>
> when a input system is well designd, it could be actually more
> efficient than
> keyboard combinations to typo special symbols (such as in Mac OS X's
> opt key, or
> Windows's AltGraph). Because a input system can be context based, that
> it looks
> at adjacent text to guess what you want.
>
> for example, when you type >= in python, the text editor can
> automatically change it to ≥ (when it detects that it's appropriate,
> e.g. there's a “if� nearby)
>
> Chinese phonetic input system use this
> extensively. Abbrev system in word processors and emacs is also a form
> of
> this. I wrote some thought about this here:
>
> 〈Designing a Math Symbols Input System〉
> http://xahlee.org/comp/design_math_symbol_input.html
>
> Xah Lee
More people despise APL than like it.

Allowing non-ascii characters as operators is a silly idea simply
because if xorg breaks, which it's very likely to do with the current
video drivers, I'm screwed. Not only does the Linux virtual terminal not
support displaying these special characters, but there's also no way of
inputting them. On top of that, these special characters require more
bytes to display than ascii text, which would bloat source files
unnecessarily.

You say we have symbol congestion, but in reality we have our own symbol
bloat. Japanese has more or less than three punctuation marks, while
English has perhaps more than the alphabet! The fundamental point here
is using non-ascii operators violates the Zen of Python. It violates
"Simple is better than complex," as well as "There should be one-- and
preferably only one --obvious way to do it."

On Fri, 18 Feb 2011 04:43:13 -0800, Xah Lee wrote:

> for example, when you type >= in python, the text editor can
> automatically change it to ≥ (when it detects that it's appropriate,
> e.g. there's a “if� nearby)

You can't rely on the presence of an `if`.

flag = x >= y
value = lookup[x >= y]
filter(lambda x, y: x >= y, sequence)

Not that you need to. There are no circumstances in Python where the
meaning of >= is changed by an `if` statement.


Followups set to comp.lang.python.


--
Steven

On Fri, 18 Feb 2011 11:16:30 -0800, Westley MartÃ*nez wrote:

> Allowing non-ascii characters as operators is a silly idea simply
> because if xorg breaks, which it's very likely to do with the current
> video drivers, I'm screwed.

And if your hard drive crashes, you're screwed too. Why stop at "xorg
breaks"?

Besides, Windows and MacOS users will be scratching their head asking
"xorg? Why should I care about xorg?"

Programming languages are perfectly allowed to rely on the presence of a
working environment. I don't think general purpose programming languages
should be designed with reliability in the presence of a broken
environment in mind.

Given the use-cases people put Python to, it is important for the
language to *run* without a GUI environment. It's also important (but
less so) to allow people to read and/or write source code without a GUI,
which means continuing to support the pure-ASCII syntax that Python
already supports. But Python already supports non-ASCII source files,
with an optional encoding line in the first two lines of the file, so it
is already possible to write Python code that runs without X but can't be
easily edited without a modern, Unicode-aware editor.


> Not only does the Linux virtual terminal not
> support displaying these special characters, but there's also no way of
> inputting them.

That's a limitation of the Linux virtual terminal. In 1984 I used to use
a Macintosh which was perfectly capable of displaying and inputting non-
ASCII characters with a couple of key presses. Now that we're nearly a
quarter of the way into 2011, I'm using a Linux PC that makes entering a
degree sign or a pound sign a major undertaking, if it's even possible at
all. It's well past time for Linux to catch up with the 1980s.


> On top of that, these special characters require more
> bytes to display than ascii text, which would bloat source files
> unnecessarily.

Oh come on now, now you're just being silly. "Bloat source files"? From a
handful of double-byte characters? Cry me a river!

This is truly a trivial worry:

>>> s = "if x >= y:\n"
>>> u = u"if x ≥ y:\n"
>>> len(s)
11
>>> len(u.encode('utf-8'))
12


The source code to the decimal module in Python 3.1 is 205470 bytes in
size. It contains 63 instances of ">=" and 62 of "<=". Let's suppose
every one of those were changed to ≥ or ≤ characters. This would "bloat"
the file by 0.06%.

Oh the humanity!!! How will my 2TB hard drive cope?!?!


> You say we have symbol congestion, but in reality we have our own symbol
> bloat. Japanese has more or less than three punctuation marks, while
> English has perhaps more than the alphabet! The fundamental point here
> is using non-ascii operators violates the Zen of Python. It violates
> "Simple is better than complex," as well as "There should be one-- and
> preferably only one --obvious way to do it."

Define "simple" and "complex" in this context.

It seems to me that single character symbols such as ≥ are simpler than
digraphs such as >=, simply because the parser knows what the symbol is
after reading a single character. It doesn't have to read on to tell
whether you meant > or >=.

You can add complexity to one part of the language (hash tables are more
complex than arrays) in order to simplify another part (dict lookup is
simpler and faster than managing your own data structure in a list).

And as for one obvious way, there's nothing obvious about using a | b for
set union. Why not a + b? The mathematician in me wants to spell set
union and intersection as a ⋃ b ⋂ c, which is the obvious way to me (even
if my lousy editor makes it a PITA to *enter* the symbols).

The lack of good symbols for operators in ASCII is a real problem. Other
languages have solved it in various ways, sometimes by using digraphs (or
higher-order symbols), and sometimes by using Unicode (or some platform/
language specific equivalent). I think that given the poor support for
Unicode in the general tools we use, the use of non-ASCII symbols will
have to wait until Python4. Hopefully by 2020 input methods will have
improved, and maybe even xorg be replaced by something less sucky.

I think that the push for better and more operators will have to come
from the Numpy community. Further reading:


http://mail.python.org/pipermail/pyt...er/083493.html


--
Steven