1. 41
  1.  

  2. 10

    Somehow I don’t consider this to be that wierd, but it’s probably because I’m familiary with the concept from Lisp’s setf form, that assigns values to “generalized places”. It’s even more interesting (or wierd depending on your take) in Elisp, where it can be used to set the position of the point and mark, the widths of windows (Emacs’ Speak for Frame), match data or even conditionals such as if or cond. Any function that builds on this “generalized place” abstraction, such as push or incf (rather cl-infc for Elisp) work as expected.

    The difference between that and what JavaScript is that all of these things have been implemented in the language itself, and anyone could extend it to fit any new function or datatype, while at the same time one can understand how it is done. car and cdr quite simply set up by

    (gv-define-simple-setter car setcar)
    (gv-define-simple-setter cdr setcdr)
    

    where it’s pretty understandable what gv-define-simple-setter does, without having to read the definition of the macro (or even knowing that it is a macro (although it should be obvious to anyone knowledgable in lisp)). I guess in that sense, in the hidden and incomprehensible complexity of the internal workings of Javascript, I can agree, in more that this case, that it is “wierd.”

    1. 8

      I also don’t consider this syntax weird (this is how array access should have worked from the beginning in all languages).

      Nevertheless, it’s a great demonstration of how lopsided the consideration of language additions has been (and are to this day):

      Whenever a new feature is proposed, people only ever look at “how hard is it to add this?” and never ask “how hard is it to remove it again?”.

      The result are languages that grow more impenetrable with every release, without even having a working process to remove existing features from the language.

      1. 2

        Not just array access. Imagine typeable, composable, isomorphic getter/setters.

        1. 2

          Yep. My point is that array read and array write are nothing more than functions Array -> Int -> T and Array -> Int -> T -> Unit, and should receive no special treatment compared to any other functions.

          Additionally, [] are required for Generics in most languages, so they have to be dropped for this special case anyway.

          1. 1

            Are you saying that you’re against all syntactic sugar?

            1. 1

              Pretty much, yes. In 90% of the cases it backfires so hard, that it just isn’t worth it.

              Hindsight is 20/20, but that doesn’t help when most language designers spend very little time looking back at decisions and reflecting on how they worked out.

              1. 1

                Can you provide a description for a minimal language that’d be useful but also doesn’t provide syntactic sugar?

      2. 7

        “What in the Crockford is going on?”

        That line made me giggle.

        1. 2

          I came to say the exact same thing.