Почему Python используется для высокопроизводительных / научных вычислений (а Ruby нет)?


106

Вот цитата из выступления на PyCon 2011 :

По крайней мере, в нашем магазине (Аргоннская национальная лаборатория) у нас есть три общепринятых языка для научных вычислений. В этом порядке они являются C / C ++, Fortran во всех его диалектах и ​​Python. Вы заметите абсолютное и полное отсутствие Ruby, Perl, Java.

Это было в более общем контексте высокопроизводительных вычислений. Конечно, цитата только из одного магазина, но в другом вопросе о языках для HPC также указан Python для изучения (а не для Ruby).

Теперь я могу понять, что C / C ++ и Fortran используются в этом проблемном пространстве (и Perl / Java не используется). Но я удивлен, что будет существенное различие в использовании Python и Ruby для HPC, учитывая, что они довольно похожи. (Примечание - я фанат Python, но ничего не имею против Ruby).

Есть ли какая-то конкретная причина, почему один язык взлетел? Это о доступных библиотеках? Некоторые особенности языка? Сообщество? Или, может быть, просто историческое происшествие , и оно могло пойти другим путем?


2
Я хотел бы предположить, что, хотя они оба являются динамическими языками, Python и Ruby весьма различны. Больше отличается, чем похожий.
— Адам Кроссленд

20
Я не знаю, что это ответ, но - помните, что у Python было больше «тяги», прежде чем Ruby вышел из небольшого сообщества с Rails (около 2005-2006). Google некоторое время использовал Python, что привело к росту его популярности (начало 2000-х). Синтаксис Python ясен и легок в изучении и чтении (и помните, что это было в эпоху, когда Perl был действительно единственным другим важным вариантом), поэтому я думаю, что это действительно подтолкнуло научные вычисления к этому. После этого это было, вероятно, самоутверждение, так как люди создавали NumPy / SciPy, MatPlotLib и многие другие пакеты для научных вычислений.
— wkl

4
Люди, заинтересованные в этом вопросе, также могут заинтересоваться сайтом обмена стеками Computational Science
— Марк Бут


1
Чтобы предложить некоторую перспективу вычислительной химии, довольно просто распараллелить вычисления с Python, а также дешево. Возможно, и то, и другое верно и в Ruby. Я не знаю.
— Джонатан Ландрум

Ответы:


108

Я буду расширять свой комментарий.

Я думаю, что есть несколько факторов, которые повлияли на использование Python в научных вычислениях, хотя я не думаю, что есть какие-то определенные исторические моменты, в которых вы могли бы сказать: «Да, именно поэтому Python используется над Ruby / чем-то еще. "

История ранних веков

Python и Ruby примерно одного возраста - согласно Wikipedia, Python был впервые официально выпущен в 1991 году, а Ruby - в 1995 году.

Тем не менее, Python приобрел известность раньше, чем Руби, так как Google уже использовал Python и искал разработчиков Python на рубеже тысячелетий. Так как у нас нет кураторской истории использования языков программирования и их влияния на людей, которые их используют, я буду теоретизировать, что это раннее принятие Python компанией Google стало большим стимулом для людей, стремящихся выйти за рамки простого использования Matlab, C ++, Фортран, Стата, Математика и др.

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

Событие слияния

Научные вычисления раньше выполнялись на специализированных машинах, таких как SGI и Crays (помните их?), И, конечно, FORTRAN широко использовался (и все еще используется) из-за его относительной простоты и потому, что его можно было легче оптимизировать.

В последние десять лет или около того, в сфере научных и массовых вычислений захватили товарные аппаратные средства (то есть то, что вы или я можем себе позволить, не будучи миллионерами). Посмотрите на текущие топ-500 рейтинга - многие из «суперкомпьютеров» с самым высоким рейтингом в мире построены на обычном оборудовании Intel / AMD.

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

Плюс, если вы покопаетесь в каких-то старых статьях по научным вычислениям, они начали появляться примерно в эпоху 2000 года.

Ранее поддержка

Вот статья, написанная для программного обеспечения и систем для анализа астрономических данных , написанная в 2000 году, предлагающая Python как язык для научных вычислений.

В статье есть эта цитата о Python:

Python - это интерпретируемый объектно-ориентированный язык программирования, которому в научных приложениях уделяется значительное внимание (Python, 1999). Это потому, что Python и языки сценариев в целом представляют собой следующий логический шаг для многих научных проектов (Dubois 1994). Во-первых, Python предоставляет интерпретированный язык программирования, который можно рассматривать как расширение простых командных языков, уже используемых научными программами.

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

