Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 115
Закреплённые комментарии
Если считать по описанной в статье методике, то доля прикладных конструкций в Julia чуть меньше половины - 46.6%. Это немного выше, чем у C++ или Rust, но почти вдвое меньше, чем у Python.
Причем грамматика у Julia точно так же перемешана как в С++ (прикладные и системные макросы и ключевые слова используются вперемешку, чем Rust отличается от них в лучшую сторону, у которого системные термины лексически сгруппированы преимущественно в атрибутах).
В основе Python, как и совершено любого другого языка программирования, много чего лежит. Это и идеология, архитектура, синтаксис, стандартная библиотека, дополнительные библиотеки, расширения, экосистема и т.д.
Но в случае с Python и различными математическими и матричными вычислениями - все совершенно прозрачно. Просто перейдите на https://ru.wikipedia.org/wiki/NumPy#История и почитайте, сколько лет потребовалось на переделывание интерфейса математической библиотеки и на его реализацию, чтобы в результате получился всем известный NumPy, который и был включен в Python, как часть проекта.
И только после этого любые другие библиотеки стали придерживаться идеологии NumPy, которая разрабатывалась годами, задолго до возникновения ML бума. Поэтому "На Питоне просто немного короче получается. " - это принципиальное следствие идеологии Python, а вовсе не случайна причина его успеха.
Поэтому говорить в сослагательном наклонении бессмысленно. Считается, что на Fortran написано больше всего математических библиотек, но большинство почему то используют Python. И у того же самого PyTorch - не расскажете, что означают первые две буквы этой С++ библиотеки?
Вы писали, что лежит в основе. В основе лежит не Python.
У вас странное утверждение. В основе Python лежит именно Python, с его идеологией и синтаксисом. И чтобы библиотеке стать частью Python, она должна соответствовать всем этим требованиям, т.е. нужно адаптировать API библиотеки под философию и возможности языка, но никак не наоборот.
Python структурно ориентирован на предметную область почти втрое сильнее, чем C++ или Rust
Ориентированность на предметную область определяется только количеством ключевых слов? Тогда по ориентированности условный Brainfuck оставляет Python далеко позади
Это только меня напрягает:
Python 43 35 9 81%
???
Как-бы: 9 + 35 = 44
Сарказм: может поэтому питон и нравится автору: подогнать можно под любой ответ!?
Какая "глубокая по силе" статья! Браво, автор, взять списки ключевых слов, произвольно поделить их на «прикладные» и «системные», получить красивые проценты, из чего сделать вывод, что Python «структурно ориентирован на предметную область почти втрое сильнее» и поэтому «никогда» не будет заменён.
Приплести сюда реальность ML-стека - мать моя женщина...
Практически весь производительный код современного ML написан не на Python:
-Ядро PyTorch (ATen, CUDA-ядра) - C++/CUDA.
-NumPy - по большей части C.
-Tokenizers, safetensors, многие высокопроизводительные компоненты Hugging Face - всё чаще Rust.
-Production inference, high-frequency и низколатентные системы - C++/Rust/CUDA.
Python выигрывает как язык-клей и язык прототипирования, а не как язык, на котором реально крутится тяжёлая математика. Это классическая проблема двуязычия, которую пытаются решать Julia, Mojo, Swift for TensorFlow и т.д. И делать вид, будто её не существует - очень некрасиво по отношению к читателю.
Утверждать, что C++ или Rust «никогда не смогут заменить Python» это всё равно что утверждать, что Python «никогда не сможет заменить C++ в ядрах ОС или драйверах».
Бред короче
С++ библиотеками можно пользоваться и на самом С++, но для прототипирования это действительно очень неудобно. И да, проблемы нескольких языков несомненно существует и я пишу про ее причину, а не просто как как констатацию факта.
Утверждать, что C++ или Rust «никогда не смогут заменить Python» это всё равно что утверждать, что Python «никогда не сможет заменить C++ в ядрах ОС или драйверах».
В ядрах ОС этот самый С++ обычно не используется
Поддержу. Тут скорее Пайтон поменяют , если найдется более удобный, простой и быстрый язык (например, который можно писать голосом , на естественном языке - хотя возможно с учетом нейронок , мы к этому придем )
Python поменяют на С++, если на нем можно будет писать голосом? Вы в самом деле так думаете? :-)
Мне кажется речь скорее была про то что питон поменяют на что то более удобно для "не-хардкорного-инженера", и всякие МВП, МЛ, научные исследования от слабых программистов но сильных в своей (любой) области ученых и тд и тп уйдут с питона на это самое "удобное", а вот все ядра, внутренности того "удобного", высоконагруженное и т.п. прдолжат писать на плюсах/расте сильные программисты (но слабые как ученые). И это сейчас существующее разделение останется таким же какое оно естт, просто одна из сторон поменяет свой инструмент
Я и не утверждаю, что Python предел совершенства. Но мне было интересно понять, почему один язык оценивается как “сложный”, а другой “простой”. Понятно, что многое зависит от задачи и от знаний пользователя, но все равно общее мнение об удобстве Python должно же чем то объясняться? Вот я и попробовал оценить сложность синтаксиса подобным образом.
Язык - это инструмент. Если инструмент 1 лучше подходит для работ по металлу, а инструмент 2 - для работ по дереву, то резать доски можно и первым, но зачем?
Очень плохой пример, чтобы резать доски нужна высокая скорость, иначе вы будете не резать дерево, а рвать его. С другой стороны для металла высокая скорость приведёт к нагреву и разрушению пилы. Ну и сами зубья разные, пила по металлу просто перегреется на дереве и разрушится.
Но ваше утверждение правильно для сверел, сверлами для металла сверлят дерево, это не так удобно как сверлами по дереву
При понятном посыле статьи, примеры на C++/Rust притянуты за уши. Раз уж тут псевдокод, то ловите функциональный аналог питоновской версии на C++
for( const auto& batch : dataloader) {
auto logits = classifier(batch.features);
auto loss = cross_entropy(logits, batch.labels);
loss.backward();
optimizer.step();
}и на Rust
for batch in dataloader {
let logits = classifier.forward(&batch.features)?;
let loss = cross_entropy(&logits, &batch.labels)?;
/// ...
}
Тоже глаза резануло. В результате главный тезис статьи очень сильно проседает. А если еще, в С++ и Rust, позволить программе паниковать если какой-то функции ее собственный результат не понравился, так и вообще мало, что остается.
Весь псевдокод предполагает некоторые допущения. В вашем случае, допущением является отсутствие необходимости в обработке ошибок в коде на С++, тогда как обработка ошибок в Python уже реализована в вызываемых инструментах. Тоже самое и с Rust. Что будет в случае возникновения ошибки?
И в Rust, и в C++ ничего дополнительно делать не нужно. Уже в псевдокоде всё работает "из коробки" - ошибки уже корректно обрабатываются:
В C++, как и в python, кидается exception
В Rust стандартный возврат результата через Result: https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#the--operator-shortcut
В Rust ошибки уже обрабатываются оператором ?.
Примеры красивые – правда, `///` в Rust это doc-комментарий, и компилятор споткнётся о него раньше, чем дойдёт до обучения. По-моему, отличная иллюстрация к самой статье: в Python оборванный цикл просто отработает, а тут вы сначала полчаса объясняете компилятору, что вообще имели в виду. Краткость записи и краткость пути до результата – это разные краткости.
В том-то и дело, что полный код и на Rust, и на C++ будет безусловно сложнее, но не там, где ищет автор статьи.
Заметно усложнится библиотечный код - и большая часть боли будет там. Появятся нетривиальные сигнатуры, потребуется явно продумать систему типов, преобразования типов ошибок и т.п. В случает плюсов отдельная боль будет, чтобы настроить сборку и просто всё собрать со всеми зависимостями
Вы правы. Просто в случае С++ вы используете библиотеку с помощью её внутреннего API и всех возможностей зыка разработки. Тогда как в случае Python, разработчик обязан адаптировать внешний API библиотеки к возможностям целевого языка, т.е. сделать его достаточно простым. А это в свою очередь и определяется возможностями синтаксиса Python.
непонятно зачем люди сложно пишут на с++ если можно писать сильно проще. стреляют в колено, когда пишут на с++ образца старых годов или используя синтаксис С
У С++ ключевая фишка - сохранение обратной совместимости
Которая к сожалению не очень работает. Во-первых разные компиляторы и даже разные версии компиляторов могут по разному интерпретировать тот же код. Во-вторых если некоторые методы просто помечали как deprecated на более свежих версиях, то сейчас некоторые варианты методов начинают просто удалять. В-третьих старые методы и шаблоны могут становиться даже вредными, как в случае с make_shared, что создавался убрать проблему порядка формирования указателей в аргументах методов, а потом порядок решили стандартизировать, а make_shared оказывается теперь может привести к некоторым проблемам (что именно не помню, была статья тут)
Рискую кармой, но присоединюсь - меня задела проблема совместимости, правда только совместимость компиляторов, но тем не менее. Я долгое время писал программы использую компилятор от майкрософт, часто прибегая к использованию шаблонов. И кто мог знать, что мсвц значительно мягче относится к
синтаксису шаблонов?
О чем я. Когда я попробовал собрать свою либу на gcc или кланге, то мне начало выдавать пелену ошибок связанную с шаблонами, я долго не мог понять в чем конкретная проблема, а оказалось, что мсвц позволяет опускать написание typename к обращению в зависимое имя. Я имею ввиду:
template<typename T>
class SomeClass {
using field = typename T::some_field;
}То есть комилятор позволяет опустить typename в некоторых контекстах, то же касается и template если сама сущность из зависимого имени является шаблонной. И кто знает сколько еще такого есть у каждого компилятора?
Кто-то скажет мол пиши правильно всегда, но проблема в том, что ты узнаешь об этом когда переходишь на другой компилятор(если не очень опытный разработчик с++), но как часто вы меняете компиляторы? Может это я самоучка такой неправильный, но для меня это стало неприятным осознанием. И теперь другой вопрос, неужели я один такой на свете кто столкнулся с такой проблемой? Типа кто то грузит свои либы без тестов, и тоже может не знать об этом. Если с++ так славится своей обратной совместимостью, то почему я должен проверять сборки под каждый компилятор?
Как минимум сборка под какой-то компилятор уже сейчас не гарантирует совместимость
Смена компилятора, даже внутри одной линейки, это сложно для нетривиальной кодовой базы. Ошибки компиляции только вершина айсберга, да и бороться с ними не так сложно. Гораздо опасней UB, которые могут проявляться по разному. То есть код успешно будет собираться, но приложение собранное одном компилятором работает "нормально", а собранное другим периодически крешится
Это в большей степени не про обратную совместимость, хотя и в рамках одной линейки компиляторов от версии к версии подобные приколы бывают. Лечится только тестированием сборок под разными компиляторами, санитайзерами, статическими анализаторами и т.п.
И вы не один такой. Если пробовать читать исходники библиотеки типа boost, которая работает на широком наборе компиляторов разных версий, то можно увидеть много приседаний для поддержки работоспособности
Вряд ли ваш случай, это проблема обратной совместимости в части С++ стандарта. Это скорее особенность компилятора, тем более MS славятся подобными подлянками.
Это расширение MSVC, причём принятое не так давно в стандарт, если не ошибаюсь
Как по мне, так на математику это совсем не похоже
for batch in dataloader:
logits = classifier(batch.features)
loss = cross_entropy(logits, batch.labels)
loss.backward()
optimizer.step()
Особенно последние две строчки. Мутабельный loss? Optimizer на каких-то скрытых сайд-эффектах и глобальных переменных? Совершенно непрозрачно.
А по поводу простоты синтаксиса и количества ключевых слов можно вспомнить Scheme. Там нет ни синтаксиса ни ключевых слов, и выглядит он гораздо понятней и математичней.
Питон может быть и будет заменён ruby. Потому, что
руби более простой язык для программиста.
он быстрее в исполнеии
он имеет прекрасные средства не только тестирования, но и одновременно документации кода.
разработка на нём примерно в 2 раза быстрее, чем на питоне.
Проблема только в том, что преподаватели в школах выучили python и не выучили ruby, поэтому они обучают первому языку, а не второму.
Руби - это язык для программистов, тогда как Python преимущественно для обычных пользователей.
Это очень большое заблуждение. Для "обычных" пользователей освоить ruby на порядок проще, чем python..
Это “заблуждение” хотелось бы как нибудь обосновать, а то придется спорить насчет цвета и вкуса фломастеров.
Руби был сконструирован под то, как мыслит человек. К тому же как объектно-ориентированный язык, каковым питон не является, хотя умеет прикидываться таковым.
Для примера, пусть у нас есть коллекция людей. Нам надо из неё выбрать всех тех, чья фамилия начинается на "пу" или "зе" и отсортировать их по имени. На руби это будет выглядеть так:
collection.select{|person| %w[пу зе].include? person.last_name.downcase[0..1])}.sort_by(&:first_name)
Я написал это в одну строчку, хотя это не принято. Как это будет на питоне, я надеюсь, Вы сможете сами написать. Мне лениво. А потом покажите оба кода непрофессионалу, и попросите его рассказать, что он понял.
При всей моей любви к руби, пример не выглядит как "мыслит как человек".
collection.select{|person| %w[пу зе].include? person.last_name.downcase[0..1])}.sort_by(&:first_name)
Мне бо-бо на это смотреть) А я на С++ пишу, я знаю что такое боль)
collection.select{|person| %w[пу зе].include? person.last_name.downcase[0..1])}.sort_by(&:first_name)
Я не профессионал. Если вы хотели доказать, что Руби интуитивно понятен не программисту, то вы сделали ровно обратное.
sorted((person for person in collection if person.last_name[:2].lower() in ["пу", "зе"]), key=attrgetter("name"))
Поциент уже давно помер, кого он может заменить?)
У Ruby был шанс, кроме RoR, ничем отметиться не успел, а сейчас ниша уже полностью закрыта
руби более простой язык для программиста.
Пруф?
он имеет прекрасные средства не только тестирования, но и одновременно документации кода.
Наличие документации зависит от разработчика, а не языка.
разработка на нём примерно в 2 раза быстрее, чем на питоне.
Пруф?
Сначала я задам Вам встречный вопрос. Вы, наверняка, знаете, что делает сайт bit.ly. У вас есть сайт, созданный на питоне. Сколько Вам надо времени, чтобы к нему добавить базовый функционал bit.ly? А потом я скажу, сколько это потребовало времени у меня.
Рискую сейчас обнулить свою карму, но все таки
Зачем смотреть на языки программирования с точки зрения что кто то должен кого то заменить?
если вам надо перевезти кучу мебели вы арендуете фургон или малолитражку? каждый язык предназначен для решений своих задач. Вы бы еще написали статью заменит ли когда нибудь Linux Windows :)
Если у вас в фургоне панель управления как в самолете, то может быть взять малолитражку и съездить несколько раз с привычнымии органами управления, чем сперва учиться, потом сдавать на права и привезти всю мебель за один раз, но только через 4 месяца?
если у вас панель управления как в самолете то может лучше нанять специалиста (водителя фургона) что бы он это сделал?
Вы, как исследователь, наверно сможете нанять водителя программиста, чтобы он вам написал программу на C++. Но ему во первых нужно платить, а во вторых, вы еще сами не знаете, куда нужно ехат что конкретно нужно делать.
Ну если вы не знаете что надо делать, то может не надо это делать?
А только когда поймете, что нужно делать то решите что и как вам правильней делать. И да, ваше время и ресурсы тоже стоят денег.
Ну если вы не знаете что надо делать, то может не надо это делать?
Это вопрос не ко мне, а к ученым, исследователям и всем тем, что пытается изучить или сделать что-то новое. Или вы сами никогда не сталкивались с задачами, которые неизвестно как решать?
Задача подразумевает что есть конечная цель. Если предположить, что вы делаете что то новое, ранее не описанное в интернетах, то логично предположить что вы будете использовать тот инструмент, что есть под рукой и которым вы умеете пользоваться. После того как получите како то работающий прототип, вы уже с полученным багажом знаний, решите продолжать использовать то, что вы умеете использовать или правильней нанять водителя фургона. Если тот инструмент, которым вы владеете, не позволяет вам сделать то что нужно вам, то необходимо начинать изыскания каким инструментом это возможно сделать, и опять таки или изучать его и делать самому или нанимать водителя фургона. Все зависит от вашей конечной цели.
Да, все так. Конечная цель и имеющейся под руками инструмент, а так же простота его использования.
Ну вот я решил этой зимой запрограммировать роботележку на esp32. Я большую часть своей проф жизни программировал pl/sql и не много python. Почитал интернеты, сделал прототип с начало на С с использованием фреймворка Arduino. Тележка хреново но поехала, потом стал углубляться в FreeRTOS и стал туда добавлять ее возможности. Тележка поехала уже намного лучше. Побочный эффект смог уже сам добавить туда ультразвуковой сонар. На очереди лидар и esp32-cam. Жизнь прекрасна :)
Всё же Python это альтернатива Matlab/Maple итд, а не С++/Rust . Python в мире ML это язык скриптования тулбоксов: PyTorch, JAX, итд. А С++/Rust это технологи на которых реализуют эти тулбоксы.
Пример “хорошего” api как раз и показывает компромиссность связанную с производительностью Python:
for batch in dataloader:
logits = classifier(batch.features)
loss = cross_entropy(logits, batch.labels)
loss.backward()
optimizer.step()
Где градиент? Какие параметры оптимизирует оптимизатор? Как эти параметры попадают в целевую функцию? Совершенно не видно потока данных. Всё это скрыто не потому, что это удобно - это не удобно, а потому, что мы не хотим, чтобы выполнение вываливалось в python-код и тормозило библиотечный код.
Это проблема курицы и яйца. Что стоит в самом начале, невозможность встроить в поток выполнения быстро работающие инструкции и поэтому нужно структурировать код программы, или специальное намерение архитектуры самого языка принудить пользователя к определенному структурированию и описанию своих намерений?
Я думаю, что нет никакой сложности добавить в язык какие нибудь низкоуровневые оптимизирующие лексические конструкции, но это не делается специально, чтобы не раздувать синтаксис.
А почему не Julia ?
Как по мне, Julia - это не промышленный язык программирования, а пример коммерческого языка для академической среды, который развивается на гранды.
Я не про это, а про примененную Вами методику [подсчета лексем] для ответа на вопрос.
Если считать по описанной в статье методике, то доля прикладных конструкций в Julia чуть меньше половины - 46.6%. Это немного выше, чем у C++ или Rust, но почти вдвое меньше, чем у Python.
Причем грамматика у Julia точно так же перемешана как в С++ (прикладные и системные макросы и ключевые слова используются вперемешку, чем Rust отличается от них в лучшую сторону, у которого системные термины лексически сгруппированы преимущественно в атрибутах).
По-моему логическая цепочка проще:
С++ сложный -> с него не начинают учить программированию
Python учат в школе (колледже) и его многим достаточно -> его используют для всего [непрофессионалы в программировании]
Вы правы. Просто вопрос в том, что является причиной оценки “простой” или “сложный”. И мне захотелось посмотреть на эту проблему с описанной в статье точки зрения. Ведь если словарь языка программирования без затруднения понимается не программистом, то он априори будет “проще”.
у питона легкий вход но затем кривая обучения резко вырастает, у си++ наоборот, с начало тяжело потом легко.
по мне очень жаль что начинают учить не с С/С++ а с Python. Ломать мозги при переходе с ЯП где динамические типа на ЯП со статическими типами больно (проходил это когда переучивался с Basic на C в начале 90-х)
Как по мне, то у C++ легко не бывает в принципе :-(
Давно, будучи студентом, наткнулся на такой язык, как Standard ML of New Jersey. Помню, что это был эстетический восторг.
Он не слишком известен и скорее академический. Из ближайших родственников - это OCaml. Семейство ML-языков сильно повлияло на Haskell / F# и на индустрию в целом (алгебраические типы, Continuation‑Passing Style, вывод типов Hindley‑Milner и т.п.). Интересно наблюдать, как через десятки лет идеи оттуда проникают, трансформируясь по пути, в современные mainstream языки (Rust/C++/Python/Kotlin/...).
Интересно было бы пофантазировать, каково изучать в качестве первого языка что-то типа OCaml.
Тезис про "понятно не программисту" разбит уже сто лет назад. "Бухгалтер сам сможет поправить формулу", "дизайнер исправит форму без программиста", и прочие сказки венского леса закономерно не сработали. Им все равно непонятно. Работы добавилось програмисту. Даже кобол, который специально делался для понятности любому профильному специалисту, все равно потребовал программистов.
Очень многое в успех питона вложил гугл. Гугл его пиарил как только мог, даже давал жирные бесплатные инстансы под питон-скрипты - в тот момент другие бесплатно давали только пару сотен мегабайт под статику, причем с рекламой. Прямым конкурентом был Ruby, но потом свернул куда-то не туда и быстро ушел в тень.
Питон не разу не простой. Он простой только на входе, когда надо налабать несложный однофайловый скриптик, но чуть сильнее углубись в базовые фреймворки и сломаешь мозги. Ровно как с жавой - новичку кажется очень простой, но потом приходит спринг, камунда, базы данных, кафка... И сложность улетает в небеса, оказывается, что plain java никому нафиг не сдалась.
Ровно как с жавой - новичку кажется очень простой, но потом приходит спринг, камунда, базы данных, кафка... И сложность улетает в небеса, оказывается, что plain java никому нафиг не сдалась.
если вы знаете хорошо core java то вы как минимум сможете прочитать код и при необходимости влезть в него, а вот зная core python влезть в ту же django может оказаться гораздо более сложной задачей...
Статью даже читать не буду, прокомментирую заголовок и постараюсь предугадать посыл: Автор сам вводит безосновательный тезис, который противоречит происходящему в айти, а затем ловко разбивает его аргументами.
почему никто не упоминает Cython? когда полностью исключаешь python объекты внутри cdef конструкций скорость не хуже чем у C и Rust
Ну экзотики много... Есть еще микропитон, который транслируется в С, а тот уже компилируется.
не могу назвать экзотикой этот язык хотябы даже потому что на нем написаны такие пакеты как numpy, scipy, pglast, pyarrow, pandas, lxml, scikit-learn. не полностью на cython, но в значительной степени
Вы что-то путаете, микропитон работает как обычный - компилирует исходник в байт-код, а потом его интерпретирует. Это как раз cython, nuitka и т.п. делают C-код из питона и компилируют его в нативный.
почему C++ не стал основой для исследований в этой (или любой другой) области?
А почему вы сразу же пишете заведомую ложь? PyTorch написан на C++. То, что вы поверх этого пишете скрипты на Python не меняет того, что лежит в основе. Я сам вообще не программист, а физик, и пишу скрипты на Python. Но я бы никогда им не пользовался, если бы не написанные на C и Fortran NumPy и SciPy. И у меня никогда не возникало странных идей, что в основе моих расчётов лежит Python. Непонятно, откуда у вас такие идеи возникли.
То, что вы поверх этого пишете скрипты на Python не меняет того, что лежит в основе. Я сам вообще не программист, а физик, и пишу скрипты на Python.
Меняет принципиально. Потому что вы, как НЕ программист, а физик, пишите именно на Python не зависимо от того, сколько еще вычислительных слоев еще лежит в глубине используемых библиотек, какие драйвера вызываются и на каком языке они написаны. Но чтобы вы могли это делать, API используемой библиотеки должны быть адаптированы в рамках идеологии Python,
И если честно, то я не понял вашего пассажа насчет моих идей и ваших странных мыслей. Но это точно идеи не мои, так как свои я постарался описать в статье. Ведь вряд ли скрипты для Python вы станете писать на С++ из-за того, что на нем написана PyTorch.
видите, даже не профильному специалисту ясно что противопоставление c++ и python надуманное, очередная кликбейтная статья с таким же заголовком из разряда, как иногда встречаются на ютубе, htmx (javasccript библиотека) и zero javascript в одном придложении, как будто бы это что-то отдельное, так и у вас , прелесть питона в скорости вхожденя в язык, т.к. писать на c++ это не для всех, но для использования c++ на нëм писать не обязательно, ну и противопрставлять одно другому не имеет смысла, тк надо сравнивать яблоки с яблоками, хотябы c++ и rust. хотя для llm харнесов стандартом сейчас является javascript как клей и под капотом что угодно, в том числе и rust...
Но чтобы вы могли это делать, API используемой библиотеки должны быть адаптированы в рамках идеологии Python,
В том и дело, что нет. Если бы Python исчез, для меня ничего не изменилось бы. Я бы писал свои скрипты непосредственно на C++ (точнее, у меня получился бы C с какими-то элементами C++ - всё-таки, я вообще не программист). Всё-таки, пары по информатике и вычислительным методам у студентов физических специальностей тоже есть. На Питоне просто немного короче получается. А вот если бы исчезли написанные на C/Fortran/C++ библиотеки, то Python стал бы абсолютно бесполезен для любой исследовательской деятельности. Прочитайте, пожалуйста, ещё раз, на какой ваш тезис я отвечал. Вы писали, что лежит в основе. В основе лежит не Python. Python - это обёртка, удобная для непрофессионала.
В основе Python, как и совершено любого другого языка программирования, много чего лежит. Это и идеология, архитектура, синтаксис, стандартная библиотека, дополнительные библиотеки, расширения, экосистема и т.д.
Но в случае с Python и различными математическими и матричными вычислениями - все совершенно прозрачно. Просто перейдите на https://ru.wikipedia.org/wiki/NumPy#История и почитайте, сколько лет потребовалось на переделывание интерфейса математической библиотеки и на его реализацию, чтобы в результате получился всем известный NumPy, который и был включен в Python, как часть проекта.
И только после этого любые другие библиотеки стали придерживаться идеологии NumPy, которая разрабатывалась годами, задолго до возникновения ML бума. Поэтому "На Питоне просто немного короче получается. " - это принципиальное следствие идеологии Python, а вовсе не случайна причина его успеха.
Поэтому говорить в сослагательном наклонении бессмысленно. Считается, что на Fortran написано больше всего математических библиотек, но большинство почему то используют Python. И у того же самого PyTorch - не расскажете, что означают первые две буквы этой С++ библиотеки?
Вы писали, что лежит в основе. В основе лежит не Python.
У вас странное утверждение. В основе Python лежит именно Python, с его идеологией и синтаксисом. И чтобы библиотеке стать частью Python, она должна соответствовать всем этим требованиям, т.е. нужно адаптировать API библиотеки под философию и возможности языка, но никак не наоборот.
Так же влияет то что питон интерпретатор, а с++ компилирует в машинный код под конкретную машину / ос
Одна ид проблем C++ это сборка, она намного дольше и ресурсоёмко по сравнению со многими другими языками.
Другая проблема это читаемость шаблоных классов просто ниже плинтуса по сравнению с C# и Java.
А еще можно вспомнить про DLL ад, проблемы когда у нас много разных версий одной библиотеки и где-то сломалась совместимость. Эти не редкие ошибки линковки. Надо еще уметь писать cmakefile. В итоге порог вхождения достаточно высокий.
Самое интересное, что наиболее популярные языки как Python и JavaScript оба являются интерпретируемые и со слабой типизацией. По мне люди любят свободу типов, которая в шаге от хаоса =)
Чего open source, включая python, не хотят - так это чтобы "из коробки" интерпретатор (например python) умел выбирать версию. Потому что когда вышел 3, очень долгое время была проблема а какой же python нужен например для скрипта. Так же и с NodeJS, не хотят делать выбор исполнителя, а юзать всякие nvm, env и т.д. это костыль и перекладывание решение на кого-то иного.
кто угодно может вот так прям взять и начать писать на python, именно как уже сказано, медленность языка вообще не причëм, всë что требует скорости написано на C и прочем, python только клей...
Почему C++ или Rust никогда не смогут заменить Python
Потому что действует принцип неуловимого Джо? Перефразируя анекдот:
...
- А, это у нас Python, его не могут заменить даже С++ и Rust
- Почему?
- Да потому что никто и не пытается
Датасатанистам и учёным нужен был простой в освоении язык, на котором можно быстро писать код на выброс, который обрабатывает данные экспериментов. Тяп-ляп, получил результат, выбросил. Python тогда был идеален для этого.
Потом для этих людей написали массу математических библиотек, наличие которых ещё сильней укрепило позиции языка в научной среде. А далее лавинообразный эффект, когда наличие математики привлекает новых учёных, и появляется запрос в большем количестве математики. В результате у ученого в принципе и выбора-то нет другого. И это ни в коем случае не плохо, потому что всё развивается, цветёт и пахнет. Это и есть великолепная ниша Питона.
Но когда встаёт вопрос об использовании Python в обычном бизнесовом программировании, то я не вижу преимуществ у этого языка. Медленный, жрёт гораздо больше ресурсов на задачи, которые должны работать молниеносно на калькуляторе. Аргумент с предметной областью, как мне кажется, не выдерживает никакой критики. Я бы ни в коем случае не выбрал Python в качестве языка для нового проекта.
Аргумент с предметной областью, как мне кажется, не выдерживает никакой критики. Я бы ни в коем случае не выбрал Python в качестве языка для нового проекта.
И как быть, если новый проект - это математика и датасаентисзм? Особенно, если на старте проекта непонятно, как и что нужно делать? Сразу начинать писать на С++ или Rust?
Ну я же как раз и написал, что датасатанизм лучше с python. Просто потому что он для такого наилучший инструмент, ведь именно там идёт развитие этого направления. Когда я писал о новом проекте, я имел ввиду какой-то не датасатанистский бэкенд для бизнеса. Вот тут Python со всеми своими недостатки станет настоящей обузой.
Вот тут Python со всеми своими недостатки станет настоящей обузой.
Так в статье речь идет с точностью наоборот. Если есть проект для Python, то начинать писать его на С++ или Rust, это будет не очень хорошее решение.
Но это вовсе не значит, что любой проект нужно начинать именно на Python (как в комментариях выше предположили писать на Python драйвера или яро ОС).
Есть одна вещь которая в питоне, которая очень печалит. Если код пролетел через текстовый фильтр, который тримит в строках пробелы - то никакой бьютифайэр уже не поможет )))
Хорошо бы в табличку и в окончательные выводы добавить C++14 и C++98, потому, что он был сильно проще в то время, но и тогда картина применительно к прикладной области была схожая.
Стандарт C++98 короче. А вот код, сопоставимый по производительности и функционалу, будет более многословным и намного менее читабельным по сравнению с C++11/14/... Потребуется возвращать результат через выходные параметры, работать с индексами или итераторами для обхода коллекции, явно прописывать типы в прикладном коде. В общем - страшный сон, который хочется поскорее забыть.
Если современный C++ позволяет писать код, приближающийся по читабельности к python, то C++98 недостаточно выразителен - там приходится страдать и писать кучу обслуживающего кода, не относящегося напрямую к логике алгоритма
Какую фигню вы написали. Питон выигрывает не потому что он проще чем раст или с а потому что его библиотеки сбалансированы. Питон нативно вызывает библиотеки написанные на си.
Как по мне, примеры из статьи больше сравнивают не сами языки, а реализацию ML фреймворка. И если "кишки" библиотек торчат наружу, то это не проблема C++ или Rust, а проблема реализации фреймворка, которую для них предоставляют.
В Rust запросто можно было все ошибки кидать в виде паники внутри фреймворка, так что пользовательский вызывающий код выглядел бы как самый первый и короткий пример на Python, без символов ? и проверок на ошибки (разумеется, промышленный код нельзя так писать).
Что на самом деле дало Python лидерство? Я считаю, что одновременное сочетание нескольких факторов, таких как
изобилие и доступность готовых библиотек и фреймворков
отсутствие необходимости ручной работы с памятью
синтаксический сахар вокруг бойлерплейта, но без фанатизма, что позволило сделать код короче, сохраняя читаемость.
Почти во всех языках нет ручной работы с памятью. Многие тоже имеют развитую экосистему. Языком ML мог стать тот же Java. Однако, в него долго не завозили ФП и было мало сахара. В Ruby - слишком много сахара, так что код становится менее очевидным (лично я так не считаю, но многие так говорят). Да и относительно лаконичности синтаксиса до сих пор идут баталии. Появляются языки типа Go, философия которых делает ставку на явность ценой лаконичности.
В этом плане обидно, конечно, за Java, Ruby, Julia и т д. Но так или иначе Python победил.
изобилие и доступность готовых библиотек и фреймворков
Это уже отмечали многие, как и то, что эти библиотеки и фрейворки написаны не на Python. Но использовать C\C++ библиотеки могут почти все языки. Поэтому можно считать, что условный PyTorch может быть использован везде, где есть вызовы нативных библиотек.
отсутствие необходимости ручной работы с памятью
Это тоже есть в подавляющем количестве языков. Даже тот же самый С++ позволяет писать с автоматическим управлением памятью.
1.Кстати, заголовок слишком кардинальный.
Даже тот же самый С++ позволяет писать с автоматическим управлением памятью.
2. Но не очень удобно - много приходится печатать.
Скорее уж тогда надо сравнивать с Julia, Nim, D, итп в которых удобнее синтаксис, упрощена работа с памятью и C-interop.
Кстати, заголовок слишком кардинальный.
Почему??? Я действительно считаю, что тут у C++ или Rust нет никаких шансов. Правда причиной этого будет конечно не синтаксис, а назначение языка, но именно назначение ЯП и определяет синтаксис (точнее необходимость наличия в синтаксисе низкоуровневой машинной составляющей).
Ну да, не столько заголовок, сколько суть. Надо было сразу брать планку ниже, как я пример привел.
А так можно было и от ассемблера начать...Почему на нем неудобно
Вы не поверить, но исследования я с ассемблера и начинал. У него, кстати, лексика 100% машиннозависимая, так что это ответ на вопрос, почему на нем будет неудобно :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему C++ или Rust никогда не смогут заменить Python