Comments 34
Это не вброс, просто капелька негодования.
Зачем нужны динамические типы, если всё равно надо в уме держать схему их неявных преобразований?! )
Зачем нужны динамические типы, если всё равно надо в уме держать схему их неявных преобразований?! )
UFO just landed and posted this here
Строки, числа и даты.
Неявные преобразования — явное зло и не очень понятен выгоды этого действа над строгой типизацией.
Но, подозреваю, эта тема мучает обе стороны с момента появления нестрогой типизации, так что не думаю что стоит об этом спорить.
Неявные преобразования — явное зло и не очень понятен выгоды этого действа над строгой типизацией.
Но, подозреваю, эта тема мучает обе стороны с момента появления нестрогой типизации, так что не думаю что стоит об этом спорить.
UFO just landed and posted this here
Ну так и не надо сравнивать разнородные сущности. А если сравнивать — то явно указывать правила сравнения, а не полагаться на «подразумевающийся» алгоритм приведения типов… который и приходится держать в уме.
Это не проще. Это — скрывает логику и порождает ошибку )
ЗЫ: Спасибо за презентацию, но я и так это всё уже давно знаю )
Это не проще. Это — скрывает логику и порождает ошибку )
ЗЫ: Спасибо за презентацию, но я и так это всё уже давно знаю )
Нет никакой неявности в преобразовании типов, типы преобразуются по строгим правилам, которые можно выучить за 15 минут с запасом. Как и при перегрузке операторов в C++, правила преобразования определяются типом первого аргумента, поэтому «1» + 1 и 1 + 1 дают разные результаты. Перегрузки операторов в самом JavaScript нет, поэтому выражения с участием объектов бессмысленны, рассматривать стоит только примитивы. Строки всё приводят к строке, остальные типы к своему типу, кроме опратора "+", он приводит к строке даже если строка только второй аргумент, это сделано для удобства. Поздравляю, вы знаете приведение типов в JavaScript.
т.е. это как синтаксический сахар — просто позволяет не писать иногда преобразования примитивов, а просто скрывает их и подразумевает? )
Удобно, но минимально.
Удобно, но минимально.
== это сделано для удобства
Это сделано по глупости и является неиссякаемым источником самых идиотских багов. Удобство — это строго на строго запретить 1 + '1' или кидать на него эксепшен. В абсолютно всех более или менее нормальных языках так и сделано
Это сделано по глупости и является неиссякаемым источником самых идиотских багов. Удобство — это строго на строго запретить 1 + '1' или кидать на него эксепшен. В абсолютно всех более или менее нормальных языках так и сделано
UFO just landed and posted this here
Когда это твой код или маленький фрагмент — возможно.
Если это чужой код и большой фрагмент кода то SomeVar1 + SomeVar2 может выдать… всё что угодно.
И неявные правила — это всегда риски багов. =)
Если это чужой код и большой фрагмент кода то SomeVar1 + SomeVar2 может выдать… всё что угодно.
И неявные правила — это всегда риски багов. =)
UFO just landed and posted this here
Те, которые ты не пишешь руками.
SomeVar1 + SomeVar2Вот пример. Без разбирательства что в переменных и в каком виде храниться даже зная правила неявных преобразований типов сложно гарантировать что получим на выходе.
Без разбирательства что в переменных и в каком виде храниться
… нельзя их складывать. Просто совсем нельзя.
UFO just landed and posted this here
Конечно дело в том кто им пользуется. И большинство тех кто им пользуется — пишут так себе код. Поэтому надеяться на читабельность доставшегося куска кода, адекватность того кто это писал, отсутствие других факторов (надо было костыль для конкретного случая нафигачить) как то… наивно.
В таком случае лучше иметь строгий язык, не позволяющий стрелять себе в ногу и скрывать эту боль до момента, когда не будет поздно ) Да и не так уж и много это требует действий на самом деле.
В таком случае лучше иметь строгий язык, не позволяющий стрелять себе в ногу и скрывать эту боль до момента, когда не будет поздно ) Да и не так уж и много это требует действий на самом деле.
UFO just landed and posted this here
т.е. проверку чёткости работы с типизацией вы хотите решать изменением процесса разработки и найму лишних людей? )
интересный подход.
Но тем не менее, это классический пример скрытой логики, которая может приводить к ошибкам, созданной для удобства. Да, это удобно и да у этого есть некоторые очевидные минусы.
Собственно — это не спор, что лучше, а просто было высказанное мнение ) я знаю за и против.
интересный подход.
Но тем не менее, это классический пример скрытой логики, которая может приводить к ошибкам, созданной для удобства. Да, это удобно и да у этого есть некоторые очевидные минусы.
Собственно — это не спор, что лучше, а просто было высказанное мнение ) я знаю за и против.
UFO just landed and posted this here
Ну, мы говорим не о том, как не писать говнокод, а о том, что неявные преобразования в виде отсутствия строгой типизации могут приносить проблемы. С большей вероятностью, чем их отсутствие.
Более ярко это выражено в проектах с так себе кодом, менее ярко — где код хороший.
Это то небольшое удобство, которое приносит и небольшие риски. =)
Более ярко это выражено в проектах с так себе кодом, менее ярко — где код хороший.
Это то небольшое удобство, которое приносит и небольшие риски. =)
Более ярко это выражено в проектах с так себе кодом, менее ярко — где код хороший.
Неправда ваша.
Ярко выражено — где так себе код, совершенно не является проблемой — где код хороший. Риски околонулевые.
Хотя, честно говоря, я бы предпочёл статическую типизацию с неявными преобразованиями.
Ярко выражено — где так себе код, совершенно не является проблемой — где код хороший. Риски околонулевые.О чём я и писал. Чем лучше код — тем меньше это может вызвать проблем.
Но во-первых — а так ли мало этого не очень кода? (много!)
во-вторых — риски есть риски. и хотелось бы их совсем избежать, особенно когда их привносят просто фишечки порядка «удобно» и «не надо писать лишнее слово». ) Но вот это уже часть ИМХО, конечно, о чём я сразу и сказал.
Всё неявное рано или поздно становится явной проблемой. =) Вам так лень написать одну директиву для преобразования в нужный тип?)
Слушайте, из этих ваших простых правил могут быть и бывают сложные, запутанные и ни разу не очевидные следствия. Во всех языках на такую дичаюшую дичь, как неявное преобразование любого типа в строку в выражении с оператором "+", наложено жесточайшее табу. И только в джаваскрипте это считается фичей. В данном случае следствием этого вашего якобы офигенного удобства написания примитивного кода является то, что программисту приходится выполнять работу компилятора/интерпретатора в нормальных ЯП. Чуть менее тривиальный код, где производятся вычисления с number, зачастую приходится обвешивать тестами и костылями, проверяющими тип входных параметров. Потому если туда внезапно приходит строка, получаем на выходе упс, на который интерпретатору плевать.
== дело не в языке, а в том кто им пользуется
так можно оправдать любой косяк любой технологии — во всём виноваты те, кто пользуется технологией, а сама технология хорошая, она не при чём. Суперджет офигенно удобный самолёт, во всём виноваты пилоты и пассажиры, которые его не правильно используют, ага.
== 'Количество: ' + num — офигенно удобно,
`Количество: ${num}` ещё более офигенно удобно.
== дело не в языке, а в том кто им пользуется
так можно оправдать любой косяк любой технологии — во всём виноваты те, кто пользуется технологией, а сама технология хорошая, она не при чём. Суперджет офигенно удобный самолёт, во всём виноваты пилоты и пассажиры, которые его не правильно используют, ага.
== 'Количество: ' + num — офигенно удобно,
`Количество: ${num}` ещё более офигенно удобно.
Чтобы потом, после прочтения K&R, жизнь этого новичка заиграла новыми, яркими и радостными красками.
После удивленного «а что, так можно было?».
После удивленного «а что, так можно было?».
КОМММЕНТАРИЙ АВТОРА ПОТОМ УДАЛИТЬ: здесь могла быть картинка с эйнштейном: cs11.pikabu.ru/post_img/2019/02/07/6/1549532414127869234.jpg
Забыли удалить?
И конечно, на собеседованиях часто попадается такая задача, чья особенность связана с динамической типизацией:Распространенная ошибка новичка. Именно в этом примере НЕТ приведения типов и динамическая типизация — тоже ни при чем.
console.log(null==undefined);//true console.log(null===undefined);// а вот тут уже false
С приведением типов при сравнении в JS связано большое количество фокусов, всем мы их здесь привести физически не сможем. Рекомендуем обратиться к «Что за черт JavaScript „.
Ужасная статья. Будь я новичком — я бы тоже перестал понимать эти 5 вещей после такой статьи.
Для иллюстрации, представьте, что вам нужно запомнить имена трех новых коллег по работе — совершенно новые имена, и для усиления сравнения, ваши новые коллеги из Индии или Китая с необычными для вас именами. А теперь представьте, что коллег зовут также, как вас, и двух ваших лучших друзей в школе. В какой ситуации вам будет запомнить легче? Здесь память человека и компьютера работает схоже.
Компьютеру легче запомнить имя его школьных друзей? Компьютеру легче запомнить переменные, названные привычными ему обозначениями? Мне кажется новичков он только запутает.
Приведем несколько конкретных примеров
Приводит один пример без верного ответа.
Давным-давно, еще в ES5 все было достаточно просто: было только объявление переменной с помощью var, которое при объявлении в потоке выполнения программы считалось глобальным
WAT? А function scoped объявления тоже не было? На фоне такой жести продвижение let, в отличие от const смотрится как детская шалость.
Стрелочные функции, которые появились в ES6, достаточно быстро завоевали популярность — их очень быстро взяли на вооружение программисты на Node.js и React
Записал эту фразу, скажу ее на следующем собеседовании. Я хочу увидеть их глаза :D
Пример со стрелочными функциями очень странный. Автор объясняет что такое стрелочные функции, но делает это с помощью двух новых концептов — this и биндинга функций
Остальная такая же бредовая — рандомные обрывки сведений в рамках одного пункта. Фиг с ними с "особенностями", но вот события — такая благодатная тема, перескажи в кратце суть, например, вот этого поста.
Так нет же, надо в двух разных абзацах про разные вещи использовать термин "отмена события". "отмена события" у нас теперь и preventDefault и stopPropagation. Пойду создам предложение переименовать оба метода в cancelEvent. А при вызове выбирать рандомно.
И я понимаю, статья подается не как справочник, а как 5 рандомных фактов, но в рамках этих 5 пунктов — можно же объяснить более менее системно, чтобы не закидывать "новичка" кучей не связанных между собой фактов, типа "зубри ска"
Причем виден резкий упор на собеседования, но опять же — новичка прочитавшего вашу статью легко выявить любым смежным вопросом.
tl;dr дорогие новички, бегите из этого центра пока вам ещё есть чем бежать.
Думал, зайду и всё разложат по полочкам. Нет. Объясняется всё так же, как и на любом другом ресурсе.
Нужно придумать чёткую градацию уровня знаний. А то у одних новичок — тот, кто хэлоу ворлд и типы данных знает, а у других — тот, кто недавно познал классы, прототипы, TDD и MVC…
… и чему же? Почему?console.log(obj.x) // и чему же сейчас равен obj.x ?
В отношении контекста стрелочные функции соблюдают следующее правило: они не привязываются к this.Ну, тут по классике. Любой новичок знает, что такое this, bind и зачем их писать.
Нужно придумать чёткую градацию уровня знаний. А то у одних новичок — тот, кто хэлоу ворлд и типы данных знает, а у других — тот, кто недавно познал классы, прототипы, TDD и MVC…
Sign up to leave a comment.
5 вещей, которые чаще всего не понимают новички в JavaScript