> 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.
So basically you need to use strict ownership at API boundaries as that is the only way to avoid this. This isn't always optimal. It sounds like you're sacrificing quite a few goats at the js altar for no real benefit.
Your question about why a developer would need to change an internal function's signature is ridiculous. Maintaining code involves changing function signatures all the time. If another developer is working within the same API boundary, he's screwed.
This isn't a necessary fact of life. Even most sane dynamic language will error out when such incompatibility arises, instead of blaming the developer for using a process incompatible with the js way.
Not to mention the other argument, that with all the discipline in the world, humans will still make mistakes. Instead of translating to errors, they translate to bugs.
The gain? not having to use an asterisk when you want varargs. That's just stupid.
> So basically you need to use strict ownership at API boundaries as that is the only way to avoid this. This isn't always optimal. It sounds like you're sacrificing quite a few goats at the js altar for no real benefit.
No, but when somebody I'm working with makes a potentially breaking change to a shared codebase, they either ensure that they also fix the now broken code, or they flag it up to the people whose responsibility that is. Aside from that - most people simply avoid making a breaking change - or if it absolutely must be made, then a process is followed.
> Your question about why a developer would need to change an internal function's signature is ridiculous
I wasn't asking why the developer was changing a function signature - rather why they're so eager to change a function signature without following up and either fixing the things they break, or flagging those things up to the people who require it.
> This isn't a necessary fact of life. Even most sane dynamic language will error out when such incompatibility arises, instead of blaming the developer for using a process incompatible with the js way.
There's no such thing as a random error. If there's an error, somebody made a mistake. Some mistakes are stupid, others are subtle. Changing a method signature and then not doing something about the callers is a stupid mistake.
> Not to mention the other argument, that with all the discipline in the world, humans will still make mistakes. Instead of translating to errors, they translate to bugs.
Of course humans will make errors - but your job is to minimise the frequency and severity of those errors. There's no excuse for sloppiness - you either keep on top of shit, or you don't. Call it whatever you like, but a shitty broken codebase is only the fault of the developers, not the language.
> Aside from that - most people simply avoid making a breaking change - or if it absolutely must be made, then a process is followed.
Changing internal functions is not considered a "breaking change" by anyone I know. You're allowed to refactor code internally, which definitely includes changing the structure of the internal functions.
Other coders who are also working inside the same module/API boundary will have their edits broken by this change. The original developer cannot fix their code because it's not checked in yet.
> rather why they're so eager to change a function signature without following up and either fixing the things they break, or flagging those things up to the people who require it.
I already explained why they can't follow up - because the code that needs the follow up is in their codevelopers' working trees. Flagging here would be silly. Almost every single commit would be "flagged for fixing breakage", since every single commit can refactor/change internal function signatures.
> If there's an error, somebody made a mistake. Some mistakes are stupid, others are subtle. Changing a method signature and then not doing something about the callers is a stupid mistake.
Yes, and we are all human so sometimes, despite heroic efforts, we will all make stupid mistakes as well as subtle mistakes.
Now, once we made the mistake, do we want our tool to insidiously hide this mistake from us, making it as expensive as possible to punish us for our mistake? Or do we want a tool that tells me ASAP "Hey dude, you made a stupid mistake over there"?
> but your job is to minimise the frequency and severity of those errors.
And to do this job, I have tools like languages that help me find those mistakes quickly.
> There's no excuse for sloppiness
Making mistakes isn't "sloppiness", it's human.
> Call it whatever you like, but a shitty broken codebase is only the fault of the developers, not the language
If one language makes writing a non-shitty codebase harder than a different language, it is also the fault of that language.
> Changing internal functions is not considered a "breaking change" by anyone I know.
If changing internal functions results in breakages, then I don't know what else you'd call it except a breaking change.
> You're allowed to refactor code internally, which definitely includes changing the structure of the internal functions.
If the person changing the function doesn't then go and update all of the callers, then that person isn't doing their job properly. It's not refactoring if you just randomly decide to modify a single function's signature and then don't follow up and fix the rest of the code.
> Other coders who are also working inside the same module/API boundary will have their edits broken by this change. The original developer cannot fix their code because it's not checked in yet.
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.
> I already explained why they can't follow up - because the code that needs the follow up is in their codevelopers' working trees. Flagging here would be silly. Almost every single commit would be "flagged for fixing breakage", since every single commit can refactor/change internal function signatures.
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 is because you're allowing your working trees to become too out of sync. If everybody is working on the same module, then those developers should be trying to retain lock-step. Even if developer A (the breaker) doesn't have access to the code of developer B and therefore can't update his function calls - committing smaller changesets and merging more often, where the overhead in assessing changes is tiny, will wipe out 99% of these issues. If you can't see the forest for the trees, then issues are going to slip through.
> Yes, and we are all human so sometimes, despite heroic efforts, we will all make stupid mistakes as well as subtle mistakes.
Now, once we made the mistake, do we want our tool to insidiously hide this mistake from us, making it as expensive as possible to punish us for our mistake? Or do we want a tool that tells me ASAP "Hey dude, you made a stupid mistake over there"?
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.
> And to do this job, I have tools like languages that help me find those mistakes quickly.
Then use them, and stop complaining about something that you don't even use.
> Making mistakes isn't "sloppiness", it's human.
Making the same mistake repeatedly and then blaming your tools is sloppiness however you dress it up.
> If one language makes writing a non-shitty codebase harder than a different language, it is also the fault of that language.
It's not harder, it's just different. If you learn the language and its subtleties, then you won't have these problems.
> 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.
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.