3 ms·

> 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 pe

by 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?
- powatom 13y ago
  > Given that other people are working on the same code base and may have added calls to this function, this is not even possible. Except it clearly is possible since I and millions of other developers seem to manage it daily. > 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. This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit, then whose fault is that? Of course you need to fix calls to changed functions - but if doing so is causing you and your team pain, then perhaps you have other problems. > 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. Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out. > What do you gain here? You save an asterisk in the syntax when you want to overload? Like I said before, squishiness. > In a collaborative environment, we merge work with each other every single day. As do I, and clearly millions of other developers who don't seem to run into your problems. > Do you have documentation and release notes for every commit you publish? We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS. Sure, not every single commit is perfectly documented, but small commits and concise messages go a long way to ensuring that the history is traceable and the code is clean. The more often you commit and merge with your collaborators, the more in lock-step you are and the less likely you are to run into these kinds of issues. Messy merges will happen from time to time regardless of your preferred language. > Do you go and check the commit's release notes every time you pull? Not always, but often. Maintaining visibility of the trajectory of the code and the project as a whole will help massively in heading off risks and development issues.
  - Peaker 13y ago
    > Except it clearly is possible since I and millions of other developers seem to manage it daily. Clearly possible to fix code that's in branches/working trees that you don't even have access to?? > This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit When you change function signatures, code that calls those functions is broken. In static languages the breakage is a compile-time error. In dynamic languages the breakage is a run-time error. In JS the breakage is a cryptic bug. > Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out. The code is tightly-coupled and shitty because it has functions that get called? > Like I said before, squishiness. By squishiness, do you mean "trade errors for cryptic bugs"? You seem to be exactly who Dijkstra referred to when he said [1]: > It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) > As do I, and clearly millions of other developers who don't seem to run into your problems. I'm wise enough to avoid JS, so I don't encounter such silly problems. I don't trust you to even know you are having these troubles, because the whole point is that these problems translate to cryptic bugs, rather than visible errors. > We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS Note that the word "merges" may be misleading here. As every little pull you do (even a FF pull in git which updates files that don't overlap with your modified files) is a merge for this purpose. Your approach here means that I must review all the function signature changes in every commit I pull, synchronously, before I carry on work. This doesn't help lock-step development as it incurs a serious overhead on such development. > Not always, but often That means when you pull, all the function calls to functions that may have had their signatures changed in your pulls may now become cryptic bugs. Awesome! [1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

by powatom 13y ago

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?

powatom 13y ago
> Given that other people are working on the same code base and may have added calls to this function, this is not even possible. Except it clearly is possible since I and millions of other developers seem to manage it daily. > 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. This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit, then whose fault is that? Of course you need to fix calls to changed functions - but if doing so is causing you and your team pain, then perhaps you have other problems. > 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. Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out. > What do you gain here? You save an asterisk in the syntax when you want to overload? Like I said before, squishiness. > In a collaborative environment, we merge work with each other every single day. As do I, and clearly millions of other developers who don't seem to run into your problems. > Do you have documentation and release notes for every commit you publish? We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS. Sure, not every single commit is perfectly documented, but small commits and concise messages go a long way to ensuring that the history is traceable and the code is clean. The more often you commit and merge with your collaborators, the more in lock-step you are and the less likely you are to run into these kinds of issues. Messy merges will happen from time to time regardless of your preferred language. > Do you go and check the commit's release notes every time you pull? Not always, but often. Maintaining visibility of the trajectory of the code and the project as a whole will help massively in heading off risks and development issues.
- Peaker 13y ago
  > Except it clearly is possible since I and millions of other developers seem to manage it daily. Clearly possible to fix code that's in branches/working trees that you don't even have access to?? > This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit When you change function signatures, code that calls those functions is broken. In static languages the breakage is a compile-time error. In dynamic languages the breakage is a run-time error. In JS the breakage is a cryptic bug. > Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out. The code is tightly-coupled and shitty because it has functions that get called? > Like I said before, squishiness. By squishiness, do you mean "trade errors for cryptic bugs"? You seem to be exactly who Dijkstra referred to when he said [1]: > It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) > As do I, and clearly millions of other developers who don't seem to run into your problems. I'm wise enough to avoid JS, so I don't encounter such silly problems. I don't trust you to even know you are having these troubles, because the whole point is that these problems translate to cryptic bugs, rather than visible errors. > We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS Note that the word "merges" may be misleading here. As every little pull you do (even a FF pull in git which updates files that don't overlap with your modified files) is a merge for this purpose. Your approach here means that I must review all the function signature changes in every commit I pull, synchronously, before I carry on work. This doesn't help lock-step development as it incurs a serious overhead on such development. > Not always, but often That means when you pull, all the function calls to functions that may have had their signatures changed in your pulls may now become cryptic bugs. Awesome! [1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...