5 ms·

I hate this trope that "js people just discovered this feature and now rush to get it included". Not only is it not true in many cases (I've been using pattern

I hate this trope that "js people just discovered this feature and now rush to get it included". Not only is it not true in many cases (I've been using pattern matching for years in other functional languages and I'm anxiously hoping the proposal will get closer to inclusion in JS, but I'm sure if/when it lands I'll be told about how sad it is that I just learned about this feature when others have had it for decades...), but it's also pointlessly "holier than thou". If JS doesn't have a feature, people say that they want it. Once it gets it, another crowd complains about how they should have had it 15 years ago. The fact is that there wasn't much of a need for something like globalThis 15 years ago. We had window, and that's all that we needed. Then we got global with node, and then self in workers, and then JS started getting more usage in embedded contexts with none of that. A problem was found, a proposal created and refined, a polyfill made, and finally it's going to be part of the language. This is progress, this is the maintainers identifying and fixing a deficiency, only to be met with "who cares they should have done it years ago [when nobody was asking for it]". My point being there's just no need to say that. It doesn't contribute anything, it's just belittling the work of some very talented people who are making things that people are asking for in ways that don't break past code. That may not have been your intention, and I'm sorry for coming into this with a lot of baggage here, but it's just something that really gets under my skin and I've seen multiple TC39 people talk about how they avoid places like HN because of those kinds of attitudes, and I feel that everyone is missing out because of it.

lmm 7y ago
People were asking for it. OCaml is the same age as JavaScript but had all these features from day 1. It's especially frustrating when JavaScript fans talk as though JavaScript had invented a language feature that in fact existed decades earlier, which frequently happens. It's worth being aware that JavaScript is (and always has been) a long way behind the language design state of the art. That informs people's choice of language (in cases where non-JS is an option - but in these days of transpilers, non-JS is always an option). It's not a reason for people to stop improving JavaScript if they find it useful to do so, but it may be a reason to switch away from JavaScript.
- Klathmon 7y ago
  But you're building a strawman there. I don't think I've ever seen anyone claim that javascript invented these features (especially not this one! It's a reference to the global scope...). People are excited to have these features in their language, they may like the JS implementation better than others or vice versa, they may talk about how much it improves the language or how it's a detriment to the language to have it included, but I haven't seen anyone claim that "javascript invented this". It's fine to want to be aware that JS isn't "state of the art" in language design, but I really don't think anyone believes that it is. (and as an aside, I don't think I'd want to use a language that was state of the art as the base for a large application, because that means that there isn't much testing or prior art to build from) But that argument also misses the point. I'm happy to talk about the pros and cons of languages, I'm happy to discuss how erlang's message passing makes some things extremely easy to develop, how python's collections make many kinds of programming much easier to read. But bringing up how other languages have had a feature "years ago" once it's arrived in javascript isn't discussing pros and cons or offering reasons to switch, it's turning tools into sports teams where you are "rooting" for your favorite. If/when JS gets pattern matching, you can be your ass i'll be in that thread comparing it to ocaml's approach, or F#'s approach to see the differences and similarities, to see the benefits of each, to see how they all fit into each languages ecosystem. But I won't be exclaiming how it doesn't matter because "other languages had this years ago!", because it doesn't help anything, it doesn't give anyone information they can act on, it doesn't discuss tradeoffs, it is just downplaying the achievements of the people that helped make it a reality.
  - lmm 7y ago
    > People are excited to have these features in their language, they may like the JS implementation better than others or vice versa, they may talk about how much it improves the language or how it's a detriment to the language to have it included, but I haven't seen anyone claim that "javascript invented this". I've seen people say javascript invented non-blocking I/O or had the first practical implementation. I've even seen people say it was the first mainstream language with map/reduce/filter. > But that argument also misses the point. I'm happy to talk about the pros and cons of languages, I'm happy to discuss how erlang's message passing makes some things extremely easy to develop, how python's collections make many kinds of programming much easier to read. But bringing up how other languages have had a feature "years ago" once it's arrived in javascript isn't discussing pros and cons or offering reasons to switch, it's turning tools into sports teams where you are "rooting" for your favorite. That's a failure mode, sure. But being aware of where a language stands on the innovation spectrum can also help you learn more about what else is out there. If you know JavaScript is getting a feature today that OCaml had 20 years ago, you might start looking around for language features that JavaScript will be getting in 20 years' time that are available in other languages today. That's information you can act on, and might draw attention to a tradeoff you weren't even aware you were making by using JS.
