Здравствуйте, netch80, Вы писали:

V>>>>>>А так-то сам по себе PHP очень даже неплох, местами на голову выше Питона, разумеется.
N>>>Начни с обоснования этого тезиса, безаргументный ты наш...
V>>- Меньше неявных соглашений.
N>Безаргументно.

Нет, это важный аргумент. Один из самых важных.
В Питоне до черта неявных соглашений:
— по синтаксису;
— по правилам именования идентификаторов;
— по огромному количеству "системных" ф-ий и методов, полный список которых перевешивает вдвое запас ключевых слов многих сравнимых по функциональности языков.
А есть же еще и ключевые слова сверху. ))


N>С учётом следующего пункта — их больше.

Не видел раскрытия мысли.


V>>- Возможность строгой типизации.
N>Ага-ага. "Возможность".

Ты не понял.
В сигнатурах методов прямо указываются типы, как аргументов, так и возвращаемого значения.
Не "аннотации", которе выглядят поздно-введёным в язык костылём, а прямо такой синтаксис языка изначально.


N>И как давно убрали автоконверсии между строками и числами?

Такой неявной конверсии в обе стороны нет. Есть только нявное приведение к string любого типа, когда такое приведение требуется согласно сигнатуре метода, типу переменнной или аргумента.
Это всё.
Конкретно числа тут не при чём, это общее правило для любых типов.
Точно так же как в дотнете WriteLine(object) вызывает у того метод ToString().


N>В Питоне этого дерьма не было изначально.

Да ладно?
А как же print работает? ))


V>>- Поддержка абстрактных классов и интерфейсов. Для абстрактного класса можно задать сигнатуру конструктора.
N>Есть абстрактные классы.

Э, нет.
В Питоне абстрактных классов НЕТ.
Под тем же самым термином в Питоне понимается нечто другое, чем, скажем, в Java/Delphi/C#/C++/D/Go/Rust/Swift/Dart/ и т.д. до бесконечности.


V>>- Абстрактный итератор в языке, возможность описания собственных/произвольных итераторов (не путать с генераторами).
N>Зачем нужен?

Затем же, зачем и в дотнете.
Просто еще одна удобная фишка в языке из многих десятков их.
Ведь не всегда удобно реализовать логику на yield, когда, скажем, необходимо передать экземпляр итератора "куда-то еще" для продолжения итерирования.


V>>- "чистая" реализация генераторов в виде корутин, что этот механизм применяется напрямую как для итерации, так и для задач, где в C# или Питоне 3.6 используют костыли async/await.
N>Корутины есть отдельно. И чем именно async — костыли?

Потому что yiled не справился при абсолютно идентичной семантике stateless coroutines.


V>>- Абстрактный функциональный тип в языке, возможность описания произвольных своих функторов.
N>Функторы есть.

Это ж не функторы и ы прекрасно об этом знаешь.
Это эмуляция функторов на методах, с потерей взаимозаменяемости в произвольном контексте со встроенным функциональным типом.
Т.е., функторы должны быть неотличимы от функционального типа, как функторы в C++ на основе типов с определённым operator()(), подаваемым в шаблоны, ожидающие ф-ии.


N>Абстрактный функциональный тип в языке — в стандартной библиотеке есть достаточно близкое.

В самом языке есть lambda и def, но получаемые с их помощью функциональные типы не абстрактные, а всегда конкретные типы конкретных созданных экземпляров.
Абстрактный же функциональный тип задан своей сигнатурой и позволяет производить автоматическую селекцию при выборе перегрузок в compile или run time.
Такой функциональности в Питоне нет.


V>>- Декомпозиция элементов языка (можно property описать как объект-шаблон).
N>Зачем нужно?

Для дешевого порождения сложного property view.

Например, в том же дотнете есть TreeView, сам этот объект имеет коллекцию/св-во Nodes типа TreeNodeCollection и каждый Node имеет такое же точно св-во Nodes.
Но в реальности этой отдельной коллекции нет, бо ноды хранятся системным объектом, это лишь публичный View над внутренней коллекцией.
Так вот, засада дотнета в том, что пришлось описывать тип TreeNodeCollection и хранить переменную этого типа в TreeView и в TreeNode, чтобы синтаксически это выглядело как-то так:

nodeA.Nodes.Add(nodeB);

Т.е., на каждое такое св-во надо хранить лишнюю переменную.
И само такое св-во должно хранить переменную своего владельца.
Сие очевидная глупость, коль в момент обращения к св-ву на руках уже есть и тот и другой. ))

В общем, в PHP не надо хранить лишнюю переменную для такого view и в самом view не надо хранить ссылку на владельца.


V>>- Более последовательная и удобная работа с метаинформацией.
N>Бездоказательно.

Если ты действительно готов в это погрузиться, то можно.
Но если ты достаточно знаешь Питон, то и сам в курсе.


V>>- Явное наличие неймспейсов, операторы области видимости '::'.
N>Делается на импортах проще и удобнее.

А колокольчик насчёт константности и статических мемберов тут не прозвенел? ))
Оно не проще и не удобней. Оно делается через разыменование доп. переменной-словаря в текущем контексте и поиска нужной ф-ии или переменной внутри неё.
В то время как в PHP идёт непосредственное обращение к ф-ии или переменной, без лишнего уровня косвенности.
Ну и, перечислять все импортируемые ф-ии и переменные порой устанет рука.
Проще один раз импортировать неймспейс.


V>>- Строгие замыкания, возможность управления замыканием по имени или по-значению, а так же "уровнем" захвата переменной (вот эта вечная боль в JS — когда же надо создавать промежуточную переменную для вложенной иерархии анонимных ф-ий, а когда нет, вся эта боль решается, при надобности, явным use в PHP и указанием типа индирекции).
N>Что такое "строгие" замыкания и чем они лучше обычных питоновых?

Строгие замыкания позволяют описывать — как именно замыкается контекст.

В Питоне, как и в JS, не зная тонкостей и не споткнувшись десяток раз, изначально не понятно, как именно захватывается переменная — по значению (например, по ссылочному значению захватываемой переменной, как захват this-функции в JS или enclosing context в Питоне) или по ссылке на неё (для ссылочной переменной будет ссылка на ссылку, как захват остальных переменных в JS). Этот момент — постоянный источник багов в JS и Питоне, которые (баги) регулярно допускают даже опытные программисты.


V>>- Анонимные классы.
N>Зачем?

Примерно затем же, зачем и в джаве — по месту переопределить пару методов без полноценного объявления класса.
Особенно хорошо это смотрится прямо во время вызова new, как и в джаве, собсно.


V>>- Карринг и частичное применение в явном виде.
N>functools.

Увы.
Ошибка карринга или частичного применения, совершённая в момент самого частичного применения, вылезет не в момент совершения ошибки, а где-то далеко после, в момент вызова порождённой ф-ии. Посему и считается не очень хорошим тоном злоупотребление partial.


V>>- Набор аргументов ф-ий можно рассматривать как один именованный тупл, т.е. оперировать им как единой сущностью (привет теориям типов).
N>В Питоне из коробки, но зачем?

Нет там ничего из коробки.
Тупл — это рекорд, тип данных, состоящий из именованных типизированных полей.
А в Питоне аргументы — это просто нетипизированный безымянный список, плюс словарь для именованных аргументов.
Никакую полезную информацию из этого не извлечь, поэтому да, незачем.


V>>- Миксины, трейты, явное управление конфликтами:
N>Всё есть.

Трейтов нет. Как всегда, под трейтами в Питоне понимается нечто, что трейтами не является, т.е. это название некоей прикладной библиотеки.
Миксинов нет. Есть множественное наследование и отсутствие ср-в разрешения конфликтов. Опять и снова, термин был взят неверно.

Это примерно того же уровня злоупотребления терминологией, как одно время было модно всё-что-угодно называть "монадами".
Типа, это придавало вес остальным рассуждениям автора. А на деле, в глазах грамотных коллег не придавало ни разу, бо ровно наоборот, сей незамысловат трюк бросается в глаза, т.е. опускает его автора до уровня клоуна, хотя бы автору и казалось обратное. ))


