Чем плох Python?

В JS, например, почему-то есть компиляция.

Не компиляция, а JIT-компиляция. Разница как между свинкой и морской свинкой.

Ну то, что в питоне нормально JIT-компиляцию не запилишь, вроде уже обсудили.

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

Прототип — абстракция более общая, чем класс. И более простая. На прототипах можно писать классы.

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

Ну и еще у них хватило ума не напихать в язык костылей, в отличие от питона.

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

Ты уверен, что это проблема? Проблема не в наличии диспетчеризации, а в невозможности вывести точные типы в частном случае. Сам об этом пишешь.

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

«Статическая типизация ради рефакторинга» — это какой-то выверт мозга архитектурной космонавтики. Тем более «автоматический рефакторинг», брр.

Рефакторинг — набор приёмов, позволяющих трансформировать код наименьшим количеством усилий. Применять можно к любому ЯП. Вопрос практической необходимости трансформировать код в конкретном случае — это уже другой вопрос.

Динамическая диспетчеризация по одному аргументу является лишь одним, и далеко не самым популярным инструментом. https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice

я быдло. Я из этого списка слышал только про CL и Julia и ни на чем из этого не писал.

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

У тебя преждевременная оптимизация :P

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

Типовое решение — последовательная диспетчеризация по всем объектам с переброской вызовов через классы.

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

Учитывая, что Ruby и так быстрее Python (был, текущее состояние не знаю), а на Python без всякого JIT шарашат тонны сервисов, то ты уверен, что это говорит хоть о чем-то? Ну не написали, потому что никому не надо было.

(При этом RoR — на практике тормознутый комбайн. Вот так у них получилось…)

Проблема Ruby — в него натолкали слишком много всего, и в синтаксис, и в ядро, и библиотеку. Писать на нём приятно, а вот заниматься его реализацией я бы не захотел.

Это нужно сесть, расковырять его core-модель исполнения в точности и сделать выводы, что он собой представляет по отношению к питону и JS. Делать это я конечно же не буду.

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

Хорошо, что сделали правильно.

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

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

Это не вопрос оптимизаций. То есть не совсем… У меня ощущение, что ты путаешь локальную оптимизацию, когда можно точно вывести тип, и JIT-оптимизацию, когда компилятор выводит динамические классы.

Собственно, вот выше твой пример:

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

Asm.js работает аналогично.

Суть оптимизации тут в выводе примитивных типов, у которых невозможно сделать Int.prototype.add = ..., и следовательно их можно компилировать без v-таблиц.

Так это не полноценный вывод типов, это сведение высоуровневого языка до обертки на Си. И даже хуже: в Си хотя бы есть структуры. А тут и того нет.

Ну да, ты сможешь скомпилировать a + b + c * d в машинный код. Но на этом всё. Дальше оптимизация не идёт.

Что касается динамических классов, это не классы языка. Каждый раз, когда ты делаешь anything.prototype.foo = ..., компилятор заводит новый класс. И от run time проверок при каждом обращении к переменной никак не избавиться. Все эти V8 так и работают.

Язык со сборкой мусора является заменой C++? Ты сейчас серьезно?

А в чём проблема? Во многих областях применения крестов наличие сборки мусора является скорее преимуществом. Например большинство десктопного софта.

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

#!/usr/bin/tcc -run

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

А полу-динамический чем проиллюстрируете? А то я не всё распарсил.

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

Справедливости ради, мало кому понравится исполняемый файл на 50 Мб. А так уж устроены интерпретаторы, что они не знают, какая часть библиотеки им в следующий момент понадобится.

На Питоне сложно писать однострочники.

Ты же имел ввиду, что это преимущество питона, а не недостаток? Верно?

Работа с модулями ужасна.

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

Что не так?

ООП - это синтаксический сахар

Ох б.я...
Ты серьёзно???

Справедливости ради, мало кому понравится исполняемый файл на 50 Мб.

Electron это не останавливает, для многого размер дистрибутива приложения не настолько критичен, сколько вообще возможность и простота его создания. У питона с этим печальнее чем в среднем по зоопарку.

так уж устроены интерпретаторы

Упомянутая выше в качестве решения nuitka — скорее компилятор, чем интерпретатор, хоть и зависит от libpython. Но да, tree shaking в языке с живым eval сделать сложно.

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

Модуль всегда запускается весь. Разница между import … и from … import … — какой объект появится в твоём неймспейсе.

Что не так?