Итак, вы можете видеть, что у Python уже была тяга, восходящая к концу 90-х годов, потому что он был функционально похож на существующие системы в то время, и потому что было легко интегрировать Python с такими вещами, как C и существующие программы. Основываясь на содержании статьи, Python уже находился в научном использовании, начиная с 1995-1996 годов.

Разница в росте популярности

Популярность Ruby взорвалась вместе с ростом Ruby On Rails, который впервые появился в 2004 году. Я был в колледже, когда впервые услышал шум о Ruby, и это было примерно в 2005-2006 годах. django для Python был выпущен примерно в то же время (июль 2005 года, согласно Wiki), но внимание сообщества Ruby, казалось, было сосредоточено на продвижении его использования в веб-приложениях.

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

  • NumPy - NumPy официально запущен в 2005 году, но две библиотеки, на которых он был построен, были выпущены ранее: Numeric (1995) и Numarray (2001?)

  • BioPython - библиотека биологических вычислений для python, датируется как минимум 2001 годом

  • SAGE - Математический пакет с первым публичным выпуском в начале 2005 года

И многие другие, хотя я не знаю многих из их временных шкал (кроме простого просмотра их сайтов загрузки), но Python также имеет SciPy (построенный на NumPy, выпущенном в 2006 году), имел привязки с R (язык статистики) в в начале 2000-х получил MatPlotLib, а также получил действительно мощную оболочку в ipython.

ipython был впервые выпущен в начале 2000-х годов, и в него было добавлено много функций, которые делают его очень удобным для научных вычислений, например, интегрированный графический режим matplotlib и возможность управления вычислительными кластерами .

Сверху статья:

Стоит также отметить ряд других научных проектов, связанных с Python. Числовое расширение Python добавляет быстрые манипуляции с массивами и матрицами в Python (Dubois 1996), MMTK - это основанный на Python инструментарий для молекулярного моделирования (Hinsen 1999), проект Biopython разрабатывает основанные на Python инструменты для исследований в области наук о жизни (Biopython 1999), и Visualization Toolkit (VTK) - это расширенный пакет визуализации с привязками Python (VTK, 1999). Кроме того, текущие проекты в сообществе Python разрабатывают расширения для обработки изображений и печати. Наконец, работа, представленная в (Greenfield, 2000), описывает использование Python в проектах в STScI.

Хороший список научных и числовых пакетов для Python .


Так что, скорее всего, это связано с ранней историей и относительной неясностью Ruby до 2000-х годов, тогда как Python приобрел популярность благодаря евангелизации Google.

Итак, если вы оценивали языки сценариев в период с 1995 по 2000 год, на что вы действительно смотрели? Был Perl, который, вероятно, достаточно отличался синтаксически, чтобы люди не хотели его использовать, а затем был Python, который имел более четкий синтаксис и лучшую читабельность.

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

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


8
Я забыл немного о c интеграции. Во многих случаях научные вычисления требуют значительных вычислительных ресурсов, и возможность написать переменную для этого бита является важным преимуществом.
— Спенсер Ратбун

1
@SpencerRathbun В статье, на которую я ссылался, упоминается использование Python с SWIG для генерации оболочек и обеспечения возможности взаимодействия Python с кодом C / C ++. SWIG не получал официальную поддержку Ruby до выпуска Ruby 1.6, выпущенного в 2004 году. Поэтому Python уже имел большой старт, просто подумав и поделившись инструментами, позволяющими людям внедрить Python в свои существующие системы. Отсутствие необходимости отбрасывать весь существующий оптимизированный код FORTRAN / C, который использовался, было, вероятно, самым большим драйвером.
— wkl

3
В 1991 году мы использовали TCL для объединения числовых библиотек в качестве способа анализа данных без необходимости писать массу C / Fortran. Python пришел как раз в нужное время, чтобы заменить TCL. Простота взаимодействия с 'C' (и F2C с fortran) была большой проблемой по сравнению с PERL, интерфейс TCL с 'C' был очень легок
— Мартин Беккет

Процессы предпочтительного присоединения объясняют очень много о том, какие языки используются. Это Зипфиан! Смотрите Zipf Myatery "PAP" объясняется в 12:50 в него.
— радаробоб

37

