PHP vs Python. Холивар (4 стр)

Вообще уже давно наметился забавный тренд - бегство от языков без строгой типизации в сторону строгой типизации.
Причём неважно какая в целевом языке модель структурированных данных - хеши там или меши, ссылочные типы и сборка мусора и так далее. Неважно.
Но внезапно оказалось, что в современном мире лишь небольшие усилия отделяют ЯВУ от JIT-компиляции и просто глупо ей не пользоваться, то вдруг костью в горле встало главным образом отсутствие строгой типизации не позволяющей сгенерить код add eax, ebx там где сейчас CALL variant_add.
Причём изощрения и трюки на которые мысль инженерная идёт, чтобы вычислить сузить типы там где это возможно и нагенерировать 10 вариантов, но свёрнутых циклов под каждый возможный тип в массиве если можно вывести, что в массиве лежит только один и тот же тип подчас просто поражают.

Так или иначе давно уже высвечивается интересная тенденция: делайте любой язык, хоть со сборкой мусора хоть без, но если не будет строгой типизации - значит он тормозное говно об которое потом будут ломаться зубы как с него мигрировать на любой другой язык со строгой типизацией.

P.S.

PHP, кстати, пару робких, но шагов к типизации уже сделал.

Panzerschrek[CN]
Разнесение на микросервисы не даст крутиться в одном потоке кучу незначительного хлама. Функция по запросу - несколько выгоднее одного монструознаго мегакода.

Ну да ладно, мы ж не холиварить тут пришли))

=A=L=X=
> PHP, кстати, пару робких, но шагов к типизации уже сделал.
Ну в жабоскрипте не хватало вменяемого флоата или даббла. Остальное не так существенно.
Собстно, новая редакция ecma решает эту проблему введением префикса флоата перед числом. А больше и не нужно

Состоялся релиз языка программирования PHP 8.0
https://habr.com/ru/news/t/530122/

killbot
> А больше и не нужно

Да не, float-ы вообще редко нужны, особенно в вебе. Не хватает ножом по горлу именно способности писать add eax, ebx вместо call VariantAdd - это две больших разницы и суровый пенальти.
Перцы из гугла какие только хитровымученные оптимизации над ванильным JavaScript не делали чтобы слон вариантов мог в итоге родить мышь оптимального целочисленного в том числе кода.
Но в конечном итоге за счёт полноценной поддержки там мощные переборы десятки вариантов одной и той же функции в разных типах скомилированной - удары многочисленные и по кешам и по почкам.
Поэтому в итоге нормальное решение одно и только одно: сделать типизированный язык где будут и инты и флоаты, а варианты только как слабо используемая опция.

И сейчас вроде как два нормальных решения: мощное декорирование обычного ява скрипта где конструкции вида a = (b + 1) | 0; помогают компилятору понять, что в a после logical or может хранится только int или вообще отказ от яваскрипта в пользу asm.js.
Давно уже этим муки творчества наблюдаю и смеюсь - ушли когда то от Java распевая "Осанна! Пластиковый мир скриптов победил!" чтобы в итоге прийти к чему то подобному же.

=A=L=X=
> Да не, float-ы вообще редко нужны, особенно в вебе
Ну учитывая количество всяких опенгл-проектов - иногда точные вычисления полезны. Особенно учитывая классически проблемы типа 0.1 + 0.2  ))

Почему я не люблю PHP
https://habr.com/ru/post/530322/

P.S. Статьи нет, но комментарии не бесполезны. :)

KPG
> P.S. Статьи нет

Автор хотя бы обозначил о какой именно проблеме идёт речь.
Пришлось загуглить и видимо речь про это: https://www.opennet.ru/opennews/art.shtml?num=33765
Обсёр для безопасности конечно эпический - получать доступ к исходному коду любого публичного скрипта - это конечно дырень в безопасности размером больше той жопы в которой она зияет.
Забавно, - проверил версию PHP на работе и сердце ёкнуло - оно! Но попытки воспроизвести дырки успехом не увенчались. Но посмотрев в phpinfo понял, что не сработало потому что используется mod_php.

Хорошо, что уже 8.0 вышло и 5.3 юзать уже считается неприличным

killbot
> и 5.3 юзать уже считается неприличным

У нас именно 5.3 как раз из-за обозначенной проблемы - поломанной обратной совместимостью. Причём поломана она была критически при переходе с 5.x на 6.x, а что еще окажется поломанным при переходе на 8.x даже думать не хочется.

=A=L=X=
> при переходе с 5.x на 6.x
Версии 6 не было же, 5 и сразу 7.

entryway
> Версии 6 не было же, 5 и сразу 7.

Значит даже проблема была при переходе с 5.3 на 5.6. Потому что цифра 6 плотно застряла в памяти как "говнище придумали". У них то ли стало обязательно писать & при передаче параметра по ссылке, то ли наоборот они запретили писать & при передаче параметра по ссылке и говно было в том, что чтобы отловить все косяки с этим связанные нужно было прогнать все возможные ветки кода в сайте чтобы убедиться, что нигде в рабочем билде не выскочит. Ну или по всему коду искать &. В общем махнули рукой и попросили хостера даунгрейд сделать до 5.3, ибо в той версии линуксов уже не было php 5.3 в штатных репозитариях. В итоге там какой то костыль стоит на распорке чтобы последующие apt-get его не снесли апдейтами.

=A=L=X=
> то ли наоборот они запретили писать & при передаче параметра по ссылке
https://www.php.net/manual/ru/migration54.incompatible.php

По ссылке или не по ссылке указывается только в сигнатуре, да.

entryway
> По ссылке или не по ссылке указывается только в сигнатуре, да.

О да, точно, вспомнил.
Засада полная.
Почему - тоже полностью вспомнил.
Потому что если с этим переходом найти везде знаки & в вызовах функций, убрать их и в самих функциях в параметре поставить &, то нет никаких гарантий что ты не поломаешь код который где то в другом месте вызывал функцию без & надеясь как раз на передачу параметра по значению. И ничто тебе не сможет на это указать кроме того что у сайта что-то где-то стало глючить.
Всё, пипец, приплыли. Абсолютный слом без возможности восстановления и возможности просто взять и поправить код и быть уверенным, что он не поломался.
Такое исправление просто обрекло более-менее сложные проекты застопорится на 5.3 и перестать развиваться в версии.

Можно бесконечно долго наблюдать за тремя вещами: Как течет вода, как горит огонь и как в интернете рассуждают о том, почему строгая типизация луДше