Look up history-search-backward in your favorite bash/readline manual.

This is an entirely new way to misuse "strongly typed" that I was not aware of before. Amazing.

Thank you!

I disagree with pretty much everything you write here, but especially this:

First of all, you have exact same amount of parens as you would in a mainstream language like Java, C, or Js.

My Perl example uses "mainstream language" syntax. Apparently that doesn't count because it's Perl (scary! mental overhead! write only!), so here's exactly the same thing in JavaScript:

function hypot(x, y) {    return Math.sqrt(x ** 2 + y ** 2);}

... or

const hypot = function (x, y) {    return Math.sqrt(x ** 2 + y ** 2);};

... or

const hypot = (x, y) => Math.sqrt(x ** 2 + y ** 2);

Note how none of these involve four layers of nested parentheses.

Does Ruby require the use of [] and {} there? Because those %w/%i/etc things look like custom quoting operators and at least in Perl you can use any delimiter you want: qw(a b c) is a list of strings, but so are qw+a b c+ and qw;a b c;.

CPU? It's called a modem!!

BTW, you can configure uBlock Origin to block all 3rd party javascript by default, but allow 1st party scripts, so you don't even need NoScript to get most of these benefits.

If you were pair programming, your pair could always create a new failing test with the current implementation.

But I'm not pair programming. And you can't always create a new failing test because int is a finite type. There are only about 4 billion cases to handle.

Which might take a while to type up manually, but that's why we have meta-programming: Code that generates code. (In C++ you could even use templates, but you might run into compiler recursion limits.)

More to the point, the risk with TDD is that all development is driven by failing test cases, so a naive approach will end up "overfitting", producing exactly the code required to make a particular set of tests pass and nothing more. "It can't pass all test cases"? It doesn't have to. For TDD, it only needs to pass the tests that have actually been written. You can't test all combinations of all inputs.

(Also, if you changed this function to use modulus, it would handle more cases than before, which is a change in behavior. You're not supposed to do that when refactoring; refactoring should preserve semantics.)

When you say "it can't pass all test cases", what do you imagine the tests look like?

I am 100% confident that your claim is factually wrong.

I agree with your core point, but no software is intuitive.

Yeah, just don't make any mistakes and you'll be fine. Come on guys, how hard can it be?

@masterspace "Undeclared variable" is a runtime error.

Perl.