On Jun 20, 2011, at 11:16 AM, Axel Rauschmayer wrote:
>> Decorators are in some folks' sights for Harmony, but not ES.next. However,
>> they're still too verbose.
>
> I like to distinguish between
> (1) encoding complexity for people who write code and
> (2) encoding complexity for people who read code. (2) is much more important
> than (1).
>
> Examples:
> - Perl optimizes (1), to the detriment of (2)
> - Smalltalk optimizes (2).
> - Semicolons fall into a similar category: As a reader, I’m used to
> punctuation and have an *easier* time reading code with semicolons, but they
> are obviously more to type.
It's not that simple. Semicolon-free languages come in several flavors:
s-expression languages, significant-newline languages, other (generally
expression languages). The significant newline fans make a good case for both
ease of writing *and* ease of reading.
Anyway, my point is that decorators in front of functions and classes or other
declarative forms work. In front of every property assignment in an object
literal? Not so much.
It may be that we require @decorators to start on a new line (with leading
horizontal space allowed, of course), in order to enable @ as an operator in
expressions where [no LineTerminator here] would apply to the left of the @.
> I can usually handle a few special characters, but there is a threshold,
> after which I prefer full-blown keywords (again: those are parsed by the
> brain as a single token, so the cognitive load compared to single characters
> is about the same). If ES.next lands between Perl and Smalltalk, I’ll be very
> happy. ;-)
Is there really any habitable land in between? That's the question.
What are the few special characters that you can handle, right now, as
additions mooted for JS?
> If one includes ES.next’s quasis, then ES.next might even be at the center of
> a triangle (Java, Smalltalk, Lisp) – which is a good thing.
Quasi-literals rule, and `` is the right quoting system given the characters
left that can be easily typed and that don't ding readability.
We have <| but it is a bit contentious. No one has topped it, though, and a
keyword instead seems to lose on both restricted-production and
no-better-word-than-<| grounds.
Some find -> and => cryptic, but it's hard to say the only alternative is to
stick to eight-letter 'function'. ('lambda' is not reserved and can't be used
without breaking compatibility; and it's six letters.)
Some find block-lambdas with their Ruby- (and to a lesser extend Smalltalk-)
inspired {||...} bracketing cryptic.
There are other options, but they all face genreric "too much line noise!"
objections.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