Я широко использовал Python для инженерных приложений и Ruby для веб-приложений.

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

Python разработан с учетом следующей предпосылки: «Должен быть один - и желательно только один - очевидный способ сделать это». Это намного облегчает чтение чьего-либо кода и определение его намерений. Это ключ к экспертным оценкам для машиностроения и т. Д.

Мне нравится Ruby, и он отлично подходит для определенных задач, но мой код Ruby может синтаксически полностью отличаться от кода другого программиста, который делает то же самое. Это вызывает слишком много двусмысленности в научной или инженерной среде.


3
Да, в самом деле. Ruby - это традиция TIMTOWTDI, поэтому он немного лучше Perl. Программное обеспечение написано для программистов. Компиляторы / интерпретаторы являются в этом смысле вторичной аудиторией. Ученые, как правило, серьезно относятся к выполнению своей работы без чрезмерного вмешательства излишне сложного программного обеспечения. КЭД
— Доминик Кронин

4
Не уверен, что я следую этому аргументу. Если программист, а не машина, является основной аудиторией, бывают случаи, когда формулировка по-разному улучшает ясность и подчеркивает цель. Разве более гибкий язык не помогает пониманию нашим мягким человеческим мозгом?
— Андрей Вит

10
Но C может выглядеть как взрыв на фабрике ASCII. Напомним, что в C массив представляет собой оболочку вокруг указателей. Таким образом, массив [5] можно записать как * (массив + 5), который можно записать как * (5 + массив), который можно записать как 5 [массив]. Что глупо.
— Джонатан Ландрум

1
Я очень долгосрочный программист на Perl, и он остается моим любимым языком для большинства целей. Не уверен насчет математики, хотя. Я бы не согласился с таким отношением к подходу TIMTOWTDI. Наличие множества доступных подходов, конечно, не означает, что все они хороши, но важно иметь возможность адаптировать свое выражение так, чтобы оно четко и непосредственно соответствовало идее, которую вы выражаете, как вашей человеческой, так и машинной аудитории. Отсутствие синтаксических опций не помогает этому.
— mc0e

@AndrewVit: не обязательно. TIMTOWTDI прекрасно работает, если у вас есть один разработчик, или если у вас небольшая, тесно интегрированная команда разработчиков. Но как только у вас есть люди , которые никогда не встречались работать на том же коде, что вы собираетесь начать спрашивать себя : «О, почему они делают это , что путь?» Или, в качестве альтернативы, вы напишите руководство по стилю, чтобы заставить всех делать то же самое, и тогда вы больше не будете выполнять TIMTOWTDI.
— Кевин

17

По большому счету, большая часть исследователей будет полагаться на matlab . У Python есть альтернативы, такие как sage . В то время как рубин нет, или, по крайней мере, нет очевидных.

Во-вторых, согласно Ruby FAQ , python является как процедурным, так и объектно-ориентированным, тогда как ruby маскируется под процедурный язык. Если вы пишете небольшой скрипт для математических целей, например, что вы делаете в matlab, парадигма ОО - это головная боль. Не только это, но и заставляет концептуально отойти от функциональных / процедурных парадигм, которые используют исследователи. Математика это не ОО. Математика функциональна, за ней следуют процедурные (подумайте логические доказательства).

Наконец, обратите внимание, что в FAQ по Ruby говорится, что ruby ​​сложнее, чем python. Программирование занимает второе место среди исследователей, а не первое, как мы.


22
Я думаю, что ОО вещь немного красная селедка. Что волнует исследователя, 1 + 1отправляет ли выражение сообщение +объекту 1? Это не меняет структуру вашей программы в малейшей степени.
— sepp2k

1
@ sepp2k, я думаю, что Спенсер предполагает, что Руби потребует, чтобы ученые программировали по- другому. Я не знаю Ruby, но предположим, что вам пришлось создавать объекты для написания программы на Ruby, тогда как Python допускает процедуры - это увеличило бы умственные издержки. Да, не так много, но для непрограммистов каждая дополнительная работа могла бы стать причиной использования другого языка.
— Циклоп

7
@ Циклоп, я понял, что он предлагает. Я говорю, что это неправильно. Весь смысл цитаты о маскировке рубина как процедурного языка состоит в том, что вам не нужно структурировать вашу программу объектно-ориентированным способом. Если вы вводите что-то вроде «2 + 2», вы создаете два объекта Integer и вызываете метод для одного (передавая другой в качестве аргумента). Однако это не заставляет набирать «2 + 2» в ruby ​​больше усилий, чем набирать «2 + 2» на других языках.
— sepp2k

