Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Pattern Matching Proposal

github.com

Post reply on HN
Print view View original

191–200 of 254 posts

Re: JavaScript Pattern Matching Proposal

#191

Post by Tloewald »

aylmao wrote: post #127
Tloewald wrote: post #119

So the proposal is super confusing to me (but I hadn't seen match before). At first I thought it had something to do with regex. Essentially it's a switch variant that is (a) confusingly named 'match' (bad) (b) returns a value (good?) (c) and is actually a kind of function (wha?), since it (d) supports recursion, but (e) doesn't require break (good), (f) looks like a bag of inline functions but isn't (bad). How about…

Love this comment; reminds me of what I thought when I first encountered pattern matching. a. Yup, that's what it's called in OCaml, Scala, F#, etc. Might be a little confusing at first, but it's all about finding a "match" for your value, which is different from a guard in an "if" or a "switch". In an "if", you need to provide a boolean (or a value coercible to a boolean). In a "switch" you don't provide the boolean…

I totally get what it does, even if I hadn't seen it before. What I don't get is (a) the use of the word 'match' (that's unfamiliarity) and (b) the proposed syntax which looks like an absolute mess, something worthy of PHP, and the fact that we end up with something that isn't a function but is recursive. Or something.

'x => x = 1' in Javascript, is an expression that resolves to a function. I do understand the difference, and it's important.

'match(x) { {x} => foo }' is not a bag of functions but a new use of the '=>' operator that is confusing/surprising. I can get over it, but why should I have to?

'match(x) { {x} : foo }' would be less surprising.

You're saying 'match({x:1}) { ....}' is an expression, but is 'match(x) { {x} => foo }'?, What does it resolve to? It smells like it either isn't an expression (just as you can't write x = switch(x) {...};) or it's a new kind of function.

Re: JavaScript Pattern Matching Proposal

#192

Post by lmm »

stiGGG wrote: post #69
lmm wrote: post #38

Earlier quoted context omitted.

> It's been "trendy" since the 70's. It's been possible since the '70s but I've seen a lot more talking about it in the last 5-10 years.

Yeah, this applies to all that old Lisp features.

I'd say it's less about Lisp and more that the ML lineage is finally getting its day in the sun (and not before time).

Re: JavaScript Pattern Matching Proposal

#193

Post by Retra »

sibeliuss wrote: post #154
minor3rd wrote: post #126

Earlier quoted context omitted.

I think it's a stereotype from the old web when it didn't require as much technical skill as other programming fields. Most of my colleagues started in other languages and learned Node/JS on the job.

With JavaScript being the most used language in the world I highly doubt the old stereotypes still apply

Any language that is the most used is going to be used by mostly below-average programmers. I have yet to see a single domain where quality can be measured by popularity.

Re: JavaScript Pattern Matching Proposal

#194

Post by emodendroket »

Roboprog wrote: post #185
heretoo wrote: post #173

Earlier quoted context omitted.

The same can be said for function calls, with the indirection they create hiding details of broken and side-effecting implementations. None the less, the opposite is also true. Languages that have macro facilities can aid in writing more legible code. (See `threading` in clojure), or the `loop` macro and regular expression macros in common lisp.

Well said. Rambling Java code with little to no abstraction is its own kind of nightmare. Some people are just terrified of any new abstractions, I guess, preferring to work with an endless series of tally marks, rather than these obfuscating “multiplication” and “exponent” complications (exaggerating to make a point - abstract != unintelligible).

I think there is probably some middle ground between "no abstraction at all" and "literally anything goes."

Re: JavaScript Pattern Matching Proposal

#195

Post by westoncb »

aylmao wrote: post #180
westoncb wrote: post #164

Earlier quoted context omitted.

Is it the most used language in the world? Seems like I keep hearing comments like that, but the rankings I've seen don't list it that way.

According to Stackoverflow's developer survey it is [1]. Doesn't surprise me since developing for web means JavaScript. Curious to know what rankings you are referring to though. [1]: https://insights.stackoverflow.com/survey/2018/#technology

I didn't see anything on methodology, but I'm assuming they're just surveying their users—in which case, I think it would make some sense for javascript to be overrepresented.

Re: JavaScript Pattern Matching Proposal

#196

Post by westoncb »

chc wrote: post #186
westoncb wrote: post #182

Earlier quoted context omitted.

Tiobe index for one. But I just searched Google and checked the top few.

The TIOBE index has always been a bit weird. If you read their note about their methodology, you'll see that it's measuring something kind of interesting, but not really what you'd call "the most used languages." For example, IIRC part of a language's TIOBE ranking is how many college courses use it.

Do you know of another more objective source, though?

Other folks are citing Github and Stack Overflow, but they are just reporting on proportions used on their own sites, and I would not be at all surprised to find that both those sites are more popular with web developers than say Java or C/C++/C# or Visual Basic devs (all those languages outrank javascript on Tiobe).

Re: JavaScript Pattern Matching Proposal

#197

Post by recursive »

sakuronto wrote: post #34

Interestingly, the match construct is an expression, which I don't think JavaScript has m/any of. Perhaps they could retroactively make if/else expressions, if that doesn't break back-compat.

What do you mean by expression? In the common usage, javascript has plenty of them. E.G. "asdf", 1 + 2, [3, 4], {"foo": "bar"}, and fn(arg).

Not to mention the if/else expression, a ? b : c

Re: JavaScript Pattern Matching Proposal

#198

Post by Sharlin »

sibeliuss wrote: post #179
westoncb wrote: post #164

Earlier quoted context omitted.

Is it the most used language in the world? Seems like I keep hearing comments like that, but the rankings I've seen don't list it that way.

At least according to Github: https://octoverse.github.com/ - it's in its own class compared to the others: 2.3m to the next most popular (1m, python)

Yeah, but there's a trivial selection effect going on with Github.

Re: JavaScript Pattern Matching Proposal

#199

Post by Sharlin »

Tloewald wrote: post #191
aylmao wrote: post #127

Earlier quoted context omitted.

Love this comment; reminds me of what I thought when I first encountered pattern matching. a. Yup, that's what it's called in OCaml, Scala, F#, etc. Might be a little confusing at first, but it's all about finding a "match" for your value, which is different from a guard in an "if" or a "switch". In an "if", you need to provide a boolean (or a value coercible to a boolean). In a "switch" you don't provide the boolean…

I totally get what it does, even if I hadn't seen it before. What I don't get is (a) the use of the word 'match' (that's unfamiliarity) and (b) the proposed syntax which looks like an absolute mess, something worthy of PHP, and the fact that we end up with something that isn't a function but is recursive. Or something. 'x => x = 1' in Javascript, is an expression that resolves to a function. I do understand the diffe…

Apparently they're overloading the meaning of the => "fat arrow" in the proposed syntax. I agree it's confusing because it's already used with lambdas in case of JS, but many languages with pattern matching do use it (eg. Scala, Rust). Other languages like Haskell and F# use the thin arrow -> instead.

Pattern matching can be exhaustive or non-exhaustive. Basically, if a match construct is going to be an expression it has to yield a value* for any input value, ie. there has to be a case arm for every possible input. Usually match blocks have a way to declare a "default" or "else" arm for those values that don't match anything else. Some languages with static type systems can statically figure out whether a given match expression is exhaustive or not. But in JavaScript's case that's most likely not an option. The JS way is probably yielding `undefined` if a value fails to match anything.

* or diverge, ie. loop forever, or exit via nonlocal means such as exceptions.

Re: JavaScript Pattern Matching Proposal

#200

Post by XR0CSWV3h3kZWg »

heretoo wrote: post #175
bastawhiz wrote: post #46

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…

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?

Post reply on HN