V>>- Туда же ключевое слово final;
N>final делается при необходимости, но ни разу не потребовался.

А как он делается, если не секрет?
А главное, зачем, если любой объект можно легко поломать "на лету", записав что угодно в его системные или публичные кишки?


V>>- Управление уровнем ссылочности, разыменование ссылок.
V>>- Т.е. фактически прямой выход скриптового исходника на возможность его "честной" компиляции в нейтив, в отличие от полукомпиляции в проекте CPython и других уже умерших проектах-экспериментах.
N>CPython живее всех живых. О чём конкретно речь?

О принципиальной невозможности компиляции в нейтив.
Только интерпретация, только динамика.

Предварительная конверсия в "байт-код" ничего, по-сути, не меняет.
Это делал еще Лисп хрен знает когда. ))
Зато Схему уже компилировали в чистый нейтив.
А всего-то наложили несколько ограничений на Лисп.


V>>- Легкое расширение языка, см. модули паттерн-матчинга, модуля-аналога LINQ, модуль PHP-COM, модуль PHP-.Net, обертки над нейтивом и т.д.
V>>- Наличие позднего статического связывания позволяет разрабатывать абсолютно-достоверную диагностику для кода, т.е. не нужны никакие среды-утилиты, это всё можно делать через встроенные ср-ва языка.
N>Пример?

Например, у gdb есть модули для отладки Питона.
Потому что в Питоне не просто узнать, кто тебя вызвал.
В PHP — просто.

V>>Про синтаксису Питона не проходился только ленивый, это объект нескончаемого флейма.
N>Сплошное хейтерство ((c) vdimas) от неосиляторов отступов.

В отличие от, я ни разу на эту тему не высказывался, по крайней мере на этом сайте.
Всё что я об этом думаю, я высказал еще в 96-м году, а последний раз достаточно резко в 2001-м.
С тех пор зарёкся, бо уже тогда началось вот это "ми-ми-ми" из разряда "мой любимый Питончик". Тьфу, гейство! ))

Там же дело не только в отступах.
Непоследовательность синтаксиса Питона резала глаза с самого начала.
Просто человек, он же такая свинья — ко всему привыкает.
Но уже тогда Питон привлёк к себе наших тестеров и они на ём сделали тестовый фреймворк.
Я был в ужасе, но ни на чём другом они бы сделать его не смогли бы.
А если бы могли — они работали бы не тестерами, а боевыми разработчиками за втрое большую ЗП.
Вот так я навсегда смирился с новым BASIC-ом в индустрии


V>>Напротив, синтаксис PHP никакого флейма не вызывает, там всё чисто изначально.
N>Агащазз.

Тем не менее.
Споры вокруг PHP ведутся в основном в плане разнобоя name conventions, но это не синтаксис ни разу.


V>>Я не перечислял равные возможности, навроде генераторов yield и т.д., так шта, просьба не пытаться отвечать "а вот у Питона зато есть то-то и то-то" не проверив сначала, в каком виде "оно же" есть в PHP.
N>Так ты объясни, что именно в конкретных реализациях тебе так больше нравится, потому что угадать твои предпочтения невозможно, а к практике они обычно ортогональны.

Я просто показывал, что PHP по своим св-вам более мощный и последовательный язык, чем Питон.

Питон — он ведь как JS по своему устройству, вид сбоку.
Каждый пользовательский объект в нём — просто объект-словарик.
Чем отличается конкретно Питон от вовсе незамысловатого JS? — что в его "словариках" потенциально содержится куча __специальных_значений__, которые простейший парсер/интерпретатор Питона пытается натягивать на исходник, что заметно замедляет даже сам парсинг, в сравнении с тем же JS.

И что "помойкой" язык делают не его св-ва, а его экосистема.
Так вот, происходящее с Питоном последние лет 10 лично мне видится как де жа вю.

Ну и, очевидно, что PHP и Питон — они из разных весовых категорий.
Питон из категории средневесов, типа JS.
PHP — это тяжеловес, типа Смолтолка или Перла.
А если объективно, по кач-вам дизайна языка и реализации внутренней механики PHP на пару весовых категорий повыше Смолтолка будет.
Просто под PHP никогда не было написано такой замечательной среды разработки, которая однажды была написана для Смолтолка.

