Если нужно объяснять, почему шутка смешная, то шутка не удалась. Если 28 минут нужно объснять логику работы примитивных выражений ЯП из одного мемеса, то явно есть где то проблема. Никто не сомневается в том, что JS работает ровно так, как описано в документации к JS. Факт в том, что его синтаксис больше контринтуитивен, нежели чем-то полезен, и при разработке новых ЯП таких "нюансов" явно следует сторониться
А в Perl кроме "." для конкатенации и тип определяется операцией, ">" сравнит как числа, "gt" как строки, вот динамическая типизация, сделанная правильно.
Оффтоп. Веселая у тебя оправа! Смотрится стильно! :) Видео тоже классное! После ассемблера ничего не кажется странным, в основном всё объяснимо. Типы данных - абстракция для людей, машинам они не нужны особо.
У всех языков программирования есть косяки и их решения. Причина всего этого, что есть недочёты это недочёты любой аппаратной системы. Каламбур не правда ли? По этой причине невозможно создать идеальный язык программировани так как всегда приходиться чем-то жертвовать. Тяжело спорить что хуже а что лучше так как каждая задача решается лучше (иногда просто быстрее) на чём-то одном, ну и так далее. По этой причине создано так много всякого рода языков программирования.
А вот один из настоящих косяков жс в том что когда ты попробуешь отсортировать массив чисел не передавая колбэк в метод сорт то он преобразует числа в строки и отсортирует, почему так мне не понятно, числа это же примитив, могу предположить что это из-за того что когда в массиве есть не только Инты тогда надо всё преобразовать в флота к примеру, а там опять же будут огрехи, потому если кто знает то скажите мне
В русской и английской версиях википедии есть статьи про «0.(9)». Там приводятся доказательства того, что 0.(9) это другая запись для числа 1. Предлагаю вам ознакомиться :)
Смысл столько времени тратить на плавающую точку и вообще про работу флоатов? Это очевидно как бы. Вот неявное преобразование типов как раз таки зло. попробуй поскладывать Bool в haskell, или неявно прийти из 999999999999 к BigInt в java,которое почему-то на единицу больше, что вообще не норма ни в каком виде. Ну или сравнивать несравнимое(0 и [], например), нормальные языки с четкой семантикой не должны позволять такое делать.
Это к с++ то никаких претензий? Смешная шутка. js считают ужасным языком зе на их арифметкиу с флоатами, которая такая-же как у других языков а за динамический this, с которым легко написать код который упадет в рантайме за единый оператор конкатенации и сложения, который приводит к тому что 10+'1' становится '101', что опять же при отсутствии проверки типов приводит к ошибкам(а в других языках, даже с приведением типов обычно делают 2 разных оператора и таких проблем просто нет) за одновременно существующие undefined и null за очень куцую стандартную библиотеку за node_modules, огромных размеров, и длительное развертывание/сборку за несколько систем модульности, бандлеров
Подожди, но this вообще можно не использовать, если он тебе не нравится, ну либо следить за контекстом единый оператор конкатенации это вроде тоже не проблема, ты ж должен следить за типами, ну или использовать typescript Не понял в чем проблема с undefined и null Раздутый node_modules это вообще не про js, а про реализацию npm Про несколько синтаксисов систем модулей я соглашусь, но тут же не в языке дело, а в том, что нода ушла в CommonJS. Язык ведь не несет ответственности за то, что кто-то может придти со своим видением.
@@johenews21"следить на контекстом", "следить за типами", когда в других языках это не нужно. т.е. просто на пустом месте появляетс больше мест, где можно ошибится, при этом не получая от этого никакого профита. Про npm, рассматривать язык без экоситстемы тож как-то неправильно, т.к. ты его в отрыве использовать и не будешь. Вообще основаня проблема - язык был рожден довольно быстро, с довольно сомнительными решениями, т.к. из задач было просто добавить совсем чуть-чуть интерактивности. А потом, т.к. только он релизован во всех браузерах стал безальтернативным и на нем начали писать сложные приложения.
"следить на контекстом", "следить за типами", когда в других языках это не нужно. Ну по факту и в других языках точно так же следишь за типами, только тебе их надо всегда самому определять. И даже если ты их определяешь, то тебе все равно нужно с ними париться. Например в том же го, ты не можешь сложить два числа с разными типами, тебе надо сначала свести их к одному. Так что в любых языках ты будешь с этим париться. Про npm, рассматривать язык без экоситстемы тож как-то неправильно. Правильно. JS существовал до npm десяток лет. Да и сейчас есть куча библиотек на js и ты их можешь юзать без npm. Ну и опять же, ну ок, у тебя дохуя всего в node_modules. Ну и что? У нас что какая-то серьезная проблема с памятью, что мы не можем позволить себе захламить там все?
@@johenews21 Ладно, приведу пару реальных примеров на счет "следить за типами". Предположим мы написали скрипт, кторый делает какие-то расчеты и результат выводит пользователю. И где-то внутри у нас есть конструкция c = (a + b) * 3, с дальнейшим выводом c. a и b числа. После этого нам понадобилось чуть отрефакторить, например вместо константы в качестве b брать значение из файла/инпута. И мы сделали ошибку и забыли преобразовать эту строку в число. Как в итоге поведут себя программы: 1) на языке со статической проверкой типов - мы получаем ошибку компиляции, исправляем, получаем рабочую программу 2) на языке с динамиечской проверкой типов но без приведения типов - мы получаем ошибку в рантайме, исправляем, получаем рабочую программу 3) на языке с динамической проверкой типов но разными операторами для сложения и контатенации - происходит сложение, мы получем рабочую программу с корректным реузльататом сразу. 4) в JS - мы получаем РАБОЧУЮ программу которая выдает НЕКОРРЕКТРЫЙ результат. Т.е. конкретно в этом случае получается что в других языках мы можем особо не смотреть за типами, т.к. расхождение типов нам будет неважно, либо язык нам про это расхождение скажет(ко время компиляции или в рантайме) И только в js нам самим приходится сидеть и очень внимательно думать, как наши доработки/рефакторинг могут выстрелить. В итоге, имея один оператор для сложения/конкатенации мы получаем кучу головняка при этом не получая каких-то дополнительных профитов. Точно так-же с умножением где-то вместо числа получили строку от пользователя. 10 * '1,3' превратилось NaN и соответственно все остальные выражения, которые это использовали тоже стали NaN. И сиди ищи, где-же это выстрелило. Когда в других языках будет ошибка в месте, где проходит умножение на строку.
Есть такой термин "Garbage in - garbage out" Как вы уже сказали, если вы подадите мусор на вход, то в любом языке у вас будут какого-либо рода проблемы Кстати, для решения таких во тпроблем программисты и пишут юнит тесты
Ваша мысль понятна. Я не думаю, что любое поведение языка является оправданным, даже если язык себя ведёт каким-то образом в соответствии со спецификацией. Я думаю, что динамические языки, которые по умолчанию кидают ошибки при попытке сложить объекты (Lua, Python), в данном случае более интуитивны для пользователей. Из этого не следует, что те языки лучше. Я комментирую конкретную особенность
Только про жс такие картинки потому что большинство прахрамистов только жс понимают. А вообще я никогда на практике за 8 лет не сталкивался с вот этими приколами ни в каком языке, а тем более в жс, может быть я просто не шарю
Мемы это мемы, воспринимать их серьезно это странно. Тк js сейчас в тренде по этому и мемов много про него. Раньше про php такое было, питон вообще питухоном называют и тд
16:30 - Нет, в математике это так не работает, 0,(3) это эквивалент 1/3, и при его умножении на 3 мы получим один. Да, можно записать 0,(9), но лучше не надо, принято просто один, потому что 0,(9)=1. Это доказанный математический факт, ничего ни к чему не стремится. Математика НЕ работает так, как ты описал, в ней НЕ получается каких-то несостыковок в настолько базовых вещах, и именно поэтому никого это не смущает
Машины не умеют хранить десятичные дроби с абсолютной точностью. Например: математическое 1/3 - невозможно записать в виде конечной десятичной дроби. Дробные числа хранятся с некоторой погрешностью, и при манипуляциях с несколькими такими дробными числами, эта погрешность может расти. Следующий код на языке с++ наглядно показывает погрешности при сложении 0.1 + 0.2 #include #include int main() { std::cout
Потому что в цифровом мире числа храняться в памяти в 2-ичной системе счисления, в которой эти дробные числа имеют бесконечную запись. И есть 2 пути: либо использовать значительно больше памяти под каждое число (чтобы из набора битов можно было обратно восстановить исходное значение, см. типы Decimal), либо округлить (тогда исходное значение восстановить без погрешности не получиться, но выгрываем в скорости/объеме памяти)
@@user-jp2zc3lo9o о, спасибо за разъяснение. Я правда ничего не понял, но я теперь знаю, что этому фокусу есть разумное объяснение, выходящее за грани моего понимания)
"Минус всегда вычитание, js умный и все знает..." Ну, это в js не бывает операции противоположной конкатенации, а, например, в груви можно из строки вычесть подстроку при помощи "-". А в js просто беда с типами, не понимаю, зачем пытаться это оправдать
смеятся в том что это смешно для человека не знакомого с языками программирования это как будто нарушает принцип последовательности. И да 0.5+0.1 == true, а 0.1+0.2 == false говорит о том, а если мы возьмём другие значения тру у нас будет или false? Это нельзя точно сказать.
Это вообще не сравненеие, если что. Сравнение - процесс количественного или качественного сопоставления разных свойств (сходств, отличий, преимуществ и недостатков) двух (и более) объектов. То, что написано у тебя сравнением точно не является. Ты тут вводишь какую-то переменную с отклонением и почему-то задаешь ей значение в одну десятитысячную. Это бред, дружище
@@johenews21 Сами вы бредите. А человек выше привел вам пример сравнения дробных чисел в языке с++. Подобный код вы можете увидеть в фреймворке Google test, и ли например, в библиотеке nlohmann. // код взят из библиотеки nlohmann template inline bool is_same(T a, T b, T epsilon = std::numeric_limits::epsilon()) noexcept { return std::abs(a - b)
Это лучшая реклама, которую я видел! 🎉 Просто пушка
Если нужно объяснять, почему шутка смешная, то шутка не удалась. Если 28 минут нужно объснять логику работы примитивных выражений ЯП из одного мемеса, то явно есть где то проблема. Никто не сомневается в том, что JS работает ровно так, как описано в документации к JS. Факт в том, что его синтаксис больше контринтуитивен, нежели чем-то полезен, и при разработке новых ЯП таких "нюансов" явно следует сторониться
Синтаксис ещё более-менее, а вот семантика местами адская.
"скриншоты курсов, только от более умных людей" )) Стандарт IEEE 754 для арифметики чисел с плавающей запятой или точкой? ))) никто не отменял.
не осуждайте блогера за рекламу, кому сейчас легко живется....
Вывод: Учите ассемблер проблем не будет, а остальное от Лукавого.
несправедливо мало подписчиков у такого качественного контента
Про вим оч смешно конечно
Конечно, без явного указания типа для 0.3 код будет не корректен, скорее всего.
(0.3).toFloat, например, для Scala3 работает верно.
ох уж этот автокомплит
В некоторых языках (Lua, Haskell) отдельный оператор («..», например) для конкатенации, чтобы проблем с 90 + '1' не было
А в Perl кроме "." для конкатенации и тип определяется операцией, ">" сравнит как числа, "gt" как строки, вот динамическая типизация, сделанная правильно.
Оффтоп. Веселая у тебя оправа! Смотрится стильно! :) Видео тоже классное! После ассемблера ничего не кажется странным, в основном всё объяснимо. Типы данных - абстракция для людей, машинам они не нужны особо.
typeof null === «object» - признанная ошибка
У всех языков программирования есть косяки и их решения. Причина всего этого, что есть недочёты это недочёты любой аппаратной системы. Каламбур не правда ли?
По этой причине невозможно создать идеальный язык программировани так как всегда приходиться чем-то жертвовать.
Тяжело спорить что хуже а что лучше так как каждая задача решается лучше (иногда просто быстрее) на чём-то одном, ну и так далее. По этой причине создано так много всякого рода языков программирования.
А вот один из настоящих косяков жс в том что когда ты попробуешь отсортировать массив чисел не передавая колбэк в метод сорт то он преобразует числа в строки и отсортирует, почему так мне не понятно, числа это же примитив, могу предположить что это из-за того что когда в массиве есть не только Инты тогда надо всё преобразовать в флота к примеру, а там опять же будут огрехи, потому если кто знает то скажите мне
Как страшно жить
«0.(9)» и «1» это два способа записать одно и то же число
Конечно же нет. 0.(9) не равно 1
В русской и английской версиях википедии есть статьи про «0.(9)». Там приводятся доказательства того, что 0.(9) это другая запись для числа 1.
Предлагаю вам ознакомиться :)
Ознакомился. Вы действительно правы.
Реклама зачетная!😂😂
с рекламы орнулось нормально)) собрание скриншотов...))
Смысл столько времени тратить на плавающую точку и вообще про работу флоатов? Это очевидно как бы.
Вот неявное преобразование типов как раз таки зло. попробуй поскладывать Bool в haskell, или неявно прийти из 999999999999 к BigInt в java,которое почему-то на единицу больше, что вообще не норма ни в каком виде.
Ну или сравнивать несравнимое(0 и [], например), нормальные языки с четкой семантикой не должны позволять такое делать.
Не думаю, что IEEE 754 очевидно.
В python None является типом NoneType, а не float
Ты такой внимательный
То, что речь не про None, а про NaN
@@johenews21 В python есть NaN?)
есть
@@johenews21 Действительно, не знал :о
Это к с++ то никаких претензий? Смешная шутка.
js считают ужасным языком зе на их арифметкиу с флоатами, которая такая-же как у других языков
а за динамический this, с которым легко написать код который упадет в рантайме
за единый оператор конкатенации и сложения, который приводит к тому что 10+'1' становится '101', что опять же при отсутствии проверки типов приводит к ошибкам(а в других языках, даже с приведением типов обычно делают 2 разных оператора и таких проблем просто нет)
за одновременно существующие undefined и null
за очень куцую стандартную библиотеку
за node_modules, огромных размеров, и длительное развертывание/сборку
за несколько систем модульности, бандлеров
Подожди, но this вообще можно не использовать, если он тебе не нравится, ну либо следить за контекстом
единый оператор конкатенации это вроде тоже не проблема, ты ж должен следить за типами, ну или использовать typescript
Не понял в чем проблема с undefined и null
Раздутый node_modules это вообще не про js, а про реализацию npm
Про несколько синтаксисов систем модулей я соглашусь, но тут же не в языке дело, а в том, что нода ушла в CommonJS. Язык ведь не несет ответственности за то, что кто-то может придти со своим видением.
@@johenews21"следить на контекстом", "следить за типами", когда в других языках это не нужно. т.е. просто на пустом месте появляетс больше мест, где можно ошибится, при этом не получая от этого никакого профита.
Про npm, рассматривать язык без экоситстемы тож как-то неправильно, т.к. ты его в отрыве использовать и не будешь.
Вообще основаня проблема - язык был рожден довольно быстро, с довольно сомнительными решениями, т.к. из задач было просто добавить совсем чуть-чуть интерактивности. А потом, т.к. только он релизован во всех браузерах стал безальтернативным и на нем начали писать сложные приложения.
"следить на контекстом", "следить за типами", когда в других языках это не нужно. Ну по факту и в других языках точно так же следишь за типами, только тебе их надо всегда самому определять. И даже если ты их определяешь, то тебе все равно нужно с ними париться. Например в том же го, ты не можешь сложить два числа с разными типами, тебе надо сначала свести их к одному. Так что в любых языках ты будешь с этим париться.
Про npm, рассматривать язык без экоситстемы тож как-то неправильно. Правильно. JS существовал до npm десяток лет. Да и сейчас есть куча библиотек на js и ты их можешь юзать без npm. Ну и опять же, ну ок, у тебя дохуя всего в node_modules. Ну и что? У нас что какая-то серьезная проблема с памятью, что мы не можем позволить себе захламить там все?
@@johenews21 Ладно, приведу пару реальных примеров на счет "следить за типами".
Предположим мы написали скрипт, кторый делает какие-то расчеты и результат выводит пользователю.
И где-то внутри у нас есть конструкция c = (a + b) * 3, с дальнейшим выводом c. a и b числа.
После этого нам понадобилось чуть отрефакторить, например вместо константы в качестве b брать значение из файла/инпута.
И мы сделали ошибку и забыли преобразовать эту строку в число. Как в итоге поведут себя программы:
1) на языке со статической проверкой типов - мы получаем ошибку компиляции, исправляем, получаем рабочую программу
2) на языке с динамиечской проверкой типов но без приведения типов - мы получаем ошибку в рантайме, исправляем, получаем рабочую программу
3) на языке с динамической проверкой типов но разными операторами для сложения и контатенации - происходит сложение, мы получем рабочую программу с корректным реузльататом сразу.
4) в JS - мы получаем РАБОЧУЮ программу которая выдает НЕКОРРЕКТРЫЙ результат.
Т.е. конкретно в этом случае получается что в других языках мы можем особо не смотреть за типами, т.к. расхождение типов нам будет неважно, либо язык нам про это расхождение скажет(ко время компиляции или в рантайме)
И только в js нам самим приходится сидеть и очень внимательно думать, как наши доработки/рефакторинг могут выстрелить.
В итоге, имея один оператор для сложения/конкатенации мы получаем кучу головняка при этом не получая каких-то дополнительных профитов.
Точно так-же с умножением где-то вместо числа получили строку от пользователя. 10 * '1,3' превратилось NaN и соответственно все остальные выражения, которые это использовали тоже стали NaN.
И сиди ищи, где-же это выстрелило. Когда в других языках будет ошибка в месте, где проходит умножение на строку.
Есть такой термин "Garbage in - garbage out"
Как вы уже сказали, если вы подадите мусор на вход, то в любом языке у вас будут какого-либо рода проблемы
Кстати, для решения таких во тпроблем программисты и пишут юнит тесты
В некоторых языках (Python) «арифметические» операторы над не численными типами кидают ошибку, а не выдают чепуху
ну так и js не выдает чепухи
Ваша мысль понятна. Я не думаю, что любое поведение языка является оправданным, даже если язык себя ведёт каким-то образом в соответствии со спецификацией. Я думаю, что динамические языки, которые по умолчанию кидают ошибки при попытке сложить объекты (Lua, Python), в данном случае более интуитивны для пользователей. Из этого не следует, что те языки лучше. Я комментирую конкретную особенность
@@johenews21 (1+'10')*2 в питоне приведет к ошибке, в lua привете к результату 22, в js приведет к результату 220.
Крутая футболка!!!
Только про жс такие картинки потому что большинство прахрамистов только жс понимают.
А вообще я никогда на практике за 8 лет не сталкивался с вот этими приколами ни в каком языке, а тем более в жс, может быть я просто не шарю
Мемы это мемы, воспринимать их серьезно это странно. Тк js сейчас в тренде по этому и мемов много про него. Раньше про php такое было, питон вообще питухоном называют и тд
Нет, любой мем можно подвергать критике, это нормально
0.1 + 0.2 ==0.3 ради прикола проверил в Python, консоль выдала false.
какие же топовые очки
16:30 - Нет, в математике это так не работает, 0,(3) это эквивалент 1/3, и при его умножении на 3 мы получим один. Да, можно записать 0,(9), но лучше не надо, принято просто один, потому что 0,(9)=1. Это доказанный математический факт, ничего ни к чему не стремится. Математика НЕ работает так, как ты описал, в ней НЕ получается каких-то несостыковок в настолько базовых вещах, и именно поэтому никого это не смущает
Да, именно так. В математике 1/3 - это абсолютно точное значение.
Это доказанный факт только для определенных аксиом о вещественных чисел. Изменив одну аксиому - измениться все
Так и не раскрыл тему, почему 0,1+0,2 не равно 0,3. Может кто-нибудь объяснит?
Машины не умеют хранить десятичные дроби с абсолютной точностью. Например: математическое 1/3 - невозможно записать в виде конечной десятичной дроби. Дробные числа хранятся с некоторой погрешностью, и при манипуляциях с несколькими такими дробными числами, эта погрешность может расти.
Следующий код на языке с++ наглядно показывает погрешности при сложении 0.1 + 0.2
#include
#include
int main()
{
std::cout
Потому что в цифровом мире числа храняться в памяти в 2-ичной системе счисления, в которой эти дробные числа имеют бесконечную запись. И есть 2 пути: либо использовать значительно больше памяти под каждое число (чтобы из набора битов можно было обратно восстановить исходное значение, см. типы Decimal), либо округлить (тогда исходное значение восстановить без погрешности не получиться, но выгрываем в скорости/объеме памяти)
@@user-jp2zc3lo9o о, спасибо за разъяснение. Я правда ничего не понял, но я теперь знаю, что этому фокусу есть разумное объяснение, выходящее за грани моего понимания)
Потому что в IEEE 754 так сказано, грубо говоря
@@alurma Грубо говоря, надо в школе вместо математики изучать IEEE754)))
Дим, просто else в питоне.
"Минус всегда вычитание, js умный и все знает..." Ну, это в js не бывает операции противоположной конкатенации, а, например, в груви можно из строки вычесть подстроку при помощи "-". А в js просто беда с типами, не понимаю, зачем пытаться это оправдать
Так в чем заключается беда?
предполагаю, что речь про неявное приведение типов. правила языка нужно знать - на этом всё)
Мне больше всего нравится мем 'ba' + + 'a'
смеятся в том что это смешно для человека не знакомого с языками программирования
это как будто нарушает принцип последовательности. И да 0.5+0.1 == true, а 0.1+0.2 == false говорит о том, а если мы возьмём другие значения тру у нас будет или false? Это нельзя точно сказать.
Три раза прочитал этот комментарий и ничего не понял. Вам надо идти в политику.
В С/С++ так float-ы не сравниваются
покажи как сравниваются
@@johenews21
#include
#include
bool compare_floats(float a, float b, float epsilon)
{
return fabs(a - b) < epsilon;
}
int main()
{
float num1 = 0.1;
float num2 = 0.2;
float sum = num1 + num2;
float tolerance = 0.0001; // Define your tolerance level here
if (compare_floats(sum, 0.3, tolerance)) {
printf("true
");
} else {
printf("false
");
}
return 0;
}
+ еще в С library есть стандартные функции специально для сравнения флоатов
Это вообще не сравненеие, если что.
Сравнение - процесс количественного или качественного сопоставления разных свойств (сходств, отличий, преимуществ и недостатков) двух (и более) объектов.
То, что написано у тебя сравнением точно не является.
Ты тут вводишь какую-то переменную с отклонением и почему-то задаешь ей значение в одну десятитысячную.
Это бред, дружище
@@johenews21 Сами вы бредите. А человек выше привел вам пример сравнения дробных чисел в языке с++. Подобный код вы можете увидеть в фреймворке Google test, и ли например, в библиотеке nlohmann.
// код взят из библиотеки nlohmann
template
inline bool is_same(T a, T b, T epsilon = std::numeric_limits::epsilon()) noexcept
{
return std::abs(a - b)
скатился джохе, уже ролики ради рекламы делает
Думал автор адекватный человек, но увидел имперско-шовинистскую футболку и сразу захотелось отписаться. Прощай российский имперец.
🤡
о, футболка работает
А минусы будут?
О нет, только не отписывайся! Что же автору без тебя делать?
@@johenews21 Ты конь педальный. Работают HIMARS, ATACMS, дроны "Лютий".