Problems of Symbol Congestion in Computer Languages

[John Nagle]

On 2/17/2011 6:55 PM, Cor Gest wrote:
> Some entity, AKA Cthun<cthun_117 at 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