IgorPartola 7y ago
The day JS stops making ’1’ + 2 a string and throw an error is the day I will stop pointing it out. Yes lots of experienced devs use JS. Some of them come from other languages with lots of experience. But at the same time, JS language feature development is slow and awkward. This article is a good example of that. I know of no other popular language where accessing the global object is such a mess. And we will wind up with globalThis as some built in language feature which makes no goddamn sense. Read that variable name out loud a few times. Even reading the article you start bumping into “this globalThis variable is this and that”. I swear keeping window would have been preferable. Or calling it global. But instead we have a language spec that allows this this to be different from that this and this global this is not the same as this globalThis and that globalThis. I point this out because it is important to contextualize why JS is in the state it is in. The powers that be seem less interested in fixing the issues of the languages and more interested in plastering over them. A language with this many polyfills is broken. I use JS almost every day at work, same as Python. 100% prefer Python.
- crooked-v 7y ago
  > I swear keeping window would have been preferable. Or calling it global. The tc39 proposal for globalThis mentions that `global` was preferred, but it broke major websites that were for whatever reason relying on setting their own values for `window.global`.
- jraph 7y ago
  > The day JS stops making ’1’ + 2 a string and throw an error Please, no. I'm bitten by this in Python every other day, with its otherwise weak typing. It feels like you can do many horrible things with types in Python, but no, you shall explicitly cast those numbers to strings. It is being more pedantic than Java by doing this. This never caught a real error in my code but it did make it needlessly fail at runtime because I did not put "str()". I know that the newer Python 3.x versions provide a nice bash-like way to embed expressions in strings and would let me avoid the problem entirely, but this would prevent my code to run in many places (and "Hello, I'm {}".format(age) is painful, hence the new feature by the way). Thank you for trying to save my back from unwanted implicit type casts, but provide me with static typing instead if you want to do so, and fail at compile time. If you want '1' + 2 to fail in JavaScript (You might want to, especially when keys of objects are coerced to strings in Javascript, which is actually crappy, and when you are constantly fetching numbers as strings from the web page), use TypeScript. It's amazing and provides a far better way of handling silly type errors. edit: and by the way, C++ is a bit surprising in this respect. "Hello" + 2 is equal to... "llo".

lmm 7y ago

People were asking for it. OCaml is the same age as JavaScript but had all these features from day 1. It's especially frustrating when JavaScript fans talk as though JavaScript had invented a language feature that in fact existed decades earlier, which frequently happens. It's worth being aware that JavaScript is (and always has been) a long way behind the language design state of the art. That informs people's choice of language (in cases where non-JS is an option - but in these days of transpilers, non-JS is always an option). It's not a reason for people to stop improving JavaScript if they find it useful to do so, but it may be a reason to switch away from JavaScript.

