Live data from Hacker News

Is JavaScript getting worse?

buzzdecafe.github.io

51–60 of 117 posts

Re: Is JavaScript getting worse?

#51
post #34

Earlier quoted context omitted.

ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people are doing that already .

I somewhat agree, but "adding tools" at the language level doesn't come for free: it causes an explosion in the number of interactions to keep track of. How do classes interact with prototypes? How do they interact with lexical scope? How do they interact with exceptions? etc. The egregious part is that, by turning something into a language feature, those who don't use it are often forced to take it into account in t…

> those who don't use it are often forced to take it into account in their code; especially library authors.

No, `class` is syntactic sugar for the most common way of doing classes in ES3 and ES5. There is no semantic difference between:

    function Thing () {}

    Thing.prototype.greet = function () { alert("hello"); };
and

    class Thing {
      greet () {
        alert("hello");
      }
    }

They are the same, so it introduces no new traps for library authors.

Re: Is JavaScript getting worse?

#52

Earlier quoted context omitted.

What you have to keep in mind is that JavaScript is not "a properly scoped language". Pretending that it is will cause you to miss key aspects of how the tool works. This helps no one, including you. Please, for as crappy as the language might feel, approach the language on its own terms.

Function scopes and variable hoisting was not the best parts of JS anyway. let brings lexical scope into the game, which I think is a great progress. And you cannot expect a variable to be defined outside of its lexical scope. That's not any different that trying to access a variable outside of a function that is defined in. If people were abusing variable hoisting in some way, they can continue to do so, by not usin…

> And you cannot expect a variable to be defined outside of its lexical scope.

Okay, but since `typeof x` can return "undefined", I would expect it to return `undefined` if x is no defined. Now, sometimes `typeof x` returns `undefined` if x is not defined, but other times it raises if x is no defined. That's the issue.

I too predict this is going to give people a lot of trouble. We will see.

Re: Is JavaScript getting worse?

#53
post #24

Whats his problem with classes? I find them a whole lot easier to reason about than prototype based inheritance. (But then I have more experience with class based languages).

Well, even if you prefer classes, you've now got to reason about prototypes and classes, and possible mixtures of both.

Re: Is JavaScript getting worse?

#54
post #7

I like `let`. It means you have to be implicit and actually be aware of what you're doing.

That part of the article isn't particularly clear. The intended behavior of let is great. The unintended behavior - that it can cause typeof to fail - is bad.

It seems to me typeof in the described case should return undefined.

Re: Is JavaScript getting worse?

#56

This is one of the few posts about javascript that I've encountered that sees hoisting as a good thing. I like `let`.

Hoisting is great thing, it is really helpful to improve readability when doing asynchronous function calls.

    function a(){
      setTimeout(b, 1000);
    }

    function b() {
      setTimeout(c, 1000);
    }

    function c() {
    }

Re: Is JavaScript getting worse?

#57
post #54
post #7

Earlier quoted context omitted.

That part of the article isn't particularly clear. The intended behavior of let is great. The unintended behavior - that it can cause typeof to fail - is bad.

It seems to me typeof in the described case should return undefined.

typeof is never being invoked, so it can't return anything.

The rules of let are that any reference to the variable before the let declaration (the "temporal dead zone"), it's a reference error. So the reference error is being thrown before typeof is invoked.

Re: Is JavaScript getting worse?

#58
post #21

Earlier quoted context omitted.

"They are not reflected in the function’s length property" is exactly what the article does say. Whoop-dee-freakin’-doo http://en.wiktionary.org/wiki/whoop-de-doo http://en.wikipedia.org/wiki/Tmesis

My bad, I misread. However, my point is still the same: there was two equally valid choices. Should the other path had been prefered, the author would now be complaining about it too. I don't find it very constructive. As for Whoop-dee-freakin’-doo, no, it don't think it means anything in the context. That's not an argument, and the following sentence isn't either. Maybe I don't understand because english isn't my na…

From my understanding, the author was complaining about the way default arguments mess up implementations of currying. If default arguments were included in the .length, then all existing currying implementations would carry on working with no modifications, they would just ignore the default values and require that we pass in values explicitly.

Let's say we have these functions:

    function getElem(arr, index=0) { return arr[index]; }
    var curried = curry(getElem);
In a hypothetical world where default arguments are included in the length, we would have to supply them explicitly. That's no big deal though, it's just a potential inconvenience:

    // Hypothetical, "better" semantics
    var arr = ["a", "b", "c"];
    console.log(curried(arr));     // partially-applied function, *not* "a"
    console.log(curried(arr, 0));  // "a"
    console.log(curried(arr, 1));  // "b"
The ES6 semantics is worse because we cannot provide a non-default argument to a curried function:

    // Actual, "worse" semantics
    console.log(curried(arr));     // "a"
    console.log(curried(arr, 0));  // Error: attempts to run `"a"(0)`, but "a" is not a function
    console.log(curried(arr, 1));  // Error: attempts to run `"a"(1)`, but "a" is not a function
The reason this is particularly unfortunate is that one major use-case of currying is to provide default arguments! In other words, by adding default arguments to the language in this way, ES6 is breaking an existing mechanism for default arguments!

I would argue that currying is actually more general than default arguments, so if it's a choice between one or the other, they should have added currying to the language instead of default arguments.

They're not quite comparable, but you can think of currying as supplying default arguments "dynamically" (at the call site), whereas regular default arguments are supplied "statically" (at the definition site). For example:

    // Give "y" a default value for everyone
    var defaultMultiply = function (x, y=2) { return x * y; };

    console.log(defaultMultiply(5, 7));  // 35
    console.log(defaultMultiply(5));     // 10

    // Don't commit to any defaults yet
    var curryMultiply = curry(function(x, y) { return x * y; });

    console.log(curryMultiply(5, 7));  // 35

    // Give "x" a default value, to act like defaultMultiply
    var double = curryMultiply(2);

    console.log(double(5));  // 10

    // Give "x" a different default, which we can't do with defaultMultiply
    var triple = curryMultiply(3);
    console.log(triple(5));  // 15
I've implemented and used currying in JS, PHP and Python, and I found JS the most pleasant, specifically because it didn't have default values.

Re: Is JavaScript getting worse?

#59
>Classes. Whoop-dee-freakin’-doo.

There are dozens of ways to do classes/inheritance. Standardizing this means better tooling, documentation, and interoperability.

>Default parameters. By itself, this is another “so what” feature.

It's extremely useful in conjunction with named parameters. Named parameters are so much better than "option" objects.

If it's right in the function's signature, you can see right away how this thing is supposed to be used. Since it's declarative, it can be also picked up by your editor, too.

>let considered harmful

No, it's not. It makes variable declaration work like everywhere else. Function scope is the super weird anomaly.

Re: Is JavaScript getting worse?

#60
post #56

This is one of the few posts about javascript that I've encountered that sees hoisting as a good thing. I like `let`.

Hoisting is great thing, it is really helpful to improve readability when doing asynchronous function calls. function a(){ setTimeout(b, 1000); } function b() { setTimeout(c, 1000); } function c() { }

If I'm not mistaken that's not hoisting, since that code will work as long as a() is called after b is declared regardless of the hoisting. Keep in mind b is only accessed when a() is actually executed, not when it's declared!

Hoisting works like this:

    a();

    function a() {
      console.log("FOO");
    }
Which might or might not be more readable, depending on your tastes.
Post reply on HN