[plt-scheme] The perfect teaching language--Is this too much to ask for?

On Jun 14, Luciano Ramalho wrote:
> [...]
> 
> If I see:
> 
> (x y z)
> 
> I have no idea how that will be evaluated, whether y or z will ever
> be evaluated, and if so, in what order. I have to find out whether x
> is a function or some other form, because the syntax gives me no
> clue.

This is obviously a trade-off.  In PLT, the bottom line is that you
should always be able to tell what `x' is -- it's either something
that the language you chose defined, something that comes from a
library that you explicitly required, or something that you defined
yourself.

In most infix-ish languages, you have the exact same issue to deal
with -- for example `for' is clearly not evaluating its "arguments"
like other functions.  You don't even have a clear syntactic hint
about what is (for example) a new binding and what is a reference to
an existing binding -- an identifier in prentheses can be a reference
(for example, `my_fun(x)') or it can declare a new binding (for
example `function my_fun(x)'); an identifier outside of parentheses
can also be either a reference (`x + 1') or a binding (`var x').

The advantage of infix-ish (or more accurately macro-less-ish)
languages is that there is a very small and inflexible set of such
constructs, and it's all part of the core language.  (That's a very
common point that people raise against having macros, BTW.)  But the
tradeoff here is very significant -- the constructs are not flexible
so changing them is much more traumatic (for example, to get a
`for-each' kind of iteration Java had to revise the core language);
and in addition such constructs are limited to the kind of things that
belong in the core -- something like the `automaton' macro from
Shriram's talk is clearly not a core language feature in this sense,
so there is no chance of seeing something like that built-into some
language (unless, of course, it's a language that revolves around
automatons).

Yet another factor is a much larger set of things that are built-in --
for example, in PLT optional and keyword arguments, the class system,
contracts, types, and a bunch of other such things are not built-in.
This makes the cost of developing them and maintining them much lower
-- and even more significantly this applies to the cost of designing
them too.  When you're dealing with a language like Java or Python,
the class system must be designed extremely carefully, since you have
almost no room for mistakes.  In contrast, the PLT class system is
something that is very much alive.

>From a commercial perspective, this can be a huge advantage: consider
this as a competition between two products --- with the fixed world
you need to make sure that you have all possible features.  The Java
class system is nearly fixed, and can react to changes extremely
slowly.  Younger languages can beat Java in ways that Java cannot
react to -- but they risk similar costs with changes that the future
will hold.  But if you're using something like Scheme where the syntax
is much more flexible, adapting things become two orders of magnitudes
easier.

Finally, earlier you mentioned:

  things that are similar should look similar, things that are
  different should look different

which sounded like you're trying to make a point for infix syntax
being more natural to use.  As Shriram said, things are much more
complicated when you're dealing with a programming language syntax.
I thought that a very good example here is spaces as natural
delimiters -- they're natural in both human texts and as arguments.
For example, using a space in

  dir c:\Temp

is natural, but also using a space in naming some directory "Program
Files".  Trying to abuse spaces for both of these purposes is one of
the bigger catastrophes that Microsoft has inflicted on the world of
programming.  I'm sure that they had good intentions -- they were
trying to make things simple -- following just that kind of argument.
The result is that issues like double-quotes leak through all
abstraction layers and even worse -- it's indirectly inherited by many
tools.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!