Problems of Symbol Congestion in Computer Languages

[Westley Martínez]

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