Klathmon 7y ago
But you're building a strawman there. I don't think I've ever seen anyone claim that javascript invented these features (especially not this one! It's a reference to the global scope...). People are excited to have these features in their language, they may like the JS implementation better than others or vice versa, they may talk about how much it improves the language or how it's a detriment to the language to have it included, but I haven't seen anyone claim that "javascript invented this". It's fine to want to be aware that JS isn't "state of the art" in language design, but I really don't think anyone believes that it is. (and as an aside, I don't think I'd want to use a language that was state of the art as the base for a large application, because that means that there isn't much testing or prior art to build from) But that argument also misses the point. I'm happy to talk about the pros and cons of languages, I'm happy to discuss how erlang's message passing makes some things extremely easy to develop, how python's collections make many kinds of programming much easier to read. But bringing up how other languages have had a feature "years ago" once it's arrived in javascript isn't discussing pros and cons or offering reasons to switch, it's turning tools into sports teams where you are "rooting" for your favorite. If/when JS gets pattern matching, you can be your ass i'll be in that thread comparing it to ocaml's approach, or F#'s approach to see the differences and similarities, to see the benefits of each, to see how they all fit into each languages ecosystem. But I won't be exclaiming how it doesn't matter because "other languages had this years ago!", because it doesn't help anything, it doesn't give anyone information they can act on, it doesn't discuss tradeoffs, it is just downplaying the achievements of the people that helped make it a reality.
- lmm 7y ago
  > People are excited to have these features in their language, they may like the JS implementation better than others or vice versa, they may talk about how much it improves the language or how it's a detriment to the language to have it included, but I haven't seen anyone claim that "javascript invented this". I've seen people say javascript invented non-blocking I/O or had the first practical implementation. I've even seen people say it was the first mainstream language with map/reduce/filter. > But that argument also misses the point. I'm happy to talk about the pros and cons of languages, I'm happy to discuss how erlang's message passing makes some things extremely easy to develop, how python's collections make many kinds of programming much easier to read. But bringing up how other languages have had a feature "years ago" once it's arrived in javascript isn't discussing pros and cons or offering reasons to switch, it's turning tools into sports teams where you are "rooting" for your favorite. That's a failure mode, sure. But being aware of where a language stands on the innovation spectrum can also help you learn more about what else is out there. If you know JavaScript is getting a feature today that OCaml had 20 years ago, you might start looking around for language features that JavaScript will be getting in 20 years' time that are available in other languages today. That's information you can act on, and might draw attention to a tradeoff you weren't even aware you were making by using JS.

IgorPartola 7y ago

The day JS stops making ’1’ + 2 a string and throw an error is the day I will stop pointing it out. Yes lots of experienced devs use JS. Some of them come from other languages with lots of experience. But at the same time, JS language feature development is slow and awkward. This article is a good example of that. I know of no other popular language where accessing the global object is such a mess. And we will wind up with globalThis as some built in language feature which makes no goddamn sense. Read that variable name out loud a few times. Even reading the article you start bumping into “this globalThis variable is this and that”. I swear keeping window would have been preferable. Or calling it global. But instead we have a language spec that allows this this to be different from that this and this global this is not the same as this globalThis and that globalThis. I point this out because it is important to contextualize why JS is in the state it is in. The powers that be seem less interested in fixing the issues of the languages and more interested in plastering over them. A language with this many polyfills is broken. I use JS almost every day at work, same as Python. 100% prefer Python.

crooked-v 7y ago
> I swear keeping window would have been preferable. Or calling it global. The tc39 proposal for globalThis mentions that `global` was preferred, but it broke major websites that were for whatever reason relying on setting their own values for `window.global`.
jraph 7y ago
> The day JS stops making ’1’ + 2 a string and throw an error Please, no. I'm bitten by this in Python every other day, with its otherwise weak typing. It feels like you can do many horrible things with types in Python, but no, you shall explicitly cast those numbers to strings. It is being more pedantic than Java by doing this. This never caught a real error in my code but it did make it needlessly fail at runtime because I did not put "str()". I know that the newer Python 3.x versions provide a nice bash-like way to embed expressions in strings and would let me avoid the problem entirely, but this would prevent my code to run in many places (and "Hello, I'm {}".format(age) is painful, hence the new feature by the way). Thank you for trying to save my back from unwanted implicit type casts, but provide me with static typing instead if you want to do so, and fail at compile time. If you want '1' + 2 to fail in JavaScript (You might want to, especially when keys of objects are coerced to strings in Javascript, which is actually crappy, and when you are constantly fetching numbers as strings from the web page), use TypeScript. It's amazing and provides a far better way of handling silly type errors. edit: and by the way, C++ is a bit surprising in this respect. "Hello" + 2 is equal to... "llo".