5
Я с sepp2k, я тоже не покупаю этот аргумент. Некоторые языки, такие как Java, навязывают вам парадигму OO - не так с Ruby. Что мешает вам написать чисто процедурную или функциональную программу на Ruby?
— Майк Баранчак

2
@ Циклоп точно. Хотя Ruby может претендовать на процедурный характер, в нетривиальном контексте вы столкнетесь с ситуациями, когда парадигма ОО заставляет язык работать определенным образом. Если вы не понимаете или игнорируете это, то либо вы не можете делать то, что вы хотите, либо вы получите грязный хак.
— Спенсер Рэтбун

14

Когда BDFL (Guido van Rossum) впервые написал Python, цель состояла в том, чтобы он был так же понятен, как и простой английский (предложение финансирования DARPA), что позволило бы устранить распространенные ошибки кодирования.

Одна проблема, которая очень заметна - это использование отступа для разделения блоков. В языках, которые имеют явные сложные разделители операторов (например, C-скобки, Pascal BEGIN / END), пробелы будут свернуты в один пробел перед передачей кода в лексер. Это позволило бы значительно варьировать способ написания кода.

Для профессиональных программистов это не проблема, потому что они приучили себя справляться с этим с 30 или более часов в неделю практики.

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

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

Это единственный пример того, почему он популярен вне профессии программиста. Есть и другие примеры, которые можно использовать для иллюстрации того же момента, такие как включенные батарейки, The Zen of Python ( import this), использование юмора Монти Пайтона и так далее.


Я не могу найти ссылку на диссертацию или докторскую программу в резюме Гвидо или в списке публикаций. У вас есть цитата для этого? Это интервью просто говорит, что он был исследователем в CWI.
— М. Дадли

Я полностью запутался в этом: я читал, что он сделал это диссертацию, но не проводил должного исследования. Я нашел свою ошибку после того, как написал этот пост, но потом так и не сделал исправления здесь. Благодарю.
— Лэнс Хелстен

5

Это отличная дискуссия, я думаю, что посты действительно ответили, почему python более популярен в научном сообществе. Тем не менее, есть несколько контраргументов для рубиновых наук:

  • ruby может быть более интуитивно закодирован, чем python (DSL и т. д.): при условии правильного использования пакетов:

    проверьте bioruby: http://bioruby.org/ резерв последовательности может быть простым: s.reverse и т. д., если вы используете базы данных: API связывания базы данных ruby, возможно, лучше, чем python.

  • Рубин позволяет более высокий уровень абстракций в то же время кратко.

  • Лучшая система управления пакетами: рубиновые гемы намного проще по сравнению с: setuptools, pip и т. д.

Однако, усыновление рубина было / будет / будет затруднено его сложностью. Я думаю, что Лисп - отличный / мощный язык, но почему он не стал общим языком? похожая ситуация здесь с ruby ​​- он наследует много власти от lisp, светских разговоров и perl !: но на самом деле только часть людей будет использовать его для получения преимуществ. В конце концов, он может оставаться сильным в определенных нишевых / специальных областях (таких как рельс в сети, марионетка в конфигурации), «не» программистам трудно в полной мере наслаждаться этим, но это может быть хорошим другом программиста (видел некоторый компьютер ученым нравится язык: http://www.cleveralgorithms.com/nature-inspired/index.html )

Некоторое последнее обновление: кажется, что python уже захватывает весь ландшафт. Недавно такие книги, как: http://www.amazon.com/Python-Data-Analysis-Wes-McKinney/dp/1449319793 и многие другие книги (анализ данных, машинное обучение и т. Д.), Все написаны на python в качестве используемого языка. , Если рубин хочет наверстать упущенное, ему нужны серьезные усилия. Рассматривая matplotlib в python, вероятно, потребуется несколько человеко-лет, чтобы привести его в состояние, в котором он находится сейчас. Если в ruby ​​не будут предприняты серьезные усилия, он, вероятно, не сможет догнать этап анализа данных Python / научных вычислений в ближайшие 2-3 года.


3

После использования python для анализа данных в течение некоторого времени (исходя из опыта работы с ruby, lua и R) пакет numpy (и многие связанные с ним научные библиотеки) делает возможным «запуск» быстрых вычислений (скорость, аналогичная C, как numpy) написано / интегрировано с кодами C) с легкостью программирования на Python.

