I see two different points in this proposal.
1. Indentation matters. This point is entirely orthogonal to syntax.
It applies to Racket and Honu as well.
2. Syntax matters. But I don't understand whether the proposal is
really for students only or for students and then a lot more.
If it were for the former, I wouldn't expect any discussion of
Racket macros in the design document. I'll treat it for now as
"it is initially for students but it should accommodate everyone."
On Jul 29, 2010, at 2:09 PM, Shriram Krishnamurthi wrote:
> I think parens are synecdoche.
This is true and easier said than with a rarely used word.
Programmers who complain about parens mean something larger:
-- the entire syntax (it doesn't look traditional)
-- the entire semantics (function calls dictate nearly everything)
-- the way we program (inductive structures have more weight than indexed ones)
and more and certainly all the 'syntactic' symptoms that come with this:
-- nested expressions show up a lot; how to read them
-- array/for-loop "patterns" of programming aren't working, how to start?
-- why this focus on data representations, can't we just use arras?
And I am sure the list of such make-me-feel-bad unfamiliarities goes on.
Assuming that the lack of syntactic familiarity outweighs the others
-- something we don't know for sure -- I think the next question
to ask is how much distance to 'real' or 'familiar' syntax these
'targeted' people can tolerate.
After reading the entire document and looking at the sample
programs, I remain unconvinced in two ways:
1. I tend to agree with Eli's general point and his arithmetic
example illustrates this point really well.
2. I doubt that we can figure out the usefulness of this new
syntax on this mailing list.
I really think we need a reasonably large-scale experiment and that
worries me. With such an experiment a lot of things need to be considered:
-- say we stick with +(1,2,3) and people don't come, what went wrong?
they considered +(1,2,3) too distant from 1 + 2 + 3
they didn't like identifiers such as posn-x
they disliked the semantic distance, i.e., they wanted to
write p.x not posn-x(p) because they think they don't
care when p is not a posn struct
in general, who knows what to conclude from a failure
-- conducting this experiment on students will lead to very
different results than conducting it on 'real' programmers
Where should we start? Personally I think students are the
_wrong_ audience. They can cope with () and this prefix
notation in the middle is something they are guaranteed
_not_ to encounter elsewhere.
-- how much work do we have to invest to make it so robust that it
works as well as Javascript?
I think you have a nice prototype and it's roughly were
Honu was a while back. But we need much much more to
get the full power of Racket with P4P.
And I am sure you can imagine many more questions that we
should discuss before we spend the resources.
I for one am looking forward to a robust discussion of this
topic at PLT day.
-- Matthias
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
