Кому то что то не понравилось в ваших комментариях настолько, что человек подписался, чтобы минусовать посты. У меня таких 48.
З.Ы. Каюсь, сам подписан на троих с той же целью.
З.З.Ы. Я подписан и на нормальных, адекватных и интересных людей. Таких больше и в жизни и на Пикабу.
Пожалуйста, запилите литературу по JavaScript! Возьмите мои деньги! Вот в таком формате объяснения как у вас, язык становится понятным!
а так как он дрочит на себя то он их возможно нашёл на пикабу
А во вторых, был бы я действительно хорошим программистом, то не сидел бы сейчас без работы
Э нет, не надо так. Как показывает практика, наличие работы - это умение себя продавать, проходить собеседования, нихера не умение работать.
Я искала работу три месяца, думала, что я херовый фронт, раз сижу без работы и зависаю на вопросе "писали ли вы сложные компоненты" (что есть такое сложные компоненты?). Три недели как работаю новую работу, и есть у меня коллега, код которого заставляет меня повесить над столом плакат "обращаясь к древнегреческому богу недоумения, не забудь поднять челюсть". Я делала много всяких допущений, я пыталась понять, что со мной не так, чего-то я не понимаю может быть в этой жизни? Но нет. Сегодня я убедилась в том, что этот человек правда не понимает, зачем у нас в стилях переменные, зачем глобальные классы, зачем настройки компонентам, а если уж смирится с настройками, то почему бы не сделать по настройке для каждого отдельного свойства стилей, а в их названиях не проявить фантазию, для каждого компонента отдельную. Знаешь, в чем соль? В том, что он не заикается на собеседовании, называя себя опытным разработчиком, и не зависает на вопросе "писали ли вы сложные компоненты", потому что для него сложный компонент - это попап, а дропдаун - это сверхсложный компонент. Его не ебет, какие данные к нему придут, откуда и в каком виде. Его не ебет, как делать локализацию и версию для слабовидящих (это ведь потом будет, аж через месяц, это ведь кто-то другой подумать должен (и переписать все его говно)). Он бодро рапортует на созвонах, что все хорошо и к нему нет претензий. У него есть работа, и его пока что называют не только программистом(!!!), но и хорошим(!!!1) программистом (ведь пока все норм выглядит, а "потом" будет потом).
А ты сиди и думай, че с тобой не так. От така хуйня
Бля, я наверно хуевый поддерживатель. Но ты это, не кисни. Умение работать не равно умение искать работу
мне как раз нужен прогер на аутсорс,часто мелкие заказы и доработки нужны)
Безработный программист, который умеет складывать числа и строки в ЖС? Вы реактом владеете? ;)
А вот это неверное предположение, это вам не Java. Вы можете быть великолепным специалистом, но быть без работы или не востребованы как сотрудник по другим причинам, например, какие-то ваши личные качества мешают вам быть эффективным. Или не на своем месте. Может, как верно заметили, вам давно уже пора примерить на себя роль наставника. Ваш кадровый консультант
Это похоже что с какого-то анекдота или фильма
Пересекался с одним директором по работе и у него любимая присказка была: сорок, сорок это рубль сорок
После всех этих повторений слова сорок оно начало мне казаться каким то ебанутым и неправильным, и начинает терять свой смысл в голове, мысли о том почему это слово именно блять сорок и никак иначе вытесняют нормальное восприятие этого слова. Ну пиздец, зачем вы это сделали?
Ну со словом пылесос все нормально, он же пыль сосет все-таки. А вот сорок выбивается из общего ряда "двадцать, тридцать, четыредцать... тьфу, сорок... пятьдесят, шестьдесят..." и так далее
Мне кажется, как минимум один из этих учебников стоит не 9, а '9' баксов. Можно ли вычесть из его стоимости 0 баксов, пожалуйста?
*зануда мод он*
не равно без преобразования типов
'1' != 1 // false
'1' !== 1 // true
*зануда мод офф*
Минуту. Если мы не меняем тип с строки на число, то почему первое - false? Строка не равно число. в чем проблема? Или только второе без преобразования?
в первом случае идет приведение типов и единица-строка равна единице-числу, по этому false (условие проверки "не равно")
символ "=" - значит присвоить значение
символ "==" - значит равно
символ "!==" - просто не равно)
Странно, что в 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"
IT-юмор
5.6K постов52.5K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору