Чем плох Python?

Ну да, необходимость боксинга/анбоксинга такой базовой фигни как функция это прям Ъ-ООП.

Покажи, что это боксинг/анбоксинг.

Ключевой вопрос: боксинг/анбоксинг чего?

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

2.3.3 :001 > a = -> { 1 }
 => #<Proc:0x0000000279fbd8@(irb):1 (lambda)> 
2.3.3 :002 > a
 => #<Proc:0x0000000279fbd8@(irb):1 (lambda)> 
2.3.3 :003 > a.()
 => 1 
2.3.3 :004 > 

Это чисто синтаксическая заморочка.

Если бы a вызывалась как a, то ты бы не мог её даже присвоить ничему. Сразу бы вызывал при любом упоминании.

Функций никаких нет концептуально. Такое вот оно ООП. И вызовов нет, это сообщения. Тут надо глубже копать, что мол ООП это какая-то фигня непонятная. Верните мне мои функции! Ну лямбды это почти что функции, можно на них всё писать. И обычно так и делается, когда нужно оперировать кодом как данными.

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

Ненене, там же семантика сообщений. См. коммент выше. Всё там грамотно сделано в рамках выбранной концепции. Надо ругать не синтаксис, а именно сам принцип. Хотя за что ругать, по-моему всё норм.

Отступы, отступы, отступы. ОТСТУПЫ! Это меня не только в питоне бесит, в yaml-х всяких тоже. Тому, кто придумал завязывать семантику на отступы, надо гвоздь в голову вбить!

А так мне питон нравится, как вспомогательный язык вполне норм.

Ненене, там же семантика сообщений. См. коммент выше. Всё там грамотно сделано в рамках выбранной концепции. Надо ругать не синтаксис, а именно сам принцип. Хотя за что ругать, по-моему всё норм.

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

Вообще думаю, что «Ruby будущего» — это JavaScript. И «Питон будущего» тоже.

15 лет назад JS смотрелся невероятно убого. На его фоне Ruby выглядел космической технологией.

Но всё-таки Питон и Ruby оба содержат детские болячки в синтаксисе и отчасти в семантике, которые никак без слома языка не исправишь.

JS из-за своей простоты не содержала достаточное количество синтаксических конструкций, чтобы авторы наломали дров.

Когда в 2010-х её стали основательно дорабатывать, уже было сформировано чёткое понимание, как надо. И детские болячки удалось по большому счёту закрыть. Стандартная библиотека тоже перестала содержать только полторы функции и в целом достаточно адекватная.

Но это актуально как начиная хотя бы от ES2015, до этого JS был ужасным.

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

зачем тогда все эти machine learning и прочие data analysis тулзы используют именно питон в качестве обвязки

Разгадка простая - FFI с минимумом телодвижений, без необходимости пилить модуль биндингов на Си/крестах. Получается такой matlab на стеройдах. Кроме того язык какбы создавался в качестве учебного. Получается что он просто идеален для лаб и не только, а потому горячо любим в академической среде. Ну а дальше синдром утёнка у студентов.

Это меня не только в питоне бесит, в yaml-х всяких тоже

В yaml это ещё терпимо, т.к. их редко нужно переписывать и изменением структуры. А в питоне это конечно боль.

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

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

Конфиги с завязкой на отступы – рай для потенциальных ошибок.

Деплоили мы как-то новый сервис на спрингбуте. Чувак, который его настраивал, пару строк с настройкой datasource криво скопипастил с неправильным уровнем отступа. «Умный» спринг тихо «задискаверил» какую-то другую базу через cloudconnector и лихо ее заюзал. А мы долго не могли понять какого хера этот сервис не видит данные с других. Мы, конечно. сами дураки, но будь бы это xml-конфиг, мы бы с этим не трахались.

пару строк с настройкой datasource криво скопипастил с неправильным уровнем отступа

Ну если так, то да.

Значимые отступы это всегда адок. Не видали верстальщиков, которым приказали с haml или jade работать? Там у людей потом нервный тик начинается. Хотя на хеловорлдах всё очень красиво и лаконично. Ну это еще ладно, а тут целый ЯП на отступах. Открываешь файл, а там 3000 строк и 30 уровней вложенности, причем где-то это отступы, а где-то форматирование, потому что гениальный PEP8 принуждает переносить каждую третью строчку.

Но писатели учебных пособий типа Гвидо конечно далеки от этих проблем. Там другая важнейшая задача: втиснуть пример в одну страницу. А потом язык становится лидером индустрии. Фейспалм.

И главное, кому эти { и } мешают? Место много занимают? Глаз мозолят? Или это просто стремление выделиться?

