История изменений

Так всё-таки зачем питона мучать? В твоем положении это как раскачивать вагон, надеясь что весь поезд перепрыгнет на соседние, «правильные», рельсы

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

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

Здесь не так мало людей, которые всерьез считают, что «правильные» рельсы — это что-то вроде лиспа. Или хаскеля, мол, для прототипирования самое оно, ага: лаконичный синтаксис, «не нужно думать» о проверке корректности, «просто пишешь» что тебе нужно и реагируешь на экраны текстов ошибок, которые тебе выдает компилятор.

Если внимательно присмотреться к диалектам питона, то можно увидеть, что они просто-напросто реализуют подмножество питона. Они не так уж и далеки от питона. Например, мое предложение о новом синтаксисе передачи блоков кода делает ненужными старые лямбды, менеджеры контекстов, list comprehension, и декораторы. Просто херак — и вместо четырех специализированных конструкций одна универсальная. Как натянуть это дело на наследие питона — оч хороший вопрос. Например, как в Unladen Swallow и его наследнике PyPy, делать несколько уровней компиляторов-интерпретаторов.

Но, блин, нужно было годами методично и беспощадно вырезать из языка все кривые фичи и паталогические подходы к кодописанию — вот прямо то, ради чего я начал писать тред. Эдакий аналог «strict mode» из JS. А этого никто не делал 30 лет, хотя бы потому, что язык все эти 30 лет толком никто не поддерживал и не развивал: тут подопрем костылем, здесь подперем, а проблемы решать не будем. Ведь даже в PHP стандартную либу переписывали, но не в питоне.

По-моему, Дзеном питона должно быть «мне похер, это ваша проблема». Если ты посмотришь на все изгибы исторического следа питона, то они идеально подходят под этот лозунг. То есть, медленно работают опреации над матрицами? Мне похер, это ваша проблема — пиши расширения специально для матриц. Криво реализован синтаксис или функция стандартной либы? Мне похер, это ваша проблема — самое смешное то, что ведь интерпретатор не зависел от браузеров, как это было в случае JS. Как реализовать оператор, полиморфным по двум операндам? Мне похер, это ваша проблема. Как реализовать многопоточность? Мне похер, это ваша проблема — делайте ad-hoc на C/C++ или многозадачность, которая ползает еще медленнее (куда еще, казалось бы) чем обычный однозадачный питон.

И вот я вылажу со своей либой для многозадачности в разделяемой памяти, а на меня смотрят как на сумасшедшего: «ты что, не слышал про дзен питона?». Всем похер, а тебе не похер — куда ты прешь против паровоза? Но все же хочется эту карту разыграть. Я получил на неоптимизированных разделяемых структурах данных одну четвертую от производительности заоптимизированного вхлам однопоточного питона. Эти структуры не обязательно должны быть ограничены CPython — можно натянуть их на какой-то диалект или схожий язык. Какой? Я пока что так и не придумал. Вплоть до того, что лепить свой собственный диалект питона, но тогда возникает проблема с готовыми решениями. точнее, их отсутствием. Ух, близко локоток, да не укусишь.

Так всё-таки зачем питона мучать? В твоем положении это как раскачивать вагон, надеясь что весь поезд перепрыгнет на соседние, «правильные», рельсы

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

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

Здесь не так мало людей, которые всерьез считают, что «правильные» рельсы — это что-то вроде лиспа. Или хаскеля, мол, для прототипирования самое оно, ага, лаконичный синтаксис, «не нужно думать» о проверке корректности, «просто пишешь» что тебе нужно и реагируешь на экраны текстов ошибок, которые тебе выдает компилятор.

Если внимательно присмотреться к диалектам питона, то можно увидеть, что они просто-напросто реализуют подмножество питона. Они не так уж и далеки от питона. Например, мое предложение о новом синтаксисе передачи блоков кода делает ненужными старые лямбды, менеджеры контекстов, list comprehension, и декораторы. Просто херак — и вместо четырех специализированных конструкций одна универсальная. Как натянуть это дело на наследие питона — оч хороший вопрос. Например, как в Unladen Swallow и его наследнике PyPy, делать несколько уровней компиляторов-интерпретаторов.

Но, блин, нужно было годами методично и беспощадно вырезать из языка все кривые фичи и паталогические подходы к кодописанию — вот прямо то, ради чего я начал писать тред. Эдакий аналог «strict mode» из JS. А этого никто не делал 30 лет, хотя бы потому, что язык все эти 30 лет толком никто не поддерживал и не развивал: тут подопрем костылем, здесь подперем, а проблемы решать не будем. Ведь даже в PHP стандартную либу переписывали, но не в питоне.

По-моему, Дзеном питона должно быть «мне похер, это ваша проблема». Если ты посмотришь на все изгибы исторического следа питона, то они идеально подходят под этот лозунг. То есть, медленно работают опреации над матрицами? Мне похер, это ваша проблема — пиши расширения специально для матриц. Криво реализован синтаксис или функция стандартной либы? Мне похер, это ваша проблема — самое смешное то, что ведь интерпретатор не зависел от браузеров, как это было в случае JS. Как реализовать оператор, полиморфным по двум операндам? Мне похер, это ваша проблема. Как реализовать многопоточность? Мне похер, это ваша проблема — делайте ad-hoc на C/C++ или многозадачность, которая ползает еще медленнее (куда еще, казалось бы) чем обычный однозадачный питон.

И вот я вылажу со своей либой для многозадачности в разделяемой памяти, а на меня смотрят как на сумасшедшего: «ты что, не слышал про дзен питона?». Всем похер, а тебе не похер — куда ты прешь против паровоза? Но все же хочется эту карту разыграть. Я получил на неоптимизированных разделяемых структурах данных одну четвертую от производительности заоптимизированного вхлам однопоточного питона. Эти структуры не обязательно должны быть ограничены CPython — можно натянуть их на какой-то диалект или схожий язык. Какой? Я пока что так и не придумал. Вплоть до того, что лепить свой собственный диалект питона, но тогда возникает проблема с готовыми решениями. точнее, их отсутствием. Ух, близко локоток, да не укусишь.