> на Perl сегодня писать никого не заставляют
> нелюбовь к Perl не считается чем-то плохим

Лол, истинная причина статьи?

не совсем понял, что не так с примером?
отличный код, понятно, что происходит с первого взгляда и без комментариев, при чем все выполняется асинхронно!
как по вашему было бы лучше это написать?

Ну да, но я не могу сказать, что это сильно менее очевидно, чем то, что пустой массив приводится к false в перле и пхп (хотя ссылка на него не является null). В общем, у всех свои недостатки.

Честно говоря, думал, что люди, пишущие на языке, в котором возможны конструкции типа

echo "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`~{;;y; -/:-@[-`{|~};`-{/" *-;;s;;$_;see'

не будут удивляться тому, что некоторые вещи в JS работают не очевидно для них ;-)

Что вы ожидаете услышать, говоря «хочу, чтоб яваскрипт работал как перл»? Я уверен, что можно накатать статью «20 и 1 фейл перла» с аргументацией «а у нас в яваскрипте принято не так», и уверен, что первый же коммент будет «читай спеку».

1. Меня наоборот смутило бы подобное поведение, т.к. при приведении ссылки на массив к bool я скорее буду ожидать true в случае users !== null (в сишечке !!users было бы 1 при не нулевом указателе), а вот эти штуки в перле и пхп мне постоянно мозг выносили.

2. Конкатенация строки и числа — чаще используемая операция, а приведение строки к числу я все равно хотел бы контролировать, т.к. это операция с потерей данных.

я же говорю, что это не равнозначные конструкции, и не только в JS.

char* x;
bool y = false;
cout << (!x == y) << endl; // 1
cout << (x != y) << endl; // ошибка, в С++ нельзя сравнивать указатели и целые

Погодите-ка, сравнение строк — тоже результат вроде bool, а ведь строки не приводятся к bool при сравнении?

Вообще, всегда автоматическое приведение типов работало так, чтоб исключить потерю значения. Сравните:
Boolean(Number(true)) // true, никаких потерь
Number(Boolean(42)) // 1, упс!

Так что именно приведение boolean к number выглядит логичнее. Ну а то, что вы операцией сравнения приводите какое либо значение к булевому типу вместо имеющихся способов приведения — так это уже ваши проблемы.

более удобным засунуть тяжелую операцию и отображение ее прогресса в одну функцию

Это в корне неправильно — смешивать бизнес-логику и интерфейс. Как раз обмен сообщениями здесь смотрится уместнее.

Для отслеживания изменения атрибута есть MutationObserver. Да, и невозможность работы с DOM из воркера — не недостаток языка (DOM — не часть JS), а ограничение API браузера.

Проблемы от уверенности, что при сравнении вида == обе части должны приводиться к boolean, хотя это ниоткуда не следует, более того, даже не всегда логично, например, конвертация number -> boolean приводит к потере информации, т. к. диапазон значений boolean меньше, чем у number.

Будете удивлены, но (!true == false) === (true != false) и в javascript. Это, кстати, никак не опровергает мой тезис о неравнозначности этих конструкций.

Эм, вроде же вся «длинная-длинная таблица» отличий от строгого сравнения — четыре строки:
— null == null, undefined == undefined, null == undefined
— при сравнении строки с числом, строка приводится к числу
— при сравнении чего угодно с булевым значением, булево значение приводится к числу
— при сравнении строк и чисел с объектами, объект приводится к примитивному типу

Еще раз, (!x == y) === (x != y) далеко не всегда и не во всех языках верно.

Расшифрую на всякий случай: для меня очевидно, что все указанные величины можно сравнить между собой в языках со слабой типизацией (это вообще следует из определения слабой типизации). Потому ваши претензии к JS относятся также и ко всем языкам со слабой типизацией (C/C++, кстати, в их числе).

На самом деле нет.

В JS как раз 42 == true не выполняется, т.к. true будет приведено к 1 (toNumber), и в результате получится 42 === 1, об этом и срач =)
gleb_kudr почему-то считает, что всегда должно выполняться (!x == y) === (x != y), и удивляется, что это не всегда так.

Что значит «не сравниваемых»? 42 и false — сравниваемые величины? А null и undefined? null и true? null и ""? null и 42?

console.log(42) — тут тоже ошибку рантайма кидать?

Нет, не так.

!x — это не проверка, не условие, а оператор. Подразумевается, что в операндах у него — значение булевого типа. Если ты туда запихал что-то другое, то ССЗБвыполняется операция приведения типа операнда к булевому, это происходит по некоторым правилам, и они вполне привычные:
— undefined, null -> false
— 0, NaN -> false
— пустая строка -> false
— все остальное -> true

Напротив, == — сравнение значений, и у него тоже есть пара особенностей:
— null == null, undefined == undefined, null == undefined
— при сравнении строки с числом, строка приводится к числу
— при сравнении чего угодно с булевым значением, булево значение приводится к числу

Это не сложно вроде, в том же PHP сложнее.

Эм, вы точно туда отвечаете?

А, так то есть в одном случае адекватная цена — цена, установленная рынком, а в другом — «себестоимость*маржа»?