On May 18, 2011, at 9:25 AM, Dean Landolt wrote:
> I think the argument for ease of static analysis applies just as well to
> human analysis (after all, our wetware makes for a poor interpreter). But I
> think the counter-argument is more compelling -- this is yet another
> construct our *tooling* would have to understand, and every new construct
> *substantially* ups the ante for fluency (ISTM the tax for each new syntax is
> approximately combinatorial for inexperienced developers).
I hear this sometimes, but not about languages with established syntactic
complexity (e.g. Ruby). Indeed people learn Ruby and other languages by
learning subsets. They learn via tutorials. They learn inductively until idioms
need to be learned.
Meanwhile, syntax as better user interface, for usability ("developer
ergonomics" applies to programming languages too), must matter. Not just
keystrokes and chording for code production. That hurts (some of my RSI
afflicted talented-programmer friends testify) but for *maintenance*.
And readability, which ultimately trumps writability but not in any
zero-sum-game sense, can be aided by new syntax, compared to using library
methods and functions.
> The imperative alternative, on the other hand, only requires learning the
> semantics of a new API, not whole new constructs and how they compose
> (regardless of how nicely they compose). I personally believe this matters a
> great deal, and not just for newcomers.
I don't see why you assume newcomers learn all the syntax, all at once. I did
not when I learned a great many languages.
> As I've heard /be suggest, some of javascript's success can be owed to its
> lack of syntactical novelty. I'm not saying all new syntax is bad syntax, but
> at the very least the committee should be optimizing for humans first.
JS mainly had first-mover and it "did not suck" so badly that it lost to a
second mover -- it stuck. We are not removing old syntax. So people can learn
the old syntax if they like.
Then the objection moves from pedagogy to maintenance: "I don't want to have to
maintain paren-free code", e.g. But you always have choices. Refuse,
parenthesize were allowed, negotiate. Syntax is partly social.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