И тот факт, что практически весь современный веб живёт на PHP — он ведь тоже говорит сам за себя, верно?
Не смотря на все "ми-ми-ми" в сторону Питона. ))


N>Задачи, где требуется суперскорость собственного кода, я на Питоне и не рассматриваю. Но таких 1-5%.

В точку. потому что разные подходы.

Если Питон ускоряют через обертки над нейтивными либами, то в PHP ускоряют именно евойный код.
Причём, для веба получается быстрее, чем даже в случае С/С++.
Там на обработку запроса выделяется grow-only аллокатор из пула, в конце запроса просто курсор аллокатора в начало сбрасывается и всех делов.
Т.е. затраты на выделение и освобождение памяти близки к абсолютному 0-лю.
И в случае полной типизации простые тулзы генерят честный С-код из PHP, получая затем нейтивный-оптимизированный.
Т.е. весь матан можно колбасить прямо в PHP — будет в наилучшем виде на выходе.


N>Что простой — согласен. Потому что в разы более логичный.

Я не вижу "логичности".
Я вижу простую модель отображения некоторых элементов синтаксиса/операторов на т.н. "специальные имена".
На этом логичность исчерпывается.
Простой язык ведь не обязан иметь простое внутреннее устройство, не?
А в случае с Питоном это именно так, отсюда все побочные эффекты и ограничения и, прямо скажем, видимый еще из 96-го года "потолок" развития.


V>>Сравнивать с ним убогие JS или Python можно лишь от упёртой агнажированности, т.е. поправ всякую объективность.
N>Сказал самый упёртый в этом треде.

Я тут вообще над схваткой. ))
К Питону и PHP питаю одинаковые чувства, мне тут банально не понравились тонны неправды про Питон, поэтому встрял.
Слишком много успели вылить эмоционального и слишком много сугубо оценочных суждений.
Я лишь пытаюсь уравновесить всю эту необъективность техническими деталями.

Здравствуйте, netch80, Вы писали:

V>>>>>>А так-то сам по себе PHP очень даже неплох, местами на голову выше Питона, разумеется.
N>>>Начни с обоснования этого тезиса, безаргументный ты наш...
V>>- Меньше неявных соглашений.
N>Безаргументно.

Нет, это важный аргумент. Один из самых важных.
В Питоне до черта неявных соглашений:
— по синтаксису;
— по правилам именования идентификаторов;
— по огромному количеству "системных" ф-ий и методов, полный список которых перевешивает вдвое запас ключевых слов многих сравнимых по функциональности языков.
А есть же еще и ключевые слова сверху. ))


N>С учётом следующего пункта — их больше.

Не увидел раскрытия мысли.


V>>- Возможность строгой типизации.
N>Ага-ага. "Возможность".

Ты не понял.
В сигнатурах методов прямо указываются типы, как аргументов, так и возвращаемого значения.
Не "аннотации", которе выглядят поздно-введёным в язык костылём, а прямо такой синтаксис языка изначально.


N>И как давно убрали автоконверсии между строками и числами?

Такой неявной конверсии в обе стороны нет. Есть только нявное приведение к string любого типа, когда такое приведение требуется согласно сигнатуре метода, типу переменнной или аргумента.
Это всё.
Конкретно числа тут не при чём, это общее правило для любых типов.
Точно так же как в дотнете WriteLine(object) вызывает у того метод ToString().


N>В Питоне этого дерьма не было изначально.

Да ладно?
А как же print работает? ))


V>>- Поддержка абстрактных классов и интерфейсов. Для абстрактного класса можно задать сигнатуру конструктора.
N>Есть абстрактные классы.

Э, нет.
В Питоне абстрактных классов НЕТ.
Под тем же самым термином в Питоне понимается нечто другое, чем, скажем, в Java/Delphi/C#/C++/D/Go/Rust/Swift/Dart/ и т.д. до бесконечности.


V>>- Абстрактный итератор в языке, возможность описания собственных/произвольных итераторов (не путать с генераторами).
N>Зачем нужен?