Numpy существует уже некоторое время, его наличие помогло создать множество других связанных научных пакетов, таких как scipy, pandas ... и т. Д. Там отличные инструменты делают python отличной экосистемой для научных вычислений, тогда как в Ruby подобная более быстрая матрица Библиотека вычислений находится в стадии разработки (NMtrix: https://github.com/SciRuby/nmatrix ). Эта огромная разница во времени делает Python очевидным выбором для научных вычислений.


5
«В конце концов, Python как язык всех», вам нужно будет предоставить источник, чтобы поддержать это.
— Уолтер

2

Мне было интересно это то же самое. Я думаю, что это, как сказал Спенсер Рэтбун, из-за процедурного аспекта Python. Будучи «не программистом», я нахожу прекрасным то, как вы можете писать код на Ruby, а инфраструктура Rails отлично подходит для простоты использования. Однако, когда вы пишете код для научных целей (математика, биология и т. Д.), Вы обычно думаете на «математическом» языке, то есть вас не волнуют такие высказывания, как

Person.find_by_name 'Juanito'

но ты больше заботишься о

A = B*C + D

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


0

Python лучше поддерживает N-мерные массивы с пакетом Numpy. Я не видел ничего подобного для Руби.

Python, кажется, быстрее в численных вычислениях / научных вычислениях, которые я сделал. У меня нет никаких доказательств, кроме того, что когда я написал подобные алгоритмы на Python и Ruby, алгоритмы Python работали быстрее (YMMV).


2
Это не очень способствует обсуждению. Эффективность Numpy уже описана (более подробно) в принятом ответе . Ваш аргумент производительности остается неубедительным; Мне не нравится полагаться на анекдоты при обсуждении исторического исполнения, особенно когда любые такие аргументы, вероятно, уже хорошо покрыты достоверными (ну, более надежными, чем анекдот без контекста) тестами.
— Брайан

@ Брайан, согласился.
— Джош Петитт

@ Брайан, мой конкретный вклад был комментарием к N-мерным массивам. В этом суть Numpy, да, но я не видел упоминаний о массивах ND. Это ядро ​​линейной алгебры и то, что хорошо делают Матлаб и Нумпи. Ruby использует массивы так же, как программисты используют массивы, а не как инженеры и ученые используют массивы (то есть матрицы). Если вы думаете, что это поможет, я добавлю комментарий о массивах ND к принятому ответу.
— Джош Петитт

@Brian, и я до сих пор поддерживаю мой комментарий, что я не видел хорошей поддержки массивов ND для Ruby для научных вычислений.
— Джош Петитт

0

Одна из причин заключается в том, что Python имеет хорошую поддержку для использования / интеграции / вызова кода C / C ++, тогда как, насколько мне известно, Ruby не предлагает такой же степени (простоты) интеграции. Это означает, что вы можете написать высокопроизводительные компоненты кода на C / C ++, а затем использовать Python (т. Е. Язык высокого уровня / проще на глазах), чтобы склеить все это вместе. Я полагаю, что это также является одной из причин его раннего институционального принятия Google.


0

Я думаю, что одна из главных причин, почему Python стал настолько популярным для науки о данных, была из-за количества времени / усилий (то есть денег), которые мы могли бы сэкономить, чтобы расширить наши сценарии для реального решения (например, системы программного обеспечения). С помощью Python мы могли бы легче создавать системное решение на основе кода, который мы написали для науки о данных.

У меня есть опыт поиска переводчика с этой функцией около 15 лет назад. В то время Python был выбран именно потому, что это не идеальный язык для науки о данных, а потому, что это был редкий язык ООП с быстрым / переносимым интерпретатором, который также расширялся для взаимодействия с другими языками, такими как C / C ++ / Ява. В отличие от сегодняшнего дня, это были отличные, но редкие возможности для непосредственного построения решений из базового кода, уже реализованного для науки о данных.

Время может быть еще одним критическим фактором для создания языка науки данных. 15 лет назад мы обнаружили, что в Python уже есть базовые пакеты, такие как numeric и scipy для численных вычислений, но мы даже не знали о существовании Ruby как языка программирования. К концу 2018 года я мог найти несколько проектов, использующих Ruby для обработки данных. Возможно, через 10 лет можно было бы спросить, почему Ruby так популярен для ИИ.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.