Всегда писал всякий временный и отладочный код без отступов от начала строки. Если забыть удалить, то будет бросаться в глаза в diff перед коммитом.

Но в питоне особый путь…

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

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

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

Ну какбы go это совсем не замена питону, go это замена c++. И да, на него очень многие таки прыгнули.

Разве есть ЯП схожей природы, в котором можно решить эту проблему?
Всё упирается в компиляцию, которой в таких языках принципиально нет

Какой еще «природы»? Кусок дерьма без архитектуры? В JS, например, почему-то есть компиляция. Еще можно блокироваться на уровне составных объектов. Но в CPython объекты и их связи чудовищно размазаны, об этом я и писал статью — что классы должны быть зафиксированы, побочные эффекты должны быть ограничены, а выполнение кода должно быть предсказуемо, а не как сейчас — выполнение внезапно рвется или прыгает на генераторах/контекста/исключениях. Причем, даже сам CPython испытавает трудности в интерпретации кода, в котором все эти три сущности используются одновременно (генераторы-корутины, контексты, и исключения).

Язык с динамической типизацией и прекрасной многопоточностью есть — это Clojure. Именно он меня вдохновил на написание моего проекта, который по сути является самостоятельным языком, но питоноподобным и способным выполнять питоньи куски кода, ровно как и предоставлять наружу интерфейсы, близкие к CPython.

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

Да, раздельное выполнение, но некоторые объекты — общие, и операции над разделяемыми объектами польностью сериализуемы. Только так, больше нет вариантов. Был PyPy-STM, который не взлетел потому, что заставлял довольно серьезно менять поведение программы при переходе от однопотока к многопотоку, потому что суть проекта PyPy-STM заключалась в том, чтобы хоть как-то ввести многопоток в питон, а не в том, чтобы сделать многопоточный код удобным и безопасным.

Я это вижу тупо как рантайм проверки, которые заменяют явные проверки, что на входе не рандомный мусор. Но это и так теперь есть

Что есть? Функция из стандартной либы может убедиться, что ты передал ей аргумент корректного типа? Не может. А большая часть твоего кода будет неизбежно дергать стандартную либу. хотя бы потому, что там реализованы базовые классы, вроде списка, кортежа, ассоциативного массива, строк, и других (булевого значения, массива байт, файлы, исключения, числа, итератор, memoryview, упорядоченный ассоциативный массив, слайс, множество, слабая ссылка) — в сорцах CPython это даже не совсем стандартная либа, а что-то между интерпретатором и либой.

У js с самого начала была ООП модель. Просто синтаксис был непривычный

У JS с самого начала были ассоциативные массивы и функции, а прототипы просто служили для упрощения напихивания атрибутов в ассоциативные массивы, вроде «создай копию этого объекта».

Адепты класс-ориентированного программирования с ноги запихивают методы работы с объектами в сами объекты, и делают вид, что так понимать код стало проще

Методы обеспечивают динамическую диспетчеризацию вызова по таблице методов объекта слева. Там, где она (диспетчеризация) вам нужна — используйте. Там, где не нужна — не используйте. Всё логично. Есть задача, есть под неё инструмент

Типовая проблема с твоим подходом — это когда я абсолютно точно знаю тип значения и мне не нужна динамическая диспетчеризация.

В JS по этой причине очень часто можно увидеть строки вроде Array.prototype.map.call(value...) или чуть покороче [].map.call(value...). Второй подход к решению проблемы статической диспетчеризации, который можно часто увидеть в стандартной библиотеке CPython — это пересоздание объекта через конструктор конкретного типа, например:

def somefunc(argument):
    val = str(argument)
    ...

Это, на самом деле, и является основной целью статической типизации, то есть, внесение предсказуемости в поведение моего кода, чтобы я был уверен, что мой код будет работать так, как я его написал и оттестировал, а не так, как в него передадут аргументы. Короче говоря, изоляция областей ответственности и локальное тестирование, или еще короче — модульность. По этой причине, например, CPython является языком со слабой модульностью, хотя, казалось бы, модули в нем есть — но они там только для виду и больше похожи на динамически подгружаемые строки кода, аля os = eval(open("os.py")). Как это когда-то делалось и в JS, пока в ES2015 не ввели настоящие модули.

И нет, статическая типизация сделана не ради рефакторинга. Рефакторинг является бессмысленной затеей, которая возникла прежде всего из-за большого объема ручной работы, требуемой для рефакторинга жавы. Потому рефакторинг является недостатком языка, а не его преимуществом. Грамотно написанный проект на языке программирования вместо жавы не требует длинного автоматического рефакторинга, чаще требуя ручного вдумчивого вмешательства, где статическая типизация уже не играет серьезной роли.

Ты заметил, что классы не помогают решать эту проблему? Динамическая диспетчеризация по одному аргументу является лишь одним, и далеко не самым популярным инструментом.

https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice

Это абстрактное исследование в вакууме показало, что 65-93% всех вызовов методов, как правило, вызывают только один-единственный статичный метод. Попытка сделать весь язык вокруг диспетчеризации по одному аргументу значит, что язык строится вокруг 13-32% всех вызовов в программах. Причем, проблема диспетчеризации по нескольким аргументам, как правило, в таких языках не решена вообще никак, таким образом отправляя эти 3-7% вызовов методов на костыли и «паттерны программирования».

На практике в архитектуре мы имеем дело не с числами, а со всякими плагинами, виджетами, менеджерами, менеджерами менеджеров, абстракциями над объектами БД и т.п. Всему этому нужна динамическая диспетчеризация

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

Это проблема невротичного ума, а не классов. Читайте книги по архитектуре кода, там все эти типовые ошибки рассматриваются, когда в класс суют не то, что к нему относится

Подразумеваешь, что я эту парашу еще не читал. По факту, если ты посмотришь на реальные достаточно крупные проекты, то результат один: огромный базовый god object с методами на все случаи жизни, от которого наследуются мелкие конкретные реализации. Ну и где твои авторы книжек? Как правило, они выдают не связанные с реальность примеры, выдуманные плюшевые сложности, которые автор с легкостью решает своим тонким и прозорливым умом. Но по факту этот автор за свою жизнь не написал больше 10 тысяч строк, однако же, учит тебя писать сложные системы.

Я отвечал по поводу JS vs CPython — это два языка, которые я хорошо знаю. Я не знаю деталей реализации руби, но подозреваю, что они ближе к питону, чем к JS.

В чем именно он ближе к Питону?

Я сужу по косвенным признакам, таким, как отсутствие эффективного JIT-компилятора для Руби. Напоминаю, что JIT-компилятор для Lua написан одним-единственным человеком, даже никакого гугла не понадобилось. PyPy тоже основан на проекте одного-двух людей, пусть сейчас им и занимается много кто.

В JS нет примитивности работы с объектами. Есть концептуальная простота, которая позволяет делать JIT относительно малой кровью, в сравнении с Питоном

Я уже упомянул прототипы, который более ограничены, чем классы в Ruby/CPython, при этом лучше понимаются и оптимизируются. Еще в JS не было никаких способов перехвата доступа к атрибутам. Только в ES5 появилось defineProperty, которое все равно было ограниченным. Полноценный динамический доступ к атрибутам появился только в ES6 (ES2015) с Proxy и Reflect. Причем, эти фичи сделали отдельностоящими, они не слились со старыми примитивными методами работы объектов.

Эээ? Можно менять поля прототипа в любой момент
qjs > Object.prototype.xxx = 1

Да, действительно, можно. Видать, я посчитал что нельзя, потому что этого никто не делает. А не делают потому, что в таком случае ломаются оптимизации.

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

Как это не прыгнули, если прыгнули? Вон, сколько людей пользуется докером и кубером на Go. Питон от гугла тоже не сразу подхватили, но подхватили же в итоге.

В гугле бросали игральную кость? Читали из /dev/random? По кофейной гуще определили язык?

https://www.youtube.com/watch?v=x6MxvzliG6I

и питон создан до джавы

О_о! А можно какой-то пруфец? А то чёт дочитал до сюда и как-то в остальное уже сложно верится

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

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

Низкая по сравнению с чем? Где бенчмарки посмотреть?

По сравнению почти со всеми самыми популярными языками, кроме Ruby и Perl. Даже ActionScript 3 (который во флеше) имеет JIT-компиляцию и бегает на порядок быстрее интерпретируемых собратьев. Бенчи есть на techempower.com и benchmarksgame-team.pages.debian.net.

60% стандартной библиотеки написано на сишке

Как по мне, это скорее достоинство, чем недостаток. Особенно для языков, прямое назначение которых быть клеем.

Чем плох Python? (комментарий)
«Это парадоксально, и в то же время иронично: язык Си является препятствием для оптимизации выполнения питоньего кода»

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

И какой с этих людей толк? Это какие-то манагеры-датасаентисты, которые толком даже не умеют писать программы на ЯП, но при этом «сознательно юзает его через всю его корявость». Как они могут откритиковать ЯП? Для них разница языков заключается в форме и количестве скобочек.

На две страницы двое упомянули GIL, ни одной чёткой претензии к объектной модели, подавляющее большинство претензий к какой-то косметике и к утиной типизации в языке, о боже, с утиной типизацией

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

И это тред про язык, где нельзя проксировать произвольный объект

Какой тред?

