4) да, потому что всё это, чем вы хвастаетесь в R - всего лишь сахар над этими самыми fp-примитивами. Он есть много где, включая питон
5) arrow - всего лишь формат представления. Polars - не arrow, а набор методов поверх, как и многие другие библиотеки. Даже pandas его сейчас использует, как промежуточное представление
6) я очень за вас рад, но R тут ни при чём. Можно с тем же успехом оптимизировать код на Numpy и сильно выиграть в итоге по скорости и памяти
Моя претензия в том, что ваши заявления не базируются на аргументах - в статье почти все ваши набросы неверны или неточны, что я выше и разобрал. Это похоже на "синдром утёнка", когда человек начинает считать лучшим то, что просто первым познал.
Вы молодец и отлично знаете инструмент, которым пользуетесь, но пока что всерьез показать людям, что на него стоит переходить с более мейнстримных языков у вас, к сожалению, не получилось.
+1 за Брендана, его книжка Systems Performance есть у меня в бумаге
Этого вполне достаточно для констатации, что здесь применяется ООП подход
Разумеется, нет. pd выступает в качестве неймспейса, просто чтобы держать пачку процедур вместе. Датафрейм в той же степи - вы не будете наследоваться от Dataframe/Series в своем коде, не будете переопределять какие-то методы объектов или их поля. Не надо притягивать за уши ООП туда, нет его там
2) Разумеется, я сразу сказал, что это anecdotal evidence. Но я всего лишь толкал вас от "R лучше управляет памятью и типами" к "надо сравнивать и анализировать". Потому что иначе это сильное и ничем не подкрепленное заявление
3) Я ходил по вашим ссылкам и смотрел на этот нечитаемый ад с левыми символами. И привел вам гораздо более явные и читабельные альтернативы со стороны Python. Не надо за меня делать вывод, что я читал, а что нет
4) Я за вас очень рад, вы открыли для себя accumulate() и reduce() (он же fold()). Продолжайте изучать Python, он еще и не такое умеет. Вот вам классное видео, например https://www.youtube.com/watch?v=ThS4juptJjQ
5) На случай, если вы не открывали вашу собственную ссылку - там на первом месте, внезапно, не data.table (который "быстрее всех", по вашим заявлениям), а Polars. А еще в случае pandas там вообще не описано, как именно проводилось чтение датафрейма, были ли указаны типы и кодирование категорий. Я сам не раз согласился с тем, что pandas медленный, но работать с ним тоже нужно уметь. Разница недостаточно большая, чтобы сказать "data.table" однозначно лучше и стоит того, чтобы тащить в проект левый академический язык вместо питона
6) Ваш пункт похож на цитату из Сорокина, вот можно по ссылке посмотреть. Судя по всему, вы просто осознали свою ошибку и теперь просто "бычите" и переходите на личности. Рекомендую вам вот это видео, чтобы понять, о чем вообще речь.
Ну, во-первых, Go до сих пор оправляется от войны между разными способами управлять в нем пакетами. Да, формально go modules победили, что не мешает все равно до сих пор некоторым проектам использовать dep и прочие альтернативы. Да и домены сайтов в импортах модулей смотрятся специфически.
Во-вторых, в Go пока что мало стабильных и готовых к продакшену модулей для сложных вещей. Например, толковый ORM вроде как есть, но иногда в нем встречаются совсем детские ошибки. С миграциями все сложно. С XML неймспейсами Go работать, внезапно, не умеет в принципе, ни через стандартную библиотеку, ни через внешние. Только адские костыли.
В-третьих, разные модули используют разные подходы, например, к остановке горутин. Где-то надо внутрь прокидывать Context, где-то канал, а где-то вообще это не настраивается и приходится переопределять что-то самому. Хранение глобальных переменных в контексте - очевидный антипаттерн, но, тем не менее, тоже иногда используется.
Можно еще много чего вспомнить. Непонятно зачем существующие в языке массивы, указатели на интерфейсы. Не очень хорошего качества http-модуль в стандартной библиотеке, который иногда течет по памяти. append(), результат которого нельзя присваивать не той же переменной, что у него в аргументе. Это все рано или поздно пофиксят или переделают, но пока что смотрится довольно незрело, несмотря на то, что даже сейчас языка проще и удобнее для написания быстрых асинхронных сетевых сервисов просто нет.
1) Вы сейчас пытаетесь россказать, что любой вызов метода через точку - уже ООП? Нет, так не работает. В случае Pandas большинство вещей - это либо методы самого модуля pd, либо методы датафрейма. Откуда там ООП (наследование, полиморфизм, инкапсуляция?) - решительно непонятно 2) Видел, конечно. В R их не меньше, управлять памятью вообще непросто в случае больших датасетов. Но вот выпадать в сегфолт некрасиво 3) спорно. В любом случае, упоминать имя датафрейма постоянно уже не нужно, а других пунктов вы особо и не приводили 4) вы привели внешний модуль, который умеет в цепочечные вызовы. Во-первых, в pandas есть pipe. Во-вторых, в питоне есть масса модулей, которые позволяют делать похожие вещи, потипу toolz или pipetools. И да, это не фича языка
5) я вам привел пример - не обыгрывает. В моем случае пандас справился лучше, да еще и, при грамотном указании типов, в памяти может занимать меньше
6) все прямо наоборот. Бенчмаркинг - всего лишь одна из функций профилировщика. Именно профилировщики и дают полную картину, а простой бенчмаркинг - нет
Да, примерно так и бывает, когда исключительно академичные люди на академичном языке пишут академичный код. Хорошо, что с питоном в этом плане сильно легче, и читать код на нем базово может даже джун
Да, аргумента "потому что и так вокруг питон" уже достаточно. Не говоря уже о том, что разница между питоном и R по части целевых библиотек и производительности не настолько большая, чтобы предпочитать узкоспециализированный язык общему. Достаточно даже просто посмотреть на объемы баз пакетов.
Так я не воспринимаю в штыки. У R есть сильные стороны и он отлично применим в своей нише. Но порой создается впечатление, что люди, которые топят за то, что он там, оказывается, умеет еще и какие-то вебсервисы и что-то еще, просто плохо знают текущие стеки в индустрии. Практически весь MLOps везде на питоне - MLFlow, DVC, Airflow. Пандас медленный, да. Но при правильном приготовлении пережевывает датасеты размером больше, чем R.
Вы все правильно написали, просто почему-то из этого делаете противоположный очевидному вывод - если вся индустрия пишет на питоне, найти питониста легко, найти обертку/модель/что угодно, которая есть в R, но нет в питоне, весьма сложно - так зачем брать R в реальном коммерческом стеке? Ну нет у него преимуществ толком, не-ту. Только для статистиков и аналитиков, только для академических целей. И это его сильная сторона, не надо его натягивать, как сову на глобус, на все подряд.
Так и numpy отлично себя проявляет, и scipy. Зачем брать то, что плохо интегрируется, если можно взять то, что интегрируется хорошо? Из-за того 0.01% статмоделей, которые еще не портировали из R в Python? Сомнительно.
Если учесть, что я работаю архитектором по построению DS-решений... Если бы вы имели дело с коммерческой разработкой подобных вещей, то наверняка знали бы, что в случае классического ML особых изысков бизнес не требует, чаще всего достаточно взять ансамбль простых моделей, какой-нибудь xgboost и все будет работать. На каком языке будут эти модели - не особо важно, но питон лучше и легче интегрируется с остальными компонентами системы.
А про то, что примерно весь DL (там, где он реально нужен) сейчас на питоне, вам уже ниже рассказали в деталях в других комментариях, не буду повторяться.
это ограничение его экосистемы. Тот же Rust, например, несмотря на всю свою красоту и низкоуровневость, до сих пор не очень подходит для решения задач анализа данных в силу слабой интеграции с BLAS и отсутствием стабильного набора тулинга для подобных задач. Это не значит, что в будущем его нельзя будет развить в эту сторону, но это значит, что в текущем виде это не очень хороший выбор для подобного класса задач. То же самое в случае R и почти любых не-статистических задач.
весь тред не читали?
читал. Называется несколько мелких проектов для частных случаев. Это мило, но как это сравнимо с тысячами проектов и оберток в этих же сферах для питона? Судя по аргументам в том комментарии, R взяли просто потому что команда быстрее и проще всего умела на нем фигачить, а не потому, что он прям идеален для подобных задач. И это вполне логично, но никак не является аргументом в поддержку языка. Могли бы взять с тем же успехом любой другой, с которым просто умели работать
Пока джависты уже пыхтят и пишут код, бизнес до сих пор ищет хотя бы одного разработчика на рынке, способного поддерживать легаси на R. И как эту ерунду интегрировать с их вебсайтом и настроить для нее мониторинг. В итоге просто нанимают джуна на питоне, который за пару вечеров переписывает модельку на аналогичную откуда-нибудь из scikit-learn, и это перестает быть проблемой.
1) Нет. Не знаю, откуда вы это взяли, это просто неверно. Более того, несмотря на то, что все - объекты, именно ООП-подход в питоне довольно куцый и не очень удобный
2) Читал. Костыли для управления памятью есть везде, но только вот в пандасе они вполне работают. Более того, у меня был на практике случай, когда большой csv-файл спокойно прочитался пандасом в память (и не сильно много занял), а R выдал...сегфолт. Без объяснений, просто не работало
3) Я привел конкретный пример, как избавиться. Не говоря уже о том, что явное лучше неявного, а переменных без объявления в середине выражения быть реально не должно
4) Не настолько разные. Если вам просто нужно организовать цепочку вычислений, где следующий шаг получает результаты предыдущего - для этого есть генераторы. Пайп - это конструкция в первую очередь операционной системы, а в языках есть разные свои обертки, которые реализуют что-то похожее
5) Не понял, причем тут распределенные вычисления. Питоном тоже можно считать на одной машине
6) Профилировщик - сюрприз - в том числе может запускать бенчмарки по коду. По вашим ссылкам всего лишь простейшие инструменты для флеймграфов, при этом тот же Scalene умеет, например, в рандомизацию окружения, бенчмарки на GPU, бенчмарки многопоточных и многопроцессных программ, отдельный вывод статистики не только по user time vs kernel time, но и по Python time vs C time
P.S. Ваша нумерация ответов полностью игнорирует нумерацию в моем комментарии, в результате сбивает с толку и игнорирует часть пунктов, которые были упомянуты выше. Это не очень хороший прием в обсуждении
dplyr/dbplyr транслирует dplyr-глаголы соединенные пайпами в родной SQL в любую поддерживаемую БД
Я могу на основе этого подхода в проекте завести миграции, которые можно будет одной командой накатывать и откатывать? Нет же?
это давно не так в задачах вокруг данных, от их добычи до выдачи пользы наружу
для работы с данными, анализа их и построения статистики - несомненно, я с этим и не спорил. Я говорил именно про применение в качестве языка общего назначения. Представьте себе сайт веб-приложений из нескольких вебсервисов, например. Там, где нужна интеграция с биллингами, внешними API, работа с отложенными задачами, конвертации форматов данных. Кто для этой задачи возьмет R? Да никто, потому что он для этого не подходит. Если вы фанатик, то вы сможете все это при помощи такой-то матери реализовать, да, но зачем, если гораздо проще взять языки, лучше подходящие для этой задачи?
Вот поэтому я и говорю - R решает задачи статистики и делает это отлично. Он удобен для статистиков и аналитиков, математичен и лаконичен. Но когда речь идет о написании коммерческого решения на бэкенде, с интеграциями, дальнейшим развитием и поддержкой, он не подходит.
Почти все решения для R, которые я нашел навскидку для асинхронного HTTP и сваггера, не обновлялись уже несколько месяцев минимум (нет коммитов), а то и несколько лет. Это не значит, что не существует более свежих и широко используемых, конечно, но немного настораживает. И я согласен, что ORM - зло, но все-таки лучше, когда есть возможность на нем быстро собрать и сделать миграции, чем совсем без него писать все руками.
Так что да, я даже не считаю это за холивар - R действительно не подходит для решения задач общего назначения. Это не делает его плохим языком, хотя лично мне его синтаксис кажется весьма неудобным по сравнению с промышленными языками. Просто за пределами его основной области (статистический анализ) он несравним с более крупными игроками, а то, что питон по функциональности даже в анализе практически перегнал - не очень хороший знак для языка в целом. Скорее всего, он так и останется академическим, и это отлично для него. Лучше расти вглубь, чем вширь.
В области DS все просто - Python умеет примерно все то же самое, что и R, но еще и многое другое сверху, что и делает его более желательной целью для изучения и продвижения. А еще вы подменяете понятия - фразы "го лучше питона в конкретной сфере" и "питон не универсален" логически не связаны. Да, лучше. Но нет, универсален.
Видел я многие курсы, не надо старье пихать 20-ти летней давности. Курсы надо актуализировать периодически, хоть это и трудозатратно.
Эти курсы сейчас актуализируют тем, что переводят их на Python. Потому что он более востребован и удобен для широкого круга задач.
Не надо воспринимать эти заявления, как личные нападки. Это очень удобная позиция, бесспорно, но никто лично на вас не наезжает. Просто почти все пункты вашей статьи не по делу.
1) "ООП и DS плохо совместимы" - возможно, только Python тут ни при чем. Он позволяет использовать как ООП, так и процедурный подход при желании. Мимо. 2) "Недостаточность базовых типов данных" - import numpy решает эту проблему. Мимо. 3) "Векторизация" - см предыдущий пункт. Мимо. 4) "Колонки", "Поддерживается странная концепция эквивалентности работы как по вертикали, так и по горизонтали" - это прямым текстом неправда. Pandas хранит данные в колоночно-ориентированном формате и оптимизирован для векторных операций на колонках. То, что можно, перебирать ряды - просто костыль и общепризнанный антипаттерн. Мимо. 5) "Индекс" - редкая валидная претензия, которая, тем не менее, чинится просто чтением документации один раз 6) "Copy-paste" - про метод query мы умолчим, а то идея развалится. Мимо. 7) "Отсутствие полноценной конвейерной обработки (pipe)" - то, что вы не знаете про генераторы в Python, не значит, что они отсутствуют. Мимо. 8) "Производительность" - да, согласен, Pandas довольно медленный. Но, во-первых, ему есть масса альтернатив (как лихо вы выкинули из рассмотрения Dask и polars, ни к селу ни к городу приплетя Clickhouse). А во-вторых - вот новость - статистический анализ в питоне не ограничивается пандасом. 9) "Бенчмарки" - написана лютая чушь, извините, конечно. Вы бы ради приличия хотя бы разведали, что существуют Scalene и Memray, ничего хотя бы близкого к которым в мире R не существует в принципе. Мимо.
Вот отсюда и подобная реакция на сей опус - он делает ряд мало связанных с реальностью заявлений и сравнивает бензопилу и швейцарский нож.
Я на этом докладе был лично. То, что вы приводите его в пример, показывает, что вы вообще не понимаете, о чем речь - Go не является заменой питона, тем более в DS, и у него масса проблем с экосистемой. Он отлично подходит для быстрых асинхронных сетевых сервисов и вещей потипу параллельных ETL, но это весьма специфическая вещь.
Про полмира вы, мягко говоря, лукавите. Полмира сидит как раз на питоне, а R знает только по отдельным статьям, и то ищут, как те же вещи перетащить в питон. Ведущие университеты курсы переводят на питон.
P.S. Да, если что, вам "стыдно" за курсы Johns Hopkins University, например. Не говоря уже о том, что предложенный пойнт про "почему так методы называются" самоочевиден, с ним сложно спорить. Это еще одна из слабых сторон R.
и применять его вне академической среды - моветон?
Разумеется, моветон. Это нецелевое использование инструмента.
и может быть академическая среда применяет R по академически, не по программистки?
Нет, потому что R - не язык программирования. R - язык статистического анализа. Для этого он подходит хорошо, а языком общего назначения он отродясь не был.
микросервисы на R? легко, пакет RestRserve + Docker и вперед
Ничего "легкого" в этом нет. Нормальная поддержка Swagger-спек? Асинхронности? ORM? Валидации структур? Есть несколько костылей, которые позволяют сделать что-то отдаленно похожее, но по факту язык просто для этого не подходит.
Нет, конечно. Половину ваших претензий из статьи можно просто перечеркнуть фразой "просто возьмите numpy". Низкоуровневые типы? Numpy. Векторизация? Numpy. R - узкоспециализированная штука, которая умеет это из коробки - ну и молодец. А для питона это всего лишь еще одна из функций.
Питон офигительно развивается с точки зрения производительности и с точки зрения параллельности. Погуглите по словам Mark Shannon, Pyston и multiprocessing shared memory. Вот буквально только что JIT зарелизили, например https://opennet.ru/57320/
R непригоден для промышленной разработки. Я проходил курсы по нему от нескольких университетов, и в каждом из них были фразы в духе "почему эти функции называются lapply/rapply/xapply/tapply? никто не знает, надо просто зазубрить" и "если у вас при импорте датасета возникает сегфолт - попробуйте другую версию библиотеки". Это язык, созданный в академической среде для этой самой академической среды. Давайте будем честны и не будем делать вид, что он отлично подходит для разработки тех же микросервисов. Это примерно как разработка десктопных приложений на PHP - по фану можно, но на деле язык не для этого.
Это далеко не всегда правда даже в айти. Формально да, это одна из причин роста зарплаты айтишников вообще, но чем дальше мы уходим от крупных городов и от технических компаний - ситуация становится сложнее. Пандемия немного с этим помогла, не спорю, но примерно в любой книге по переговорам написано, что главная ошибка - это принимать первое же предложение другой стороны.
4) да, потому что всё это, чем вы хвастаетесь в R - всего лишь сахар над этими самыми fp-примитивами. Он есть много где, включая питон
5) arrow - всего лишь формат представления. Polars - не arrow, а набор методов поверх, как и многие другие библиотеки. Даже pandas его сейчас использует, как промежуточное представление
6) я очень за вас рад, но R тут ни при чём. Можно с тем же успехом оптимизировать код на Numpy и сильно выиграть в итоге по скорости и памяти
Моя претензия в том, что ваши заявления не базируются на аргументах - в статье почти все ваши набросы неверны или неточны, что я выше и разобрал. Это похоже на "синдром утёнка", когда человек начинает считать лучшим то, что просто первым познал.
Вы молодец и отлично знаете инструмент, которым пользуетесь, но пока что всерьез показать людям, что на него стоит переходить с более мейнстримных языков у вас, к сожалению, не получилось.
+1 за Брендана, его книжка Systems Performance есть у меня в бумаге
1)
Разумеется, нет. pd выступает в качестве неймспейса, просто чтобы держать пачку процедур вместе. Датафрейм в той же степи - вы не будете наследоваться от Dataframe/Series в своем коде, не будете переопределять какие-то методы объектов или их поля. Не надо притягивать за уши ООП туда, нет его там
2) Разумеется, я сразу сказал, что это anecdotal evidence. Но я всего лишь толкал вас от "R лучше управляет памятью и типами" к "надо сравнивать и анализировать". Потому что иначе это сильное и ничем не подкрепленное заявление
3) Я ходил по вашим ссылкам и смотрел на этот нечитаемый ад с левыми символами. И привел вам гораздо более явные и читабельные альтернативы со стороны Python. Не надо за меня делать вывод, что я читал, а что нет
4) Я за вас очень рад, вы открыли для себя accumulate() и reduce() (он же fold()). Продолжайте изучать Python, он еще и не такое умеет. Вот вам классное видео, например https://www.youtube.com/watch?v=ThS4juptJjQ
5) На случай, если вы не открывали вашу собственную ссылку - там на первом месте, внезапно, не data.table (который "быстрее всех", по вашим заявлениям), а Polars. А еще в случае pandas там вообще не описано, как именно проводилось чтение датафрейма, были ли указаны типы и кодирование категорий. Я сам не раз согласился с тем, что pandas медленный, но работать с ним тоже нужно уметь. Разница недостаточно большая, чтобы сказать "data.table" однозначно лучше и стоит того, чтобы тащить в проект левый академический язык вместо питона
6) Ваш пункт похож на цитату из Сорокина, вот можно по ссылке посмотреть. Судя по всему, вы просто осознали свою ошибку и теперь просто "бычите" и переходите на личности. Рекомендую вам вот это видео, чтобы понять, о чем вообще речь.
Ну, во-первых, Go до сих пор оправляется от войны между разными способами управлять в нем пакетами. Да, формально go modules победили, что не мешает все равно до сих пор некоторым проектам использовать dep и прочие альтернативы. Да и домены сайтов в импортах модулей смотрятся специфически.
Во-вторых, в Go пока что мало стабильных и готовых к продакшену модулей для сложных вещей. Например, толковый ORM вроде как есть, но иногда в нем встречаются совсем детские ошибки. С миграциями все сложно. С XML неймспейсами Go работать, внезапно, не умеет в принципе, ни через стандартную библиотеку, ни через внешние. Только адские костыли.
В-третьих, разные модули используют разные подходы, например, к остановке горутин. Где-то надо внутрь прокидывать Context, где-то канал, а где-то вообще это не настраивается и приходится переопределять что-то самому. Хранение глобальных переменных в контексте - очевидный антипаттерн, но, тем не менее, тоже иногда используется.
Можно еще много чего вспомнить. Непонятно зачем существующие в языке массивы, указатели на интерфейсы. Не очень хорошего качества http-модуль в стандартной библиотеке, который иногда течет по памяти. append(), результат которого нельзя присваивать не той же переменной, что у него в аргументе. Это все рано или поздно пофиксят или переделают, но пока что смотрится довольно незрело, несмотря на то, что даже сейчас языка проще и удобнее для написания быстрых асинхронных сетевых сервисов просто нет.
1) Вы сейчас пытаетесь россказать, что любой вызов метода через точку - уже ООП? Нет, так не работает. В случае Pandas большинство вещей - это либо методы самого модуля pd, либо методы датафрейма. Откуда там ООП (наследование, полиморфизм, инкапсуляция?) - решительно непонятно
2) Видел, конечно. В R их не меньше, управлять памятью вообще непросто в случае больших датасетов. Но вот выпадать в сегфолт некрасиво
3) спорно. В любом случае, упоминать имя датафрейма постоянно уже не нужно, а других пунктов вы особо и не приводили
4) вы привели внешний модуль, который умеет в цепочечные вызовы. Во-первых, в pandas есть pipe. Во-вторых, в питоне есть масса модулей, которые позволяют делать похожие вещи, потипу toolz или pipetools. И да, это не фича языка
5) я вам привел пример - не обыгрывает. В моем случае пандас справился лучше, да еще и, при грамотном указании типов, в памяти может занимать меньше
6) все прямо наоборот. Бенчмаркинг - всего лишь одна из функций профилировщика. Именно профилировщики и дают полную картину, а простой бенчмаркинг - нет
Да, примерно так и бывает, когда исключительно академичные люди на академичном языке пишут академичный код. Хорошо, что с питоном в этом плане сильно легче, и читать код на нем базово может даже джун
Да, аргумента "потому что и так вокруг питон" уже достаточно. Не говоря уже о том, что разница между питоном и R по части целевых библиотек и производительности не настолько большая, чтобы предпочитать узкоспециализированный язык общему. Достаточно даже просто посмотреть на объемы баз пакетов.
Так я не воспринимаю в штыки. У R есть сильные стороны и он отлично применим в своей нише. Но порой создается впечатление, что люди, которые топят за то, что он там, оказывается, умеет еще и какие-то вебсервисы и что-то еще, просто плохо знают текущие стеки в индустрии. Практически весь MLOps везде на питоне - MLFlow, DVC, Airflow. Пандас медленный, да. Но при правильном приготовлении пережевывает датасеты размером больше, чем R.
Вы все правильно написали, просто почему-то из этого делаете противоположный очевидному вывод - если вся индустрия пишет на питоне, найти питониста легко, найти обертку/модель/что угодно, которая есть в R, но нет в питоне, весьма сложно - так зачем брать R в реальном коммерческом стеке? Ну нет у него преимуществ толком, не-ту. Только для статистиков и аналитиков, только для академических целей. И это его сильная сторона, не надо его натягивать, как сову на глобус, на все подряд.
Так и numpy отлично себя проявляет, и scipy. Зачем брать то, что плохо интегрируется, если можно взять то, что интегрируется хорошо? Из-за того 0.01% статмоделей, которые еще не портировали из R в Python? Сомнительно.
Если учесть, что я работаю архитектором по построению DS-решений... Если бы вы имели дело с коммерческой разработкой подобных вещей, то наверняка знали бы, что в случае классического ML особых изысков бизнес не требует, чаще всего достаточно взять ансамбль простых моделей, какой-нибудь xgboost и все будет работать. На каком языке будут эти модели - не особо важно, но питон лучше и легче интегрируется с остальными компонентами системы.
А про то, что примерно весь DL (там, где он реально нужен) сейчас на питоне, вам уже ниже рассказали в деталях в других комментариях, не буду повторяться.
это ограничение его экосистемы. Тот же Rust, например, несмотря на всю свою красоту и низкоуровневость, до сих пор не очень подходит для решения задач анализа данных в силу слабой интеграции с BLAS и отсутствием стабильного набора тулинга для подобных задач. Это не значит, что в будущем его нельзя будет развить в эту сторону, но это значит, что в текущем виде это не очень хороший выбор для подобного класса задач. То же самое в случае R и почти любых не-статистических задач.
читал. Называется несколько мелких проектов для частных случаев. Это мило, но как это сравнимо с тысячами проектов и оберток в этих же сферах для питона? Судя по аргументам в том комментарии, R взяли просто потому что команда быстрее и проще всего умела на нем фигачить, а не потому, что он прям идеален для подобных задач. И это вполне логично, но никак не является аргументом в поддержку языка. Могли бы взять с тем же успехом любой другой, с которым просто умели работать
Пока джависты уже пыхтят и пишут код, бизнес до сих пор ищет хотя бы одного разработчика на рынке, способного поддерживать легаси на R. И как эту ерунду интегрировать с их вебсайтом и настроить для нее мониторинг. В итоге просто нанимают джуна на питоне, который за пару вечеров переписывает модельку на аналогичную откуда-нибудь из scikit-learn, и это перестает быть проблемой.
1) Нет. Не знаю, откуда вы это взяли, это просто неверно. Более того, несмотря на то, что все - объекты, именно ООП-подход в питоне довольно куцый и не очень удобный
2) Читал. Костыли для управления памятью есть везде, но только вот в пандасе они вполне работают. Более того, у меня был на практике случай, когда большой csv-файл спокойно прочитался пандасом в память (и не сильно много занял), а R выдал...сегфолт. Без объяснений, просто не работало
3) Я привел конкретный пример, как избавиться. Не говоря уже о том, что явное лучше неявного, а переменных без объявления в середине выражения быть реально не должно
4) Не настолько разные. Если вам просто нужно организовать цепочку вычислений, где следующий шаг получает результаты предыдущего - для этого есть генераторы. Пайп - это конструкция в первую очередь операционной системы, а в языках есть разные свои обертки, которые реализуют что-то похожее
5) Не понял, причем тут распределенные вычисления. Питоном тоже можно считать на одной машине
6) Профилировщик - сюрприз - в том числе может запускать бенчмарки по коду. По вашим ссылкам всего лишь простейшие инструменты для флеймграфов, при этом тот же Scalene умеет, например, в рандомизацию окружения, бенчмарки на GPU, бенчмарки многопоточных и многопроцессных программ, отдельный вывод статистики не только по user time vs kernel time, но и по Python time vs C time
P.S. Ваша нумерация ответов полностью игнорирует нумерацию в моем комментарии, в результате сбивает с толку и игнорирует часть пунктов, которые были упомянуты выше. Это не очень хороший прием в обсуждении
Я могу на основе этого подхода в проекте завести миграции, которые можно будет одной командой накатывать и откатывать? Нет же?
для работы с данными, анализа их и построения статистики - несомненно, я с этим и не спорил. Я говорил именно про применение в качестве языка общего назначения. Представьте себе сайт веб-приложений из нескольких вебсервисов, например. Там, где нужна интеграция с биллингами, внешними API, работа с отложенными задачами, конвертации форматов данных. Кто для этой задачи возьмет R? Да никто, потому что он для этого не подходит. Если вы фанатик, то вы сможете все это при помощи такой-то матери реализовать, да, но зачем, если гораздо проще взять языки, лучше подходящие для этой задачи?
Вот поэтому я и говорю - R решает задачи статистики и делает это отлично. Он удобен для статистиков и аналитиков, математичен и лаконичен. Но когда речь идет о написании коммерческого решения на бэкенде, с интеграциями, дальнейшим развитием и поддержкой, он не подходит.
Почти все решения для R, которые я нашел навскидку для асинхронного HTTP и сваггера, не обновлялись уже несколько месяцев минимум (нет коммитов), а то и несколько лет. Это не значит, что не существует более свежих и широко используемых, конечно, но немного настораживает. И я согласен, что ORM - зло, но все-таки лучше, когда есть возможность на нем быстро собрать и сделать миграции, чем совсем без него писать все руками.
Так что да, я даже не считаю это за холивар - R действительно не подходит для решения задач общего назначения. Это не делает его плохим языком, хотя лично мне его синтаксис кажется весьма неудобным по сравнению с промышленными языками. Просто за пределами его основной области (статистический анализ) он несравним с более крупными игроками, а то, что питон по функциональности даже в анализе практически перегнал - не очень хороший знак для языка в целом. Скорее всего, он так и останется академическим, и это отлично для него. Лучше расти вглубь, чем вширь.
В области DS все просто - Python умеет примерно все то же самое, что и R, но еще и многое другое сверху, что и делает его более желательной целью для изучения и продвижения. А еще вы подменяете понятия - фразы "го лучше питона в конкретной сфере" и "питон не универсален" логически не связаны. Да, лучше. Но нет, универсален.
Эти курсы сейчас актуализируют тем, что переводят их на Python. Потому что он более востребован и удобен для широкого круга задач.
Не надо воспринимать эти заявления, как личные нападки. Это очень удобная позиция, бесспорно, но никто лично на вас не наезжает. Просто почти все пункты вашей статьи не по делу.
1) "ООП и DS плохо совместимы" - возможно, только Python тут ни при чем. Он позволяет использовать как ООП, так и процедурный подход при желании. Мимо.
2) "Недостаточность базовых типов данных" - import numpy решает эту проблему. Мимо.
3) "Векторизация" - см предыдущий пункт. Мимо.
4) "Колонки", "Поддерживается странная концепция эквивалентности работы как по вертикали, так и по горизонтали" - это прямым текстом неправда. Pandas хранит данные в колоночно-ориентированном формате и оптимизирован для векторных операций на колонках. То, что можно, перебирать ряды - просто костыль и общепризнанный антипаттерн. Мимо.
5) "Индекс" - редкая валидная претензия, которая, тем не менее, чинится просто чтением документации один раз
6) "Copy-paste" - про метод query мы умолчим, а то идея развалится. Мимо.
7) "Отсутствие полноценной конвейерной обработки (pipe)" - то, что вы не знаете про генераторы в Python, не значит, что они отсутствуют. Мимо.
8) "Производительность" - да, согласен, Pandas довольно медленный. Но, во-первых, ему есть масса альтернатив (как лихо вы выкинули из рассмотрения Dask и polars, ни к селу ни к городу приплетя Clickhouse). А во-вторых - вот новость - статистический анализ в питоне не ограничивается пандасом.
9) "Бенчмарки" - написана лютая чушь, извините, конечно. Вы бы ради приличия хотя бы разведали, что существуют Scalene и Memray, ничего хотя бы близкого к которым в мире R не существует в принципе. Мимо.
Вот отсюда и подобная реакция на сей опус - он делает ряд мало связанных с реальностью заявлений и сравнивает бензопилу и швейцарский нож.
Я на этом докладе был лично. То, что вы приводите его в пример, показывает, что вы вообще не понимаете, о чем речь - Go не является заменой питона, тем более в DS, и у него масса проблем с экосистемой. Он отлично подходит для быстрых асинхронных сетевых сервисов и вещей потипу параллельных ETL, но это весьма специфическая вещь.
Про полмира вы, мягко говоря, лукавите. Полмира сидит как раз на питоне, а R знает только по отдельным статьям, и то ищут, как те же вещи перетащить в питон. Ведущие университеты курсы переводят на питон.
P.S. Да, если что, вам "стыдно" за курсы Johns Hopkins University, например. Не говоря уже о том, что предложенный пойнт про "почему так методы называются" самоочевиден, с ним сложно спорить. Это еще одна из слабых сторон R.
Разумеется, моветон. Это нецелевое использование инструмента.
Нет, потому что R - не язык программирования. R - язык статистического анализа. Для этого он подходит хорошо, а языком общего назначения он отродясь не был.
Ничего "легкого" в этом нет. Нормальная поддержка Swagger-спек? Асинхронности? ORM? Валидации структур? Есть несколько костылей, которые позволяют сделать что-то отдаленно похожее, но по факту язык просто для этого не подходит.
Нет, конечно. Половину ваших претензий из статьи можно просто перечеркнуть фразой "просто возьмите numpy". Низкоуровневые типы? Numpy. Векторизация? Numpy. R - узкоспециализированная штука, которая умеет это из коробки - ну и молодец. А для питона это всего лишь еще одна из функций.
Питон офигительно развивается с точки зрения производительности и с точки зрения параллельности. Погуглите по словам Mark Shannon, Pyston и multiprocessing shared memory. Вот буквально только что JIT зарелизили, например https://opennet.ru/57320/
R непригоден для промышленной разработки. Я проходил курсы по нему от нескольких университетов, и в каждом из них были фразы в духе "почему эти функции называются lapply/rapply/xapply/tapply? никто не знает, надо просто зазубрить" и "если у вас при импорте датасета возникает сегфолт - попробуйте другую версию библиотеки". Это язык, созданный в академической среде для этой самой академической среды. Давайте будем честны и не будем делать вид, что он отлично подходит для разработки тех же микросервисов. Это примерно как разработка десктопных приложений на PHP - по фану можно, но на деле язык не для этого.
Был приятно удивлен вот этой статистикой https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-operating-system
Это далеко не всегда правда даже в айти. Формально да, это одна из причин роста зарплаты айтишников вообще, но чем дальше мы уходим от крупных городов и от технических компаний - ситуация становится сложнее. Пандемия немного с этим помогла, не спорю, но примерно в любой книге по переговорам написано, что главная ошибка - это принимать первое же предложение другой стороны.