Модули в питоне похожи на то что происходит в файловой системе, но не совсем, там есть неожиданный для некоторых (многих?) слой абстракции. Если забыть __init__.py, получаем namespace package который по-другому и не очень очевидно работает. sys.path получается разный в зависимости от того выполняешь ли ты python foo.py или python -m foo. А самый рекомендуемый способ сделать модули твоего проекта адекватно импортируемыми независимо от способа и условий запуска — установить его в venv, для чего нам нужно выдумывать целый setup.py, что само по себе целый экскурс в историю питонокостылей. Ах да, ещё надо объяснять народу что такое venv, но с этим питон-комьюнити более-менее справляется.

Но что происходит на практике, народ сталкивается с ModuleNotFoundError, берёт в руки PYTHONPATH или sys.path.append(…) и делает так чтобы ModuleNotFoundError ушёл. А потом ловит очень неочевидные глюки, связанные с тем, что один и тот же модуль импортировался дважды под разными путями.

Ты серьёзно???

Давай сравним:

Си практически 50 лет назад

struct Point {
    int x;
    int y;
}

Pascal более чем 50 лет назад

Point = record
    x: integer;
    y: integer;
end;

Тем временем в питоне?

class Point:
    
    def __init__(x, y):
        self.x = x
        self.y = y

    def __eq__(self, another):
        return (self.x == another.x
                and self.y == another.y)

    def __hash__(self):
        return hash((self.x, self.y))

И это без __repr__ и может ещё пары полезных для данной структуры методов.

Ну ладно, хорошо, сейчас есть датаклассы, но между появлением в питоне ключевого слова class и появлением builtin’а dataclass прошло очень много времени. И чтобы разрабы питона задумались, должен был сначала появиться attrs.

Тут товарищ изучает питон, попросил как-то помочь разобраться с багом:

for record in table:
    #что-то делаем
    my_dict[key].append(record)

for recod in my_dict[some_key]: #упс опечатка в одной букве
    #делаем что-то с record, но получаем всегда одно и то же значение :)

Совпали 2 антифичи питона, после первого цикла record зачем-то доступен и 2е – неиспользование переменной это ок. Товарищ до этого пописывал на VBS, после того как я ему показал эту ошибку и объяснил что к чему, он сказал, что такого не ожидал, в VBS такое не могло бы случиться.

Ещё одна странность:

my_var = 1
def f1():
    print(my_var) #получаем доступ к глобальной переменной

def f2():
    my_var = 10 #создаёт локальную, для доступа к глобальной надо писать global

На мой взгляд это не логично.

Перед php — конечно да

И какие преимущества вы видите?

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

Более грамотный синтаксис, лучшая организация стандартной библиотеки.

Лучше средства развёртывания. (??? вот тут не уверен. Не в курсе современного состояния экосистемы php.)

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

На Питоне сложно писать однострочники.

Ты же имел ввиду, что это преимущество питона, а не недостаток? Верно?

Задумывалось именно так. Но как сказали выше, где нельзя обойтись точкой с запятой, начали городить list comprehension с тернарными выражениями :)

А понятно как, везде будут хэштаблицы.

Во-во.

В то время как в JS можно замакетировать «на хэш-таблице» (которая на самом деле просто объект), а потом дописать поведение, и получится класс.

С другой стороны, такой подход (JS) часто порождает трудноуловимые ошибки.

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

Да нет же, в данном случае 50 лет назад никакого полиморфизма и типа интерфейсов не было бы. И именно с ними проще многие вещи делать.

классы на каждый чих делать муторно

Странно, я всюду встречаю классы, и сам их делаю...

Не всегда нужен полиморфизм и интерфейсы.

Для работы с данными нужно тупо записи, структурно повторяющие данные извне. И бьющие по рукам за попытку обратиться к полю с неправильным именем или типом.

@byko3y выше об этом упоминал тоже.

нужно тупо записи, структурно повторяющие данные извне

Мне даже в голову не приходило говнокодить это на питоне без классов. Жаль, что кто-то так делает.
А так да, наверно, структуры тут логичнее.

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

А вот то, что в языке долгое время не было встроенных средств, чтобы малой кровью сделать plain old data object, не переписывая все имена полей как минимум дважды, а если хочется сравнения объектов, то по 7 раз, то это как раз, что называется, сапожник без сапог. Это то, чем питон (долгое время был) плох.

go это замена c++

Хорошая шутка.

А! Упс, сам тупо писал простыни. Ещё радовался, что в java вроде ещё больше.

Странно, я всюду встречаю классы, и сам их делаю…

Тривиальные классы в питоне делать муторно. В итоге люди таскают туда сюда дикты или, того хуже, балуются namedtuple’ами.

Да ладно, сделать скрипт, пишущий описание модели по JSON-у, тривиально. И наверняка кто-то уже это сделал для питона.

Да есть и attrs, и встроенный dataclass. Правда для dataclass надо иметь минимум питон 3.7. Какой там был в предыдущем ubuntu LTS или нам повезло? Ведь запаковать приложение вместе с интерпретатором трудно, а простейший способ обновления питона в линуксе — переустановка/апгрейд всего дистрибутива.

Есть ещё pydantic.

а простейший способ обновления питона в линуксе — переустановка/апгрейд всего дистрибутива.

pyenv?

pyenv

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

Не знаю, сколько компилируется питон. Я в rvm как ruby собрал, так он несколько лет и проработал; я аж пропустил несколько значимых релизов.

Вот на днях собрал версию посвежее. Ушел обедать. Пришел - собрано.

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

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

Начиная с сравнения питона с турбопаскалем, вы рассуждаете, как герой анекдота, которому не понравился «естедей», после того, как ему его Рабинович напел по телефону. Уровень аргументов доставляет.

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

Не включайте компьютер в сеть, это требует энергозатрат.

Питон компилится за вменяемое время (до получаса в однопоток, а то и всего 15-20 минут) и на малинках и на бюджетных впсках. На современном десктопе это вообще меньше 3-х минут.

А с учётом, что переканпилять требуется, ну не чаще раза в квартал, а то и раз в год, о чём вы тогда? Что за экономия такая?

сознательно

Ты мне тут посылкой сообщений не отвертишься, определение ООП ЕМНИП для Smalltalk’а писалось, а everything все равно is an object. Тоже мне, «ложки нет».

К лямбдам и претензий нет.

Методов в Proc, я же говорю.

Ты там об альтернативных реализациях пел, а не о производительности. Cython от референса недалеко падает.

Так это не функция — «не объект первого класса», а к слоту в таблице методов нет прямого доступа.

Да заладил ты со своими синтаксисами. Имя у этой сущности есть? Осмысленные операции над ней есть? Все, дайте мне ей оперировать. Плевать какой при этом будет синтаксис, но не должно быть боксинга и должна сохраняться identity. Не можете => это не объект, это полуфабрикат. В C функции больше «объект», чем это.

А «есть лямбды, юзайте лямбды» тоже не ответ, everything работает не так.

Над методами? Только через костыли. Напрямую нет.

Ты наверное хочешь сказать, что в языке должна быть возможность сделать:

var f = Array.prototype.map;

и получить метод в переменную?

Я правильно понял?

Согласен, должна быть. Но вот в Ruby сделано через жопу.

Другой вопрос: почему ты считаешь, что это говорит о плохом дизайне его модели ООП?

А полу-динамический чем проиллюстрируете? А то я не всё распарсил.

А я уж думал никто и не спросит. Показываю на примере:

v = [1, 2, 3]
v[4] = 5

И всё, питон умирает (а динамический руби расширяет массив).

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

Это вообще к чему? Стандартная библиотека любого языка привязана к версии стандарта языка. Это настолько же верно для С++, как для питона. Питонисты немного мухлюют говоря «что делает cpython, то и есть стандарт», но так вообще много кто делает.

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

А если я хочу воспользоваться альфой питона 3.10, то её придётся так или иначе ставить на все компьютеры, на которых захочется запустить программу. Либо явно, либо собирая «репак».

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

А теперь внимательно:

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

Глупость феерическая

Речь про референс там в контексте как бы. Товарищ сравнивает питон с жопоскриптом, у которого референса нет.

Питон компилится за вменяемое время (до получаса в однопоток, а то и всего 15-20 минут) и на малинках и на бюджетных впсках. На современном десктопе это вообще меньше 3-х минут.

Живых архитектур сколько? Со всеми специфичными вариациями наберётся от силы штук 20. Соответственно этих 20 бинарников хватило бы практически всем.

За майнинг биткоинов хотя бы эти самые биткоины дают, а за компиляцию питона ты получаешь практически такой же бинарник, который получали другие тысячу раз до этого. А если этот этап ещё и в CI/CD засел, то вообще ой, Греты Тунберг на вас нет.

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

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

А почему бы не сравнивать?

Я только за. Но всё-таки применительно к действительности.

А действительность (в моём понимании), такова:

