Несколько дней назад (Оригинал заметки был опубликован 12 сентября 2017. — Здесь и далее прим. переводчика), я заметил этот твит в своей ленте:
Я 'всё ещё' программирую на Си. Почему? Подсказка: дело не в производительности. Написал эссе с разбором… появится на Onward!
(Onward! — одна из конференций в составе SPLASH, посвящённая обсуждению новых идей и парадигм в программировании и размышлениям о программном обеспечении.)
Это показалось хорошим чтением на выходные — им оно и было. Главный аргумент, который приводит автор: язык Си остаётся непревзойдённым как язык системной интеграции, потому что разрешает взаимодействовать с "чужим" кодом, то есть кодом, написанным независимо и возможно даже на других языках, вплоть до ассемблера. Фактически, Си — один из немногих языков программирования, позволяющих иметь дело с любыми данными на уровне байтов. Большинство более "современных" языков запрещают такое взаимодействие во имя безопасности: вся память, к которой вы можете получить доступ — это память, выделенная с помощью безопасной среды исполнения языка. Как следствие, вы застреваете в его замкнутой вселенной.
Системная интеграция — несомненно важный аспект работы с программным обеспечением, который часто упускают из виду. И это особенно верно для научных вычислений (scientific computing), где прикладное программное обеспечение с фиксированным набором функций встречается редко. Чтобы решить научную задачу часто требуется собрать множество кусочков программ в сильно зависящее от конкретной проблемы целое, которое, возможно, будет запущено всего пару раз (смотрите также мой более ранний пост на эту тему). Это в точности та задача, которой занимается системная интеграция: собрать из кусочков единое целое, при необходимости используя связующий код. В вычислительной науке (computational science) связующий код принимает форму скриптов, потоков работ (workflows) и, в последнее время, блокнотов (notebooks). C технической точки зрения это заметно отличается от системной интеграции на уровне операционной системы, на которую ссылается Стивен Келл, но функционально это то же самое.
Статья Стивена напомнила мне о давнем плане написать в блог о том, почему Python так успешен в научных вычислениях, несмотря на его репутацию языка с плохой производительностью. Так что… вот она.
Разумеется, причин успеха Python много, но одна из них — он отлично справляется с задачами системной интеграции. Python обладает двумя особенностями, которые я считаю важными в этом деле, и которые не поддерживаются многими другими языками. Одна — типы данных, явно разработанные для связывания (interfacing); другая — утиная типизация в сочетании с маленьким, но гибким набором стандартных интерфейсов.
Первый тип данных Python, разработанный для связывания в контексте научных вычислений — старый добрый массив NumPy, который на деле оказывается старше NumPy, будучи представлен в 1995 году его предшественником, Numeric. Массивы — это один из типов данных, являющихся "хлебом насущным" научных вычислений, вплоть до того что это единственный тип, доступный в языках вроде Fortran 77 или APL. Реализация массивов в Numeric была разработана для использования с той же схемой расположения данных, что и в Фортране с Си, чтобы обеспечить взаимодействие с библиотеками на Фортране и Си, доминировавшими в научных вычислениях в 1995 году (и до сих пор, хоть и в меньшей степени). За Numeric и, позднее, NumPy всегда стояла идея использовать Python как связующий язык для библиотек на Фортране и Си, и добиваться скорости, делегируя критичные по времени операции коду, написанному на этих языках.
Второй тип данных Python, спроектированный для связывания — это memoryview, связанный с buffer protocol. Здесь Python ближе всего подбирается к Си-образному доступу к памяти. Буферный протокол позволяет разным типам данных Python получать доступ к внутренностям друг друга на уровне байтов. Типичным примером использования может быть тип данных изображения (например из Pillow), с доступом к представлению изображения в памяти через тип массива (например из NumPy), что позволяет реализовать алгоритмы работы с изображениями в виде операций над массивами.
Третий и наименее известный тип данных Python для связывания — это capsule, заменяющий более ранний CObject. Капсулы существуют исключительно на благо написанных на Си модулей Python, которые с помощью связующего кода на Python могут обмениваться друг с другом непрозрачными данными, даже несмотря на то, что сам связующий код не может как-либо проверить или обработать данные. Типичный пример: обернуть указатели на функцию на языке Си в объект Python так, чтобы связующий код на Python — скрипт, например, — мог передать функцию на Си из одного модуля коду на Си в другом модуле.
Все эти интерфейсные типы данных служат посредниками между кодом на Python и Си, хотя зачастую системный интегратор на Python вообще не подозревает об использовании кода на Си. Другая особенность Python для системной интеграции, утиная типизация со стандартными интерфейсами, способствует связыванию независимо написанных модулей Python. Под "стандартными интерфейсами" я понимаю интерфейсы последовательности (sequence) и словаря (dictionary), а также стандартные имена методов для перегрузки операторов.
Чтобы увидеть, почему эта особенность важна, посмотрим на статически типизированные языки, в которых она намеренно отсутствует. В качестве конкретного примера возьмите многомерные массивы Java. Они не являются частью языка или стандартной библиотеки, но могут быть реализованы поверх них с разумными усилиями. Фактически существует несколько реализаций на Java, из которых вы можете выбирать. В этом и кроется проблема. Предположим, вы хотите использовать библиотеку для быстрого преобразования Фурье (БПФ), основанную на реализации массивов "A", вместе с библиотекой линейной алгебры, основанной на реализации массивов "B". Не повезло — массивы из "A" и "B" имеют разные типы, так что вы не можете использовать выходные данные БПФ как вход для системы решения линейных уравнений. Не имеет значения, что в основе лежат одни и те же абстракции, и даже что реализации имеют много общего. Для компилятора Java типы не совпадают, и точка.
Python не полностью свободен от этой проблемы. Вполне можно писать код на Python или код в модуле на Си, который ожидает точный тип данных в качестве входа, а иначе выбрасывает исключение. Но для кода на Python это будет считаться плохим стилем, и в модулях на Си для Python тоже, за исключением тех, где требуется производительность или совместимость с другим кодом на Си. Там, где это возможно, от программистов на Python ожидается использование стандартных интерфейсов для работы с данными. Например, итерация и индексирование работают одинаково для массивов и встроенных списков. Для операций, не поддерживаемых стандартными интерфейсами, от программистов на Python ожидается использование методов Python, также подлежащих утиной типизации. На практике, независимо реализованные типы Python намного более интероперабельны, чем независимо реализованные типы Java. В конкретном случае n-мерных массивов, у Python был шанс принятия подавляющим большинством единой реализации, что связано с вопросами скорее социальными и историческими, чем техническими.
Наконец, даже несмотря на то, что Python — довольно хороший выбор для системной интеграции в научных вычислениях, разумеется есть ограничения, как раз того рода, что описывает Стивен Келл в своём эссе: сочетание кода Python с кодом на других языках с управляемой памятью, скажем, R или Julia, требует много труда, и даже после этого остаётся хрупким, потому что требуются ухищрения, основанные на недокументированных деталях реализации. Подозреваю, что единственным решением может быть появление нейтральных по отношению к языкам объектов данных, поддерживающих сборку мусора и предоставляемых как сервис уровня операционной системы, сохраняющий возможность неуправляемого (unmanaged) доступа на уровне байтов, а-ля Си. Самая близкая из существующих технологий, о которой мне известно — CLR от Microsoft, более известная под коммерческим названием .NET. Её реализация теперь имеет открытый исходный код и работает на множестве платформ, но её происхождение "только для Windows" и прочные связи с огромной майкрософтовской библиотекой являются препятствием для принятия в традиционно Unix-центричном сообществе людей, занимающихся научными вычислениями.
Комментарии (49)
smer44
19.02.2018 21:37как в том анектоде.
и не питон а библиотеки Numpy и Scypy и.т.п
и не хороши, а плохи по производительности по сравнению с тем же
Tensorflow для CPU не говоря уже о паралельном железе.
BkmzSpb
19.02.2018 22:22Python «хорош» в научных вычислениях из-за низкого порога вхождения.
Для большинства людей, занимающихся наукой (даже теорией), необходим инструмент для каких-никаких расчетов, да чтоб еще графики рисовал. В моей области когда-то давно был такой монстр как IDL, но сейчас все поголовно пишут на Python.
При этом зачастую не используются никакие фичи языка кроме стандартных циклов/ветвлений, функций и многомерных (в лучшем случае) массивов. Всё.
Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации, ни о чем либо еще люди даже не слышали. К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.
Всё вышенаписанное — личное мнение, основанное на личном опыте.Krummi Автор
19.02.2018 23:30К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
Об этом и речь. Если бы человек хотел заниматься программированием — стал бы программистом, разве нет? А если инструмент прост в освоении и подходит для решения научных задач — в чём польза от времени, потраченного на изучение «профильного» программирования?
Ничего не имею против «программирования ради программирования», но у всего есть свои границы применимости.
Интересно было почитать про IDL, спасибо! А что у вас за область, если не секрет?BkmzSpb
19.02.2018 23:47IDL никогда не пользовался (я несколько младше, не застал), но «старшие» (от 35 где-то) всё еще его используют. Я вычисления/графики делаю на R (и я один такой на отделении).
Специальность — астрофизика.Alexey_mosc
20.02.2018 20:24+ в карму R (его редко цитируют где-либо в рунете). Я тоже на R фигачу. Но сам этот факт не отделяет этот язык от Python в срезе
К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
Хотя, в чем-то и отделяет, например, через возможность связать функции библиотеки с рядом публикаций, указанных в help.chersanya
20.02.2018 20:37А что вы имеете в виду под возможностью связать публикации? Действительно интересно. Это не то же самое, что например в питоне — вот хелп первой попавшейся функции из scipy, там для всего разумного даны ссылки. И такое видел во многих библиотеках, несколько раз действительно смотрел указанные статьи когда нужно было.
Alexey_mosc
20.02.2018 21:01Я имею в виду, что открывая help в любой функции из R stats:: или из другой библиотеки можно уточнить смысл некоторых — говоря языком разработчика — скалярных значений, возвращаемых этими функциями при определенных условиях, либо же в целом понять подход, который закодирован в этих функциях, почитав публикации в реферируемых журналах. Пример для семейства функций gamma:
dgamma is computed via the Poisson density, using code contributed by Catherine Loader (see dbinom).
pgamma uses an unpublished (and not otherwise documented) algorithm ‘mainly by Morten Welinder’.
qgamma is based on a C translation of
Best, D. J. and D. E. Roberts (1975). Algorithm AS91. Percentage points of the chi-squared distribution. Applied Statistics, 24, 385–388.
plus a final Newton step to improve the approximation.
rgamma for shape >= 1 uses
Ahrens, J. H. and Dieter, U. (1982). Generating gamma variates by a modified rejection technique. Communications of the ACM, 25, 47–54,
and for 0 < shape < 1 uses
Ahrens, J. H. and Dieter, U. (1974). Computer methods for sampling from gamma, beta, Poisson and binomial distributions. Computing, 12, 223–246.
Пример для функции регуляризованной обобщенной регрессии glmnet:
Author(s)
Jerome Friedman, Trevor Hastie, Noah Simon and Rob Tibshirani
Maintainer: Trevor Hastie hastie@stanford.edu
References
Friedman, J., Hastie, T. and Tibshirani, R. (2008) Regularization Paths for Generalized Linear Models via Coordinate Descent, web.stanford.edu/~hastie/Papers/glmnet.pdf
Journal of Statistical Software, Vol. 33(1), 1-22 Feb 2010
www.jstatsoft.org/v33/i01
Simon, N., Friedman, J., Hastie, T., Tibshirani, R. (2011) Regularization Paths for Cox's Proportional Hazards Model via Coordinate Descent, Journal of Statistical Software, Vol. 39(5) 1-13
www.jstatsoft.org/v39/i05
Tibshirani, Robert., Bien, J., Friedman, J.,Hastie, T.,Simon, N.,Taylor, J. and Tibshirani, Ryan. (2012) Strong Rules for Discarding Predictors in Lasso-type Problems, JRSSB vol 74,
statweb.stanford.edu/~tibs/ftp/strong.pdf
Stanford Statistics Technical Report
Glmnet Vignette web.stanford.edu/~hastie/glmnet/glmnet_alpha.html
И, вдогонку к последнему примеру, обсуждение формулы для смешанной регуляризации на профильном ресурсе (обсуждение на уровне топовых представителей математической статистики): https://stats.stackexchange.com/questions/326427/why-does-glmnet-use-naive-elastic-net-from-the-zou-hastie-original-paper/327129#327129
Все это подстегивает определенный исследовательский интерес. Но, в целом, его подстегивает, в первую очередь, заказ на глубину объяснения используемых методов со стороны заказчика. Если его нет, то тут уж сам скорее себя драйвишь.
Alexey_mosc
20.02.2018 21:04Вижу, что для этого примера в Python также есть ссылки. Но я не говорю, что это самый главный фактор превращения программиста в ученого, но как бы в R-сообществе этому принято больше внимания уделять, что-ли.
vladob
20.02.2018 23:40+ в карму R (его редко цитируют где-либо в рунете). Я тоже на R фигачу. Но сам этот факт не отделяет этот язык от Python в срезе
"Редко цитируют" не довод для ученого!
Я на Matlab работал с 1989 года с версии 2.0 до примерно 2005.
В течение 12 лет я не встречал ни одного человека, который бы тоже работал в Matlab, за исключением своего универовского друга, который меня и "подсадил", коллег, с которыми я сам поделился сей радостью, и своих студентов.
И с появлением ру интернета очень долго — годы! — никто про матлаб даже не упоминал. Так что ссылки в инете не есть "наше все".
Alexey_mosc
20.02.2018 23:48В этой цитате никаких доводов и не было!
Я только вношу маленький вклад в популяризацию.vladob
21.02.2018 00:18Я понял, что это довод, но не Ваш, а скорее, Ваших оппонентов и вы его во внимание не особо принимаете, а продолжаете на R фигачить. Я понял так и попытался поддержать описанием своего примера с матлабом.
Удачи! :)
Alexey_mosc
21.02.2018 12:34Ок, и Вам. Я вообще не ученый, просто довольно много статистики в моей DS-работе (на production, в том числе).
Alexey_mosc
21.02.2018 12:59Пишем большой проект одновременно на R и Python. Обкладываем проверками, используем быстрые библиотеки для прожевывания датафреймов. Мой коллега на Py пишет в стиле OOP, я, как не программист, пишу функционально. Объемы кода до 10К строк. Все крутится на production в docker container. Переходим на Spark. И R и Python идут нос в нос, но на R быстрее разработка идет. Также были сложности с переносом в Py логики расчета доверительных интервалов для моделей (то, что в R вызывается в функции, в Py решается матричными операциями, что опять же накладывает ограничение на скорость разработки).
vladob
21.02.2018 13:15+1Также были сложности с переносом в Py логики расчета доверительных интервалов для моделей (то, что в R вызывается в функции, в Py решается матричными операциями, что опять же накладывает ограничение на скорость разработки).
Не только скорость разработки, еще и делегирование ответственности влияет на выбор тулсов.
По степени доверия в вопросах статистики опенсорсный R, пожалуй, уже приближается к SAS.
Да, без проблем найти формулы для доверительных интервалов (и прочей статистической лабуды). И джуниор запрограммирует хоть на питоне, хоть на сях, хоть на фортране.
Вот, только, в серьезный продакшен лучше запускать статистику на надежных библиотеках, а не самописанную. Я так думаю.
vadimturkov
19.02.2018 23:42По своему опыту научной работы могу сказать, что когда над задачей работает от одного до нескольких человек, он повторном использовании кода речи не идёт. Пишут как получится, используются минимальные возможности языка, о системах контроля версий большинство не знает. Да и в общем потоке информации которую необходимо изучать ( математика, физика) для программирования места почти нет. Может быть, если бы на первых курсах универа больше уделяли этому внимания, ситуация могла быть лучше.
Kroid
20.02.2018 02:26+1Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации [...]
А зачем? ООП ради ООП, программирование ради программирования? Вы путаете программирование для автоматизации и программирование для вычислений.
Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.
Когда мне нужно написать, к примеру, бекенд для веб-приложения, я проектирую архитектуру, пишу классы, использую фреймворки и всё такое.
Когда мне нужно проверить теорию, к примеру, time series forecasting с помощью Х, я беру python, открываю jupyter notebook, пишу модель, тестирую ее, визуализирую результаты, подвожу итоги. Если результат удачный, я перепишу получившийся алгоритм для продакшена, а этот код выкину. Если нет — я этот код опять-таки выкину. Какой смысл наводить красоту в, по сути, одноразовом коде?robotobor
20.02.2018 09:29Если результат удачный, я перепишу получившийся алгоритм для продакшена, а этот код выкину.
Подскажите, а это на сколько трудозатратно. Я вот тоже смотрю в сторону ML, эксперементирую с Anaconda, skikit-learn. Хотел бы ввести некоторые модели и наработки в прод. Сам я также занимаюсь бэкэндом под .NET, архитектурой, БД и автоматизацией в общем. И вот задумался, как бы лучше ввести в продакшн некоторые алгоритмы из библиотеки skikit-learn…Kroid
20.02.2018 13:19Для моих целей лучший результат дают простые линейные модели, которые можно на любом языке без проблем «в лоб» написать, без библиотек. Чем больше фич учитывает модель, чем она сложнее — тем хуже в итоге результат на out of sample.
Если же использовать что-то сложное, то лучшее, до чего я смог дойти — запихнуть модель в микросервис на питоне, залить в облако для маштабирования, и обращаться к нему по рест-апи с бекендов на других языках.
BkmzSpb
20.02.2018 11:27Возможно мы немного о разном говорим, но в моем случае код пишется один раз «как есть», не важно, как хорошо он работает, считает ли он сутки то, что при небольшой оптимизации считается за час. Никакого «перепишу потом». И хорошо, если один раз написал, опубликовал и забыл. А если через пол года этот код отдается в руки студенту для проекта «а давайте учтем еще один фактор в модели»? Когда ни писавший этот код ни тем более другой не-программист не могут понять, что же в нем происходит? Например из-за повального отсутствия комментариев и выражений вида
cc1 = aa1 + bb1; c2 = cc1 * dg3
Если вы когда-нибудь работали с legacy-кодом, то представьте что здесь «legacy»-код зачастую пишется в реальном времени.
Понятное дело что ни у кого нет времени писать качественный код, когда нужно делать науку. Хотя вот сейчас пошла мода на требование исходников при публикации определенных типов работ. Может это поправит ситуацию.
Nick_mentat
20.02.2018 12:19На самом деле оптимизации не помешали бы. Я бы не отказался от такого языка, компилятор которого анализирует поток вычислений и делает из него машинный код, аналогичный оптимизированому на с. Помню, сидел я как то 3 дня, за которые компьютер воспроизвёл всего 13 лет жизни системы. А нас интересовала тясяча. Код тогда никто не переписывал, просто закинули на суперкомп. Получить доступ к суперкомпьютеру оказалось проще, чем уговорить кого-то переписать код на с++, потому что на фоне пайтона это объективно — ад. Хотя скорость выполнения искушает…
naviastro
20.02.2018 12:39В моей области (астрофизика) царит огромный зоопарк языков программирования, библиотек и инструментов. IDL — только одна маленькая клеточка, причиняющая боль всей голове кучей необходимого легаси кода и проприетарных зависимостей. Многие направления десятилетиями развивались независимо, результат — практически у каждой специализированной софтины (пакета) есть свой уникальный интерфейс командной строки, свой скриптовый язык, свой формат конфигов. И конечено же, цимес в том, что сейчас, в эпоху великого объединения, требуется работать сразу с добрым десятком таких пакетов (астрономия стала воистину всеволновой!). К счастью, многие значимые для меня проекты стали использовать Python в качестве своего рода командной оболочки. Это радикально упрощает жизнь. Пиши вычислительный код на чём пожелаешь (хоть на Brainfuck), строй графики в экселе, но интерфейсик делай на Python)). Python в науке для учёного — скорее как bash или powershell в *nix/win для юзера/админа. Не стоит удивляться, что возможности языка часто используется слабо. Может это и к лучшему.
potan
19.02.2018 22:42С задачей системной интеграции прекрасно справляются множество языков. TCL первым озаботился этой проблемой и вполне успешно ее решал. Lisp замечательно может справиться с интергацией. С помощью различных RPC-подобных протоколов, от CORBA до GraphQL, интеграцию можно осуществлять практически на любом языке. То же можно делать на системах обмена сообщениями.
kkirsanov2
19.02.2018 23:09--интеграцию можно осуществлять
--То же можно делать
Почти никогда нельзя.
Не видил ни одного учёного крупного вне математики (в меньшей степени) или информатики (в большей) который бы тратил силы на интеграцию с корбой, GraphQL или кафкой.
Для этого есть специально обученые аспиранты.potan
20.02.2018 01:17А на питоне видели?
Все биндинги написаны теми же аспирантами или самими разработчиками библиотек. И даже не потому-что к питону биндинги писать проще, а потому-что он уже популярен и при наличии биндингов к питону библиотекой скорее станут пользоваться. Все преимущество в положительной обратной связи популярностей у разработчиков библиотек и конечных пользователей. В системах с такой связью велико влияние случайности и совсем не обязательно побеждает лучший.
Hedgehogues
19.02.2018 22:44Почему ruby не стал таким популярным?
Krummi Автор
19.02.2018 22:49Заметку как раз на эту тему я изначально и увидел: jeffknupp.com/blog/2017/09/15/python-is-the-fastest-growing-programming-language-due-to-a-feature-youve-never-heard-of
Вкратце: буферный протокол, позволяющий эффективно работать с данными.
potan
20.02.2018 01:18Потому что основная документация к нему очень долго была на японском и медленно переводилась на английский.
kuraga333
20.02.2018 15:21Сейчас уже интересно, почему не взлетает Julia…
Hedgehogues
20.02.2018 16:03Потому что есть питон и R и этого достаточно? Кстати, как у Julia с параллельностью?
zirix
19.02.2018 22:58В качестве конкретного примера возьмите многомерные массивы Java. Они не являются частью языка или стандартной библиотеки, но могут быть реализованы поверх них с разумными усилиями. Фактически существует несколько реализаций на Java, из которых вы можете выбирать.
Мне не очень понятен этот фрагмент. В java есть многомерные массивы, они являются частью языка и есть только одна «реализация». Вот пример:
byte[][][] test = new byte[100][100][100];Krummi Автор
19.02.2018 23:17Да, не очень ясный момент. Подозреваю, что автор имел в виду отсутствие многомерности «как в NumPy». В Java, насколько я понимаю, приведённый вами код это всё таки «массив массивов массивов», то есть массив указателей на массивы указателей на массивы элементов. В Python ndarray — это гораздо более гибкая штука, по сути — кусок памяти, который можно разбить на элементы произвольным образом.
potan
20.02.2018 01:20Это будет не массив массивов? То есть с дополнительным уровнем коственности на каждый индекс?
Flux
20.02.2018 18:04Это не многомерный массив в numpy'евском понимании, это массив указателей на массивы указателей на массивы.
Под многомерным массивом тут понимается непрерывный кусок памяти у которого «многомерность» появляется только на этапе индексации. Это дает всякие плюшки типа быстрых решейпов, быстрой индексации, лучшего обращения к кешу и так далее.
Нативно в java такого нет, есть в C#:
byte[ , , ] arr = new byte[2, 3, 8]
vladob
19.02.2018 23:51+1Многие положения статьи показывают, что автор не имел счастья поработать с приличным коммерческим научным софтом, который существовал во все времена, но был не для всех.
Все, что в статье ставится в заслугу Питону, придумано и воплощено давно и другими авторами, как говаривал мой шеф.
Кроме тех преимуществ, которые дал Питону опенсорс, ничего выдающегося в нем для науки ИМХО нет. R люблю больше.
Питон использую вынужденно, если нужен доступ к библиотекам,, с которыми R не подружили.Например OpenCV
chersanya
20.02.2018 00:45Сейчас питон просто «достаточно хорош» по сути во всех областях, пусть и не является везде лучшим. Зато можно знать по сути один язык, и иметь готовые функции для огромного количества математических операций (numpy, scipy, другие более мелкие библиотеки), писать достаточно тяжёлые численные вычисления (numba), заниматься статистикой включая продвинутую байесовскую (pymc), писать маленькие и большие скрипты, делать сайты (flask, django, ...), рисовать графики и иллюстрации (matplotlib), и многое другое. И пусть в одной области несколько лучше чем python будут C/Fortran, в другой R, в третьей например nodejs — но библиотек на любой случай жизни уже столько, что другие языки нужны в очень-очень узких случаях.
Всё вышеописанное конечно не относится к программистам, у которых программа это основной выходной результат — скорее к учёным или людям, программирование для которых является именно инструментом. Сейчас вижу, как у нас всё больше и больше людей разных возрастов (как минимум до 40-50) переходят на питон со всяких fortran, idl, perl и т.п.
Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.potan
20.02.2018 01:24Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
Положительная обратная связь. Много пользователей — имеет смысл разработчикам делать биндинги своих библиотек, доступно много библиотек — у пользователей появляется стимул перейти в эту экосистему.
vladob
20.02.2018 01:53Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
Что и где появилось впервые — вопрос спорный.
Вот здесь главный (но не единственный) репозиторий библиотек R.
В принципе, это нарастающий холивар -- R vs Python in Data ScienceПосмотрите, может найдете что-нить для себя.
Мой взгляд на этот вопрос — выбор во многом зависит кто и откуда приходит в то, что сейчас называют Data Science.
К R приходят те, чей путь тем или иным образом проходит через медико-биологические и кондово-статистические задачи. Т.е. из науки (исходно без программирования), но с кучей данных.
В Python-Sci приходят из программирования, когда открывают для себя науку.
Но эти часто бросаются в Python вместо (бездарного по их мнению) сидения в библиотеке и изучения наследия гигантов. Вот они погуглили, все поняли, а потом все, что они поняли, расскажут коротко и ясно в 3-х минутном ролике на Ютубе.
Утрирую, конечно…
За что и почему я люблю R я писал.
chersanya
20.02.2018 07:45В data science — может и нарастающий холивар, не буду спорить (хотя все знакомые в этой отрасли преимущественно используют питон, да и курсы в основном на нём). И я знаю, что в R есть больше статистических библиотек — но ведь data science и статистика это только один из огромного массива применений для языка программирования. В R, насколько я знаю, далеко не так удобно писать например сайты, скрипты автоматизации; ООП так себе в нём реализовано; биндинги для всяких нишевых библиотек реже есть готовые. Ну и лично мне сам язык не понравился, хотя начал немного писать на нём примерно одновременно с питоном :)
А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook, это уже потом куда подключили всё что можно. И сейчас намного проще писать на питоне, изредка для очень узкоспециализированных вещей используя например R, чем наоборот.potan
20.02.2018 09:29Вообще-то notebook сначала появился для Wolfram Mathematica.
chersanya
20.02.2018 16:26Ну вольфрам это всё-таки не general purpose язык, его напрямую странно сравнивать с питоном. Я имею в виду из нормальных языков — а из них питон первый получил notebook.
vladob
21.02.2018 00:05А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook
Идею нотбука на PC я впервые осязал в Mathcad V2.6.
Я с ним немного работал параллельно с Матлабом, но потом Матлаб победил.
спойлерА вообще я опасаюсь исторические изыскания молодых и ищущих как вот тут с Питоном. Что компьютер изобрел Бил Гейтся и Стив Джобс — это я уже слышал.
В общем, не против Питона я.
Не сотвори себе кумира — я вот о чем.
chersanya
21.02.2018 11:36Прочитайте комментарий прямо над вашим — он абсолютно так же применим к Mathcad, как и к wolfram mathematica. Оба этих продукта странно напрямую сравнивать с нормальными языками (типа C/Python/...).
Krummi Автор
21.02.2018 13:48исторические изыскания молодых и ищущих
Не знаю насчёт комментаторов, но автора статьи едва ли можно назвать молодым. Он вообще являлся одним из разработчиков Numerical Python, так что, надо полагать, знает о чём говорит.
Сопутствующие bias — отдельная тема, но как попытка описать возможные причины объективно наблюдаемой популярности Python — почему бы и нет?
irepetitor_ru
20.02.2018 02:05Научные вычисления научным вычислениям рознь. Если говорить про анализ данных, то
есть большая четвёрка универсальных программ, есть куча мелких полезных специализированных программ, есть недо-программы. Python видимо входит в третью группу.
Как универсальная платформа, библиотеки python не дотягивают ни до R, ни до SAS, ни до Matlab. Если человек не работал в статистических программах, то он вряд ли поймёт минусы python, у него нет какого-то сценария, что должен делать уважающий себя статпакет с пол пинка.
Alex_ME
20.02.2018 10:26Как говорил мой преподаватель, Python — это клей между большим количеством разнообразных готовых библиотек.
ElectroGuard
Что-то я так ничего и не понял. Чем же он так хорош? Единственный пример с массивами так и не доведен до логической развязки. В общем — видимо, минусы не зря поставили.