3 ms·

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

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

Peaker 13y ago
It seems you are misunderstanding me. I am not talking about library APIs here. I am talking about internal function signatures inside a single product developed by multiple codevelopers. All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you will integrate with your work with an innocuous "git pull" and force you to review everything just to rule out what JS could have easily detected. > If a change in a dependency causes you to have a ripple effect of completely broken code - then yes, your code is tightly coupled. Again, I'm not talking about "dependencies" or libraries here at all. > 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. The push was completely benign. The integration of that push with your current work will be broken in cryptic ways. Not necessarily ones that show up in the testing suites. > 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. Every single function signature can break things, not just exposed APIs. Two developers might work on the same piece of code. There's not necessarily any obvious point to notify here and still breakage may arise. > Except it doesn't, because who updates a dependency without checking that they can actually depend on it? The clue's in the name. You clearly haven't understood the scenario involved, I'll try to describe it again: 1) Developer A adds a new function FOO that calls internal function BAR in his unpushed working tree. 2) Developer B changes the signature of internal function BAR, and pushes this change to "master". 3) Developer A pulls from master, his code is now broken, but JS doesn't even warn him when he executes it. Instead, wrong results (or accidentally correct results for any given test case) arise. 4) The test suites don't catch the error. Developer A unwittingly pushes the broken code to master.
- powatom 13y ago
  > All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you will integrate with your work with an innocuous "git pull" and force you to review everything just to rule out what JS could have easily detected. Everything that you didn't write yourself is an external API for all intents and purposes - you're using somebody else's code, regardless of whether that person 'owns' the code or not. The fact remains that if you're relying on a function and somebody changes it without considering the consequences, then that's a process issue, not a JS one. In the same way, if you're writing code which others may depend on, then you need to consider the potential consequences of your changes. > Again, I'm not talking about "dependencies" or libraries here at all. The point is that you should be talking about dependencies and libraries. The situation you're describing is one in which code is not properly modularised and organised - where any developer can change any function and thereby fuck up the rest of the project. If your code was organised properly, these problems would disappear. > The push was completely benign. The integration of that push with your current work will be broken in cryptic ways. Not necessarily ones that show up in the testing suites. You keep using the word 'will'. I'm telling you with hand on heart that this problem does not happen if you sort out your development team and project structure. > Every single function signature can break things, not just exposed APIs. Yes, it can break things, but it shouldn't. > Two developers might work on the same piece of code. There's not necessarily any obvious point to notify here and still breakage may arise. If two developers can't work on the same area of code without stepping all over each other, then you need to look at how you're structuring your code. > 1) Developer A adds a new function FOO that calls internal function BAR in his unpushed working tree. > 2) Developer B changes the signature of internal function BAR, and pushes this change to "master". > 3) Developer A pulls from master, his code is now broken, but JS doesn't even warn him when he executes it. Instead, wrong results (or accidentally correct results for any given test case) arise. > 4) The test suites don't catch the error. Developer A unwittingly pushes the broken code to master. Why is developer B changing the signature of function BAR willy nilly? Code isn't written in isolation and your changes have an effect on other developers. If you have a function which is being used by other people - then you have a public API. You don't break an API randomly.

by powatom 13y ago

Peaker 13y ago

It seems you are misunderstanding me. I am not talking about library APIs here. I am talking about internal function signatures inside a single product developed by multiple codevelopers. All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you will integrate with your work with an innocuous "git pull" and force you to review everything just to rule out what JS could have easily detected. > If a change in a dependency causes you to have a ripple effect of completely broken code - then yes, your code is tightly coupled. Again, I'm not talking about "dependencies" or libraries here at all. > 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. The push was completely benign. The integration of that push with your current work will be broken in cryptic ways. Not necessarily ones that show up in the testing suites. > 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. Every single function signature can break things, not just exposed APIs. Two developers might work on the same piece of code. There's not necessarily any obvious point to notify here and still breakage may arise. > Except it doesn't, because who updates a dependency without checking that they can actually depend on it? The clue's in the name. You clearly haven't understood the scenario involved, I'll try to describe it again: 1) Developer A adds a new function FOO that calls internal function BAR in his unpushed working tree. 2) Developer B changes the signature of internal function BAR, and pushes this change to "master". 3) Developer A pulls from master, his code is now broken, but JS doesn't even warn him when he executes it. Instead, wrong results (or accidentally correct results for any given test case) arise. 4) The test suites don't catch the error. Developer A unwittingly pushes the broken code to master.

powatom 13y ago
> All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you will integrate with your work with an innocuous "git pull" and force you to review everything just to rule out what JS could have easily detected. Everything that you didn't write yourself is an external API for all intents and purposes - you're using somebody else's code, regardless of whether that person 'owns' the code or not. The fact remains that if you're relying on a function and somebody changes it without considering the consequences, then that's a process issue, not a JS one. In the same way, if you're writing code which others may depend on, then you need to consider the potential consequences of your changes. > Again, I'm not talking about "dependencies" or libraries here at all. The point is that you should be talking about dependencies and libraries. The situation you're describing is one in which code is not properly modularised and organised - where any developer can change any function and thereby fuck up the rest of the project. If your code was organised properly, these problems would disappear. > The push was completely benign. The integration of that push with your current work will be broken in cryptic ways. Not necessarily ones that show up in the testing suites. You keep using the word 'will'. I'm telling you with hand on heart that this problem does not happen if you sort out your development team and project structure. > Every single function signature can break things, not just exposed APIs. Yes, it can break things, but it shouldn't. > Two developers might work on the same piece of code. There's not necessarily any obvious point to notify here and still breakage may arise. If two developers can't work on the same area of code without stepping all over each other, then you need to look at how you're structuring your code. > 1) Developer A adds a new function FOO that calls internal function BAR in his unpushed working tree. > 2) Developer B changes the signature of internal function BAR, and pushes this change to "master". > 3) Developer A pulls from master, his code is now broken, but JS doesn't even warn him when he executes it. Instead, wrong results (or accidentally correct results for any given test case) arise. > 4) The test suites don't catch the error. Developer A unwittingly pushes the broken code to master. Why is developer B changing the signature of function BAR willy nilly? Code isn't written in isolation and your changes have an effect on other developers. If you have a function which is being used by other people - then you have a public API. You don't break an API randomly.