For modern development Javascript indeed is a shit language

Except it clearly is possible since I and millions of other developers seem to manage it daily.

> Also, dynamic languages all require you to fix calls to changed functions. But at least, when you test that code, it won't accidentally seem to work when it is broken.

This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit, then whose fault is that? Of course you need to fix calls to changed functions - but if doing so is causing you and your team pain, then perhaps you have other problems.

> This doesn't sound potential at all. It sounds like you either lose a huge amount of reliability, or add a huge burden to development.

Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out.

> What do you gain here? You save an asterisk in the syntax when you want to overload?

Like I said before, squishiness.

> In a collaborative environment, we merge work with each other every single day.

As do I, and clearly millions of other developers who don't seem to run into your problems.

> Do you have documentation and release notes for every commit you publish?

We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS. Sure, not every single commit is perfectly documented, but small commits and concise messages go a long way to ensuring that the history is traceable and the code is clean. The more often you commit and merge with your collaborators, the more in lock-step you are and the less likely you are to run into these kinds of issues. Messy merges will happen from time to time regardless of your preferred language.

> Do you go and check the commit's release notes every time you pull?

Not always, but often. Maintaining visibility of the trajectory of the code and the project as a whole will help massively in heading off risks and development issues.

Clearly possible to fix code that's in branches/working trees that you don't even have access to??

> This is a problem of your code-base, not the language. If your code is so brittle that it can't stand a few function changes without collapsing into a miasma of shit

When you change function signatures, code that calls those functions is broken. In static languages the breakage is a compile-time error. In dynamic languages the breakage is a run-time error. In JS the breakage is a cryptic bug.

> Of course it's potential. Nobody's forcing you to write tightly coupled, shitty code which breaks after every merge. Seriously? Figure it out.

The code is tightly-coupled and shitty because it has functions that get called?

> Like I said before, squishiness.

By squishiness, do you mean "trade errors for cryptic bugs"? You seem to be exactly who Dijkstra referred to when he said [1]:

> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.)

> As do I, and clearly millions of other developers who don't seem to run into your problems.

I'm wise enough to avoid JS, so I don't encounter such silly problems. I don't trust you to even know you are having these troubles, because the whole point is that these problems translate to cryptic bugs, rather than visible errors.

> We have proper commit messages and tracking codes for every task / bug, yes. There's no such thing as perfect information - and sometimes merges get messy - but this is not unique to JS

Note that the word "merges" may be misleading here. As every little pull you do (even a FF pull in git which updates files that don't overlap with your modified files) is a merge for this purpose.

Your approach here means that I must review all the function signature changes in every commit I pull, synchronously, before I carry on work. This doesn't help lock-step development as it incurs a serious overhead on such development.

> Not always, but often

That means when you pull, all the function calls to functions that may have had their signatures changed in your pulls may now become cryptic bugs. Awesome!

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/E...

It hides the error by carrying on, despite having the wrong number of arguments, and executing code with thus necessarily wrong inputs.

> Messing with a function signature and not updating callers of that function is not a bug in the language, it's a bug in the programmer

When editing code, you routinely change the function signatures of hundreds of functions. Of course you're going to miss some, some of the time. Human errors happen, and good languages help us deal with them.

Also, every time you pull code from another repository, function signatures all over the place change. Some of those may be functions your currently edited code is calling. This means every little divergence requires reviewing every single signature change or cryptic bugs will result.

> and will result in runtime bugs in any dynamic language.

It will result in runtime errors in dynamic languages. Errors that are visible, and difficult to ignore. That means the code gets fixed. UT triggers it trivially.

Whereas with Javascript, even code under UT can easily pass accidentally when wrong numbers of arguments are used.

This Dijkstra quote is relevant:

> It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.)

> If you require X number of args, then assert that they aren't undefined

That captures half of the bugs (too few arguments), for a large overhead (an extra line for almost every argument in every function).

> If you presume callers pass in X number of args in a variable args language, and then change the required args, you're the bug, not the language

Every time you change code, there is potential to insert bugs. Of course all bugs originate from programmer errors. The tools can work with us to find these errors and mitigate them, or they can give us hell.