[php][история успеха][закопать]

> Но ты забыл сказать, что те же грабли и в питоне лежат.

Дык ты ж об этом уже сказал, зачем мне повторять:

забавный баг в известной питоновской программе.

Конечно, первым был Lisp; но Фортран-то считается языком низкого уровня по сравнению с питонами и пр. Поэтому фокусы с преобразованием целых в булевы есть признак определенной традиции программирования — ассембли, С, Форт и т.п.

Когда сей признак появляется в языках уровня питона, мне становится неприятно.

Я типа за объективность. Это такой же рудимент низкого уровня, как и «деление с остатком» в исходном посте.

( Да, документированный косяк не перестает быть косяком.)

>Конечно, первым был Lisp; но Фортран-то считается языком низкого уровня

Э... Фортран, всё же, был первым :) И у него было немало детских болезней, которые, думаю, просто не могли сразу предусмотреть при разработке. В конце концов, делали не универсальный язык, а FORmula TRANslator :)

А вот уже посмотрев на него и учтя многие ошибки, в других языках стали делать иначе.

Когда сей признак появляется в языках уровня питона, мне становится неприятно.

Привычка :)

А, тут есть непонимание.

Lisp был первым среди языков высокого уровня, к котороым Фортран-77 по данному признаку как раз ОТНОСИТСЯ: неявное преобразование целого в логический не описано в стандарте, посему считается UB и не рекомендуется.

> Да, документированный косяк не перестает быть косяком.

Тут в треде у большинства отметившихся философия «Быстро поднятое не считается упавшим. Быстро задокументированное не считается багом.»

Когда я пишу в программе на Си тип переменной int я понимаю что получится переменная размером 32 бита со всеми вытекающими ограничениями. Если я буду знать что число может попасться больше 2 ^ 31, то я опишу переменную как long long или в некоторых случаях как unsigned int (число не больше 2 ^ 32 и не отрицательное). В PHP тип переменной явно не указывается и на это никак нельзя повлиять. Я не могу сказать интерпретатору при объявлении переменной, что хочу чтобы она была long long, как и не задаю явно, что она int. Если интерпретатор не поддерживает такое задание типов, то числовые переменные должны быть «безразмерные» и я не должен знать во что она превратиться в памяти компьютера, хоть в int, хоть в long long, хоть в double, а может вообще в массив long long для хранения чисел больше 2 ^ 63. При этом время за которое интерпретатор разберёт арифметическое выражение на порядок больше, чем то, за которое он его вычислит даже если будет использовать для этого длинную арифметику. Поэтому мне наплевать на то, будет ли он использовать самый маленький тип или самый большой и медленный для обработки.

>Ошибки типа something == false вместо something === false в том же PHP косяками ходят.

как у тебя все запущено :)

>Я не могу сказать интерпретатору при объявлении переменной, что хочу чтобы она была long long

Потому что в PHP нет такого типа.

как и не задаю явно, что она int

$x = 1234; // $x тут будет integer
$x = 1234.; // $x тут будет float
$x = «1234»; // $x тут будет string
$x = true; // $x тут будет boolean
$x = 99999999999; // $x тут будет float, эта особенность явно оговорена в документации

Если интерпретатор не поддерживает такое задание типов, то числовые переменные должны быть «безразмерные»

Мнения бывают разные.

>Я не могу сказать интерпретатору при объявлении переменной, что хочу чтобы она была long long

если хочешь длинные числа - можешь явно использовать соответствующий модуль. В чем принципиальная разница?

Вообще, наступить на грабли с 32-битной целочисленной арифметикой на современном железе весьма проблематично.