Как я понял, он спросил равен ли Нулл нулю. Джава скрипт ответил что нет. Тогда он спросил меньше ли Нулл нуля. ЖС ответил что нет. И когда тот уже решил что нулл больше нуля, он спросил меньше либо равен нулл, и ЖС ответил что да, противореча себе до этого.
Если ты пишешь что-то хоть сколько-нибудь серьёзное, то должен быть в курсе таких фишек языка, а лучше если ещё и понимаешь, почему они так работают. Если же ты только встаёшь на путь познания языка, то не будешь утверждать, что "все верно написано", а пойдешь курить маны.
А если ты говнокодишь за бутеры, вряд ли тебя будет волновать такая мелочь, как не всегда верно работающий код.
А тут херня в другом на самом деле. Так как JS имеет слабую динамическую типизацию, то что угодно может быть чем угодно. То есть написал хорошую функцию, которая работает с числами. А тут какой-то еблан передал в неё null. Таким образом приходится писать проверки на входящие данные, но на все же не напишешь проверки на все и всякие структуры. Из-за подобной поеботы и придумали статические языки поверх JS - Typescript и Flow.
TS и flow не особо поможет, так как это все просто транспайлится в обычный js, а там уже что хочешь можешь передать в публичные методы на стадии выполнения. Просто скажу что JS не такой уже и баганый, если у тебя ровные руки. Для своей специфики, а это работа в вебе, где важна легковесность и функциональность. Если бы он был на уровне java или с#, то в веб бы его никто не запилил.. Другое дело когда у нас куча разработчиков на JS пытается его прихуярить к вещам на которые JS не рассчитан Кстати подобных приколов полно и в других языках, в частности Ruby
Если у тебя хачкель компилируется в ассембелер, то ты уже теряешь все свойства монад и эффектов? Похуй во что оно там транспилится, главное, какие гарантии дает язык.
Сломать эту хуйню можно только если миксовать тс и жс, но это надо быть отбитым на всю голову.
это проблемы еблана. нужно проверять что прислал сервер или вернула функция - там действительно могут быть null или undefined. А если еблан сознательно пихает строку "hello" в функцию, которая ожидает число - это не твои проблемы. Иначе - скрипты разрастутся до немыслимых размеров и слабая типизация тут будет не плюсом, а минусом.
Там идея в том что в случае "больше или равно" идет проверка на "меньше", если false, то значит "больше или равно" - true. И наоборот с "меньше или равно" - проверяется "больше" и возвращается обратный результат.
не проще, операторы строгого сравнения в JS сначала преобразовывают операнды к одному типу данных и потом уже сравнивают. но что во что преобразовывается - нету удобной и понятной таблички, нужно читать тонны скучных спецификаций на англ. языке.
да и не нужны эти таблички, просто пиши нормальный код, в неочевидных случаях сам преобразовывай типы к нужному.
В плюсах и це NULL физически равен 0. Так что сравнение с нулем может как дать, так и не дать 0.
Причем в це еще и bool нет. Так что там результат сравнения - это 0 или 1.
Ты наверно с NaN перепутал. Любая арифметическая операция с NaN дает NaN, и при этом NaN не равен сам себе.
Что нет?
По твоей же ссылке:
an integer literal with value zero, or a prvalue of type std::nullptr_t (since C++11)
В С++11 он все так же физически равен 0. И в С++20 он также будет 0
Просто неперь у него тип std::nullptr_t, чтобы его можно было кастить к любому указателю, вот и все.
Не. Вполне естественно, что какой-то программист хочет сделать функцию, которая учитывает ошибки предшественника, но называет её также, зато кладет в другой НС. Или вот show JQuery или MooTools. Они делают похожие вещи, но, все-таки, они разные. Это нормально. Если бы у них было одинаковое поведение, то одна из них была бы просто лишняя и это бы стало уже странным
isFinite пытается всё превратить в число, так как это - глобальный метод, и в нём null превращается в 0.
Метод объекта Number предполагает получать исключительно числа, и посылает всех нахер если это не так.
всё логично и должно работать точно так же в других языках со слабой типизацией
Если кому интересно, фишка в том, что == - это сравнение чего угодно с чем угодно, а <= - чисто числовое сравнение. Соответственно правила и порядок приведения типов разный.
как же заебали эти "шутки" от it петросяна.
блять. курите мануалы
пишите проверки
организуйте логику так, чтобы не было разных (или не приводимых) типов данных в вашем коде.
не используйте null блять там где оно не надо.
используйте соответствующие инструменты для разных задач
нет, блять, надо сравнить теплое с мягким, и гнустно хохотать, а то, что скорее всего там тонны говнокода - мы скромно умолчим.
» 4 in l <- false
Programmer Memes
@iammemeloper
Without a doubt, the best programming language
11:09 PM -Sep28, 2023 121.6K ¡ews
» let l = [1,2,3,4]
<- undefined
» 0 in l <- true
» "0" in l <- true
А если ты говнокодишь за бутеры, вряд ли тебя будет волновать такая мелочь, как не всегда верно работающий код.
null * 1 == 0
То результат true
AjiTae ниже объяснил почему так.
А null + 0 == null дает false
Все логично
Если у тебя хачкель компилируется в ассембелер, то ты уже теряешь все свойства монад и эффектов? Похуй во что оно там транспилится, главное, какие гарантии дает язык.
Сломать эту хуйню можно только если миксовать тс и жс, но это надо быть отбитым на всю голову.
Так ты уж определись - надо проверять или "разрастутся до немыслимых размеров".
> слабая типизация тут будет не плюсом, а минусом.
он начинает что-то подозревать...
0 > true && ' '
0 > true || ' '
Прошу заметить:
null >= 0
true
null
да и не нужны эти таблички, просто пиши нормальный код, в неочевидных случаях сам преобразовывай типы к нужному.
Причем в це еще и bool нет. Так что там результат сравнения - это 0 или 1.
Ты наверно с NaN перепутал. Любая арифметическая операция с NaN дает NaN, и при этом NaN не равен сам себе.
https://en.cppreference.com/w/cpp/types/NULL
По твоей же ссылке:
an integer literal with value zero, or a prvalue of type std::nullptr_t (since C++11)
В С++11 он все так же физически равен 0. И в С++20 он также будет 0
Просто неперь у него тип std::nullptr_t, чтобы его можно было кастить к любому указателю, вот и все.
Но от функций/методов, имеющих одинаковое название и предназначение логично ожидать одинакового поведения.
Метод объекта Number предполагает получать исключительно числа, и посылает всех нахер если это не так.
всё логично и должно работать точно так же в других языках со слабой типизацией
'hello' < 'hello'
'hello' <= 'hello'
блять. курите мануалы
пишите проверки
организуйте логику так, чтобы не было разных (или не приводимых) типов данных в вашем коде.
не используйте null блять там где оно не надо.
используйте соответствующие инструменты для разных задач
нет, блять, надо сравнить теплое с мягким, и гнустно хохотать, а то, что скорее всего там тонны говнокода - мы скромно умолчим.
пиздец
ну и ... не следуя этим правилам даже хелоаорлд не напишешь без ошибок.