Затем же, зачем и в дотнете.
Просто еще одна удобная фишка в языке из многих десятков их.
Ведь не всегда удобно реализовать логику на yield, когда, скажем, необходимо передать экземпляр итератора "куда-то еще" для продолжения итерирования.


V>>- "чистая" реализация генераторов в виде корутин, что этот механизм применяется напрямую как для итерации, так и для задач, где в C# или Питоне 3.6 используют костыли async/await.
N>Корутины есть отдельно. И чем именно async — костыли?

Потому что yiled не справился при абсолютно идентичной семантике stateless coroutines.


V>>- Абстрактный функциональный тип в языке, возможность описания произвольных своих функторов.
N>Функторы есть.

Это ж не функторы и ы прекрасно об этом знаешь.
Это эмуляция функторов на методах, с потерей взаимозаменяемости в произвольном контексте со встроенным функциональным типом.
Т.е., функторы должны быть неотличимы от функционального типа, как функторы в C++ на основе типов с определённым operator()(), подаваемым в шаблоны, ожидающие ф-ии.


N>Абстрактный функциональный тип в языке — в стандартной библиотеке есть достаточно близкое.

В самом языке есть lambda и def, но получаемые с их помощью функциональные типы не абстрактные, а всегда конкретные типы конкретных созданных экземпляров.
Абстрактный же функциональный тип задан своей сигнатурой и позволяет производить автоматическую селекцию при выборе перегрузок в compile или run time.
Такой функциональности в Питоне нет.


V>>- Декомпозиция элементов языка (можно property описать как объект-шаблон).
N>Зачем нужно?

Для дешевого порождения сложного property view.

Например, в том же дотнете есть TreeView, сам этот объект имеет коллекцию/св-во Nodes типа TreeNodeCollection и каждый Node имеет такое же точно св-во Nodes.
Но в реальности этой отдельной коллекции нет, бо ноды хранятся системным объектом, это лишь публичный View над внутренней коллекцией.
Так вот, засада дотнета в том, что пришлось описывать тип TreeNodeCollection и хранить переменную этого типа в TreeView и в TreeNode, чтобы синтаксически это выглядело как-то так:

nodeA.Nodes.Add(nodeB);

Т.е., на каждое такое св-во надо хранить лишнюю переменную.
И само такое св-во должно хранить переменную своего владельца.
Сие очевидная глупость, коль в момент обращения к св-ву на руках уже есть и тот и другой. ))

В общем, в PHP не надо хранить лишнюю переменную для такого view и в самом view не надо хранить ссылку на владельца.


V>>- Более последовательная и удобная работа с метаинформацией.
N>Бездоказательно.

Если ты действительно готов в это погрузиться, то можно.
Но если ты достаточно знаешь Питон, то и сам в курсе.


V>>- Явное наличие неймспейсов, операторы области видимости '::'.
N>Делается на импортах проще и удобнее.

А колокольчик насчёт константности и статических мемберов тут не прозвенел? ))
Оно не проще и не удобней. Оно делается через разыменование доп. переменной-словаря в текущем контексте и поиска нужной ф-ии или переменной внутри неё.
В то время как в PHP идёт непосредственное обращение к ф-ии или переменной, без лишнего уровня косвенности.
Ну и, перечислять все импортируемые ф-ии и переменные порой устанет рука.
Проще один раз импортировать неймспейс.


V>>- Строгие замыкания, возможность управления замыканием по имени или по-значению, а так же "уровнем" захвата переменной (вот эта вечная боль в JS — когда же надо создавать промежуточную переменную для вложенной иерархии анонимных ф-ий, а когда нет, вся эта боль решается, при надобности, явным use в PHP и указанием типа индирекции).
N>Что такое "строгие" замыкания и чем они лучше обычных питоновых?

Строгие замыкания позволяют описывать — как именно замыкается контекст.

В Питоне, как и в JS, не зная тонкостей и не споткнувшись десяток раз, изначально не понятно, как именно захватывается переменная — по значению (например, по ссылочному значению захватываемой переменной, как захват this-функции в JS или enclosing context в Питоне) или по ссылке на неё (для ссылочной переменной будет ссылка на ссылку, как захват остальных переменных в JS). Этот момент — постоянный источник багов в JS и Питоне, которые (баги) регулярно допускают даже опытные программисты.


V>>- Анонимные классы.
N>Зачем?

Примерно затем же, зачем и в джаве — по месту переопределить пару методов без полноценного объявления класса.
Особенно хорошо это смотрится прямо во время вызова new, как и в джаве, собсно.


V>>- Карринг и частичное применение в явном виде.
N>functools.

Увы.
Ошибка карринга или частичного применения, совершённая в момент самого частичного применения, вылезет не в момент совершения ошибки, а где-то далеко после, в момент вызова порождённой ф-ии. Посему и считается не очень хорошим тоном злоупотребление partial.


V>>- Набор аргументов ф-ий можно рассматривать как один именованный тупл, т.е. оперировать им как единой сущностью (привет теориям типов).
N>В Питоне из коробки, но зачем?

Нет там ничего из коробки.
Тупл — это рекорд, тип данных, состоящий из именованных типизированных полей.
А в Питоне аргументы — это просто нетипизированный безымянный список, плюс словарь для именованных аргументов.
Никакую полезную информацию из этого не извлечь, поэтому да, незачем.


V>>- Миксины, трейты, явное управление конфликтами:
N>Всё есть.

Трейтов нет. Как всегда, под трейтами в Питоне понимается нечто, что трейтами не является, т.е. это название некоей прикладной библиотеки.
Миксинов нет. Есть множественное наследование и отсутствие ср-в разрешения конфликтов. Опять и снова, термин был взят неверно.

Это примерно того же уровня злоупотребления терминологией, как одно время было модно всё-что-угодно называть "монадами".
Типа, это придавало вес остальным рассуждениям автора. А на деле, в глазах грамотных коллег не придавало ни разу, бо ровно наоборот, сей незамысловат трюк бросается в глаза, т.е. опускает его автора до уровня клоуна, хотя бы автору и казалось обратное. ))


V>>- Туда же ключевое слово final;
N>final делается при необходимости, но ни разу не потребовался.

А как он делается, если не секрет?
А главное, зачем, если любой объект можно легко поломать "на лету", записав что угодно в его системные или публичные кишки?


V>>- Управление уровнем ссылочности, разыменование ссылок.
V>>- Т.е. фактически прямой выход скриптового исходника на возможность его "честной" компиляции в нейтив, в отличие от полукомпиляции в проекте CPython и других уже умерших проектах-экспериментах.
N>CPython живее всех живых. О чём конкретно речь?

О принципиальной невозможности компиляции в нейтив.
Только интерпретация, только динамика.

Предварительная конверсия в "байт-код" ничего, по-сути, не меняет.
Это делал еще Лисп хрен знает когда. ))
Зато Схему уже компилировали в чистый нейтив.
А всего-то наложили несколько ограничений на Лисп.


V>>- Легкое расширение языка, см. модули паттерн-матчинга, модуля-аналога LINQ, модуль PHP-COM, модуль PHP-.Net, обертки над нейтивом и т.д.
V>>- Наличие позднего статического связывания позволяет разрабатывать абсолютно-достоверную диагностику для кода, т.е. не нужны никакие среды-утилиты, это всё можно делать через встроенные ср-ва языка.
N>Пример?

Например, у gdb есть модули для отладки Питона.
Потому что в Питоне не просто узнать, кто тебя вызвал.
В PHP — просто.

V>>Про синтаксису Питона не проходился только ленивый, это объект нескончаемого флейма.
N>Сплошное хейтерство ((c) vdimas) от неосиляторов отступов.

В отличие от, я ни разу на эту тему не высказывался, по крайней мере на этом сайте.
Всё что я об этом думаю, я высказал еще в 96-м году, а последний раз достаточно резко в 2001-м.
С тех пор зарёкся, бо уже тогда началось вот это "ми-ми-ми" из разряда "мой любимый Питончик". Тьфу, гейство! ))

