Чем плох Python?

Это js? Не очень в курсе что там в js происходит, но если в питоне выполнить async def без await, то ничего выполнено не будет, если возвращённое значение (coroutine object) так или иначе не скормить евентлупу (asyncio.run, asyncio.create_task итд). Если нужно выполнить корутину тут же на месте и получить результат, то обязателен await.

Это js?

Ага.

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

Цель была добавить треды в язык. Они позволяют делать интересные вещи, например одновременно исполнять raw_input() и socket.read() на платформах, где stdin нельзя засунуть в select.

Для многопоточности нужно чтобы два потока одновременно не писали в reference counter’ы, чтобы треды не видели списков смотрящих на неинициализированную память, пока другой тред работает над списком, и всякое такое. Добавлять локи в каждый объект получилось тормознуто. Перелопачивать подсчёт ссылок на другой механизм ломало расширения, которых к тому моменту уже было некоторое количество.

И это были 90-е, многопроцессорные машинки большинство видело только в рекламных буклетах компаний торгующих большими и дорогими серверами с собственными ОС. Поэтому сделать так чтобы больше одного ядра не могло одновременно выполнять байткод казалось разумным компромиссом, т.к. у большинства компьютеров, на которых пускали питон, только это одно ядро и было.

let foo = async function(x)

Бр-р-р, мерзкий жаваскрипт, а мы говорили про питон. Впрочем, аргумент валидный — в JS нет подобной необходимости протаскивать всю асинхронщину через await, но, тем не менее, асинхронщиной пользуются. Но там асинхронщина до недавних пор была единственным инструментом многозадачности, потому можно сказать, что это устаревшее наследие.

Реально я не вижу сейчас причин не использовать js как ЯП общего назначения, в том числе для логики внутри приложений, для скриптов локалхоста, или для написания самостоятельных консольных приложений, например

Низкая модульность, как в случае с питоном, по причине использования изменяемых структур данных в качестве фундаментального типа данных. Даже V8 в своих оптимизациях полагается на неизменяемые структуры, транслируя JS в работу с ними — так зачем было строить язык на неудобных структурах данных изначально? Все эти новомодные React, Vue, и языки Elm, ClojureScript, ReasonML по сути решают эту одну-единственную проблему — как изолировать побочные эффекты одного модуля от побочных эффектов другого модуля. Даже TypeScript отчасти преследует эту же цель. А без этого проект на 100k строк уже становится неподдерживаемым.

По этим причинам в качестве языка веба будущего выбрали именно WebAssembly — создатели просто отказались от выбора парадигмы среды программирования, чтобы снова не попасть в ту же ловушку, в которую попал JS.

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

Там проблема в том же, что и в CPython — без наследия JS мало кому нужен. Это не только библиотеки, но еще и бесконечный поток индусов.

Индусы переучатся, они резвые :)

Так что ж получается, F# без макросов взлетел, а Nemerle с макросами — нет?

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

Для хобби тоже не подходит, ибо после работы мозг уже не соображает и если и программировать, то на чём-то простом. Тут лучше взять PHP или Python. Тем более, что с их помощью можно какой-нибудь полезный сайтик сделать, а не только в очередной раз по хитрому посчитать числа Фибоначчи.

Цель была добавить треды в язык. Они позволяют делать интересные вещи, например одновременно исполнять raw_input() и socket.read() на платформах, где stdin нельзя засунуть в select

Вроде каких? Винды, что ли? На винде вообще нет select-а, там другие функции для ожидания файлов. На никсах описываемой тобой проблемы нет.

Я хотел бы подчеркнуть, что у питона вообще слабая поддержка винды. Например, с не-ASCII символами в виндовой консоли питон очень не дружит, за за много лет этого никто не исправил. Да что там — в релизных версии 3.7.Х питона не ставились отладочные пакеты и отладочные конфигурация сишных расширений на MSVC вообще не собирались. То есть, на винду конкретно забили. Питон изначально был unix-only, он и остался unix-only, с сильно опциональной возможностью таки как-то запустить что-то на винде, но именно «что-то» и без каких-либо гарантий.

И это были 90-е, многопроцессорные машинки большинство видело только в рекламных буклетах компаний торгующих большими и дорогими серверами с собственными ОС. Поэтому сделать так чтобы больше одного ядра не могло одновременно выполнять байткод казалось разумным компромиссом, т.к. у большинства компьютеров, на которых пускали питон, только это одно ядро и было

Все-таки я хотел бы подчеркнуть, что многопроцессорные компы до релиза питона существовали уже лет так 20-30, пусть и были дорогостоящими, так что оправданий тому, что кто-то там не спроектировал архитектуру хотя бы на 5 лет вперед — нету.

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

