Ценителю кривых недоязычков надо бы научиться различать строгую и статическую типизацию, чтобы не выглядеть банальным невеждой. Для работы данного примера нужна динамическая типизация. Динамическая типизация — это как в Python, Ruby, Erlang, LISP и ещё куче мест, где тип переменной не задаётся и может быть любым из известных, но операции с ним всё равно такие. какие позволены типу. А вот когда (хрестоматийный пример про JS) ’5’-3==2, но ’5’+3==53, это никакой динамикой не объяснить, это банальный бред, мокрая рваная тряпка вместо строгой типизации.

JS отвратителен не динамической типизацией, не поддержкой DOM, не JSON, не замыканиями и ничем подобным, но 1) слабой типизацией с непресказуемыми эффектами, 2) кучей дебильных решений по синтаксису, которые взрываются самым неожиданным образом, 3) аналогичных проблемах с библиотечными функциями. В этом он близок PHP (ещё один выбредок веба) и Perl, который всего лишь старался быть «лучший шелл, чем шелл, и лучший awk, чем awk», но его неизбежные проблемы были раздуты и подняты на флаг как принципиальные решения.

Простейшее гугление по «weird javascript feature» показывает сотни таких примеров. Вот небольшая выборка со StackOverflow:

2 == [[[2]]]
a[[[["abc"]]]] === a["abc"]

Сравнения — некоммутативные и нетранзитивные:

’’ == ’0′ // false
0 == ’’ // true
0 == ’0′ // true
false == ’false’ // false
false == ’0′ // true
false == undefined // false
false == null // false
null == undefined // true
" \t\r\n" == 0 // true

Неупорядочённый синтаксис разделения операторов, когда два оператора, валидных по отдельности, рядом через ’;’ становятся синтаксической ошибкой. Странные и неочевидные правила automatic semicolon insertion, при отсутствии возможности явно исключить его на стыке строк, как сделано во всех нормальных языках с построчным синтаксисом (Python, Occam, BASIC образца MS, и так далее).

Молчаливая конверсия между числами и строками с местами неочевидными и неуправляемыми правилами.

Восьмеричные константы по ведущему ’0′ и молчаливое игнорирование проблем с ними (parseInt("08″) == 0), а как общий подход для библиотеки — вообще тенденция на максимальное маскирование ошибок вместо показа их как исключений (опять-таки, общее с PHP и Perl).

Кривые правила видимости переменных (например, явно объявленная во вложенном блоке будет видна снаружи от него).

Возможность грязного хака с заменой значения для undefined, Infinity, NaN (общая проблема с PHP и старыми Питонами, но эти хоть в новых версиях такое правят).

Бездумное копирование свойств старых проблемных API (например, работа с датами — год минус 1900, январь как 0).

void как префиксный оператор.

Продолжать тут можно часами, мне надоело. Общее впечатление — язык разработан, мягко говоря, через пятую точку, фатально неравномерно и бескультурно. Его немногочисленные преимущества на этом фоне практически незаметны, остаётся только одно — что он хоть и четырежды дерьмовый, но уже стандарт.

Вы заняли первое место на районной олимпиаде по солипсизму.

Hint: Itanium.

А почему машина разработчика не должна быть надёжной? ;)

Пример с перевернувшимся битиком я уже приводил. Я пару раз такое видел вживую.
А прогонять всё через сборочный сервер с супернадёжным защищённым железом — не всегда возможно.

А ещё машина разработчика должна быть ровно такой скорости, чтобы его работа не тормозила, но не быстрее, иначе получится продукт известного типа, который нормально работает на железе минимум в 3 раза дороже бюджетного. Поэтому меня все эти гонки за процессорами для разработки удивляют.

А на самом деле у вас память битая, или конденсатор какой потек.

Пожалуйста, перестаньте путать кванторы. Я в этой дискуссии не рассматриваю потёкшие кондёры или битую память.

При том, что частота процессора и так была занижена производителем на 40% из маркетинговых соображений.

Примеры такого за последние лет 5 в основной линейке продуктов (не в Extreme и т.п.)?

А если же есть проблемы со стабильностью — то замедление и в два раза может не помочь.

Если бы это было так, то любой процессор можно было бы разгонять до бесконечности:)

Усиленная гарантия надёжности за счёт ухода из области проблемных частот.
Производители делают большинство моделей процессоров на едином процессе и разделяют готовые изделия по скорости в результате тестов корректности работы. Но эти тесты фактически однократные и не учитывают физическое старение техники. Поэтому работа на номинальной частоте означает повышение вероятности проблем через некоторое время (месяцы).
Реально это проявляется у нескольких процентов. Но ситуация типа «в собранном и отданном юзеру перевернулся один битик, поэтому оно глючит в неподходящие моменты», мягко говоря, неадекватна. Замедление уменьшает долю таких ситуаций до ничтожной.

Альтернатива — техника со сквозным контролем целостности данных (хотя бы ECC), она обычно исправляет одиночные однократные ошибки молча. Но это типично для серверов, а вот для настольной машины (даже разработчика) это слабо реально — никто такое не купит. Проще заказать какую-то круть типа Corei7 и чуть замедлить.