Live data from Hacker News

JavaScript Pattern Matching Proposal

github.com

201–210 of 254 posts

Re: JavaScript Pattern Matching Proposal

#201
post #23

Isn't pattern matching interesting only in a strongly typed environment where the compiler can statically check that you are giving instructions for all possible cases?

Hopefully this could be integrated with typescript as well, but this proposal would be great in certain cases to replace JS switch statements while also cleaning up the look of "case:" "break;" with something more elegant

Re: JavaScript Pattern Matching Proposal

#202
post #141

Earlier quoted context omitted.

> But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory Not to side-track the issue, but I keep hearing this. I'm wondering if this is true, and if so, how such a statement is verified. I'm currently a full-time JS dev, but have written my own programming languages, have professionally written in C, C++, C#, F#, Ruby, and others, and have…

I think you're a super anomalous member of any programming language's community. I doubt even one programmer in a thousand has written F# professionally (not being hipster here — I haven't done it myself).

a LOT of function programmers end up doing a lot of javascript work.

I don't think he is odd in any way.

Re: JavaScript Pattern Matching Proposal

#203
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…

it is showing the function roots of the match statement.

The kind of people who will jump in and use it will be the people who are used to have it called match.

Better yet, looking up match statement will show how matches work in the functional approach.

I am super happy they are calling it match.

Re: JavaScript Pattern Matching Proposal

#204
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…

Agreed that while "pattern matching" is a common term, it's perhaps not common enough. For comparison, a C# proposal of terser syntax (which uses the switch keyword) is available here: https://github.com/dotnet/csharplang/blob/master/proposals/p...

Re: JavaScript Pattern Matching Proposal

#205
post #109

Earlier quoted context omitted.

Really? I quite like them. I did get used to them in C# first, though. What would you have preferred?

I would have preferred a word. const my_arrow_function = arrow_function(){} arrow_function my_arrow_function(){} arrow_function(){}

In older C#, that would be delegate:

    delegate(int x){ return 10; }
(But yeah, nowadays that would be:)

    (int x) => 10

Re: JavaScript Pattern Matching Proposal

#206

Earlier quoted context omitted.

It's probably more of a "know your audience" decision. Anyone who's used an ML-derived language will understand the motivation for pattern matching. But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory, so they chose an example that's likely to resonate more with that group.

> But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory Not to side-track the issue, but I keep hearing this. I'm wondering if this is true, and if so, how such a statement is verified. I'm currently a full-time JS dev, but have written my own programming languages, have professionally written in C, C++, C#, F#, Ruby, and others, and have…

You are conflating two questions:

1. What percentage of JavaScript/front-end web developers are familiar with any other programming languages?

2. What percentage are familiar with a certain specific subset of other programming languages, namely functional or functional-ish languages with pattern matching as a core construct?

And you're treating an answer to (1) as an answer to (2).

Re: JavaScript Pattern Matching Proposal

#207
post #186

Earlier quoted context omitted.

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).

That seems pretty likely to be true of Github. But for Stack Overflow, I would be really surprised. Stack Overflow has had a huge and thriving C# community from the start, and it's got so much page rank that questions about any language, "web" or not, are likely to lead there. The only languages that seem likely to be underrepresented are ones that are mainly used by people who learned them long ago and aren't gaining any more users (like MUMPS or something), since those people are unlikely to have questions.

Re: JavaScript Pattern Matching Proposal

#208

Leaving aside syntax preferences or other superficial concerns, I find it discouraging that "Motivating Examples" for a proposal include direct references to particular libraries, or particular libraries' examples. I mean, that one (of two) motivations for adding a feature to a language is "Terser, more functional handling of Redux reducers", just feels wrong and casual.

Redux reducers were at least partly inspired by constructs of other languages that heavily rely on pattern matching.

So I'd take it more as "You know this mediocre compromise we had to do because JS is missing this core language feature? Well, there you go".

Re: JavaScript Pattern Matching Proposal

#209

I would prefer `match { ... } (value)`, with the `match` keyword essentially creating a function that does the matching when it invoked. Minor seeming change, but then you can think of match as being a generalization of arrow functions instead of a special new language construct (i.e., `(...args) => ...` is just shorthand for `match { ...args => ... }`) I can understand why though they went with similar syntax to a s…

This wouldn't work if the match contained eg. break or return.

Yes, if match is an expression than this restriction is the correct design in my opinion

Re: JavaScript Pattern Matching Proposal

#210
post #180

Earlier quoted context omitted.

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.

I'd be curious to see the methodology behind the rankings you speak of.

EDIT: saw the sibling thread.

Post reply on HN