8 ms·

Is this so much of a problem that we need to re-design JS to handle it? Why not just avoid making this mistake in the first place by reading the code? Not to so

by powatom 13y ago

Is this so much of a problem that we need to re-design JS to handle it? Why not just avoid making this mistake in the first place by reading the code? Not to sound dismissive - but if you're making these kinds of mistakes regularly enough to irritate you, it's not the language that's at fault. Javascript's squishiness is the thing I like the most about it. It's far from perfect, just like any other language out there - but it's fun.

gumballhead 13y ago
This. People complaining about what JavaScript lets you do just need to learn how to exploit its strengths while being aware of its dangers. It's like someone complaining that git let them make a mess after they merged master into their feature branch and then merge it back into master.
- Peaker 13y ago
  No, it's much more like git ignoring wrong command syntax and just using undefined instead. git commit - m"Hi" && git push Let's push a commit with an undefined message, and ignore the m"Hi" argument. Error messages are annoying.
Peaker 13y ago
> Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior.
- powatom 13y ago
  > We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do something which when ignored or fucked up, results in problems. This is not a JSism - this is just the way things work. Every language has 'features' like this. If you don't know what you're doing, then stop doing it. "A bad workman blames his tools" and all that jazz. > Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. So JS has a (potentially) higher maintenance cost. This doesn't mean that JS is badly designed - it's just a trade-off. Some people don't care, others do. Clearly to some people, it's an unacceptable cost - but all that means is that those people have a lower tolerance for that kind of thing than others. > Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior. This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.
  - Peaker 13y ago
    > If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. Given that other people are working on the same code base and may have added calls to this function, this is not even possible. Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken. Also, humans cannot do a perfect job every time. We will all make mistakes, and our tools shouldn't give us hell over those mistakes for miniscule to no benefit at all as in this case. Out of thousands of changes to function signatures, do you think none would ever forget to fix a caller? > So JS has a (potentially) higher maintenance cost This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development. > it's just a trade-off What do you gain here? You save an asterisk in the syntax when you want to overload? > This is just a case for good documentation and release notes. Don't merge in changes that you don't understand. In a collaborative environment, we merge work with each other every single day. Do you have documentation and release notes for every commit you publish? Do you go and check the commit's release notes every time you pull?

by powatom 13y ago

gumballhead 13y ago

This. People complaining about what JavaScript lets you do just need to learn how to exploit its strengths while being aware of its dangers. It's like someone complaining that git let them make a mess after they merged master into their feature branch and then merge it back into master.

Peaker 13y ago
No, it's much more like git ignoring wrong command syntax and just using undefined instead. git commit - m"Hi" && git push Let's push a commit with an undefined message, and ignore the m"Hi" argument. Error messages are annoying.

Peaker 13y ago

> Why not just avoid making this mistake in the first place by reading the code? We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior.

powatom 13y ago
> We're talking about programming errors. Are you suggesting the solution to human error is to just not make errors?? Not at all, I'm simply suggesting that people take care to acknowledge and operate within the rules of the language. If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. JS allows you to do something which when ignored or fucked up, results in problems. This is not a JSism - this is just the way things work. Every language has 'features' like this. If you don't know what you're doing, then stop doing it. "A bad workman blames his tools" and all that jazz. > Note, of course, that wrong arguments will frequently not arise from a function call you just wrote -- but from changes in the code. So JS has a (potentially) higher maintenance cost. This doesn't mean that JS is badly designed - it's just a trade-off. Some people don't care, others do. Clearly to some people, it's an unacceptable cost - but all that means is that those people have a lower tolerance for that kind of thing than others. > Say you merge in a trivial merge of some code, which changed a function's signature/parameters. The merge succeeds trivially. Now every single function call is a bug that is not only uncaught by a compiler. It won't even necessarily be caught at runtime. Instead, it may escalate to catastrophic, undefined/unexpected behavior. This is just a case for good documentation and release notes. Don't merge in changes that you don't understand.
- Peaker 13y ago
  > If you're making changes to a function signature in JS without assessing the impact for code elsewhere, then you're doing a bad job - and that's all there is to it. Given that other people are working on the same code base and may have added calls to this function, this is not even possible. Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken. Also, humans cannot do a perfect job every time. We will all make mistakes, and our tools shouldn't give us hell over those mistakes for miniscule to no benefit at all as in this case. Out of thousands of changes to function signatures, do you think none would ever forget to fix a caller? > So JS has a (potentially) higher maintenance cost This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development. > it's just a trade-off What do you gain here? You save an asterisk in the syntax when you want to overload? > This is just a case for good documentation and release notes. Don't merge in changes that you don't understand. In a collaborative environment, we merge work with each other every single day. Do you have documentation and release notes for every commit you publish? Do you go and check the commit's release notes every time you pull?