7 ms·

Leaving aside syntax preferences or other superficial concerns, I find it discouraging that "Motivating Examples" for a proposal include direct references to pa

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.

sharpercoder 9y ago
They should be included, as it simply is a valid use-case which most likely will actually be used. However, there should be many more examples or good real-world use-cases. Lack of those concerns me.
- karmajunkie 9y ago
  I think if you look at languages that support them natively, like F#, OCaml/Reason, or Elixir/Erlang, you'll find plenty of examples of real-world uses. Whether those would suffice to illustrate how to apply them in a JS codebase that has this proposal enabled, I cannot say. However, having gotten used to having them, I can safely say I'll always feel hobbled to work in a language that doesn't have them, so I'm very much in favor of adding them to JS, whether or not this is the proposal that wins out over time.
timhwang21 9y ago
Stage zero proposals generally read less formally. IIRC they are held to lower standards and expected to be formalized in the later stages.
austincheney 9y ago
Absolutely, agree. The code examples should be vanilla code, which could then be expanded to the preferences of any library/framework.
curun1r 9y ago
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.
- christophilus 9y ago
  > 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 dabbled in many other languages (and would love to professionally work in Clojure). [EDIT: Er, to the "non-mainstream" point, I've dabbled in Rust, Clojure, OCaml, Haskell, PureScript, Erlang, Elixir, and Elm. I don't know many JS devs that have done all of that, but most people I know have tinkered in odd non-mainstream languages.] Most JS devs I know are not single-language devs. Am I just a super anomalous member of the JS community? ... Anyway, back on topic, I'm a big fan of pattern matching, so I'm all for seeing this proposal become a reality.
  - minor3rd 9y ago
    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.
    - sibeliuss 9y ago
      With JavaScript being the most used language in the world I highly doubt the old stereotypes still apply
      - emodendroket 9y ago
snek 9y ago
Usage of these libraries are not the reason this proposal exists, but rather demonstrating how the proposal fits with popular tools and such within the ecosystem.
halestock 9y ago
I actually drew the opposite conclusion. As in, "here's an example of how a commonly used library is overly verbose and how it could be simplified with this language extension."
sibeliuss 9y ago
I really liked the examples they used. I was able to share with coworkers who weren't familiar with the concept and it made perfect sense.
shados 9y ago
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".
avshyz 9y ago
Well, think about the @ operator in python. It's aimed solely at people who use numpy.

sharpercoder 9y ago

They should be included, as it simply is a valid use-case which most likely will actually be used. However, there should be many more examples or good real-world use-cases. Lack of those concerns me.

karmajunkie 9y ago
I think if you look at languages that support them natively, like F#, OCaml/Reason, or Elixir/Erlang, you'll find plenty of examples of real-world uses. Whether those would suffice to illustrate how to apply them in a JS codebase that has this proposal enabled, I cannot say. However, having gotten used to having them, I can safely say I'll always feel hobbled to work in a language that doesn't have them, so I'm very much in favor of adding them to JS, whether or not this is the proposal that wins out over time.

timhwang21 9y ago

Stage zero proposals generally read less formally. IIRC they are held to lower standards and expected to be formalized in the later stages.

austincheney 9y ago

Absolutely, agree. The code examples should be vanilla code, which could then be expanded to the preferences of any library/framework.

curun1r 9y ago

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.

christophilus 9y ago
> 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 dabbled in many other languages (and would love to professionally work in Clojure). [EDIT: Er, to the "non-mainstream" point, I've dabbled in Rust, Clojure, OCaml, Haskell, PureScript, Erlang, Elixir, and Elm. I don't know many JS devs that have done all of that, but most people I know have tinkered in odd non-mainstream languages.] Most JS devs I know are not single-language devs. Am I just a super anomalous member of the JS community? ... Anyway, back on topic, I'm a big fan of pattern matching, so I'm all for seeing this proposal become a reality.
- minor3rd 9y ago
  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.
  - sibeliuss 9y ago
    With JavaScript being the most used language in the world I highly doubt the old stereotypes still apply
    - emodendroket 9y ago

snek 9y ago

Usage of these libraries are not the reason this proposal exists, but rather demonstrating how the proposal fits with popular tools and such within the ecosystem.

halestock 9y ago

I actually drew the opposite conclusion. As in, "here's an example of how a commonly used library is overly verbose and how it could be simplified with this language extension."

sibeliuss 9y ago

I really liked the examples they used. I was able to share with coworkers who weren't familiar with the concept and it made perfect sense.

shados 9y ago

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

avshyz 9y ago

Well, think about the @ operator in python. It's aimed solely at people who use numpy.