On 2/17/2011 6:55 PM, Cor Gest wrote:
Some entity, AKA Cthun<cthun_...@qmail.net.au>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
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.
At least it should try to mimick a space-cadet keyboard, shouldn't it?
I've used both the "MIT Space Cadet" keyboard on a Symbolics LISP
machine, and the Stanford SAIL keyboard. There's
something to be said for having more mathematical symbols.
Some programs use a bigger character set. MathCAD,
for example, has a broader range of mathematical symbols on
the input side than ASCII offers. They're not decorative;
MathCAD has different "=" symbols for assignment, algebraic
equivalence, identity, and comparison.
I've previously mentioned that Python suffers in a few places
from unwanted overloading. Using "+" for concatenation of
strings, then extending that to vectors, resulted in undesirable
semantics. "+" on arrays from "numpy", and on built-in vectors
behave quite differently. A dedicated concatenation operator
would have avoided that mess.
C++ has worse problems, because it uses < and > as both
brackets and operators. This does horrible things to the syntax.
However, adding a large number of new operators or new
bracket types is probably undesirable.
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
