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.
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 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.
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).
Sure, a lot of functional programmers probably do end up doing javascript work. But that's still a large subset of a very small fraction of programmers in general, and they're definitely still vastly outnumbered by the folks who are barely more than script kiddies.
It's certainly been my experience that there are a lot of JS developers who aren't like you, though I have met a few who are. But JS has traditionally been one of the most accessible languages. Before transpilers became common, view source allowed non-programmers to learn javascript by example. And because of it's use in the front-end/web, you saw a lot graphic designers and other non-programmers learn it to be able to put something online. Javascript also goes out of its way to be friendlier. While other languages complain when you try to add two different width integers, Javascript will happily add a number and a string together. It's something that drives those of us with a static typing background nuts, but makes the language more approachable overall.
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.
> Javascript also goes out of its way to be friendlier. While other languages complain when you try to add two different width integers, Javascript will happily add a number and a string together. It's something that drives those of us with a static typing background nuts, but makes the language more approachable overall.
We have differing definitions of friendly. Since I understand types and operator overloading, I know that 1 and "1" are different. I also know that the operator + does traditional math addition and concats Strings. If I didn't, it would probably drive me bonkers that "1" + 1 is "11" in JS instead of 2 or even "2". Having knowledge about types and overloading automatically tells me that String + Int = String.
I'm not saying that JS is bad since it lacks static typing. I'd argue that lack of static typing makes a language tougher to learn rather than more approachable. The barrier of entry is lower, but makes comprehension tougher.
> I'd argue that lack of static typing makes a language tougher to learn rather than more approachable
I think it's a bit of a wolf in sheep's clothing. It makes it harder to master, but less intimidating when you're first starting out.
Also, I probably shouldn't have used the term static typing, since the issues I'm talking about are more associated with weak typing rather than dynamic typing.
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.
Unless front-end development as a category has completely disappeared in the last few years there are certainly quite a few people who don't know how to do anything else.
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.
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.
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.
I think that the large percentage of JS developers the GP is talking about is people for whom JS is probably their first or second programming language (and then the first is something like python, ruby or php).
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).
I'm s full time JS dev too. People keep saying that JS sucks or whatever, but [Rust, Clojure, OCaml, Haskell, PureScript, Erlang, Elixir, Elm, Scala, Nim] jobs are just so rare that picking one and going deep is basically like hoping to win a lottery.
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.
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.
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."
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.
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.