Problems of Symbol Congestion in Computer Languages
nagle at animats.com
Fri Feb 18 06:43:37 CET 2011
On 2/17/2011 6:55 PM, Cor Gest wrote:
> Some entity, AKA Cthun<cthun_117 at qmail.net.au>,
> wrote this mindboggling stuff:
>> 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.
More information about the Python-list