Бр-р-р, мерзкий жаваскрипт

Сам его недавно нахваливал :-P

а мы говорили про питон

Тут уже запутаться не сложно, в какой ветке что.

По этим причинам в качестве языка веба будущего выбрали именно WebAssembly

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

Индусы переучатся, они резвые

Ну и где твой массовый рынок индусов под WAsm?

Так вся суть в том, что старый код работает как старый, а слегка адаптированный он же работает быстрее. А не вкорячивается совершенно новый стек. Ждать пришествия wasm это как ждать пришествия немерле.

Предпосылок для революционных перемен не видно.

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

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

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

Семера по прежнему очень популярна, все браузеры ее поддерживают, разве что у ноды поломали совместимость с 14-й версии, и то не особая беда. Да, это наследие, но вся винда вообще — это наследие, будущего у самой по себе у нее нет, и даже сам MS это понимает, выкидывая поддержку старого GUI из своих новых компактных версий десятки, таким образом сам MS ломает совместимость винды со старым софтом. А для всего остального семерки выше крыши.

мне и хп было выше крыши, но ПО порешало. семерку ждет та же история.

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

мне и хп было выше крыши, но ПО порешало. семерку ждет та же история

Разница в том, что семерка была лучше XP. Но восьмерка и десятка оказалась настолько хуже, что даже девять лет спустя У семеры 17%, а у восьмерки — едва 4%. По этой причине в ближайшие 2 года семерка никуда не денется, и софт не перестанет ее поддерживать.

Ну и где твой массовый рынок индусов под WAsm?

Уже пишут на знакомых им языках.

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

С++ ? ;)

Но восьмерка и десятка оказалась настолько хуже

Ну, кроме отсутствия драйвера сканера Xerox 3100, IMHO без разницы. Отсутствие выпуклого «дизайна» - вообще плюс.

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

С++ ?

Да нету там толком макросов. Разговор был именно про макросы лиспа, и почему их нет в F#. Вот, в Nemerle, вроде как, добавили лисповые макросы — а язык не взлетел. Как так? Kogrom опарвдывает это тем, что «макросы — это слишком сложна», но как-то не очень убедительно это звучит.

