151–160 of 254 posts
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…
I think it's good to note that this proposal is not far along the process. Pattern matching, if it clears TC39 (a tall order, to be honest), won't land in a spec for half a decade at least I would bet. So, keep the feedback coming, and don't worry that you'll have to learn this syntax tomorrow. It's still very early, and I wouldn't be surprised if there are at least a couple major revisions before anything like this…
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…
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 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.
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.
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…
It's certainly a tired narrative that a lot of the churn in the front-end javascript framework world comes from developers who aren't aware of well-recognized patterns and techniques from other languages. But stereotypes and tired critiques almost always have some basis in reality and it does seem like the JavaScript world is rediscovering a few lessons the hard way rather than learning from the experience of other language communities.
Earlier quoted context omitted.
Let's see an example of your proposed alternative syntax.
Here you are: var x = match (response) { case { status:200 }: true; case { status: 404 }: new NotFoundError; case Number: Math.PI; case SomeClass: 1; case /^http/: "http error"; default: -1; };
I think it's good to note that this proposal is not far along the process. Pattern matching, if it clears TC39 (a tall order, to be honest), won't land in a spec for half a decade at least I would bet. So, keep the feedback coming, and don't worry that you'll have to learn this syntax tomorrow. It's still very early, and I wouldn't be surprised if there are at least a couple major revisions before anything like this…
With babel plugins/transforms this could be used a lot sooner than that
You're right that Babel (and TypeScript!) implement features earlier than they land in the spec, but at least TS does so only when it's almost for sure going to make it in (around stage 3) and people probably shouldn't be using stage 0-2 plugins for anything but experiments, IMO.