Это шутка?
раскрыть ветку (3)
раскрыть ветку (2)
Да ладно, принципы-то простые
булева истина приводится к числу как 1, а к строке как "Да"
строка "да" приводится к булеву как истина
ноль приводится к булеву как ложь
операция для знака + определяется по левому операнду
истина+"41" = число(истина) + число("41") = 1 + 41 = 42
"41" + истина = "41" + строка(истина) = "41" + "Да" = "41Да"
-1 + истина и "да" = -1 + число(истина) и "да" = 0 и "да" = булево(0) и булево("да") = Ложь И Истина = Ложь
раскрыть ветку (1)
Блин, знал, что она неявно преобразует типы, но настолько...
Ладно хоть 2*"а333" ошибку выдает.
Сам пользоваться я конечно этим не буду. У меня в голове более жесткая типизация, чем в платформе. )))
Но знать надо. Мало ли за кем код разгребать придется.
раскрыть ветку (5)
стандартная проблема новичка:
КодОшибки = 418;
ОписаниеОшибки = "чайничек кипит";
Сообщить(КодОшибки + ": " + ОписаниеОшибки);
раскрыть ветку (2)
раскрыть ветку (1)
операция "+" перегружена. В данном случае программист ожидает конкатенацию строк, а не сложение. Но компилятор определяет операцию по значению левого операнда и пытается выполнить сложение. Число + строка даст ошибку.
грубо говоря и на примерах
1 + 4 = 5
1 + "4" = 5
"1" + 4 = "14"
"я1" + 4 = "я14"
1 + "я4" = ошибка
в комменте выше я просто привел пример часто встречающейся ошибки при написании.
почему не явно? Все логично, есть строка, ее умножают на два, адинэс\джаваскрипт смотрит что в ней лежит и пытается преобразовать в число, получилось? Умножай, это не запрещено, не получилось - вот тебе эксепшн. Но стоит помнить, что в этих языках, прости господи, "+" -это в первую очередь конкатинация и только потом - сложение.
В принципе логично, но само все это сделано изначально через жопу
раскрыть ветку (1)
раскрыть ветку (1)
Это неявное приведение типов. Динамическую типизацию вполне можно было нормально сделать.
раскрыть ветку (70)
раскрыть ветку (20)
раскрыть ветку (10)
раскрыть ветку (9)
раскрыть ветку (8)
Мы так в 9-м классе писали пробный вариант ГИА (государственной итоговой аттестации, если кто не знает). Писали в своей школе и со своими учителями.
Пишем русский язык, между парт ходит учительница. Замечает, что я подозрительно смотрю себе в кулак. Подходит, отнимает у меня бумажку, а там шпаргалка - "Жи Ши пиши с буквой И" :)
раскрыть ветку (3)
А у меня так приятеля с экзамена отправили. На матане выебнулся, какую-то банальщину написал, типа 2+2=4. А препод его выгнал, мотивировав, что это тоже шпаргалка. С пересдачей не повезло, к принципиальному попал. Хуяк-хуяк - и сам не заметил, как сначала оказался в родной Астрахани, а потом в мотострелках. Сейчас прорабом на стройке трудится.
раскрыть ветку (2)
Потому что надо: у тебя было одно яблоко тебе дали ещё одно яблоко. Потому что в условии Ивана было яблоко, дали ещё одно (не уточнили чего одно). Есть текст яблоко, есть цифра 1. Что получается когда текст яблоко соединяем с цифрой 1? Правильно 1 яблоко.
Похоже мой язык тоже javascript.
раскрыть ветку (6)
Если тебе дали одно яблоко и одно что-то, то у тебя два чего-то. Одно из которых на самом деле является яблоком.
раскрыть ветку (5)
Я тут проверила в ассемблере и питоне. При 1+яблоко тоже даёт результат 1яблоко. Хотя может я неправильно вводу. Прошу проверить знающих задачу на других языках или перепроверить на питоне или ассемблере. Спасибо.
раскрыть ветку (4)
ассемблере и питоне
Странное сочетание.
Про ассемблер можно сказать, что Яблоко+1=аблоко. Это верно для x86 с его add для любых целочисленных типов и для двух однобайтовых кодировок (CP866, CP1251).
GNU Assembler ужасает.
раскрыть ветку (2)
Ассемблер это у бывшего коллеги-инженера. Проверял он. Питоном проверила племянница. Я сидела раздавала указания. Отсюда странное сочетание.
Я всегда знал, что нельзя доверять человеку, который говорит на языке с неявным приведением типов
ещё комментарии
раскрыть ветку (25)
раскрыть ветку (12)
раскрыть ветку (9)
раскрыть ветку (8)
раскрыть ветку (7)
раскрыть ветку (6)
раскрыть ветку (5)
А Википедия так и говорит, кстати:
Это один из наиболее противоречивых терминов в области типизации, так как он не имеет одного общепринятого значения, и разные авторы используют его в разных значениях
Вообще "Строгая" типизация только мутное понятие, поэтому я решил уточнить.
раскрыть ветку (4)
Я подразумеваю под этим то, что:
а) типы писать надо везде (переменные, аргументы, свойства, короче у всего, что переносит изменяемые данные)
б) передача неправильного типа данных вызывает runtime error, хотя строгая типизация вполне себе может избавить от 99% таких ошибок ещё на этапе написания кода
в) "мягкого приведения" нет. То есть, передача int как float должно вызывать ошибку
Кстати говоря, strict_type как раз вполне себе справляется со всеми этими пунктами. Так что, непонятен был сарказм в сторону тайпхинтинга. Если инструмент выполняет свои функции, то хоть папой римским обзови, функционал у него будет именно выполнения строгой типизации.
раскрыть ветку (3)
а) типы писать надо везде (переменные, аргументы, свойства, короче у всего, что переносит изменяемые данные)
Но ведь типы переменный как раз писать не надо. $a может стать переменной любого типа, ну потому что она так и так реализуется z-val. Так что никакого строгости тут нет.
б) передача неправильного типа данных вызывает runtime error, хотя строгая типизация вполне себе может избавить от 99% таких ошибок ещё на этапе написания кода
В языках со статической типизацией такая ошибка происходит не в рантайме, а на стадии компиляции. В чём тут "Строгость"-то? Это просто тайпхитинг, а именно ПРОВЕРКА типа, и работает она в рантайме.
в) "мягкого приведения" нет. То есть, передача int как float должно вызывать ошибку
Только в аргументах, при этом типы так же неочевидно приводятся в теле функции при любом удобном случае.
В общем, ты просто подобрал такие критерии строгости, которые подошли (И то не все) к strict_type=1.
раскрыть ветку (1)
Но ведь типы переменный как раз писать не надо
Да, вот тут лажанул. Но надеюсь и им когда-то типы пропишут.
В языках со статической типизацией такая ошибка происходит не в рантайме, а на стадии компиляции
Мы про строгую типизацию, а не про статическую. PHP не является языком со статической типизацией, тут я не спорю.
В общем, ты просто подобрал такие критерии строгости, которые подошли (И то не все) к strict_type=1
Опиши своё видение тогда.
У тебя какой-то особенный php
в function (int $num) {} можно передать float и он его преобразует в инт. Даже при strict_type
В пхп другая проблема: популярность и низкая стоимость входа дает среднее качество разработчика ниже плинтуса. Еще и обидчивость – почему-то характерная черта большинства пхпшников.
раскрыть ветку (1)
Смотря на что обидчивость. Если ты скажеш, что пхпшники мудаки, мне захочется дать тебе в табло. Но если ты скажеш, что у пыха есть существенные недостатки и перечислиш их, я с тобой соглашусь, частично или полностью.
ещё комментарии
раскрыть ветку (11)
раскрыть ветку (10)
раскрыть ветку (2)
Пожалуйста, назови любой язык из повсеместно применяемых, который был бы хуже js. Даже php с определенной версии исправил достаточно недостатков, чтобы стать лучше.
Ну 1С может быть... но его и повсеместно применяемым языком-то назвать сложно.
Отсутствие нормальной типизации даже с TS. Постоянные попытки неявно скастить всё, что можно, куда угодно. Отсутствие вменяемой работы с арифметикой - integer и double слиты воедино. Игры в многопоточность, по факту остающиеся в одном потоке и тормозящие друг друга. Необходимость просто зазубрить кучу вещей из спеки, потому что реальное поведение не такое, какое было бы очевидным. Какого черта это всё вообще существует в де-факто стандарте индустрии?!
Java - не лучший язык, kotlin и даже C# гораздо лучше. Но просто сравни https://github.com/denysdovhan/wtfjs и ближайший аналог, который я нашел - http://javawtf.blogspot.com/
раскрыть ветку (1)
раскрыть ветку (5)
Про php или про js?
Для начала можно почитать https://habr.com/ru/post/142140/ и https://habr.com/ru/company/ruvds/blog/499670/
раскрыть ветку (4)
раскрыть ветку (3)
раскрыть ветку (2)
хоть я и не разраб, а ваще админ, но и про js тоже прокомментирую: сейчас что на фронте модно, не подскажешь?
раскрыть ветку (1)
++++++++++[>+>+++>+++++++>++++++++++<<<<-]>>++++++++++++.>>++++++++.-----------.++++++++++++++++++++.--------------.+.+++++++++++.<<----------.>>----------.+++++.<<.>>------------.++++++++++++++++.-----------------.++++++++.+++++.--------.+++++++++++++++.------------------.++++++++.<<++++++++++.
ещё комментарии
ещё комментарии
ещё комментарии
!!'false' == !!'true' // -> true
!!'false' === !!'true' // -> true
true - это false, спасибо js!
раскрыть ветку (18)
раскрыть ветку (13)
Надо же пример показать, чтобы непонимающие плюсанули. Получается интерпретация программы интерпретаторами, не имеющими представления о языке.
раскрыть ветку (3)
раскрыть ветку (2)
Человек переводит разные строковые значения в логические, сравнивает между собой и удивляется, что результат совпадает.
При этом в документации написано, что любая непустая строка при переводе в логическое значение даёт true (истина).
При этом в документации написано, что любая непустая строка при переводе в логическое значение даёт true (истина).
раскрыть ветку (1)
Во всех нормальных языках строка не кастуется к boolean. Так что да, дурной именно javascript, потому что позволяет это сделать.
раскрыть ветку (8)
То что для кого-то проблема выучить несколько правил приведения типов не делает язык дурным. В чужой монастырь со своим уставом не ходят
раскрыть ветку (2)
А я таки буду. Дело не в учении дополнительных правил. Дело в том, что компилятор допускает целый класс ошибок, который он мог бы отследить.
Более того, ценой быстродействия. Вместо того, чтобы реализовать несколько примитивных типов с примитивными же правилами у нас есть монстр-инстанс, для каждой переменной, которая умеет всё.
раскрыть ветку (1)
раскрыть ветку (3)
Я могу предположить только проверку на null в условии. Но "if (a != null)" небольшая цена за отсутствие багов.
раскрыть ветку (2)
Мне кажется не один язык программирования не работает столько со строками как джс.
if(a) {console.log(a)} else { console.log(“лошадь в огурцах»)}
И таким не хитрым способом мы:
- Вывели текст если он есть
- обработали вывод если там Пустая строка
- обработало вывод если там undefined
- обработали вывод если там null
И я считаю это прекрасно
раскрыть ветку (1)
Swift:
print(a?.Description() ?? "<лошадь в огурцах>")
C# :
Debug.WriteLine(a?.ToString() ?? "<лошадь в огурцах>")
А если ну очень хочется игнорировать тип - используйте базовый тип как тип параметра функции. Но эта такая редкость, что я могу пересчитать использование такого подхода на пальцах одной руки.
При чём тут true и false? В примере сравниваются строки преобразованные в boolean. Любая непустая строка преобразовывается в true.
ещё комментарии
Да это шутка. Ну ладно, а так?
0 == false // -> true
'' == false // -> true
null == false // -> false
!!null // -> false
раскрыть ветку (2)
0 преобразовывается в boolean, что даёт false.
Про пустую строку уже сказал.
null – это отдельный тип и он не равен ни true ни false.
Но при принудительном приведении результатом будет false.
Про пустую строку уже сказал.
null – это отдельный тип и он не равен ни true ни false.
Но при принудительном приведении результатом будет false.
ещё комментарии
ещё комментарии
раскрыть ветку (10)
ещё комментарии
ещё комментарий
раскрыть ветку (2)
Не, ну это так калькулятор, нарисованный на доске, посчитал, это же программа, врать не будет!
раскрыть ветку (1)
раскрыть ветку (3)
раскрыть ветку (1)
А что ещё делать, языки делятся на два типа, тех которых все хейтят, и тех на которых никто не пишет. Чаще всего хейтят js далее php, но мало хейтят питон, что бы это могло значить...
Вот задумай число, прибавь к нему столько же, раздели на первое задуманное, прибавь пять. Получилось???? Правильно, семь 😃👍
раскрыть ветку (2)
В Винде калькулятор раньше (не знаю как сейчас) мог выдать результат в зависимости от режима работы. Так выражение 2+2:2 в стандартном режиме калькулятора считалось как 2, а вот в научном (или инженерном) - как 3.
раскрыть ветку (2)
Потому что для калькулятора нужно вводить это выражение со скобками, так как он при вводе нового действия автоматически считает предыдущее (то есть когда у тебя введено 2+2, а потом ты вводишь умножение, то калькулятор производит сложение, а потом только умножение). На семерке, кстати, калькулятор в обычном режиме умеет в скобки.
раскрыть ветку (1)
У меня жена также считает, один раз покупали на авито, она сложилу цену двух товаров, получилось больше , чем было и она еще попросила продавца продать за 3500, хотя покупка вышла бы на 3300, как я долго еще ржал над тем , что продавец оказался уродом и не пошел на уступки и не поднял цену по просьбе
раскрыть ветку (1)
слышал, что в америкосии приоритета у умножения нет и действия выполняются в порядке очереди по строке. млжет под них пример. хз, правда или нет
Не-не, я физмат заканчивала: надо наоборот, т.к. умножение не может, по идее, быть меньше, чем сложение. Значит 2*8=28, ну, а 2+8 так и быть 10
раскрыть ветку (3)
$lang = "";
if ( $your_lang == "JS")
{
$lang = "true";
}
else
{
$lang = "false";
}
return $lang;
if ( $your_lang == "JS")
{
$lang = "true";
}
else
{
$lang = "false";
}
return $lang;
раскрыть ветку (4)
https://pastebin.com/BaWjjmK1 - вот кстати код из той же категории :D
И да - это реальный код, из common-библиотеки одного из сборок эмулятора сервера L2 :)
ещё комментарии
