> Какие проблемы в самом языке?

Я про это ещё год назад писал.

Школапень - У python-а низкий “порог вхождения” по этому часто приходится сталкиваться с разработчиками низкой квалификации.
Динамическая типизация - Для школапени она в радость, но для больших проектов наиболее подходит статическая типизация с выведением типов.
Многопоточность - Можно писать только конкурентные приложения.
Интерпретатор - Приходится таскать интерпретатор, проблемы с дистрибьюцией.
Тормоза - Скорость не очень.

FishHook
Ядро - это все таки интерпретатор

Ты путаешь понятия “язык” и “реализация языка”. Интерпретатор - это реализация языка. А язык - это просто грамматика. Язык есть, а реализаций может вообще не быть ни одной. И вот у языка есть ядро, а есть периферия. Ядро - то, что остаётся неизменным, а периферия - то, что может меняться. Без ядра язык существовать не может, а без периферии - может.

Можешь ли ты открыть какой-нибудь интерпретатор питона и не найти там функцию len() или класс int? А вот можешь ли ты открыть какой-нибудь интерпретатор питона и не смочь импортировать туда какой-нибудь модуль (даже стандартный)? Запросто. Бывают такие обрезанные питоны, где нет библиотеки. Но это всё равно питоны, потому что ядро есть.

Rodegast
Школапень - У python-а низкий “порог вхождения” по этому часто приходится сталкиваться с разработчиками низкой квалификации.

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

Rodegast
Динамическая типизация - Для школапени она в радость, но для больших проектов наиболее подходит статическая типизация с выведением типов.

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

Rodegast
Многопоточность - Можно писать только конкурентные приложения.

Сделали async - что-то меняется в лучшую сторону. Да часто ли ты на питоне параллелишь программы? Для параллельных программ лучше другие языки брать.

Rodegast
Интерпретатор - Приходится таскать интерпретатор, проблемы с дистрибьюцией.

Есть и другая сторона - развитый REPL, не сравнить с другими языками. Хотя REPL'ы есть и у Ruby, Perl, Lisp, Erlang, Haskell. Но питоновский гораздо развитее этих реплов, по UX он их обгоняет. Очень часто мы подолгу сидим в репле питона и даже этого не замечаем. А сидим мы в нём потому, что он удобный (высокий UX).

Rodegast
Тормоза - Скорость не очень.

Что у тебя тормозит?

py.user.next
Ты путаешь понятия “язык” и “реализация языка”. Интерпретатор - это реализация языка. А язык - это просто грамматика. Язык есть, а реализаций может вообще не быть ни одной. И вот у языка есть ядро, а есть периферия. Ядро - то, что остаётся неизменным, а периферия - то, что может меняться. Без ядра язык существовать не может, а без периферии - может.

Это ты путаешь и сам себе противоречишь. У языка, как набора синтаксических правил, не может быть “ядра” и “периферии”. Набору правил глубоко пофигу, будет ли какая-то функция стандартной или подключаемой и будет ли она реализована вообще. Язык оперирует самим понятием “функция” и только. “Ядро” и “периферия” лежат исключительно в плоскости реализации.

FishHook
“Ядро” и “периферия” лежат исключительно в плоскости реализации.

Вот язык
https://docs.python.org/3/reference/index.html
Вот куски грамматики идут
https://docs.python.org/3/reference/simple_stmts.html#expression-statements

А вот библиотека
https://docs.python.org/3/library/index.html
Входит она в язык? Не входит.

Но мы можем определить старое определение языка как “ядро языка”, а библиотеку - как “периферию языка”. И потом мы определяем “язык питон” как “ядро языка” + “периферия языка”.

При этом реализация нам не нужна для этого, мы его и так видим в воображении. Да и реализовать мы его можем на каждой отдельной операционной системе индивидуально для этой системы. Язык - это не реализация языка, а сама идея и её детали.

py.user.next
Ты опять не видишь, как сам себе противоречишь? Ну на здоровье.

FishHook
Ты опять не видишь, как сам себе противоречишь?

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

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

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

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

doza_and
Ну на этот раз он прав.

Кто именно?

doza_and
Язык определяется описанием синтаксиса и семантики.

С точки зрения py.user.next, язык определяется еще и составом встроенных функций, так сказать (цитата) ядром.

> На C, и особенно на C++, я повидал немало таких ребят. От популярности языка это зависит только.

Зависит от “порога вхождения”. Все учителя, врачи, водопроводчики и прочие люди решившие стать программистами (в основном из-за того что программисты типа много зарабатывают) начинают учить python.

> Динамическая типизация имеет ряд преимуществ над статической типизацией

Вот по этому я указал что должен быть автоматический вывод типов.

> Сделали async - что-то меняется в лучшую сторону

Ну async это ни разу не параллельность.

> Есть и другая сторона - развитый REPL, не сравнить с другими языками

Что-то я этого не замечал.

> Что у тебя тормозит?

Нет, но только потому что для ресурсоёмких задач я python не использую.

> интересно получить ссылки на исследования в которых показана более низкая средняя квалификация разработчиков на питоне.

Мы сейчас проблемы Python-а обсуждает. И проблема низкой квалификации вполне актуальна, а исследование тебе никто не проведёт. Это не возможно.

> Я не вижу разницы в таскании интерпретатора или таскании динамических библиотек.

Тогда посмотри на количество тем в которых спрашивают про то как сделать exe-шник. А всё потому что программа для запуска которой нужно что-то доустанавливать выглядит неполноценной.

Rodegast
Ну async это ни разу не параллельность.

Что же, по-твоему, такое “параллельность”?

Rodegast
Зависит от “порога вхождения”. Все учителя, врачи, водопроводчики и прочие люди решившие стать программистами (в основном из-за того что программисты типа много зарабатывают) начинают учить python.

Программистами пытаются стать чаще всего экономисты. Лингвистов-гуманитариев в расчёт не берём, так как они, как правило, просто хотят одну программку написать, потому что она им нужна. Экономисты же пытаются на этом сделать денег и очень фонтанируют идеями, не понимая, что простое окно программы и содержимое под капотом - совершенно разные вещи.
Так вот, на C++ таких генераторов идей тоже немало. Обычно это в Visual Studio ещё происходит в виде формошлёпства с умным видом. :)
Но самое ужасное - это сисадмины, таких спорщиков сложно убеждать в том, что они нихрена не шарят и что их код на страницу можно сократить до трёх строк, слегка подумав. Ну типа они же 20 лет сисадминят - а значит, программируют неплохо, пару недель им надо посидеть и станут программистами. :D

Rodegast
Что-то я этого не замечал.

ipython3 попробуй поюзать, там можно и время через timeit внутри замерять, и редактировать предыдущие коды.
Но я про обычный классический репл, который был сделан изначально, чтобы в нём подолгу можно было сидеть и всё было понятно.
Помнишь эту идею “вы можете использовать питон как калькулятор”? Это же неспроста заявлено. Это, действительно, так и есть. Он очень быстро используется для быстрых проверок кода, для применения как калькулятора, наличие интроспекции, функций help() и dir() - это всё не просто так само сделано.
Haskell в этом плане тебе ничего не покажет; там можно только код выполнить, немножко сообщение прочитать, если ошибка, но сидеть там подолгу, черпая информацию, - это не для него.

Rodegast
Нет, но только потому что для ресурсоёмких задач я python не использую.

Ты должен знать, что у тебя тормозит. Очень часто питон переводят на сишный бэкграунд. В пример можно привести collections.Counter(), который раньше я не юзал из-за его 17-кратной медленности по сравнению с обычным словарным включением. Но сегодня он переписан уже и нужно юзать только его.