Там же дело не только в отступах.
Непоследовательность синтаксиса Питона резала глаза с самого начала.
Просто человек, он же такая свинья — ко всему привыкает.
Но уже тогда Питон привлёк к себе наших тестеров и они на ём сделали тестовый фреймворк.
Я был в ужасе, но ни на чём другом они бы сделать его не смогли бы.
А если бы могли — они работали бы не тестерами, а боевыми разработчиками за втрое большую ЗП.
Вот так я навсегда смирился с новым BASIC-ом в индустрии


V>>Напротив, синтаксис PHP никакого флейма не вызывает, там всё чисто изначально.
N>Агащазз.

Тем не менее.
Споры вокруг PHP ведутся в основном в плане разнобоя name conventions, но это не синтаксис ни разу.


V>>Я не перечислял равные возможности, навроде генераторов yield и т.д., так шта, просьба не пытаться отвечать "а вот у Питона зато есть то-то и то-то" не проверив сначала, в каком виде "оно же" есть в PHP.
N>Так ты объясни, что именно в конкретных реализациях тебе так больше нравится, потому что угадать твои предпочтения невозможно, а к практике они обычно ортогональны.

Я просто показывал, что PHP по своим св-вам более мощный и последовательный язык, чем Питон.

Питон — он ведь как JS по своему устройству, вид сбоку.
Каждый пользовательский объект в нём — просто объект-словарик.
Чем отличается конкретно Питон от вовсе незамысловатого JS? — что в его "словариках" потенциально содержится куча __специальных_значений__, которые простейший парсер/интерпретатор Питона пытается натягивать на исходник, что заметно замедляет даже сам парсинг, в сравнении с тем же JS.

И что "помойкой" язык делают не его св-ва, а его экосистема.
Так вот, происходящее с Питоном последние лет 10 лично мне видится как де жа вю.

Ну и, очевидно, что PHP и Питон — они из разных весовых категорий.
Питон из категории средневесов, типа JS.
PHP — это тяжеловес, типа Смолтолка или Перла.
А если объективно, по кач-вам дизайна языка и реализации внутренней механики PHP на пару весовых категорий повыше Смолтолка будет.
Просто под PHP никогда не было написано такой замечательной среды разработки, которая однажды была написана для Смолтолка.

И тот факт, что практически весь современный веб живёт на PHP — он ведь тоже говорит сам за себя, верно?
Не смотря на все "ми-ми-ми" в сторону Питона. ))


N>Задачи, где требуется суперскорость собственного кода, я на Питоне и не рассматриваю. Но таких 1-5%.

В точку. потому что разные подходы.

Если Питон ускоряют через обертки над нейтивными либами, то в PHP ускоряют именно евойный код.
Причём, для веба получается быстрее, чем даже в случае С/С++.
Там на обработку запроса выделяется grow-only аллокатор из пула, в конце запроса просто курсор аллокатора в начало сбрасывается и всех делов.
Т.е. затраты на выделение и освобождение памяти близки к абсолютному 0-лю.
И в случае полной типизации простые тулзы генерят честный С-код из PHP, получая затем нейтивный-оптимизированный.
Т.е. весь матан можно колбасить прямо в PHP — будет в наилучшем виде на выходе.


N>Что простой — согласен. Потому что в разы более логичный.

Я не вижу "логичности".
Я вижу простую модель отображения некоторых элементов синтаксиса/операторов на т.н. "специальные имена".
На этом логичность исчерпывается.
Простой язык ведь не обязан иметь простое внутреннее устройство, не?
А в случае с Питоном это именно так, отсюда все побочные эффекты и ограничения и, прямо скажем, видимый еще из 96-го года "потолок" развития.


V>>Сравнивать с ним убогие JS или Python можно лишь от упёртой агнажированности, т.е. поправ всякую объективность.
N>Сказал самый упёртый в этом треде.

Я тут вообще над схваткой. ))
К Питону и PHP питаю одинаковые чувства, мне тут банально не понравились тонны неправды про Питон, поэтому встрял.
Слишком много успели вылить эмоционального и слишком много сугубо оценочных суждений.
Я лишь пытаюсь уравновесить всю эту необъективность техническими деталями.