Конфиги с завязкой на отступы – рай для потенциальных ошибок

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

Всегда писал всякий временный и отладочный код без отступов от начала строки. Если забыть удалить, то будет бросаться в глаза в diff перед коммитом

Очень быстро привыкаешь выделять отладочный код другими путями.

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

Как правило, в достаточно динамичных приложениях убогие типы данных, вроде тех, которые в Java, не позволяют покрыть огромного числа логических взаимосвязей данных. Самый банальный пример — число, являющееся индексом в массиве. Это уже только тестами в рантайме можно поверить. Самая крайность в данном контексте — это Си, у которого система типов настолько потрясающе убога, что совершенно бесполезна и в итоге подавляющее большинство проверок делает тестами.

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

Ну какбы go это совсем не замена питону, go это замена c++. И да, на него очень многие таки прыгнули

Язык со сборкой мусора является заменой C++? Ты сейчас серьезно? Это же минимум Java. Можно говорить о том, что Go — это Java здорового человека, которая настолько удобна и человечна, что делает бессмысленным писание прототипа на питоне. У нас тут сидят отдельные упоротые, которые расскажут, что на жаве, или хотя бы каком-то Groovy, можно писать прототипы не сложнее, чем на питоне.

там какая-то ютубовская чушь с подтверждением возраста. Тезисно можно?

Вон, сколько людей пользуется докером и кубером на Go.

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

Питон от гугла тоже не сразу подхватили, но подхватили же в итоге.

Для своих задач питон был и будет подходить лучше, чем Go.

Вот ещё что вспомнил. Когда только начинал использовать Питон, мне очень не хватало констант и enum-ов. Констант вроде бы до сих пор нет. По ссылке люди пытаются использовать костыли на свойствах: https://stackoverflow.com/questions/2682745/how-do-i-create-a-constant-in-python

Что касается enum, то они появились в версии 3.4: https://docs.python.org/3/library/enum.html . Но это тоже на костыли похоже. Хотя подобные костыльные enum-ы есть во многих языках.

А, прикольно, у меня в голове была другая хронология. С другой стороны python 1.x и 0.x для меня как будто и не было никогда.

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

Тем, что хрен соберёшь exe-шник. В турбопаскале и квикбейсике это было легко и просто лет, блин, 40 назад. А в питоне нет.

cx-freeze, nuitka

Ну да, есть сторонние костыли различной степени костыльности, которые, если повезёт, работают. А в турбопаскале это был стандартный пункт меню.

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

Что такое сторонние костыли в отношении к языку? Ты можешь показать не сторонний компилятор плюсов, например?

Турбопаскаль это вообще не язык, а IDE. Сам по себе турбопаскаль такой же сторонний костыль.

Не совсем корректное сравнение. Обобщенные типы будут работать быстрее динамической типизации. Ну и проверка обобщёнными типами не отключается. То есть у них есть свои плюсы. А в питоньих enum-ах что? Какие плюсы по сравнению с D или C#?

Тогда я принял отсутствие enum как элемент философии языка, а они взяли и ввели. Можно расценивать как непоследовательность, либо как изначальный недостаток.

Турбопаскаль шёл на одном наборе флоппиков в коробочке. А для питона костыли по всему интернету искать, чтобы собрать исполняемый файл. Который к тому же в половине случаев реализован как самораспаковывающийся архив куда-то в %TEMP%, что ещё дополнительно раздражает антивирусы на винде, и желающих иметь noexec на линуксе. А в другой половине случаев не работают условные Qt.

Турбопаскаль пилила корпорация, а питон и его тулчейн пилят всем миром.

У тебя случаем притензий к линуксу нет аналогичных, в сравнении с макосью или виндой, например?

Не, понятно что за питон мы не платили. Но также мы не платили за gcc и, не к ночи будет упомянут, freepascal, которые бинарники собрать всё же могут.

За озвученные утилиты, которые из питона бинарники собирают, тебе платить приходится?

Или у тебя gcc внезапно стало ide где все из коробки, как в турбопаскале, что бегать по интернету не надо?

Давай твоими же картами пойду.

Как на паскале написать шел-скрипт, без сторонних инструментов, как на питоне?

Как на паскале написать шел-скрипт, без сторонних инструментов, как на питоне?

На питоне шеллскрипт не неписать, т.к. питон — не шелл. Ну не считая всякие извращения вроде xonsh.

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

А установка более новой версии питона на линукс это тот ещё бег по граблям.

Вот видишь как выходит. А на питоне и шелл-скрипт написать можно, и бинарник скомпилировать.

Переиграл тебя питон.

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

тебе не нравится синтаксис len или что-то еще?

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

Пример с len() иллюстрирует слово «псевдо-объектный».