Re: various recent ll1 threads

[Sundar Narasimhan <address@hidden>]

   > Interesting points, but contemplate
   > 
   >   / * - 2 3
   >       + 4 1
   >     + 11 3
   > 
   > or, with Lisp's parentheses,
   > 
   > 
   >   (/ (* (- 2 3)
   >         (+ 4 1))
   >      (+ 11 3))
   > 
   > In this case each operator tends to be quite close to its children.
   > If all you care about is "separation", then each operator is
   > separated from its first child by zero tokens and from its
   > second child by one token (because you scan horizontally
   > over to the first child, then vertically to the second child,
   > which may be some distance down but there will be no tokens
   > in the way!).
   > 
   > This two-dimensional effect is difficult to achoeve with infix.

   This is really interesting -- I've always thought that the main advantage of
   the classical mathematical notation is likely to be that it allows (by virtue
   of its irregularity) to build visually rich two dimensional structures, which
   I assume must be more congenial to the workings of our visual system.

   Although it was clear to me that this advantage doesn't transfer well into
   ASCII, it didn't occur to me that it might actually loose out in this respect
   to prefix (the above example also seems to demonstrate, however, that parens
   are a problem -- the parenless version is definitely easier to read). Which
   brings me onto the next question -- has someone come up with a more visual
   prefix-based notation for math that isn't "flat", has implicit operators
   (e.g. in LaTeX notation ^{2}3 rather than 3^{2}) etc.?


   alex

   > 
   > Yes, infix may win for small expressions.  Years of experience
   > have convinced me what prefix wins for large expressions.
   > 
   > --Guy Steele

The finished product is easier to contemplate the way Guy has written
the above of course, but what one needs to 'manipulate' is often
different from what one needs to express the finished product -- in
this case the arithmetic expression. Guy, do you realy 'work' in
prefix while deriving equations like the above? I have never met a
mathematician who used prefix for their calculations.

The main reason infix wins (IMO) is that we are ignoring all the
special symbols (think of the sigma, pi, integration symbol, grad, set
notation etc.) that have no equivalent in most programming
languages. It's far easire to compute on paper w/ those, and then
transfer to computer-ese.. infix or prefix really doesn't matter to
me -- I spend 90% of my time getting to the equation/expression and
only <10% of the time programming it up.

This also reflects why all these comments about succinctness and
comments etc. really bother me. In my real-life, I tend to work with
large mixed integer optimizers, computer graphics/geometry code,
oodles of GUI's, resource allocation algorithms etc.. Most such code
reflects the 'end product' of hours of thought and work much of which
happens 'outside' the realm of computers or programming artifacts. As
such, it is near impossible to guess from a sampling of the code
(alone) what it is intended to do. Without comments as to what aspects
of the real world or model a particular variable, expression or
equation might represent, and without more comments about how that
equation was arrived at.. people here would be hopelessly lost. As
such, I wouldn't argue AT ALL for commentless terse code. The fact
that some people can write code that manipulates text strings very
well with uncommented code is really irrelevant to me. I know language
designers often don't think about 'modeling' or 'design and analysis'
but it seems like a big loss to me.

And the foll. is just a plea to see if it resonates:

I wish we were discussing how to make tomorrow's computer programs
easier to write. The kind where the domains weren't just strings and
numbers but perhaps real life entities like times, places and music. I
wish programming languages would take a huge step up -- not endlessly
hash old arguments about how to write 2+1, whether comments are
meaningful and whether or not you can make more money w/ or w/out
parens. In short, think not "little languages", but "really big"
targets -- like secure, reliable programs that the rest of the
non-computing world is clamoring for.