For modern development Javascript indeed is a shit language

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

Actually in C++11 you can just say:

    auto id = mongo::OID("1234...");

This gives you much (not all) of the brevity and flexibility of dynamic typing, while maintaining the power and safety of static typing.

No problem.

People who don't like or get prototypes have certainly reimplemented classes with closures, but classes are not a requirement to be OO, objects are; classes are just one way to do it, prototypes are another. Objects don't require classes, though many a JavaScript programmer thinks so.

    > [1,2,"10",3].sort()
    [ 1, '10', 2, 3 ]

That's the problem.

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