paren-free call expressions
dxgriffiths at gmail.com
Wed May 25 22:15:31 PDT 2011
My rationale is that people reading code are not the same as parsers :) If a space is sometimes just a space, and sometimes it is effectively an implied (, then the comprehension difficulty is increased.
If you could measure it with an eye-tracking system, I suspect that savings like these are actually a net cost in additional eye fixations and reading time... especially in cases where the () can only be omitted sometimes and not others.
To quote someone else, it's an "absurd geek tweak" that can only really serve to make the overall JS codebase less accessible.
That's not to say it shouldn't be supported by altJS compilers and languages that showcase extreme minimalism for the novelty value, but in a global standard?
To answer your other question though, yes, I do and I get the value. I just think in this case it's unwise.
On 21/05/2011, at 4:26 AM, Jason Orendorff wrote:
On Thu, May 19, 2011 at 2:45 AM, David Griffiths <dxgriffiths at gmail.com> wrote:
> - they overload the space character, making it mean something different in only a small fraction of cases.
> The first point is major, in my opinion. If the goal is to have an argument list opener that doesn't require an explicit close, then some other character(s) would be a better solution than forcing people to read possible double-meanings into every space they see.
Could you clarify this objection? As I understand it, even with
paren-free call syntax, spaces would still have just one purpose: to
Many, many languages (including Perl, Ruby, VB, Scala, Smalltalk,
Logo, and of course all the ML-like languages, including Haskell and
F#) do without parentheses for calls in some circumstances at least.
Do you use any of these languages? I quite like some of them.
More information about the es-discuss