4 ms·

> 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

by 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...
- powatom 13y ago
  > Clearly possible to fix code that's in branches/working trees that you don't even have access to?? This is a non-issue - if you're using unstable libraries then that's your own problem and breakages are to be expected. This is not the fault of JS. > 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. When you change function signatures, you document the change and you increment the version. If you're randomly updating dependencies without first checking that the new version is compatible with your existing code, then that's your problem. Again, this is not JS. > The code is tightly-coupled and shitty because it has functions that get called? If a change in a dependency causes you to have a ripple effect of completely broken code - then yes, your code is tightly coupled. > By squishiness, do you mean "trade errors for cryptic bugs"? You seem to be exactly who Dijkstra referred to when he said [1]: Squishiness is difficult to explain without describing the general ins and outs of dynamic languages, which I'm sure you're not completely alien to. Essentially, what I'm saying is that the problems you're experiencing with JS are largely your own fault - and no amount of complaining is going to solve the problem of the user lacking due diligence when they rely on unstable code or aren't maintaining their own dependent code properly. Again, these problems are not specific to JS. > I'm wise enough to avoid JS, so I don't encounter such silly problems. So you're weighing in on the problems of a language you don't even use. Doesn't that strike you as somewhat...silly? > 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. They translate to cryptic bugs if you develop shitty software, sure. However, if you do your homework, correctly check your dependencies and retain some semblance of stability in your code-base, then no, these problems aren't nearly as dramatic as you're suggesting. > 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. A merge is a merge is a merge. If you're merging unstable code, then you have to expect that you're going to need to do some maintenance. In what world is it sensible to develop software where you're not even attempting to ensure that potentially breaking changes aren't flagged up, discussed, and dealt with? Have you never heard of the phrase 'don't break the build'? In my job, if somebody commits and pushes something which is going to completely fuck the rest of the development team, then they're told to piss off and fix it. If you absolutely must change a function signature which is part of an API that others may be depending on, then you fucking document it and alert your users. Again, not JS. Sort your process out. > 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. No, my approach is that if I'm developing a library which others depend on, I don't fuck about with the API without a very, very good reason - and if I do, then I document it. Don't randomly update your dependencies if this is such a problem for you. If your code is so tightly coupled to whatever dependencies you have that updating that dependency means you need to change a thousand different lines of code scattered throughout your software, then you're already doing it wrong. > 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! Except it doesn't, because who updates a dependency without checking that they can actually depend on it? The clue's in the name.

by powatom 13y ago

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

powatom 13y ago
> Clearly possible to fix code that's in branches/working trees that you don't even have access to?? This is a non-issue - if you're using unstable libraries then that's your own problem and breakages are to be expected. This is not the fault of JS. > 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. When you change function signatures, you document the change and you increment the version. If you're randomly updating dependencies without first checking that the new version is compatible with your existing code, then that's your problem. Again, this is not JS. > The code is tightly-coupled and shitty because it has functions that get called? If a change in a dependency causes you to have a ripple effect of completely broken code - then yes, your code is tightly coupled. > By squishiness, do you mean "trade errors for cryptic bugs"? You seem to be exactly who Dijkstra referred to when he said [1]: Squishiness is difficult to explain without describing the general ins and outs of dynamic languages, which I'm sure you're not completely alien to. Essentially, what I'm saying is that the problems you're experiencing with JS are largely your own fault - and no amount of complaining is going to solve the problem of the user lacking due diligence when they rely on unstable code or aren't maintaining their own dependent code properly. Again, these problems are not specific to JS. > I'm wise enough to avoid JS, so I don't encounter such silly problems. So you're weighing in on the problems of a language you don't even use. Doesn't that strike you as somewhat...silly? > 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. They translate to cryptic bugs if you develop shitty software, sure. However, if you do your homework, correctly check your dependencies and retain some semblance of stability in your code-base, then no, these problems aren't nearly as dramatic as you're suggesting. > 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. A merge is a merge is a merge. If you're merging unstable code, then you have to expect that you're going to need to do some maintenance. In what world is it sensible to develop software where you're not even attempting to ensure that potentially breaking changes aren't flagged up, discussed, and dealt with? Have you never heard of the phrase 'don't break the build'? In my job, if somebody commits and pushes something which is going to completely fuck the rest of the development team, then they're told to piss off and fix it. If you absolutely must change a function signature which is part of an API that others may be depending on, then you fucking document it and alert your users. Again, not JS. Sort your process out. > 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. No, my approach is that if I'm developing a library which others depend on, I don't fuck about with the API without a very, very good reason - and if I do, then I document it. Don't randomly update your dependencies if this is such a problem for you. If your code is so tightly coupled to whatever dependencies you have that updating that dependency means you need to change a thousand different lines of code scattered throughout your software, then you're already doing it wrong. > 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! Except it doesn't, because who updates a dependency without checking that they can actually depend on it? The clue's in the name.