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?
JavaScript Pattern Matching Proposal
201–210 of 254 posts
Re: JavaScript Pattern Matching Proposal
#202Earlier 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).
I don't think he is odd in any way.
Re: JavaScript Pattern Matching Proposal
#203Earlier 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…
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
#204Earlier 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…
Re: JavaScript Pattern Matching Proposal
#205Earlier 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(){}
delegate(int x){ return 10; }
(But yeah, nowadays that would be:) (int x) => 10Re: JavaScript Pattern Matching Proposal
#206Earlier 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…
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
#207Earlier 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).
Re: JavaScript Pattern Matching Proposal
#208Leaving 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.
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
#209I 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.
Re: JavaScript Pattern Matching Proposal
#210Earlier 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.
EDIT: saw the sibling thread.