Чем плох Python?

Такие кадры на любом языке быдлокод напишут нечитабельный.

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

После переработки оказалось, что большую часть питонолапши удалось безболезненно выкинуть, переложив на пускалку.

Ну так чел просто плохо структурировал код или плохо знал баш, или и то и другое одновременно. Питон-то тут при чем?

У JS вообще нет референса.

В этом его большой плюс.

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

Никогда не встречался с ситуацией, что коллега кинул аргументом твоей функции вместо строки криптообъект? Причем, оно еще и работало как-то в таком виде, но через раз. На масштабе 10к+ строк код очень быстро выходит из-под контроля.

Очень правильный пойнт. Когда проект развивается до больших размеров, статическая типизиция позволяет проекту остаться поддерживаемым. Без неё сильно усложнены понимание кода и его рефакторинг, а это важнейшие моменты в большой кодовой базе.

а зачем вообще писать однострочники?

стандартная библиотека выглядит набором рандомных функций

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

Перл привлекает таких дурачков, которые, вычитав, как сократить исходник ещё на один символ, спешат побыстрее применить это знание в своем мега-скрипте.

Ох уж эти городские легенды. Ну вот откуда вы это берете. В перле сейчас высочайшая культура кодинга, может самая высокая среди всей пыхоплеяды. Просто потому что там не осталось случайных пассажиров с мега-скриптами. Линтеры для перла появились еще до рождения похапе например (утрирую, но примерно так). Код из 90-х, с которым я в основном работаю, это конечно адок. Как впрочем и любой код из 90-х.

На масштабе 10к+ строк код очень быстро выходит из-под контроля.

Там дело не в размере, а в количестве рыл. Больше двух рыл, про динамику забудьте. Всё просто. А в одно рыло ублажать компилятор это для извращенцев. Особенно если «проект» только и делает, что дергает базу и что-то пишет в stdout.

Угадываю уже на протяжении более чем 10 лет, и каждый раз успешно. Что я делаю не так?

Так и пхпшники говорят. Привыкнуть можно к любой дичи.

Тем что тормозит и включает пробельные символы как часть синтаксиса.

Нет сертификаций? Или есть?

Статическая типизация в языке - это самый жирный минус.

Это пока вы пишете «хеловорлд!»

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

Наверное поэтому есть костыли для проверки типов для многих ЯП с динамической типизацией.

Недавно пробегали планы добавления статической типизации в Питон.
Думаю со временем разум победит и добавят.

А какой вы можете привести аргумент против опциональной статической типизации как в Typescript?

а зачем вообще писать однострочники?

Чтобы по-быстрому что-то массово преобразовать один раз.

У JS вообще нет референса. А у питона помимо референса есть Cython, PyPy и Numba.

Cython и numba — уже не совсем python. PyPy безнадёжно медленнее v8 и быстрее он не станет потому, что в v8 слишком много ресурсов гугла.

Вложенные if’ы и for’ы в однострочнике нечитаемы на любом языке.

Паскаль с его begin-end и баш с его fi и done сильно повышают читаемость в отсутствии форматирования :)

Что я делаю не так?

Не используешь более адекватные ЯП, очевидно.

Не скажи, мне частенько удавалось давать команды на втором уровне вложенности, которые на самом деле надо было давать на третий.

Постой, а современные шеллы умеют в такую комбинацию клавиш или команду, которая вызовет $EDITOR, а что ты в нем сохранишь, то и выполнится как однострочник (даже если это не однострочник)?

man fc

Ты про C-x C-e в дефолтном баше?

http://www.onelinerizer.com/

А есть такой же, только для 3-го? Там что-то с reduce() сделали такое, что её не рекомендуется использовать.

О, точно.

Однострочники не нужны!

Ruby намного более логичный и консистентный. Всё в стандартной библиотеке устроено понятным, удобным и запоминающимся образом.

Там просто изначально задизайнена объектная модель. А другие пыхи делались по принципу «накидаем полезных функций, а там видно будет». Потом пристегивалось ООП уже на ходу. В результате всё выглядит очень печально. Что характерно, все заходы «ООП не нужно» выливаются в какое-то УГ.

В перле сейчас высочайшая культура кодинга, может самая высокая среди всей пыхоплеяды. Просто потому что там не осталось случайных пассажиров с мега-скриптами.

Да, там остались старперы и перл-хакиры. На счет высокой культуры… Не знаю, как в библиотеках, а скрипты, которые мне попадались недавно - лютый треш, портянки без функций, с крипто-кодом и магическими константами.

И тут возникает вопрос: а зачем тогда все эти machine learning и прочие data analysis тулзы используют именно питон в качестве обвязки? Без шуток, уже давно пытаюсь понять, зачем всё сделано через такие костыли, и тем не менее это настолько популярно? Должно же быть какое-то рациональное объяснение?

Вложенные if’ы и for’ы в однострочнике нечитаемы на любом языке.

В математических выражениях полно однострочных if’ов и for’ов, и даже похуже вещей. И ничего, те кто в теме, читают эту абракадабру без проблем.

адекватные

Если ты про руби, то у тебя куча ошибок в слове «всратые»

Это всё понятно, но когда вопрос производительности встаёт ребром, всё равно не JS используют.

Как ты там выше писал, это проблема конкретных погромистов. Perl тут при чём?

Для наглядности - посмотри, например, код mojolicious(использую его активно). И там всё, как ты любишь - довольно жёсткие ограничения при использовании этого фреймворка.

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

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

Я не видел ни одного, даже среднего проекта который не пришлось бы изменить.

Так что сказки о волшебном проектировании структуры проекта оставьте дошкольникам ;)

Вы видели много проектов которые перешли с питона на стон?

Если в ваш проект срочно-срочно нужно вносить изменения, не предусмотренные его структурой - это либо ЧП какое-то глобальное случилось, либо непродуманная структура. А про проекты, которые перешли с питона на cython - нет, не видел, потому что кому нужны такие переобувания. Зато видел проекты, в которых этот самый cython активно и уместно используется https://github.com/topics/cython

к Python-хейтерам - вы можете адекватно и по пунктам сформулировать, чем он плох?

Кроме того, что пистон полу-динамический псевдо-объектный им-мутант-бельный непостоянный с зоопарком разношерстных шизо-модулей, то ничем :)

Ваш хваленый ООП - это синтаксический сахар, под которым лежит старое-доброе процедурное программирование. И умелый маркетинг, конечно, тоже

Ваше хваленое процедурное программирование - это синтаксический сахар, под которым лежат старые-добрые машинные коды. И умелый маркетинг, конечно, тоже.

Если нужна статическая типизация, то есть Cython

Это не та статическая типизация.

вы можете адекватно и по пунктам сформулировать, чем он плох

Що, опять? 100500 раз уже обсосано.

Нормально объяснить чем плох X могут только X-loverы

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

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

И я об этом.

Питонщики обычно слишком уперты в том что типизация не нужна.

Ваш хваленый ООП - это синтаксический сахар

s = 'Привет мир!'
len(s)

s = 'Привет мир!'
s.size

Угадай, где ООП, а где какая-то хрень?

Чем он хуже по сравнению с Perl, Ruby, Javascript

Ничем. Python во всём лучше перечисленного

Ruby и Perl — да, мусор. А вот по поводу JS я не согласен. В нем есть настоящие модули, он достаточно прост, чтобы обеспечивать реализацию вывода типов и последующую локальную статическую типизацию, и при этом достаточно развит. Но это актуально как начиная хотя бы от ES2015, до этого JS был ужасным.

Основные проблемы: типизация... В какой-то мере это решается тайпхинтами, mypy

Основная проблема заключается в том, что не удается протипизовать стандартную либу, которая написана «на-отлюбись». В том же TypeScript этой проблемы нет, хотя бы потому, что введено понятие интерфейсов.

На Питоне это просто какое-то постоянное приключение «угадай, что!»

[не] консистентный
Угадываю уже на протяжении более чем 10 лет, и каждый раз успешно. Что я делаю не так?

Привык/заучил.

Питон медленнее и это не исправить

Глупость феерическая. У JS вообще нет референса. А у питона помимо референса есть Cython, PyPy и Numba

При чем тут референс? JS определяется стандартом, в отличие от некоторых других. Cython в немодифицированном коде не решает проблемы производительности, с Numba проблема та же, в остальном это лишь отдаленно напоминающие питон языки.

Ruby и Perl — да, мусор.

Потому что ты так сказал?)

Меня он раздражает пакетными менеджерами. pip устаревший, pyenv оооооочень меееееееедленный и тупой. После npm смотрю на них, как на говно

Да, потому что смотри выше — питон очень тяжело ускорить. Тем не менее, у NPM, как и у любого подобного проекта, будет одна и та же проблема — угадайки с работоспособными комбинациями версий пакетов. Из-за этого придумали yarn.

Из-за этого придумали yarn.

Ну это типовое решение. В 2021 в любой системе менеджмента пакетов должно быть из коробки.

Очень правильный пойнт. Когда проект развивается до больших размеров, статическая типизиция позволяет проекту остаться поддерживаемым. Без неё сильно усложнены понимание кода и его рефакторинг, а это важнейшие моменты в большой кодовой базе

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

Статью почитал.

Что касается костылей, ты во многом прав.

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

Непонятно, зачем вообще выбрал питон in the first place.

PyPy безнадёжно медленнее v8 и быстрее он не станет потому, что в v8 слишком много ресурсов гугла

Напоминаю, что гугл был основным языком для писания прототипов гугла. Но они уходят от питона, потому что питон безнадежно медленный, и даже гугл не смог ничего с этим сделать. Гуглу придется бросить всех людей на написания PyPy, чтобы сделать его сравнимым по производительности с V8 — а делать этого он не будет.

Там просто изначально задизайнена объектная модель

Это и есть причина, почему Ruby — говно. Сразу отвечаю и написавшему претензию по этому поводу выше. Класс-ориентированное программирование не работает, и это уже пора понять. Оно хорошо описывает 5% задач, и именно эти 5% почему-то любят приводить в книжках. В книжках также описывают случаи «иногда бывают трудности», но не упоминают, что «иногда» — это 95% всех задач, для которых класс-ориентированное программирование не работает.

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

Контроль типов нужен в каких случаях:

• Присваивание.
• Передача аргумента.
• Что еще упустил?

Что там такого ужасного в сорцах, что контроль типов станет катастрофой?