> взять parseInt: почему он принимает ещё и базу?А нужно было плодить отдельные методы parseInt10(), parseInt16() и т. д.?
> а для других баз существуют отдельные функции.
Ах вон как. А как там называется функция, которая переводит из 15-ричного строкового представления (не опечатка: именно 15-ричного) в число? А 17-ричного? А 30-ричного?
> почему же map принимает функцию одного-двух аргументов и даже выполняется как-то вместо того, чтобы бросать исключение
Потому что проверка аргументов не лежит в ответственности map. Функция может принимать аргументы и из arguments[0], arguments[1] и т. д. Так что map, даже если бы он с чего-то вдруг начал проверять кол-ва аргументов через fn.length, не получил бы достоверные сведения о фактическом использовании параметров.
> гремучая сместь нестрогой типизации с неявным приведением типов
Потому-то и рекомендуется всячески избегать нестрогих сравнений. Использовать принципиально ===.
> легко представить себе функцию, которая выдирает число из какого-нибудь элемента DOM, а возвращаемое значение null использует в качестве маркера, чтобы обозначить, что элемент DOM не найден
Плохая практика. Если DOM-элемента нет, эта функция попросту не должна вызываться. Проверка на существование -- это еще одна ответственность, которую ты хочешь запихнуть в одну и ту же функцию.
> И такое происходит сплошь и рядом.
Ссылочку на какой-нибудь коммит в опенсорсном js-проекте попрошу я тебя. На моей практике такого не происходило никогда.
> Нельзя же помнить все её талмуды наизусть.
Какие талмуды? По сравнению с какой-нибудь Java с тамошними Spring/EE/JBoss/etc., JS -- это язык, в котором помнить приходится о на редкость малом.