это очень субъективное мнение (:

холивар разводить не будем

ну и так-то https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide

И всё, питон умирает

Не, ну после VBA всё равно очень хорошо.

Если ты с велика садишься на чепырку, то хорошо.
А если с мерседеса на чепырку, то не очень.

Я Пыхтон узнал после Ruby, отсюда вся боль.

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

О, я тоже так делаю.

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

Это всё-таки ООП на прототипах

https://github.com/justjake/quickjs-emscripten

Это просто бомба.

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

Какие-то горе-изобретатели: собирают интерпретатор байткода под wasm и чтобы гонять JS в нём!!!

Горите в огне! 🔥 🔥 🔥

Чтобы

def one
    "This is the new one"
end

было объектом первого класса.

А стрелки на питон не переводи, питон в этом треде никто не позиционировал как носителя Ъ-ООП.

Потому что чек-лист Алана Кея начинается с «Everything is an object».

Есть ли жизнь на Ruby? Да. ООП-ли это? Да. Стоит ли его приводить в пример «Ъ-ООП»? Нет, видали и поЪевее.

Ок. А что Ъ? Смолток?

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

Это как раз нормальный режим. Человек пошурудил мозгами часик-другой, и среда исполнения развернула его 20 строчек в 2K императивной лапши. Но индустрия куда-то в обратном направлении пошла, и теперь нужно сидеть 8 часов копипастить if err != nil, ведь даже исключения это уже слишком сложная магия.

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

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

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

Да вот есть же Crystal. Там сразу и не поймешь, что многое сделано на макросах. С виду динамическая скриптуха, а на самом деле нет. Правда эти макросы читать тоже то ещё удовольствие. Или вот раст, там очень аккуратненько используют макросы. Правда я не в состоянии их распарсить и как-то понять, но это проблемы неосилятора. А чтобы макросы были читабельны и естественно укладывались в язык, это нужно быть лиспом.

Не эксперт в смоллтоке, рассуждать о нем не стану. Остановлюсь на «точно не руби».

Ну здрасьти, ваш пафос был в том, что ООП в питоне оопнутее.

Ну здрасти. Где это я такое утверждал? В питоне свои тараканы размером с айсберг.

В этом треде уже восемь страниц обсуждаем, какой плохой Питон, и хотелось бы уже закончить каким-нибудь конструктивным выводом. Какой ЯП может стать в будущем наиболее адекватной заменой питону? С учетом того, что это не только CPython, но и вся экосистема, выросшая вокруг него за последние годы - jupyter, numpy, scipy, pandas, keras, matplotlib, sqlalchemy и еще 300к проектов на pypi.org

Какой ЯП может стать в будущем наиболее адекватной заменой питону?

Одновременно во всех питоновских нишах - никакой. В некоторых нишах адекватная замена есть. Например, часто критикуются небольшие утилиты с GUI за то, что для их написания был выбран Python.

numpy, scipy, pandas, keras, matplotlib

Рассуждения на тему.

1. Был у меня на работе подрядчик, которому надо было написать прототип ПО для машинного зрения. Они говорили: какой ещё Питон, какое numpy, только Матлаб!
2. Наверное, процентов 90 этих библиотек написано на си. Теоретически, можно было бы эту часть прикрепить к другому языку, например, к Ниму. 10 % усилий - и мы имеем новую экосистему. Были бы ресурсы.
3. Ну и можно вспомнить про Delphi и Flash (ActionScript). Я считаю, что адекватных замен им нет. И ничего, все пользуемся неадекватными.

Современный python вполне себе успешно заменил делфи - во всяких мелких конторках, где на делфи раньше писали sql-запросы, теперь пишут их на питоне. Современный Javascript+html5 успешно и адекватно заменил flash - браузерные игры раньше писали на флеше, теперь на жаваскрипте. Самый яркий, по-моему, пример https://play.decentraland.org/

Kogrom: Питон плохой, кривой и неудобный

Я: дайте адекватную замену питону, чтобы я переписал свой маленький проектик, который при помощи pandas получает данные, через numpy обрабатывает и через matplotlib в jupyter’е отображает

Kogrom: нуу, теоретически, можно, например, прикрутить nim…

Нет. Это замены, но не адекватные.

1. В Delphi было нормальное GUI из коробки, приложения не требовали интерпретатора.
2. Во flash был нормальный векторный редактор.

Kogrom: Питон плохой, кривой и неудобный

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

Я: дайте адекватную замену питону

Нет. Вопрос был такой:

Какой ЯП может стать в будущем наиболее адекватной заменой питону?

В будущем же. Вот я и рассуждаю про будущее.

Какой ЯП может стать в будущем наиболее адекватной заменой питону?

Никакой, так и будем теперь 100 лет с питоном страдать. Примерно так рассуждали про дельфи и VB, а потом оно как-то резко исчезло с радаров. Думаю, если Go немножко доработают, то вот он и убийца питона.

Ну и можно вспомнить про Delphi и Flash (ActionScript). Я считаю, что адекватных замен им нет. И ничего, все пользуемся неадекватными.

Кстати да.

Мода пройдёт, и всё. Резко превратится из «хайповый язык для всего» в «фу, старое легаси с залежами гигабайт старинного кода».

Жизнь переменчива.

У F# адекватная поддержка только на винде (как и у других малопопулярных решений на базе дотнета)

А разве это:

https://fsharp.org/use/linux/

https://docs.microsoft.com/en-us/dotnet/core/install/linux

неадекватная поддержка?

Из любого DotNet языка можно использовать питоновские либы даже in-process:

https://libraries.io/nuget/pythonnet_netstandard_py39_linux

А также и либы многих других ЯП:

PHP: https://www.nuget.org/packages/Peachpie.Runtime/

PowerShell: https://docs.microsoft.com/en-us/powershell/scripting/developer/hosting/addin...

Perl (через Cишку): https://perldoc.perl.org/perlembed

Perl RegEx: https://www.nuget.org/packages/PCRE.NET/

JS: https://github.com/Taritsyn/JavaScriptEngineSwitcher

Java: https://docs.elementscompiler.com/Iodine/

GO: https://docs.elementscompiler.com/Gold/

По индекску Tiobe: https://www.tiobe.com/tiobe-index/

C#+VB.NET в сумме близки к 4-му месту, а судя по трендам в будущем могут претендовать даже на 2-3 места, т.е. обогнать Java. Мало того, они понемногу заходят и на территорию JVM, потому что компиляторы RemObjects могут компилить код на этих языках и для JVM.

VisualBasic.NET к сожалению больше не развивается в недрах Microsoft, но хотя бы поддерживается ими в новых релизах DotNet.

Зато VisualBasic.NET теперь развивается в компании RemObjects: https://www.elementscompiler.com/elements/mercury/

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

А под процедурным и вовсе маш. коды, так что давайте не будем усложнять до псевдо ООП, а будем кодить в true шестнадцатиричных кодах.

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

Так ведь над POCO обычно надстраивают еще какой-то слой классов бизнес логики?

Плох только тем что иногда его неправильно используют.

Там мертвый Fortran на 64 году жизни из могилы руку высунул и Perl обогнал, как и Go с Ruby...

Охренеть.

А перл ожидаемо давно мёртв.