4 ms·

I have a bit of a hard time with you there, I like to use maps in my code and trying to map a parser over a list of strings and getting the wrong answer is far

I have a bit of a hard time with you there, I like to use maps in my code and trying to map a parser over a list of strings and getting the wrong answer is far from 'of no consequence' to me. I'm not saying these issues make the language unusable, but you've got to be a bit more honest that you were if you want to be taken seriously.

xodeus 6y ago
But you're not getting the wrong answer, it's doing exactly what it should do. That one isn't really even a weird language quirk like the others. It's just assuming you're not aware that parseInt can take a 2nd argument
- Orou 6y ago
  The issue doesn't arise because of parseInt() being able to take more than one argument, the issue is that map() is passing not only the value in the array but also its index as well as a copy of the full array. I use map() all the time but I didn't know about that until I read this article. I wonder why map() functions this way in Javascript and if any other languages pass additional values like this in their own map() implementations. I do think GP has a fair point of criticism - at least when I use map() I expect it to take each value in the array and pass it to the callback function. I don't expect it to take each value in the array, the index of that value and the entire array and pass all of that to the callback function instead.
  - karatestomp 6y ago
    > I wonder why map() functions this way in Javascript and if any other languages pass additional values like this in their own map() implementations. Sometimes it's very convenient to be able to look ahead or behind the current element being map()'d to make decisions.
  - mellow2020 6y ago
    Where do your expectations come from though? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - Udik 6y ago
    > map() is passing not only the value in the array but also its index as well as a copy of the full array. I use map() all the time but I didn't know about that until I read this article Then you don't know the basics of the language you're using- how can you complain about it? > when I use map() I expect it to take each value in the array and pass it to the callback function. I don't expect... map is well documented. Making the element's index available is indeed pretty useful (the entire array less so, but sometimes it can be).
dvh 6y ago
Good linter will warn you that you are using parseInt without second parameter.
- tomcatfish 6y ago
  That's a fair criticism of my confusion, but I think I made my point poorly. The way map is implemented may be useful for some usecases and more convenient to implement, but it is a a very poor fit for many other usecases. As an example of one of the many ways to solve this to make it more sane, the Rust language allows you to call .iter() on something that can be looped over, but also .enum(), which gives you an index and the item. In this way, you can manage expectations about what you are actually getting. Javascript hands you all the tools at once unconditionally which strips a lot of the abstracting power away.
jdlshore 6y ago
"If I want to be taken seriously?" Was that bit of petty oneupmanship really necessary? I assure you, Alex, I'm completely unconcerned with whether you take me seriously. You were probably just trying to show off. But in case you weren't, here's how JS works. In JavaScript, if you're passing in a function as a parameter, the normal way is to use an arrow function. Like this: `array.map((element) => yourFunction(element));`. This gives you explicit control over which parameters are passed in to your function and how. As a shortcut, you can provide a function name rather than an arrow function. If you do so, you're saying that you want all parameters to be passed to that function. You're expected to know what those parameters are and how the function you're passing in will use them. If you don't know that, well, you're programming blind and bad things will sometimes happen. Maybe don't do that. As with many things in JavaScript, it's better to be explicit than rely on the shortcut. Edit: Just to be clear, here's the correct way to map an array of strings to an array of numbers in JavaScript: `array.map((s) => parseInt(s, 10));`
- BrandoElFollito 6y ago
  I am an amateur dev and used the arrow notation only in the way you described in your first example: array.map((element) => yourFunction(element)) What exactly is the shortcut you mention? (wild your mind converting the example into the incorrect/dangerous version?)
- tomcatfish 6y ago
  It wasn't meant to be oneupmanship, just that you were deliberately ignoring the core of the argument. I could make an article about why NULL in C is a wonderful feature and how it allows such nice optimizations, or I could acknowledge that it has a great cost too. You basically said "There's no downside if you are as smart and experienced as me", but with respect to Javascript, much of the world (myself included) are not. Your argument came down to "people with sufficient skill don't make this mistake", which was definitional instead of actually addressing that the default behavior of an actual usecase was not sane.

xodeus 6y ago

But you're not getting the wrong answer, it's doing exactly what it should do. That one isn't really even a weird language quirk like the others. It's just assuming you're not aware that parseInt can take a 2nd argument

Orou 6y ago
The issue doesn't arise because of parseInt() being able to take more than one argument, the issue is that map() is passing not only the value in the array but also its index as well as a copy of the full array. I use map() all the time but I didn't know about that until I read this article. I wonder why map() functions this way in Javascript and if any other languages pass additional values like this in their own map() implementations. I do think GP has a fair point of criticism - at least when I use map() I expect it to take each value in the array and pass it to the callback function. I don't expect it to take each value in the array, the index of that value and the entire array and pass all of that to the callback function instead.
- karatestomp 6y ago
  > I wonder why map() functions this way in Javascript and if any other languages pass additional values like this in their own map() implementations. Sometimes it's very convenient to be able to look ahead or behind the current element being map()'d to make decisions.
- mellow2020 6y ago
  Where do your expectations come from though? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Udik 6y ago
  > map() is passing not only the value in the array but also its index as well as a copy of the full array. I use map() all the time but I didn't know about that until I read this article Then you don't know the basics of the language you're using- how can you complain about it? > when I use map() I expect it to take each value in the array and pass it to the callback function. I don't expect... map is well documented. Making the element's index available is indeed pretty useful (the entire array less so, but sometimes it can be).

dvh 6y ago

Good linter will warn you that you are using parseInt without second parameter.

tomcatfish 6y ago
That's a fair criticism of my confusion, but I think I made my point poorly. The way map is implemented may be useful for some usecases and more convenient to implement, but it is a a very poor fit for many other usecases. As an example of one of the many ways to solve this to make it more sane, the Rust language allows you to call .iter() on something that can be looped over, but also .enum(), which gives you an index and the item. In this way, you can manage expectations about what you are actually getting. Javascript hands you all the tools at once unconditionally which strips a lot of the abstracting power away.

jdlshore 6y ago

"If I want to be taken seriously?" Was that bit of petty oneupmanship really necessary? I assure you, Alex, I'm completely unconcerned with whether you take me seriously. You were probably just trying to show off. But in case you weren't, here's how JS works. In JavaScript, if you're passing in a function as a parameter, the normal way is to use an arrow function. Like this: `array.map((element) => yourFunction(element));`. This gives you explicit control over which parameters are passed in to your function and how. As a shortcut, you can provide a function name rather than an arrow function. If you do so, you're saying that you want all parameters to be passed to that function. You're expected to know what those parameters are and how the function you're passing in will use them. If you don't know that, well, you're programming blind and bad things will sometimes happen. Maybe don't do that. As with many things in JavaScript, it's better to be explicit than rely on the shortcut. Edit: Just to be clear, here's the correct way to map an array of strings to an array of numbers in JavaScript: `array.map((s) => parseInt(s, 10));`

BrandoElFollito 6y ago
I am an amateur dev and used the arrow notation only in the way you described in your first example: array.map((element) => yourFunction(element)) What exactly is the shortcut you mention? (wild your mind converting the example into the incorrect/dangerous version?)
tomcatfish 6y ago
It wasn't meant to be oneupmanship, just that you were deliberately ignoring the core of the argument. I could make an article about why NULL in C is a wonderful feature and how it allows such nice optimizations, or I could acknowledge that it has a great cost too. You basically said "There's no downside if you are as smart and experienced as me", but with respect to Javascript, much of the world (myself included) are not. Your argument came down to "people with sufficient skill don't make this mistake", which was definitional instead of actually addressing that the default behavior of an actual usecase was not sane.