4 ms·

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

by powatom 13y ago

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

Peaker 13y ago
> 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.
- powatom 13y ago
  > 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.

by powatom 13y ago

Peaker 13y ago

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

powatom 13y ago
> 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.