• можно писать на Python 3, а не условном Python 3.9, тогда не будет проблем и лишних движений с переносом «на все компьютеры, на которых захочется запустить программу»
• второй вариант, всё таки хочется писать на 3.10, а не на 3… ну что ж, ок, девелопить можно в виртуальном окружении, не ломая хостовую систему. Остаётся претензия к «а если я хочу воспользоваться альфой питона 3.10, то её придётся так или иначе ставить на все компьютеры». Для этого и придумали всякие контейнеры с установкой нужного вместе с зависимостями не сложнее, чем бинарник поставить, первое что на ум приходит это докер.

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

Не компиляция, а JIT-компиляция. Разница как между свинкой и морской свинкой

В чисто компилируемые языки сейчас тоже вводят профилирование перед компиляцией, так что это ты зря. И интерпретаторы под кресты тоже делают. Никого уже не волнует, будет ли код, выполняющийся раз в 10 секунд, выполняться за 50 нс или за 500 нс, потому что стоимость переключения контекста составляет несколько микросекунд.

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

Ну и еще у них хватило ума не напихать в язык костылей, в отличие от питона

Создатели JS сделали язык для написания однострочников — вот и вся история, вот и вся их мотивация.

Проблема не в наличии диспетчеризации, а в невозможности вывести точные типы в частном случае. Сам об этом пишешь

А еще я писал, что в ML этой проблемы нет и таки типы выводятся. Причем, подобные танцы делались и для лиспа, и для Smalltalk, но нынешние айтишники будто ничего об этом не слышали. Собственно, даже JIT-компиляторы в итоге занимаются главным образом выводом типов, причем, даже более конкретных типов, чем «число» или «строка» — в том же упоммянутом Си нельзя создать целочисленный тип, который может принять значения «0, 3, или 7», не говоря уже про алгебраические типы.

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

У тебя преждевременная оптимизация

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

Проблема Ruby — в него натолкали слишком много всего, и в синтаксис, и в ядро, и библиотеку. Писать на нём приятно, а вот заниматься его реализацией я бы не захотел

То же самое относится к питону, причем, многие «любители питона» не подозревают, что у CPython довольно серьезные проблемы с кодерами, поскольку рук нужно много, а по факту их сильно меньше. И не в последнюю очередь такая ситуация возникла потому, что CPython намного сложнее, чем мог бы быть. Именно потому я говорю, что по косвенным признакам руби ближе к питону. Ноду, вон, изначально в одно рыло из V8 сделали.

Суть оптимизации тут в выводе примитивных типов, у которых невозможно сделать Int.prototype.add = ..., и следовательно их можно компилировать без v-таблиц

Да, в asm.js так сделали, и там были вполне конкретные оптимизации под конкретный asm.js, которые не работают для обычного JS кода.

Ну да, ты сможешь скомпилировать a + b + c * d в машинный код. Но на этом всё. Дальше оптимизация не идёт.
Что касается динамических классов, это не классы языка. Каждый раз, когда ты делаешь anything.prototype.foo = ..., компилятор заводит новый класс

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

Во многих областях применения крестов наличие сборки мусора является скорее преимуществом. Например большинство десктопного софта

Десктопный софт у языков со сборкой мусора, как правило, работает в написанном на C++ главном цикле и функциях отрисовки, а в мусоре копошится только логика. Так работает ActionScript, WPF, UWP, должна была работать JavaFX, но приказала долго жить, и особенно так работает хром вместе с электроном.

Там же либо весь модуль, либо заявленный кусок берётся и запускается

Добрая половина всех проблем питона происходят от того, что время разработки безнадежно перемешалось со временем выполнения. Это я и называю «отсутствие архитектуры». Тот же лисп уже проходил через эти стадии, но в итоге получил четкое разделение времени разработки и выполнения, вместе с возможностью компиляции. Автор питона будто ничего не знал про предыдущие 30-35 лет опыта создания языков программирования. Что, в общем-то, никогда не ставилось минусом разработчику.

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

Electron это не останавливает, для многого размер дистрибутива приложения не настолько критичен, сколько вообще возможность и простота его создания. У питона с этим печальнее чем в среднем по зоопарку

В электроне тоже не собирают один гигантский бинарник — смотри VS Code или Atom. Примерно так же распространяют сборки питона, и проблема там совсем не в невозможности собрать единый исполняемый бинарник.

да ткни ты его уже https://pyinstaller.readthedocs.io/en/stable/

проблема питона в наговнокоженых либах, адским сотоной (: тщательно выбираем что надо тащить в проект, а что нет

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