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.