Hacker News Reader

Comment by bastawhiz | Hacker News Reader

I can only see this being a foot gun. Deep equality testing of objects is going to encourage the use of getters. Getters with side effects (no way to prevent them) will basically ruin your day if you try to use pattern matching with them.

Additionally, this would be the first "native" way to do deep equality testing of objects. I can see it being abused to do simple one-off checks that could otherwise have been done more simply in an imperative way.

Do we really need to save the five lines of code at the cost of new syntax? This doesn't seem to prevent any significant amount of toil, since it can be pretty easily unrolled into existing JS syntax.

View on HN

I wouldn't necessarily say it's deep equality, it's just a less verbose way of sequentially checking properties. It's not going to check every property.

At least for me, I feel I'd be using this a lot for the boring but common use case of checking for empty arrays and such:

  const doSomethingToArr = arr => match (arr) {
    [] => whatever,
    [x] => whatever,
    [x, ...xs] => whatever
  }

I'm guessing you've not worked with pattern matching of the kind you see in F# or Elixir before? Yes, JS would definitely be better off having this available. Well-developed pattern matching can actually obviate the need for conditionals in a lot of cases, which makes for far cleaner code.

If it is five lines of code vs. one line of code, and we believe that the number of bugs is proportional to the number of lines of code, irrespective of which language we are programming in, then this would be an obvious benefit.

And it isn't four lines saved, but four lines times the number of uses in the entire code base.

> we believe that the number of bugs is proportional to the number of lines of code

Why would you believe that?

And if you do believe that why don't you use a code golfing language?

What exactly are you contributing by taking what they said to the extreme?

Should someone now have to point out to you that a million-line function is worse than a ten-line function for calculating fizzbuzz? Is that meaningful discourse in your book?

My response seems to have upset you. I'm sorry that happened.

In general I believe that number of lines of code is correlated with number of bugs, but I would hesitate to say that it is proportional to. Going in with the explicit goal of reducing the number of lines could easily lead to more bugs, not less.

I would agree, BUT code needs to be readable first. The proposed syntax applied to e.g switch would have just braces which would not look very readable.

Having less lines can make extremely unreadable code. Readable code with an error is easy to fix, unreadable code is not.

At the very least the ambiguity of doing TWO things (matching AND destructuring) should not be allowed since it changes the outcome based on whether a value is a literal or a variable with the exact same literal assigned to it (at least that's how I understand it from reading the examples)

Reply on news.ycombinator.com