1. 6

  2. 3

    I like most of these suggestions. The things that stand out the most to me are comparing by value and modularizing a sort of standard library. I’m not sure I agree with the precise syntax (std:object for example), but I am 100% behind the idea behind it (I might suggest js.object instead, using js as the standard library namespace and replacing a colon with a period).

    1. 2

      i really hope the future of javascript is a gradual migration towards becoming essentially an ML dialect, perhaps while retaining some syntactic similarity to today’s javascript. opa was sadly ahead of its time, but reason appears to be gaining a lot of traction.

      1. 2

        what is still missing? a sane language ? javascript is not php but still ….

        1. 2

          The value objects, operator overloading or at least the infix functions would go a long way to resolve some of the annoying things I use classes for; usually defining an equals() or some kind of serializing toString() prototype on records.

          I feel another useful thing that could be added would be multi module files proposal I recently saw. I feel like it would help with ES module adoption.

          1. 1

            Nice post. Thank you sharing. I’,m not sure if I understood your object equality dilemma. Can you not compare objects using a double equal instead of a triple?

            > {x: 1, y: 4} == {x: 1, y: 4}
            1. 3

              Double equals stands for “loose equality” rather than “structural equality” in JS; all it does is cast the values to a common primitive type before comparing.

              1. 2

                Double equals and triple equals both evaluate to false for that comparison. Object comparisons are by reference, not by the contents of the object. And each side is a separate instance of Object.

                1. 1

                  Just ran it in console :) I find this behaviour odd.

              2. 1

                I think the answer to 5.2 (do we need operator overloading?) is clearly yes, because it would make problems like 1.1 (value objects) solveable even without language support.

                I’ve never encountered this “infix function application” before, but it strikes me as kind of silly. I’d much rather have the pipeline operator.