Comment by powatom | Hacker News Reader

Comment by powatom | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com