символ "=" - значит присвоить значение
символ "==" - значит равно
символ "!==" - просто не равно)
Странно, что в JS нет "!=" типа "не присваивать значение".
Довольно неплохо впишется в язык.
Типа, тут мы описываем переменные, тут одной присваиваем 10, а другой не присваиваем 5.
Кстати, норм фишка была бы для, например, занулления переменной при равенстве значению.
val != 5
if val == 5 then val = null
Чисто для упрощённой записи.
Как я и уточнил, для упрощения записи.
И то, что написано у вас не равноценно тому, что написал я, хоть результат один и тот же.
В моём случае:
Сравнение
TRUE - присвоение значения
Выход
В вашем:
Сравнение
TRUE - выбор значения
FALSE - выбор значения
Присвоение значения
Выход
Еще надо добавить логики:
c = a =~= b - а возможно равно б
c = a ~= b - возможно стоит прибавить b к а? (А может и не стоит)
с = а !~= b - возможно не стоит прибавить б к а?
c = a ?+? b - сложить a и b, но в другой раз
c = :a~!<=> ?a || >b~!< || (a!~!b)?;
Значение c равно: Возможное а не из промежутков отложенных значений которые или не равны увеличенному b на не возможное уменьшение, либо это не определённое значение возможно возникающих значений a и b.
Блядь, на старте этой ветки я ещё улавливал логику построения, но с каждым новым комментом таинство программирования открывало все новые и новые грани, и по итогу кроличья нора оказалась слишком глубока.
А я тут при чем? Логические цепочки, включающие что-то вроде "может быть" ведут либо в непрошибаемую стенку, либо в нейронные сети) Тема, на самом деле, куда проще воспринимается, чем программирования (как по мне)
Ну, ващет:
"!=", "==" - нестрогое равенство (может приводить типы при сравнении), например, 1 == '1' => true или 1 != '1' => false
"!==", "===" - строгое равенство (не приводит типы), например, 1 === '1' => false или 1 !== '1' => true
=== или !== — строгое сравнение по типу
== или != — сравнение с приведением типов
> false != 0
false
> false !== 0
true
> 1 == "1"
true
> 1 === "1"
false
Не дыши, переедь.
Дом рядом с заводом хуже чем тот же дом рядом с зеленой зоной.
Сайт без джаваскрипта сейчас полная лажа.
Так ведь всё итак понятно.
Если стоит плюсик, то JS всеми силами пытается представить следующий элемент как строку. Если стоит минус, то наоборот, всеми силами пытается представить следующий элемент как тип данных, который можно вычитать.
Ну а в случае, если всё это не прокатывает, то просто хуячит всё в строку, разводя руками и преклоняясь перед величием разума того гения, который пытается творить всю эту дичь
Логика вполне простая и понятная даже мне, хоть я и не знаток JS, а работаю с другими языками. Так что хз в чём тут проблема. Не пиши говно - не будет говна. Принцип прост и работает во всех языках.
Яблоко + яблоко = 2 яблока
машина + машина = null //потому что машина не круглая и не съедобная.
С какого перепугу не должна? Ещё как должна зависеть от типа операнда!
Допустим с числами все ясно (конкретно в случае оператора +)
1 + 2 = 3
А со строковыми типами + обычно их конкатенирует
'ab' + 'bc' = 'abbc'
А в некоторых ЯП (тот же С++) для своих типов можно операторы перегрузить.
Даже в реальной жизни зависит логика работы от типа операнда, например комплексные числа складываются, перемножаются и возводятся в степень по-другому, нежели обычные.
Например, сложение:
Мнимые к мнимым, действительные к действительным!
1+2i + 1+2i = 2+4i
Еще как должна логика зависеть, просто оператор должен быть определён для типа, с которым ты его используешь.
Почему на 0 делить нельзя? Потому что в пространстве чисел операция деления конкретно в случае деления на 0 не определена.
Представь, что стоимость проезда на метро каждый день показывалась бы в новой системе счисления, основание которой - минимальный простой множитель ближайшего простого числа, образованного перемножением всех чисел месяца до текущего.
Да, логика есть и вполне детерменированная.
Удобно?
Про метро очень плохой пример плохо написанной логики, который не опровергает всего того, что я написал выше.
По твоей логике и на 0 делить можно в арифметике.
Как комплексными числами оперировать? А векторами? А пользовательские типы данных?
Ты не можешь по одной логике складывать и числа, и строки.
Возможность определять операторы не усложняет - даёт больше свободы. Просто пользуйся с умом.
Перегрузка операторов и функций - это бага, ставшая фичей.
Это удобно. Как и то, что ножом можно не только колбасу резать, но и копать, метать и бриться.
Это от безысходности
на каждый свою логику написать
В некоторых языках можно:
> creation of programmer-defined operators (e.g. Prolog, Seed7, F#, OCaml, Haskell).
https://en.wikipedia.org/wiki/Operator_(computer_programming...
Наслаждайтесь. Это практически самый актуальный и самый толковый учебный материал по JavaScript на текущий момент.
В нормальных языках если из строчки будешь вычитать число, компилятор/интерпретатор посмотрит на того, кто это написал, как на дебила и выкинет ошибку компиляции/эксепшн а не будет делать вид, что так и надо
Споры про то, нужны ли такие фишки в языках программирования или нет - это уже другой разговор. Как и в целом динамическая типизация переменных. Я вот тоже люблю строгую типизацию, да и не я один. Вот тебе TypeScript для этого, наслаждайся. Однако я не люблю когда в чем-то обвиняют язык программирования, когда он все делает правильно и логично, в отличии от кретинов которые делают такие финты ушами.
Это не имеет отношения к динамической типизации, неявное приведение типов - признак слабой типизации (хотя антагониста ты назвал правильно - строгая/сильная типизация), бывают языки как со статической и слабой типизацией (С), так и с динамической и строгой (Python)
'5' - 2 = '5-2'
5 - '2' = 3
'5' + 3 = '53'
5 + '3' = 8
Неочевидный результат, как он есть.
Если я эту же пятерку запихаю во float - компилятор не ругнется, что я целое число во флоат пихаю (типы же разные!), а результат деления уже будет другой.
Я уже ответил паре человек достаточно подробно. Не так то, что оператор один, а действия выполняет разные и дает разный результат с одними и теми же значениями на входе.
Используя этот пример у кого-то будут такие вопросы и всё вернётся к тому с чего начали.
Вычитание работает так как и должно работать приводя операнды к одному типу (числу).
Ну а для конкатенации они, возможно, выбрали не очень удобный оператор, но это все решается явным привидением типов. За типами следить придётся хоть так, хоть так, ибо не всегда можно быть уверенным в том, что тебе пришло именно число, а не строка с числом.
почему '5' - 2 это '5-2', а '5' + 3 не '5+3'? Уж впихивать знак - так впихивать, натягивать сову на глобус - так натягивать.
А сколько будет 5 + ' яблок' у вас?
Попрошу внимания, но первое выражение там вовсе не '5' - 2, а '5' + - 2. Это абсолютно разные вещи (с точки зрения javascript, конечно). В первом случае, так как минус является оператором вычитания он преобразует 5 к числу, и производит вычитание 2 из 5, получает 3. Во втором случае есть уже два оператора - плюс и минус. Плюс является оператором конкатенации, а минус уже работает не как оператор вычитания, а как изменение знака у числа 2 (причем неважно, дали ли вы ему строчку '2' или число 2, он все равно преобразует в число). Только что сама проверила, что все так и работает.
Ну так всё верно, идеально работает язык. Первое: в JS нет строгой типизации потому что JS изначально не язык программирования, а связующее звено между элементами HTML+CSS в форме яваобразного языка программирования. То, что JS уже можно использовать даже для десктопных и мобильных приложений - следствие его распространенности и адаптации, как следствие, под другие платформы и задачи.
Математические функции приводят строку к числовому значению
Если первым идёт строка она не конвертируется и яваскрипт видит выражение формата "строка" + "число". Т.к. строка с числом не складывается математически он просто конвертирует число в строку и складывает строки.
Если строка идёт второй, математические функции конвертируют её в число и яваскрипт получает два числа. после чего успешно их складывает или вычитает, что тут непонятного?
Язык прекрасен в своей простоте. Математические функция пытается привести значение к числу изначально, если не получается оставляет строку.
Равно же это знак присваивания, а не математическое "равно".
Потому что исторически
Потому что был спроектирован из говна и палок в кратчайшие сроки.
Вот и получилось то, что получилось.
Что правильного и логичного в рандомном выборе что к чему приводить?
Вычитая из строчки число - вы приводим строчку к числу? окей, понятно. Значит, при арифметических операциях строчка приводится к числу, так?
нет, нихуя не так. При сложении наоборот - число приводится к строчке. С хуя ли? А хуй знает. А потом еще строчки слепляются. не складываются - слепляются. Вообще другое действие. нахуй нам не нужное.
Вот где тут логика?
Вопрос риторический, ее нет.
Выбор не рандомный. Он вполне себе конкретный и, по своему, логичный. Да, непривычно что оно само додумывает за тебя, но вообще это дело привычки.
Основная проблема, из-за которой столько непоняток, в том что конкатенация и сложение в языке обозначаются одним символом. Поменять конкатенация на & и 3/4 подобных шуток можно в утиль списывать
по своему, логичный
Я понимаю, что это слово тебе не знакомо, поэтому держи https://ru.wikipedia.org/wiki/%D0%9B%D0%BE%D0%B3%D0%B8%D0%BA...
Когда при схожих операциях выполняются разные действия просто потому, что "иди нахуй, вот почему" - это нихрена не логика.
Когда при этом еще и выполняются операции, которые вообще не запрашивались - это вообще песец.
И на привычку можно много чего свалить, но в итоге тут нет ни логики, ни правильности. А надо тупо выучить как и что.
Если ты не понимаешь почему в одном случае так, а в другом иначе это говорит только об ущербности твоего ума, а не об отсутствии логики.
Некоторым конечно проще вызубрить, чем понять почему.
Я прекрасно понимаю, почему это так.
потому, что тот кто создавал этот язык так написал XD
Только это не наделяет функции "ну так получилось" логикой. Это именно "ну вот так получилось".
но в итоге тут нет ни логики, ни правильности
Можно сколько угодно доказывать что это логично и правильно, только вот это не поменяет того, что когда в таком выражении используются переменные и больше одного оператора, то предсказать результат становится невозможно. И это нихрена не "плюс" или "фича" языка, это наследие того времени, когда ср*ный js предполагался только для анимации снежинок на странице.
...ведь все только и занимаются тем, что вычитают числа из строк, а уж поставить угарный плюс перед числом, которое взято из непонятного источника и может прийти строкой - это так сложно, сильно сложнее явного приведения типов в других языках. Я все правильно продолжил?
Я так понимаю, вы все выражения пишите только с константами, переменными совсем не пользуетесь? Функции не пишите? С сервера данные не запрашиваете? Тогда да - шанс наткнуться на такую ошибку исчезающе мал.
а уж поставить угарный плюс перед числом, которое взято из непонятного источника
Про обработку ошибок, видимо, уточнять даже смысла нет?
Я и не говорил что это правильно. Да, такие вот неочевидные вещи это наследие "сделанного за 10 дней языка". Просто их проявление надо учитывать при написании кода, и можно либо понять логику по которой они будут проявляться, либо тупо заучить (либо не писать на JS).
Специально такое (почти) никто не в код не вставит, а вот когда результат одной библиотечной функции передаётся в другую, то можно только надеяться на адекватность разработчиков этих библиотек.
При выполнении операции пытается сперва привести типы вверх (к более широкому), если операция для него определена. Если нет - пробует вниз. Все, вся логика. Сложение для строк определено - это конкатенация. Оба операнда приводятся к строке и складываются. Вычитание для строк не определено, потому оба операнда приводятся к числу. Все просто и логично.
А ваша логика, как видите, основывается на неверных предположениях. Такой абсурд, бездумно экстраполируя предположения, можно получить из чего угодно.
Представьте себе библиотечную функцию, которая просто проводит некоторые вычисления. Если разработчик библиотеки не предусмотрел отдельную проверку всех переданных аргументов (тот ещё гемор, если функций много), то туда запросто может попасть не то что нужно.
В нормальных языках это решается на уровне синтаксиса и либо компилятор, либо рантайм автоматически проследит за соотвествием типов.
Т.е. один не добавил в свой код приведение типов, второй вызывает этот код с любой херней которая ему попадется - а не нормальным считается js? :)
Да. Задача языка минимизировать количество ошибок, и система типов как раз основной инструмент для этого.
Офигеть, а языки в курсе этой своей задачи? :) Назовите пожалуйста хоть один язык, минимизирующий ошибки (кроме js, естественно) - но именно язык, так чтоб без учета компиляторов/интерпретаторов/сред разработки.
Офигеть, а языки в курсе этой своей задачи?
Внезапно да? Я понимаю, конечно, что после js это сложно представить.
но именно язык, так чтоб без учета компиляторов/интерпретаторов/сред разработки.
Нихрена себе вы загнули - а кто будет проверять что хотя-бы опечаток нет, если исключить "компиляторов/интерпретаторов"? Если брать близкий к js язык - то, например, typescript. Уже одно то, что можно указывать ограничения типов позволяет транслятору проверять корректность вызова функций. А уж если есть поддержка в среде разработки - то там и автодополнение будет корректным (т.е. показывать именно то, что гарантированно доступно в текущем контексте, а не список всего и вся).
И да, если захотите рассказать что "И в js такое возможно", то рассказывайте о чистом js, без сторонних инструментов на связанных с языком, вроде jsdoc, jslint и прочих костылей.
int + string
Как ты предлагаешь джаваскрипту понять что ты хочешь сделать сложить или конкатенировать. Написать парсер мыслей? Другое дело сходство этих операторов, но это отдельный вопрос
Да все логично. В первом случае операция сложения строки и числа не определена, ок, тогда попытаемся привести их к одному типу, первый операнд - это строка, есть ли операция сложения строк? Есть. Можем ли мы второй операнд привести к строке? Можем. Хорошо, тогда приводим второй операнд к строке и выполняем сложение. Второй случай - операция вычитания числа из строки не определена, ок, тогда пытаемся привести их к одному типу, первый операнд строка, но у строк тоже нет операции вычитания, ок, что там со вторым операндом? Число, числа можно вычитать. Можем ли мы привести первый операнд к числу? Можем, ок, тогда приводим к числу и вычитаем. Третий случай, складываем строку с минус строкой, ну сначала выполняется операция отрицания по порядку, а потом сложения. Ок, выполняем отрицание. Стоп, для строк отрицание не определено, а для кого определено? Для чисел, ну тогда приводим к числу и выполняем отрицание. Дальше выполняем сложение строки и числа, опа, опять операция не определена, ну тогда приводим их к одному типу, первый операнд - строка, можем ли мы сложить строки? Да. Можем ли мы второй операнд привести к строке? Да. Ок, тогда приводим второй операнд к строке и складываем их
И что логичного в описанном тобой заученном алгоритме?)
Вопрос риторический) Ничего.
Это весьма костыльный алгоритм без капли логики.
Это простой алгоритм же, если оператор для этих двух типов не определен - то проверяется определен ли он для типа первого операнда и можно ли к нему привести второй, если да - второй приводится к первому типу и выполняется, если же нет - то проверяется то же самое для второго операнда. Все логично вроде.
Если не согласны - то какой более простой и логичный алгоритм Вы бы предложили для неявного приведения типов?
Сколько людей не знакомы с понятием "логика", оказывается)
алгоритм - это не логика, ау.
если я создам алгоритм "Черное = белое", "красное=дерево", "сложить значит умножить", "вычесть значит закончить" - это будет логичным?) Нет, но это будет вполне себе простым алгоритмом.
Я не собираюсь ничего придумывать. Зачем это, какой в этом смысл?
Самое логичное при возникновении ошибки писать "ошибка". Вот, что логично.
А действовать согласно алгоритму написанному просто шоб было - это костыли. И никакой логики.
Это самый логичный алгоритм для неявного приведения типов, он во всех языках используется, где оно есть. Ошибка писать логично если в языке нет неявного приведения типов, а если оно есть - то ошибку писать логично только если нет ни одного способа привести типы переменных к одному и выполнить операцию
"Как я хочу", " как я привык" - это хотелки, а не логика. Чтобы какое-то действие считалось ошибкой - недостаточно, чтобы лично ты считал это ошибкой. Если ты найдёшь официальный документ, применимый ко всем языкам в целом либо к яваскрипту, где чётко формализовано, что вычитание разных типов является ошибкой - тут у тебя будет хоть какая-то аргументация кроме личной хотелки. Если есть аналогичный документ, подтверждающий, что при возникновении "ошибки" такого типа (некритичной с точки зрения джс) обязательно надо писать "ошибка" - это опять же будет хоть какой-то аргумент. Твои хотелки, твои привычки и твоё личное представление о том, что такое ошибка - это не аргументы, и потому к логике они отношения не имеют.
Не, ну можно конечно написать что в "нормальных языках" компиляторы написаны для дебилов которые пытаются из строк числа вычитать и как бы об этом неплохо было бы предупредить т.е. как бы до компиляции таки следует следить за типизацией - в JS за этим тоже нужно следить, либо сразу писать те типы которые ожидаются если код имеет критических момент к этому. Удобно\не удобно ... На заднем сидении "Оки" неудобно сексом заниматься, но если очень хочется ...
В нормальных языках если из строчки будешь вычитать число, компилятор/интерпретатор посмотрит на того, кто это написал, как на дебилаКак на писателя JavaScript же.
Ф нямяних яфихах мюмюмю. В типизированных ты хотел сказать? А на js не гони, посмотрел бы я на тебя как ты на коленке сайтец "по-быстрому" написал на плюсах каких-нибудь, ага
Отсутствие альтернативы не меняет того факта, что многие решения в js как минимум спорные.
На счет типизации - питон не очень-то типизированный, но за строку минус число сделает приложению бросок через бедро.
Ну а на счет сайта на плюсах. бэк энд легко, а фронтэнд только если найдете поддерживающий его браузер :)
Сайт - фронтенд. Веб-приложение - фронт + бек. Я говорил вполне конкретно: проблематично писать фронт, юзая не js.
Вообще языки придумывались конкретно под работу с определенными данными. JS отлично работает с DOM. Есть что-то удобнее, чем JS для работы с DOM? - вот в чём был посыл
в случае с питоном программа просто не выполнится, в случае с JS при ошибке остановится выполнение любых скриптов на странице
Во первых, потому что интерпретируемый, скрипт спокойно запустится и будет работать до возникновения проблем с типами, при этом плюнет исключением, которое неплохо бы обработать. Во вторых, если код вызывающий исключение не будет выполнятся, то он не окажет никакого влияния на остальную функциональность и скрипт может работать годами, пока не стрельнет, а такое поведение не сильно отличается от того же JS. Программа с явными ошибками приведения типов не будет выполнятся только в случае компилируемого языка, потому что исполняемый файл не соберётся, и то не факт.
Есть транспиляция номальных языков в js, есть Blazor, который позволяет пользовательскую логику сайта делать на C#. Ещё жив GWT, который позволяет то же самое на Java.
Это означает "нелегко", а не "невозможно", о чем спорить-то? Что тебе будет легко? Ну ок, кому-то может и будет легко юзать не js(ts) для скриптинга сайта, но явному большинству всё-таки удобнее (проще) юзать js. Ну это так, чисто по статистике, которая врёт и вообще
Это называется слабая и сильная типизация. При этом это не дискретное значение. И вот спорить о том хорошо это или плохо бессмысленно. Есть языки слишком сильно типизированные, в которых строгость может помешать или заставит делать сложные механизмы, которые умещается в одну строку на языке с более слабой типизацией
В нормальных языках если ты блядь будешь писать и выражать месли читай говорить больше используя окончания, предлоги и сказуемое и немного блять мата, то тебя могут послать :)
Да смысл то в этом есть. Можно и велосипед с квадратными колесами использовать в узкоспециализированной задаче, но блин, JS стал единственным стандартом целой индустрии.
Какая индустрия, такой и стандарт. Какие программисты, такие и программы. Какие люди, такое и человечество.
Да я, в принципе, ничего не имею против такого вот угадывания с типами, когда это чисто фронтендный код. Ну что-то не сложилось, отрисую это как получится и хрен с ним, лишь бы не все сломалось сразу.
Но когда фронтенд становится тежелым, с кучей логики на нем, да еще потом на NodeJS делают бекенд - это буквально на том велике с квадратными колесами идут на велогонку, какого черта? Это же тупо.
а потом открываешь код и видишь:
let a:any = 3;
let b:any = 'qqq';
let c: any = [];
.....
c = a + b
Это называется "костыли". В теории я могу и под питон джаваскриптовый интерпретатор найти, но это извращение.
С нетерпением жду когда WebAssembly или еще что такое даст писать на нормальных языках.
Не костыли.
JavaScript на удивление мощный язык, но не особо developer-friendly за счёт некоторых неочевидностей. И раз уж так вышло, что именно этот язык понимают все необходимые устройства, то не обязательно писать на нём, можно использовать его как псевдо-байткоды.
А аналогии с палками и прочей хернёй вообще не к месту, так можно про любой язык сказать. Все они чем-то жертвуют: или читабельностью (C++), или компактностью (Java), или ещё чем-нибудь.
Другие языки жертвуют чем-то ради определенных целей, в итоге достигая их с минимальными потерями.
TypeScript же даёт нормальный удобный интерфейс, но через медленный неуклюжий внутренний механизм. То есть нативная поддержка TS могла бы быть в разы быстрее. Это я и называю знаком, как лечить зубы у проктолога - в целом работает и лучше чем совсем не лечить, но блин...
Потому что ты берешь длиннющую кривую палку, а потом пытаешься ковырять ею в ухе. Это дико неудобно, было бы гораздо удобнее взять короткую палочку, но ты же не ищешь лёгких путей.
Потому что конкатенация работает через плюс. Неужели мало символов на клаве, чтобы сделать конкат отличным от сложения? Отсюда и отличия от минуса или скажем умножения. Поэтому у тебя и не получается складывать строки или сделать конкат чисел, а не потому что ты долпаеп
Все верно, JS считает тебя гением, поэтому не пишет ошибку. В отличии от других, где при попытке так сделать, то тебе скажут: "Исправляй или не билданусь, сукаблять!".
В общем-то это нихрена не логично, и внезапно уже не одну спецификацию js противоречит сам себе.
Я просто оставлю это здесь
На вас уже нервов не хватает. Ну я не спорю, найдутся дауны которые будут такую ахинею писать в реальном коде, а не рофлов ради. А что делать то? Уже не первый год кричат, что джаваскрипт маст дай, да даже не первое десятилетие по моему. Но он - сама неотвратимая реальность. Можете плеваться желчью а можете писать нормальный код. Хуйню можно написать и на Java. И шедевры я встречал на JavaScript.
Проблема то в том, что ты не пишешь в коде такое напрямую. Ты используешь язык, ожидаешь логичности, а потом -1 < Number.MIN_VALUE вдруг true.
А потом ты складываешь две переменных, ожидая что там строчки, и отправляешь это куда-то на бекенд. А вот вдруг у тебя вместо строчек из-за ошибки в другом месте список или еще что, и вот ты какую-то несусветную дичь отправил на бекенд. И никак тебя ничто от этого не защищает. В итоге язык просто побуждает тебя писать как-то слегка работающий говнокод, который ни за что не выдает своих поломок явно.
которые будут такую ахинею писать в реальном кодеДык выпустите новый стандарт, который эту ахинею запретит нафиг.
А что помешает писать на старом стандарте? Или, может быть, запретить это все на уровне браузера, чтобы половина сайтов в сети перестала работать? Стандартов в JS и так хренова туча, уже путаешься в них. Есть и такие, где это запрещено.
Или использовать Typescript с полным покрытием типов, и тогда такие моменты будут опознаваться на этапе написания кода.
Но он же действительно дохнет. Webassembly потихоньку его того... во всяком случае на поприще Web UI. На сервер сайде он write-only. А где ещё?
Главное чтобы не получилось как в том комиксе. У нас есть 999 разных стандартов, хватит это терпеть, нам надо придумать единый универсальный стандарт. Теперь у нас есть 1000 разных стандартов.
Нет, не того. ВАСМ заточен под другие вещи. Он не сможет полностью вытеснить джс из бразуеров.
О человек решил показать свою некомпетентность. Не знает о стандарте IEEE 754 который используется во многих языках. Человек не понимает что функция max как и во всех других языках требует аргументы для вычисления максимум. Даже не смог понять простые правила приведения типов и теперь удивляется. Есть конечно неочевидные моменты в js но в этом видео я вижу только 1 момент, остально просто некомпетентность и нежелание хотя бы первую страницу доков прочитать.
Однако, плохой дизайн языка не нужно оправдывать тем, что все описано в документации. Да, конечно, описано, но это говорит только о хорошей документации, а не о хорошем и предсказуемом языке.
Факт в том приведение крайне просто работает и выбирая язык с динамической типизацией стоит потратить 5 минут времени и узнать как это работает. В видео просто какой то незнание, так и хочется автору скинуть https://0.30000000000000004.com/. Плохой дизайн это скорее про typeof null === object, NaN, неиспользование null в стандартных методах, lastIndex в regexp, и тд, чем про приведение типов которое вполне предсказуемо работает.
Приведение типов — это такой мемчик, надо же над чем-то потешаться. =)
А проблем там действительно гораздо больше. И приведение типов не самое серьезное, хотя и забавное.
1. Этот стандарт разработан для языков со статической типизацией
2. Попытка привести скрестить слона с бегемотом, как бы обречена на провал.
3. Проводить разбор выражения слева направо, на ходу меняя тип операции (пример про суммирование и вычитание строковых и целочисленных) это вообще 5.
1. Уверены? https://0.30000000000000004.com/ ничем не подтвержденные слова.
2. = 1.
3. В любую сторону придется менять тип, вы же понимаете что такое динамическая типизация?
Падажжи, я тебе явно написал, "строковые" с "целочисленными". Куда ты полез?
Вот я о чём:
3 + 1
4
"3" + 1
"31"
a = "3" +1
"31"
a = 0
0
a = "3" +1
"31"
Логика тут крайне простая, если оператор используется для разных типов данных то он выбирает операцию но основе левого типа и все. Вот так просто все работает. Всего надо запомнить 1 строку текста что-бы стал очевидным результат приведения типов.
p.s. Все еще жду пруф про насчет IEEE 754.
Вот так просто все работает.
Почему тогда, после строчки а=0, js перебил тип приёмника? почему выражение справа от = не было приведено к numeric? Именно из-за этой херни весьма простые и логичные действия в js превращаются в поеботу вроде а=x*1+y*1-z*1
Пруф на что? На то что в языках с динамической типизацией нет разницы между [signed|unsigned][int|float]?
На то что в языках с динамической типизацией нет разницы между [signed|unsigned][int|float]?
Блят, наконец-то я это понял спустя три года, как мем увидел. Спасибо тебе, милчеловек.
Учу С++ и тупо не могу с приведением типов справится. :(
единственное предназначение этих приведений типов - это дрочево на собеседовании, больше они ни для чего не нужны
в реальной жизни никогда не понадобится умножать объект на массив
Поясни, почему в случае вычитания из строки он строку приводит в число, а в случае сложения — число в строку?
Ребят, а что за хуйня у вас тут творится? Почему компилятор на это не ругается? Я шарю, просто из деревни с бэка...
Этим мемят только серьезно недалекие какие-то. Пишу уже не 1-ый год на жс, вот ни разу не было проблемы с типами, когда что-то во что-то перевелось и я этого не заметил
Ну-ка разъясни логично, почему {x:2}+" "=='Object object'. а ['x']+" "=='x'? В ссаном JS логикой никогда не пахло, его на коленке делали и там куча документированных ошибок. Например, оператор typeof работает через жопу, null у него объект, а функция внезапно не объект. Что с this происходит лучше вообще не знать.
Глядя на JS так и хочется сказать "fuck this shit", но я не очень уверен на что в данный момент ссылается this.
Я вроде разобрался. Если приводить разные типы объектов ({}, [], Error, Date ) к строке, то там по цепочке прототипов берутся разные методы, отсюда и разный результат. Объект Date в строчном виде- текущая дата. А вот например new Error().toString()=='Error'
Ну то, что в JS куча недоработок изначально, никто не скрывает, и первым об этом всегда рассказывает сам Брендан Эйх.
В последние годы их активно решают, кстати (strict mode, например).
Но это не значит, что это всё надо эксплуатировать. Если в говно палкой не тыкать, оно не воняет. Но здесь весь пост люди размазывают по стенам мирно лежащую в углу кучу говна, и тычут в это пальцем: "Смотрите какое говно!". Да я вижу, блядь, хули ты её на стены-то мажешь, пусть себе лежит в уголке.
Блядь, да не надо переводить типы из хуй знает чего в хуй знает во что, и всё будет хорошо, и внезапно JS уже не так плох. Нормальные разработчики такой хуйнёй не занимаются, и всегда знают, какого типа у них та или иная переменная.
В C++ тоже есть миллион способов выстрелить себе не то что в ногу, а в жопу и голову одновременно, но это не повод называть язык плохим из-за этого. Это повод назвать программиста плохим, если он на такое способен.
Пинки, отъебись, я и так битый час отвечал на каждый комментарий, в том числе и на одинаковые вопросы. Теперь еще ты. Спустя еще час. Когда я уже остыл и голова у меня уже оказалась занята другим.
можете ли посоветовать литературу, которая лично вам интересна, но и будет понятна такому зеленому сопляку, как я?
Неважно, какую тему затронет книга
Потому что вычитание реализовано только для чисел. Поэтому оба операнда нужно преобразовать в числа.
А знак + одновременно реализует и сложение и конкатенацию строк. А само действие определяется по операндам.
И в этом самый большой косяк в js.
В других языках даже со слабой типизацией сложение и конкатенацию вешают на разные операторы, поэтому таких проблем там нет.
А потому что блеать сложение и конкатенация должны обозначаться разными знаками сука. Ненавижу js, сейчас самому приходитмя писать фронт к своему проекту - мразотнее языка я не видел.
Не говоря уже о тонне сборщиков-хуерщиков и просего шлака.
Ну, сборщики сейчас везде, куда не плюнь. В том числе и у бэкэнда, на каком бы языке он не писался. Увы, но таковы новые правила игры, теперь ты уже не отделаешься одним тегом с подключением любимой библиотеки, собирай среду разработки, как взрослый мальчик, и пакуй все в бандл. И это тоже логично, технологии развиваются, библиотек немерянно, фронтэнд уже давно стал едва ли не сложнее и объемнее бэкэнда, а про SPA приложения я уже вообще молчу. Чтобы не сойти с ума от этого всего, придется признать, что webpack - твой друг, даже если в нем черт ногу сломит и нихуя документации внятной нет. И NodeJS - твой друг, хотя ты и не пишешь бэкэнд на дважаскрипте. И Babel твой друг, пиши на любой понравившейся надстройкой над JS, которая превратит его из залупы в идеальный язык со всеми плюшками и строгой типизацией, а он за тебя ее перегонит в es5 для динозавров
Лол, для бека собрал контейнер в докере - все блеать. Ну если пишеш на компилируемом языке - еще и скопмилил.
А на фронте... ты размер папки node_modules видел? Зависимость на каждый чих. Что за код, нахуй он нужен - никто не знает.
Как это все работает - тоже никто не знает.
Фронтенд сейчас - полное неподдерживаемое черноящичное говно.
С которым тебе придется жить. Да и какая разница, сколько весит node_modules? Это чисто служебный код. Да пусть он весит хоть половину гигабайта, кого это будет ебать если на выходе ты все равно получишь статику на килобайта 3-4?
Фронтендера ответ. Я привык знать, как код работает.
Сука, jsники еще пытются себя программистами называть с таким подходом, смешно.
А кто сказал, что я jsник? Я большую часть жизни в бэкэнде ковырялся. Да и вообще, я сертифицированный Java разработчик. Правда в жизни не пригодилось, бывает. Но я не забиваюсь в темный угол и не устраиваю вопли от страха при виде того, чего я не понимаю. Я сижу и изучаю. Быть может однажды дланью господней нам дадут панацею от всех проблем фронтэнда, но до тех пор я буду спокойно работать с тем, что есть, а не тратить нервы на истерики
Ну дык и я работаю. Но если работаешь с говном - можно и помстерить на эту тему, вай нот?
Альтернативы то нет :(
А откуда ей взяться? JS огромен. Невероятно огромен. Чтобы что-то поменять в его спецификации, что-то исправить или что-то добавить собираются целые международные собрания. Надо не просто сделать хорошо, а сделать хорошо так, чтобы все к херам не полетело. Это огромная и сложная экосистема, где любая нечаянно раздавленаня муха может привести к экологической катастрофе. Поэтому мы имеем такое явление, как транспиляторы и препроцессоры. Упаковщики и экслайнты. Чтобы все это держалось вместе и не разваливалось. И конечно, понять как это все работает от и до не суждено уже никому. Остается только сидеть и писать на каком-нибудь логичном и красивом TypeScript, но знать, что на выходе ты все равно получишь большой кусок пережатого и транслированного JS который поймет даже IE9
Ну да, я вот примерно про это :)
Даже ту же пыху можно при желании перевести в байт код и посмотреть как хто работает.
А тут вбстракция над абстракцией, и до нижнего слоя никак не добраться.
А в чем проблема прочекать все зависимости и разобрать все что ты тащишь в проэкт? Ну или не тащить всякое говно за собой, а делать самому ручками это же возможно. И от части вы правы многие тащат не нужные вещи за сабой, но такова цена быстрого мира и геперактивного комьюнити.
А бэк на каком замечательном языке написан?
а в js давно для конкатинации есть:
`${a}${b}`
или способом:
[1, -2, 'q'].join('')
потому что блеать сложение и конкатенация должны обозначаться разными знаками
Не должны. В большинстве языков и для сложения и для конкатенации используется один знак. Другое дело, что, например, Python упадет с ошибкой при попытке сложить число со строкой, а JS попробует срастить ужа с ежом.
Наверняка уже есть python.js который транспилирует код на python в js. =)
И да, фронтэнд — это простая задача, для него и JS пойдет.
Ну ок, законом не запрещено, строки складывать друг с другом можно, так что я приведу тройку к строковому типу и склею их вместе.
А числа нельзя? Почему число в строку преобразуется, а не строка в число?
Потому что строка - первая. Было бы число первым, то привел бы к числу. Кто первый, тот и главнее. Но это только со сложением работает, само собой, потому что складывать можно как строки, так и числа. При вычитании в любом случае JS попытается все превратить в числа, потому что строку из строки никак не вычесть, это бред какой-то. А вот с третьим примером все не так просто. Ведь уроки математики в школе нам говорят, что плюс на минус дает минус, и по идее, JS должен был вычесть два числа. Однако по логике вещей JS сначала вычисляет так называемые унарные операторы. Т.е он сначала сделал число отрицательным, а потом его уже сложил со строкой.
да хуй там плавал)
"5" + 2 = 52
5 + "2" = 52
Главнее тут яваскрипт и ему абсолютно похер на все. И на последовательность действий и на типы. Нету в нем логики, если правила.
Ну ошибся, бывает. Мне хватает мозгов в своей практике такими вещами не пользоваться, так что всех их нюансов я не знаю. Впрочем, логика здесь все равно есть. Хотел бы сложить числа, привел бы к числам. Машина не ошибается. Ошибается человек. Который собирал компьютер, который придумывал язык, который писал программу или который ей пользовался. Но не машина. JS можно много и долго поливать говном, что и я делал в свое время, но от него все равно не убежать. Он повсюду. Буквально. Но он растет и развивается, и может принять любую удобную форму.
Мне хватает мозгов в своей практике такими вещами не пользоваться, так что всех их нюансов я не знаю. Впрочем, логика здесь все равно есть.
Эти два твоих предложения противоречат друг другу) И ты ошибся именно потому, что рассуждал логически, а когда результат опирается на от балды взятое желание чьей-то левой пятки, которое необходимо либо знать либо наванговать - это не логика)
Хотел бы сложить числа, привел бы к числам.
Хотел бы сложить строки, привел бы к строкам?
Хотел бы вычесть числа привел бы к числам?
Ну, по логике))
Да, так я и делаю. Если есть хоть малая вероятность того, что где то я рискую получить строку вместо числа, например в ответе от сервера, я не поленюсь и допишу одну единственную строчку явного приведения, а не полагаться на обсуждаемый функционал, даже если я понимаю как он работает. Никаких противоречий я не говорил.
Ну.... явно. Говоришь такой строке "Ей, строка, ну ка parseInt живо!". И она берет и parseInt.
> parseInt("5", 10) + String ("2");
52
Че говоришь, ты вот прям явно указал число? А мне до пизды) А вот typeof результата вообще undefined, и я вообще не ебу что творю)
IT-юмор
6K постов52.8K подписчик
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору