раскрыть ветку (23)
В двоичной системе - да. Может быть в JS 1+1 идёт как конкатенации строк поэтому результат 11
раскрыть ветку (19)
раскрыть ветку (4)
Удивительно, но лн прав, просто нужно складывать строку и число и тогда будет знак определяться, как конкатенация . "1"+1
раскрыть ветку (3)
раскрыть ветку (2)
Потому что '1' в данном случае типа char и по таблице ASCII символ '1' соответствует числовому значению 31h в шестнадцатеричной системе счисления или 49 в десятичной, приплюсовав к этому числу 1 мы получим число 32h или 50, что и будет как раз соответствовать символу '2' всё по той же таблице ASCII.
раскрыть ветку (1)
Да это понятно
Хотя кого я обманываю? Невозможно понять тех, кто допустил такое в языке программирования...
раскрыть ветку (13)
А что не так?
Обычнейшее привидение типов и ничего более в нетипизированном языке.
Причём, почему при строке ВСЕГДА Всё остальное приводится к строке тоже абсолютно логично и понятно - повышение отказоустойчивости. Ведь ВСЁ можно сделать строкой. Хоть 1, хоть 2, хоть §, хоть @undefined@45455ObjectType
раскрыть ветку (10)
Это какое-то изврещенное представление об отказоустойчивости.
Отказоустойчивость - это когда всё предсказуемо, однозначно, лаконично и просто. А эти все цыганские фокусы с автоматическим приведением с миллионом разных исходов, лишь бы ошибку не сгенерить - это древнее заблуждение. Нужно правильно обрабатывать ошибки, а не прятать от них голову в песок. Так можно и говна наесться.
раскрыть ветку (9)
. А эти все цыганские фокусы с автоматическим приведением с миллионом разных исходов
Так в том то дело, что это повышает её, ведь исход... предсказуем.
Да и весьма лаконичен и прост.
раскрыть ветку (8)
1 + 1 + '1' = '21'
'1' + 1 + 1 = '111'
- это предсказуемо? Может быть, но лучше бы там была ошибка типов при наличии хорошего сахара для обработки исключений, как в питоне.
раскрыть ветку (7)
Все верно, не понимаю, но почему-то ошибки людям не нравятся. Лучше увидеть ошибку, чем не замечать того, что в прилаге в принципе расчеты неверны, пока не случится инцидент.
раскрыть ветку (4)
Юнит тесты для этого как раз придумали.
Кстати об ошибках, готов?
Вот у тебя простейшая функция: console.log которая служит для вывода информации.
Если ты пихнёшь в неё ЛЮБОЕ ЗНАЧЕНИЕ кроме строки при подходе лишь выдавания ошибок, то получишь ошибку и нужно будет везде писать toString.
И допустим нам надо вывести текст: Объект обработан:/Здесь сам объект/
А вот как это будет в JS (старой версии):
console.log('Объект обработан:'+object)
В современных можно ещё так:
console.log(`Объект обработан:{object}`)
А в Python:
console.log(f'Объект обработан:{object}') даст тебе ошибку, потому что ты не прописал у object магический метод __str__
раскрыть ветку (3)
Не совсем понятно , как юнит тесты здесь помогают. Юнит тесты закроют лишь малую часть возможных проблем. Тестовая среда отличается от реальной и, более того, вы не покрываете в юнитах взаимодействия компонентов. Если где-то на входе вы не обработали типы, вы можете получить катастрофу, про которую вы не узнаете, пока она не произойдет.
Вот о том я и говорю, это как благими намерениями выстилать дорогу в ад.
Вот у тебя простейшая функция: console.log которая служит для вывода информации.
Эта функция служит для вывода отладочной информации.
В Питоне идеально сделано в этом плане. тут явно видно, что будет происходить подстановка и будет приведение объекта к строке. Можно перекрыть метод приведения объекта к строке, а если такого метода нет, то будет ошибка и это правильно, потому что помимо вывода в отладочную консоль есть еще миллион других случаев, когда неожиданное поведение при опечатках или ошибках приведёт к чрезвычайно трудно отлавливаемым багам и опасным проблемам. Ошибку вы заметите сразу, а нечаянную конкатенацию с приведением к строке вместо сложения вы можете не заметить никогда и ваша программа в каких-то редких но важных случаях будет незаметно творить дичь прямо у клиента в браузере, а программисты будут блеять, мол, "а у нас всё работает".
Программисту не так сложно реализовать явно метод __str__ или правильно собрать форматную строку. Экономят на кавычках, скобках и пробелах только профнепригодные имбецилы и школохацкеры, которых ещё жизнь не научила делать качественный код. Некоторых и не научит.
А тут изговнякали язык только чтобы плюсиком можно было любой объект к строке прилепить и чтоб не дай боже ошибка не приключилась. Это типичная "страусиная" политика. Даже страусы так не поступают.
раскрыть ветку (1)
В Питоне идеально сделано в этом плане. тут явно видно, что будет происходить подстановка и будет приведение объекта к строке. Можно перекрыть метод приведения объекта к строке, а если такого метода нет, то будет ошибка и это правильно, потому что помимо вывода в отладочную консоль есть еще миллион других случаев, когда неожиданное поведение при опечатках или ошибках приведёт к чрезвычайно трудно отлавливаемым багам и опасным проблемам.
Да, но нет. Так как базовый объект сам по себе метод привидения к строке... СОДЕРЖИТ. То есть, фактически у нас нарушается наследование на уровне языка.
Эта функция служит для вывода отладочной информации.
Ага, только вот это произойдёт... С ЛЮБОЙ ФУНКЦИЕЙ ВЫВОДЯЩЕЙ ТЕКСТ.
Программисту не так сложно реализовать явно метод __str__ или правильно собрать форматную строку.
Конечно не сложно... на уровне 5 библиотек) Или вы забыли, что Питон это язык, который крайне сильно зависим от библиотек?
При этом опять же, в JS это как раз предсказуемое поведение. Вы точно знаете, что всё может быть приведено к строке и не важно, что это было.
В Python же, если разработчик какой нибудь библиотеки, которую юзает ваш фрэймворк не прописал привидение и оно где то вылезло, то... вы очень долго будете пытаться понять, а в чём ошибка, так как у Питона крайне весёлый вывод ошибок и там будет последовательность вызовов вплоть до какого нибудь __call__.parseExecute.ParseModule, и ни слова об ошибке типов. Потому, что... в какой то части модуля кто то не указал в отлове ошибок нормальный проброс ошибки.
А тут изговнякали язык только чтобы плюсиком можно было любой объект к строке прилепить и чтоб не дай боже ошибка не приключилась.
Так это СЮРПРИЗ делает JS больше ООП, чем Python, потому, что это.... ПОЛИМОРФИЗМ, один из принципов ООП.
1 + 1 + '1' = '21'
'1' + 1 + 1 = '111'
Да, всё предсказуемое.
Последний аргумент строка? Значит и результат строка.
Первый аргумент строка? Значит всё остальное тоже строка.
Понимаешь, в чём проблема? В языке с... НЕСТРОГОЙ ТИПИЗАЦИЕЙ выдавать ошибку ТИПОВ это мезальянс и крайне странное решение.
раскрыть ветку (1)
А кто спорит? Ошибка была именно в том, что язык был изначально с нестрогой типизацией. Неправильно так поступать.
Питон вот строго типизированный язык, хотя приведения типов там доступны и в том числе неявные.
Понять их можно легко, учитывая то, с какими вычислительными средствами им приходилось работать, и какие задачи им приходилось решать.
