> If changing internal functions results in breakages, then I don't know what else you'd call it except a breaking change.
It's not the change itself that broke things. It's the combination of two changes that you got when you used "git pull".
> Not if you're making small commits, often. Changing a function signature necessitates the modification of all callers to that function. This would be a large commit which includes all of necessary changes to ensure that the software remains in a stable state.
Small commits make this less likely -- but it can still happen.
> This is still just a process problem - if you committed and merged more often, these issues wouldn't arise. The reason you're having these issues
I'm not having these issues because I am wise enough to avoid JS.
> because you're allowing your working trees to become too out of sync
CI is great, but for some major changes, incremental changes are not always a possibility. Sometimes you have to break things temporarily in order to change the way things work in a significant way. This is typically done in a side-branch. Integrating that side branch with all the changes will require going over all functions that changed manually, to see if the signatures now mismatch their callers (solving the halting problem, in the general case), because even UT can easily miss it.
> committing smaller changesets and merging more often, where the overhead in assessing changes is tiny, will wipe out 99% of these issues
What do you propose to do about the 1% of issues that still plague the codebase?
> Except in JS, the code itself isn't a mistake. It's your problem - JS has nothing to do with ensuring that you keep your codebase bug-free.
The code itself is a mistake. You meant to call something with (x,y,z), instead you called it with (x,y/z). Now the language will do its best to hide this problem from you, so you can discover it as late as possible, when it is most expensive.
> Then use them, and stop complaining about something that you don't even use.
The thing is, I was hoping to get the perspective of someone who does use this language, to see that point of view, but the point of view seems to be "languages should not help you write good programs or find your errors", "just don't make bugs", and "change your process to accomodate JS to reduce this risk that should not exist in the first place".
> Making the same mistake repeatedly and then blaming your tools is sloppiness however you dress it up.
Who says it's the "same mistake repeatedly"? There are many different mistakes that could be made non-repeatedly by many different developers that would get caught if function signatures were verified sanely but instead hidden by JS.
> It's not harder, it's just different. If you learn the language and its subtleties, then you won't have these problems.
So you just "learn" to never make mistakes. I get it.