Comments 238
Предположу, что если бы всех учили на R, то на Хабре рано или поздно появилась бы статья с таким текстом:
Наблюдая за типовыми мучениями в решении тривиальных задач выпускников таких курсов, даже неважно какого они года выпуска, со всей очевидностью становятся видны архитектурные просчеты R в области аналитики. На фоне жутких R конструкций аналогичные решения, написанные на Python, выглядят стройными, прозрачными, компактными и работают сильно быстрее.
Зачем создавать виртуальные миры и заниматься абстрактной комбинаторикой? Смотрите на состояние "здесь и сейчас", работайте с фактами.
На случай беспокойства братья Гримм даже сказку написали: https://www.grimmstories.com/ru/grimm_skazki/umnaja_elza
А факты в большинстве своем указывают лишь на то, что закончившие учебные программы "специалисты" достаточно слабо представляют предметную область - что уже "что-то". А слабо что-либо представляя, достаточно сложно добиться того, чтобы код на чем угодно работал быстро, был понятен, прост и красив. И тут не важно, R это будет, Pyton или C++, на котором уж точно можно написать быстрее, но вряд ли проще и красивее. А все, что можно написать на C++, можно воткнуть и в питон.
Да, наверное стоит согласиться, что многое в Python тащится отовсюду, где оно уже есть. Но чем это плохо? Возможно, стоит обратить внимание на то, что есть где-то в части аналитики данных, чего нет в Python. Это было бы полезно на мой взгляд.
Зачем создавать виртуальные миры и заниматься абстрактной комбинаторикой? Смотрите на состояние "здесь и сейчас", работайте с фактами.
Что-то мне подсказывает, что именно так и думал тот "Кто за всех решил, что python удобен для «гражданской» аналитики".
Зачем создавать виртуальные миры с векторизацией, типами данных и ООП, когда можно здесь и сейчас использовать питон.
Мысль непонятна. Вы знали, что R и Python почти погодки?
Мысль непонятна.
Речь об иронии ситуации.
@starik-2005 рассматривает ситуацию "а что было бы, если бы было по другому"
Вы говорите, что не стоит создавать виртуального мира и надо жить с теми фактами которые есть.
При этом, Ваша статья как раз о том, что было бы если бы было по другому, и Вы создаёте виртуальный мир.
Что характерно, и его виртуальны мир и Ваш, это один и тот же виртуальный мир, в котором вмеcто Python доминирует R
Вы знали, что R и Python почти погодки?
Это не важно.
Ответ на вопрос "Кто за всех решил, что python удобен для «гражданской» аналитики?" не сильно зависит от самого возраста продукта.
Если смотреть на историю техники, то важна готовность аудитории и наличие тех кто будет на этой аудитории зарабатывать.
Прямо сейчас, юный падаван попадающий в айти видит:
- кучу ГОТОВЫХ примеров использования
- кучу людей РАССКАЗЫВАЮЩИХ о том какие они успешные
- кучу ПРЕДЛОЖЕНИЙ (как реальных, так и полного фуфла) научить его питону
Поэтому, полный и исчерпывающий ответ на Ваш вопрос: "Так сложилось исторически"
Хотите изменить ситуацию?
Ну, тогда создайте информационное давление на аудиторию, с рассказами какой полезный этот R , раскидайте примеры кода, создайте ажиотаж и убедите обучаторов ввести курсы по R.
Если будете настойчивым и целеустремлённым, то через 15 ситуация может измениться в нужную Вам сторону.
Вы знали, что R и Python почти погодки?Более того, R изначально был лидером в анализе данных, и учили в основном именно ему.
Но с ростом популярности Python падала популярность R.
ИМХО, основная причина в том, что R — это очень специфический язык с узкой сферой применения. Python же универсален, решения на нем можно легко интегрировать в другие продукты. Соответственно изучать Python разработчику выгодней, так как он может применять его для разных задач.
В этом рассуждении есть одна большая ошибка. Сила не в языках, а в библиотеках, алгоритмах и навыках. Есть прекрасная книга на эту тему: https://habr.com/ru/company/productivity_inside/blog/348116/
R позволяет решать практически все те же самые задачи, что и питон. Это тоже язык универсального назначения. В сети масса различных примеров есть.
R позволяет решать практически все те же самые задачи, что и питон. Это тоже язык универсального назначения. В сети масса различных примеров есть.То что его можно «натянуть» на ряд задач для которых он не был исходно предназначен не делает его языком универсального назначения.
R is a language and environment for statistical computing and graphics.<...>R is an integrated suite of software facilities for data manipulation, calculation and graphical display.<...>We prefer to think of it as an environment within which statistical techniques are implemented.Это не чьи-то сторонние фантазии, а строки описания языка на его официальном сайте.
Очень странный вопрос из уст человека, размышляющего об околоматематической дисциплине :-)
Если несложно, переформулируйте вопрос, если он тут вообще есть.
В этом потоке вовсе неочевидно понять что Вы хотели сказать.
Я хотел сказать, что умение мыслить абстрактно, а не здесь и сейчас, очень выгодно отличает человека от остального животного мира. И если вы отказываетесь от этих упражнений, ценность ваших умозаключений для меня лично сомнительна.
Надеюсь, сейчас я понятно написал ))
Да-да, подозревал, но не хотел так думать.
В целом, весь поток обсуждений вместо техники сваливается на личности и завуалированные оскорбления. Причем мы на брудершафт не пили.
Каждый раз на хабре одно и то же.
И даже уже раздражать перестало, неизбежный шлейф.
"Ну вот... опять поехало..."
Но комментаторы могут подумать, как именно они себя выставляют?
Про какие умозаключения Вы ведете речь -- тоже неведомо. Берете консоль и запускаете код и повторяете результаты. Берете статьи и книги по ссылкам (между прочим, уважаемые люди писали) и читаете. Берете код на гитхабе и разбираетесь в нем.
Из того, что я вижу, ваша основная претензия в том, что pandas медленный и не очень удобный. Проблема R в том, что он хорош только в расчётах. Если вам нужно сделать буквально что угодно, кроме манипуляций с датафреймами, вы в большой беде. Спарсить данные из интернета - хм, поднять сервер с дашбордом - со скрежетом, сделать сервер с моделью - упс. А Python умеет делать всё остальное довольно хорошо, а как оптимизировать pandas хорошо известно.
Почитайте все прошлые публикации.
R умеет делать это все куда круче питона.
Вы просто немного не в теме.
Спарсить данные из интернета - можно без проблем
Поднять сервер с дашбордом - можно без проблем
Сделать сервер с моделью - можно без проблем
Так R это всё умеет делать спокойно же
Умеет, но менее удобно. Не так уж мало людей пробуют R и если бы он обладал заметными преимуществами, они оставались бы на нём. Я статистику учил на R и буквально пару операций там делать заметно удобнее, чем на Питоне. Но в среднем преимущество за питоном.
Умеет, но менее удобно.
Да как то? немного строк - и готов докер-контейнер с апи за которой сидит моделька, или дашбоард на Shiny, встраиваем в CI/CD и живем счастливо. Что же тут неудобного?
Имхо, спор весь из-за вкусов, кому что ближе-удобнее и из-за отсутствия опыта решения конкретных задач на R, язык тут ни при чем, говорю на основе опыта в стартапах - там важно задачу решить с 1 раза и бежать дальше, R нам очень помог в этом
Тот же Dash начали списывать с Shiny. Но до последнего ему еще очень далеко.
Можете книгу почитать https://mastering-shiny.org/.
Или демки поглядеть: https://appsilon.com/
Можно контесты взглянуть:- [Winners of the 1st Shiny Contest](https://blog.rstudio.com/2019/04/05/first-shiny-contest-winners/), 2019-04-05
- [Winners of the 2nd Annual Shiny Contest](https://blog.rstudio.com/2020/07/13/winners-of-the-2nd-shiny-contest/), 2020-07-13
- [Winners of the 3rd annual Shiny Contest](https://blog.rstudio.com/2021/06/24/winners-of-the-3rd-annual-shiny-contest/), 2021-06-24
Лично я делаю почти весь скрапинг только в R — он просто намного удобнее. Python как-то не зашёл
Питон или не питон?
"Николай Дроздов целует змею"
Спарсить данные из интернета - хм, поднять сервер с дашбордом - со скрежетом, сделать сервер с моделью - упс
это мягко говоря не так, и уже давно, говорю от своего опыта использования R в телеком стартапе, на R было сделано:
- kafka producer-ы и consumer-ы, завернутые в systemd-скрипты, работающие как сервисы linux;
- отдельные step-ы в ETL-pipelines в Pentaho Data Integration (c выходом пакета targets пентаха не особо нужна);
- биллинг (на Shiny - GUI + бэкенд);
- REST JSON API для интеграций с поставщиками данных (RestRserve в Docker);
- всякие разные штуки для интеграций с системой мониторинга и ServiceDesk;
- приложение Bitrix24 для анализа бизнес-процессов (Shiny);
- приложение Bitrix24 для расчетов KPI персонала;
- всяких разных ad-hoc отчетов не счесть;
Почему R? ну разрабов было всего два, а R уже использовался для анализа данных, да и параметр time to market у R таки хорош и многое "в две строки", ну и пакетов в нем тьма - есть все, от добычи сырых данных, до выдачи пользы наружу.
Ну и да - RStudio - очень уютная IDE, по моему мнению.
Ну и про парсинг с инета - это Вы совсем зря - пакеты rvest и RSelenium не дадут мне соврать.
Так что причины НЕ использования R - не в ограниченности языка.
Так что причины НЕ использования R - не в ограниченности языка.
Разверните пожалуйста свой ответ, в чем тогда причины?
Разверните пожалуйста свой ответ, в чем тогда причины?
Мое мнение такое, и касается оно только РФ:
В нашей стране до сих пор про язык R говорят - "это язык для математиков", предыстория влияет на выбор - а что изучить? Выбираем питон - это же язык общего назначения!
В нашей стране моду (а отсюда и рынок труда) на выбор тех или иных инструментов задают крупные ИТ-компании, а эти компании выбрали Питон, разумеется работодатель не выбирает что круче, а выбирает - что дешевле с точки зрения ФОТ, так что вакансий много именно под Питон. Кстати - зарубежом вакансий под R есть.
Питон проще в изучении в самом начале, R (речь про базовый язык) классическому разработчику сначала не очень понятен, впрочем - пакеты семейства tidyverse эту трудность значительно снижают.
Т.к. обертки над tensorflow или libtorch сначала появились для Питон, а потом уже на R (дада, на R есть torch, и это не обертка над pytrorch), то что молодые управленцы внедряют? Конечно питон, там же нейронки!
Один немаловажный аспект выпал из сопоставления Python vs R, который в России-матушке перевесил все и вся. Для R есть упопомрачительное awsome расширение под web: SHINY, но это за деньги. 10 строк кода и у вас витрина данных на R Shiny. На Python всяк свой web api точит как умеет и развивает. В этом вся штука. Лично я пользуюсь R и считаю, что лучше его ничего нет. Если Мелкософт вставил в Azure поддержку, то стало быть есть перспектива и профит. STATISTICA долго упрямилась, используя VB, но и она таки вставила поддержку R.
Shiny бесплатен
. Для R есть упопомрачительное awsome расширение под web: SHINY, но это за деньги
да нет же, Shiny бесплатный! есть платный вариант хостинга своих shiny-приложений в https://www.shinyapps.io/ там много плюшек удобных, включая горизонтальое масштабирование, но лично мне удобнее своя VPS/VDS, ставим туда shiny-server и все. Хотим масштабирование и аутентификацию из коробки - shiny-proxy в помощь
У меня от работы с R сложилось впечатление, что это такой специальный язык, в котором принципиально уничтожают возможности узнать, в какой же строке ошибка - "потому что головой думать надо, а не на компилятор надеяться". Как по мне, неуказание на координаты ошибки - это хамство. Как минимум, по отношению к тем, кто собирается язык осваивать. Язык, созданный экономистами для выколачивания денег за курсы из таких же экономистов, но помоложе.
Впрочем, питон я тоже недолюбливаю.
Сстранно, с дебагом там все в порядке.
И stacktrace можно поглядеть.
Наверное, от Вас что-то скрыли.
Вот прям на Ваш вопрос: https://www.tidyverse.org/blog/2021/12/rlang-1-0-0-errors/
Люди знают потребности, люди постоянно работают над улучшением.
mtcars %>%
group_by(cyl) %>%
mutate(new = add1("foo"))
#> Error in `mutate()`:
#> ! Problem while computing `new = add1("foo")`.
#> ℹ The error occurred in group 1: cyl = 4.
#> Caused by error in `1 + x`:
#> ! non-numeric argument to binary operator
И это "новый" вариант из 2021. Я, вероятно, "познакомился" с R чуть раньше. Так вот, где тут координаты ошибки в виде номера строки и, желательно, символа, как в нормальных языках?
Вы путаете ошибки на этапе компиляции, когда компилятор точно знает что именно он сейчас парсит и какая лингвистическая ошибка возникла.
В обычной программе Вы просто получите голубой экран при сбое. И там без дебаг сборки будет вообще hex адрес в RAM.
Здесь же ошибка на этапе исполнения, когда подсунули кривые данные.
И ошибка четко указывает место и причину.
Так что Вы немного попутали фазы компиляции и исполнения.
В JS голубого экрана не будет, будет относительно внятный стектрейс. В Java, Python и т.д. - тоже. А здесь, в R - просто набор обруганных выражений безо всякой возможности загуглить ошибку (да, это важно!). "Мне не нравится x+1", и всё тут!
А как весело что-то гуглить про язык с однобуквенным названием!
Нет, язык решительно и сознательно недружелюбен, и потому место ему в /dev/null
Все есть в языке, Вы просто матчасть не изучили до конца и Вам никто не рассказал.
https://rstats.wtf/debugging-r-code.html
https://rlang.r-lib.org/reference/trace_back.html
Но у Вас просто задачи другие -- и это в порядке вещей. Язык и экосистема совершенно ни при чем.
Признаю, матчасть не изучил. Потому что "вот софтина на R, её надо запустить и чуть-чуть поправить". Двух-трёх месяцев на изучение языка системно у меня не было. В питоне в аналогичной ситуации всё было гораздо проще.
По Вашим ссылкам всё ещё нет ни одного примера сообщения "ошибка в строке N". А это действительно важно при знакомстве с языком.
Благодарю Вас, кстати, за спокойствие и терпение. Вероятно, их в Вас развил язык R ;-)
Нет никаких проблем гуглить ошибки из R, с этим не было никогда никаких сложностей. Вы сейчас просто придумываете проблему, которой нет в R. Все ошибки берутся из консоли и вставляются в Гугл и после всегда что-то можно найти.
В примере выше ошибка разжевана прямо на месте таким образом, что самый джуновый джун поймет, что происходит. Спорить с этим просто глупо.
О сколько нам открытий чудных
Готовят просвещенья дух
И опыт, сын ошибок трудных,
И гений, парадоксов друг,
И случай, бог изобретатель.
А.С. Пушкин, 1829
А еще можно законы Мёрфи почитать.
«Пух открыл Северный Полюс», сказал Кристофер Робин. «Правда замечательно?»
Пух скромно потупился.
«Это что ли?», говорит И-Ё.
«Да», говорит Кристофер Робин.
«Это то, что мы искали?»
«Да», говорит Пух.
«О!», говорит И-Ё. «Ладно, по крайней мере не было дождя», говорит.
Они воткнули Полено в землю и Кристофер Робин привязал к нему надпись:
СЕВЕРНЫЙ ПОЛЮС ОТКРЫТ ПУХОМ ПУХ ЕГО ОБНАРУЖИЛ
Для этого вам нужна функция traceback() .
Вообще вот тут есть достаточно полезная информация о том, как отлаживать код под R: https://adv-r.hadley.nz/debugging.html
Для мимокрокодила, который далек от DS сферы и работает на Java и Typescript, это выглядит примерно на уровне ассемблера в смысле Quality of Life. Про Rust и заикаться больно, сравнение с его дружелюбными сообщениями об ошибках вообще будет избиением младенца
R формален и математичен, это нравится людям с соответствующим складом ума (кого слово "вектор" не коробит, а умение складывать и умножать вектора - это обязательный навык, как обычные числа)...
python - это язык в смысле "текст" - уход от фигурных скобок и отступы - для меня, например, - это та самая киллер-фича...
ООП - это опять же для имеющих более гуманитарный склад ума. Объект класса - существительное, свойства - прилагательное, метод - глагол ("Вася, делай вот это вот так/с такими свойствами!")
В DS формализм и математика являются фундаментом.
Вектора проходят в средней школе.
Странно все это не использовать при решении аналитических задач.
Про ООП первый раз такую трактовку слышу. Наверное, потому что приходилось с этим ООП в промышленных разработках плотно взаимодействовать, С++ разрабы -- суровые люди.
Для меня код - это не только математика и логика, но в первую очередь это текст, повествование... Питон и панды искренне полюбил за это)
Почитайте https://bookdown.org/yihui/rmarkdown/
Это Literate Progamming, как его Кнут задумывал.
Это Ваше частное мнение на которое Вы имеете полное право. Строится оно на полном знании вопроса или на полном незнании -- мне неведомо.
Похоже, что R вам показали не те люди и не с той стороны. Если вдруг захотите взглянуть с другой точки зрения -- приходите с вопросами в телеграм канал. Откроете новое для себя.
В ВУЗ-ах есть кадровая проблема.
И не секрет, что в части программирования лекторы/семинаристы будут далеки от индустриальных подходов. Математики -- не самые лучшие преподаватели по программированию. По разработке алгоритмов -- да, по эффективному программированию и современным подходам -- скорее нет.
Отличная статья
Спарсить данные из интернета - хм, поднять сервер с дашбордом - со скрежетом, сделать сервер с моделью - упс
По всем этим пунктам все в полном порядке и даже более того : там где на поляне царствовал питон (deep learning) - всё тоже ок!
Вот еще ссылка где автор не поленился и сравнил "влоб" нечитабельность Python и лаконичность R
Автор, кмк, искренен и во многом прав, перечисляя недостатки Pandas на фоне "glance" R. Еще не все фишки "слизаны" с R, панды развиваются, не почивают на лаврах как монополист. Вот почти уверен что скобки и избыточность упоминания df в срезах df[(df.col1==...) & (df.col1>...)] скоро уберут.
Но на поставленный статьей вопрос "Кто решил что Python лучше?" - ответа статья не дала. Решили и выбрали Python не директора курсов и вузов, не тренеры, а... сами аналитики, их работодатели и другие программисты, которым переход на Python+Pandas и интероперабельность такой связки показались выше, чем с R.
Вакансии Python vs R соотносятся как 10:1. Мы видим по всем рейтингам популярности ЯП что доля R падает, а у Python растет, и мы понимаем что это не просто корреляция, это функциональная связь. R медленно умирает на фоне роста DS, как бы странно это не выглядело. Причин тут несколько:
1) Python настоящий "универсальный клей", среди его 400k+ библиотек найдутся тысячи, которых нет в R.
2) ООП все-таки является наиболее частой парадигмой в больших проектах и исследованиях. DS-проекты сейчас все большие. Я пишу UDF func() и тут же ее объявляю методом фрейма pd.DataFrame.func = func() и далее просто вызываю ее через точку df.func() При наборе кода это в 5 раз быстрее чем печатать df.apply('func'), а в реальном анализе такой код занимает половину, и всё это заметно даже со стороны.
3) Блокноты Jupyter выросли из IPython и стали "стандартом" исследования. R кажется застывшим в развитии. "Доказательная экономика" строится и живет сейчас в блокнотах, Питон занимает 98% кода из 2+ млн. блокнотов на Github. Это просто факты, которые "вещь упрямая".
4) Все таки синтаксис Python няшен, принудительная "пробельность" дает структурность коду, есть громадный выбор IDE на любой вкус, линтеры, IntelliSense и AI в автодополнении делают его модным и молодежным, несмотря на возраст. У R есть все это, но оно не такое и не то.
Для DS-новичков отказ от Python в пользу R, Julia или low-code ML-решений - сейчас выглядит по меньше мере странно. Вполне можно использовать лучшее из 2-х миров в блокноте, поддерживающем 100+ ЯП.
Не совсем так. На чем обучают, то потом и пытаются применять. Наблюдается засилье курсов на питоне, в т.ч. вузовских программ.
В RStudio IDE в R Notebook (считайте, аналог юпитера) можно писать код, перемежая чанки в r, python, sql. Все давно уже есть.
По R есть отличный авторский учебник (это Филиппа Управителева): https://textbook.rintro.ru/index.html и курс.
Наоборот, учить стараются тому, что востребовано. Мне кажется, выбор Python делают тогда, когда открывать новое направление в компании, связанное с DS, поручают сначала обычным программистам, которые берут то, что они сами и окружающие знают. И включается обратная связь: начали на Python, нанимаем со знанием Python, вот он и востребован.
Возможно, надо обучать R не только как отдельному инструменту для расчетов, а как логичной части большой системы. Когда я учился, у нас еще не было курса по R, но когда в рамках проекта по другому предмету нужно было получить регрессионную модель (из большей программы), решение сделать эту часть на R и дернуть извне было популярно.
R позволяет полноценно программировать, но это прежде всего все-таки DSL для статистики. По сравнению с "нормальными" языками то, что cyl в cyl отдельно и в df[cyl > 5] означает разное, воспринимается не как удобство, а как неконсистентность и необходимость держать в голове лишний контекст, что противно всем инстинктам разработчика.
В настоящем промышленном DS необходимо совмещать навыки математика, художника, алгоритмиста, настоящего разработчика, dba, сисадмина и devops. Пусть не с полным погружением, но хотя бы иметь некоторые представления об отдельных вопросах.
Чтобы включать инстинкты, их надо иметь. Чтобы их иметь, надо иметь немалый опыт за плечами в исполнении сложных командных проектов. Но такой опыт уже позволяет философски смотреть на ряд вещей.
1) Python настоящий "универсальный клей", среди его 400k+ библиотек найдутся тысячи, которых нет в R.
R - настоящий "универсальный клей", среди его 19 тысяч пакетов абсолютно все пакеты предназначены для анализа данных, ML, статистики и богатой визуализации. А сколько из 400К питоновских для этого? Какой процент? Давайте откровенно, он даже в статистике и визуализации по числу пакетов/алгоритмов до сих пор отстает. А то что какого-то питоновского пакета нет в R - значит это к аналитике данных не имеет отношения (иначе давно бы в нём было)
Мы по разному понимаем термин "ЯП - универсальный клей". Из 400k либ Python - треть является "обертками" к чужим другим либам на С, JS, R итд. Это очень эффективно, ведь сопровождением кода "материнской" либы занимается ее автор, а автор питон-либы - лишь изредка переписывает новые API-вызовы и документацию (и то не всегда). Плюс добавляет синтаксический "сахар", который, с учетом времени и опыта разработчика, часто оказывается полезным и удачным.
под клеем все понимают единообразно.
"No matter how complex and polished the individual operations are, it is often the quality of the glue that most directly determines the power of the system." — Hal Abelson
обертки на С-шными либами и там и там есть.
мериться надо не количеством, а качеством. И не забываем, что питон для не DS задач -- это другой питон, другой стиль разработки и дополнительно другие либы.
R - настоящий "универсальный клей",
значит это к аналитике данных не имеет отношения
Это же именно та проблема, про которую пишут. Вне рамок "аналитики" R не нужен (или является экзотическим) и это вытесняет его из рынка, так как специфические языки не нужны.
Тезисы субьективны.
Можно разные графики взять, R очень сильно развивается и сильно популярен в отдельных вертикалях. И на западе он очень широко применяется.
Линтеры и дополнения есть в RStudio, все работает и удобно. И автотесты есть. Есть весь DevOps стек.
Гвидо же почти остановил развитие питона. Периодически пользуюсь питоном с 2006-года.
Ну вот не смешно ли, что `switch case` завезли только в 3.10?
Про аналитику в блокнотах посмотрите последнюю ссылку в тексте https://www.youtube.com/watch?v=7jiPeIFXb6U
Все не так очевидно и прозрачно, как Вы написали.
Лол, что. Остановил?) А вы точно разбираетесь в том, что пишите?
Можно всякие штуки читать типа таких саммари (кроме what's new):
- https://antonz.org/python-stdlib-changes/
- https://nedbatchelder.com/text/which-py.html
- PEP
- ...В силу архитектурных особенностей вещи типа полноценной векторизации и NSE принципиально не завезут.
Для задач DS все эти изменения идут почти в параллельном фоне. Ацент совсем на другом.
Ну, я то читаю. И развитие языка сейчас не выглядет как остановленное, особенно после 3.4
А зачем они нужны, если есть numpy?
Даже перемножение матриц и asyncio куски?
Вы читаете через несколько строк. Посмотрите приведенные ссылки. Еще раз, Numpy придумали ученые астрономы, они это сделали по уму и хорошо. Но это исправление нашлепкой сбоку. И нашлепка все равно инородна.
Про параллельные вычисления пока речи нет. В R с этим все отлично. Но, если интересно, можете поглядеть предыдущие публикации.
У Вас есть сложившаяся точка зрения и видение. Оно не изменится ни при каких ответах. Например, потребность в векторизации возникает при решении соотв. задач. Нет задач -- нет потребности. Может тогда и не стоит копья ломать?
Нет, конечно. Половину ваших претензий из статьи можно просто перечеркнуть фразой "просто возьмите numpy". Низкоуровневые типы? Numpy. Векторизация? Numpy. R - узкоспециализированная штука, которая умеет это из коробки - ну и молодец. А для питона это всего лишь еще одна из функций.
Питон офигительно развивается с точки зрения производительности и с точки зрения параллельности. Погуглите по словам Mark Shannon, Pyston и multiprocessing shared memory. Вот буквально только что JIT зарелизили, например https://opennet.ru/57320/
R непригоден для промышленной разработки. Я проходил курсы по нему от нескольких университетов, и в каждом из них были фразы в духе "почему эти функции называются lapply/rapply/xapply/tapply? никто не знает, надо просто зазубрить" и "если у вас при импорте датасета возникает сегфолт - попробуйте другую версию библиотеки". Это язык, созданный в академической среде для этой самой академической среды. Давайте будем честны и не будем делать вид, что он отлично подходит для разработки тех же микросервисов. Это примерно как разработка десктопных приложений на PHP - по фану можно, но на деле язык не для этого.
Это язык, созданный в академической среде для этой самой академической среды.
и применять его вне академической среды - моветон?
и может быть академическая среда применяет R по академически, не по программистки? ) ругают же python-код от DS, если его смотрят python-разработчики
Давайте будем честны и не будем делать вид, что он отлично подходит для разработки тех же микросервисов
микросервисы на R? легко, пакет RestRserve + Docker и вперед, другое дело - что так не принято, там свой мейнстрим, и есть другие более подходящие инструменты
Какие-то претензии к языку из прошлого в основном, имхо
и применять его вне академической среды - моветон?
Разумеется, моветон. Это нецелевое использование инструмента.
и может быть академическая среда применяет R по академически, не по программистки?
Нет, потому что R - не язык программирования. R - язык статистического анализа. Для этого он подходит хорошо, а языком общего назначения он отродясь не был.
микросервисы на R? легко, пакет RestRserve + Docker и вперед
Ничего "легкого" в этом нет. Нормальная поддержка Swagger-спек? Асинхронности? ORM? Валидации структур? Есть несколько костылей, которые позволяют сделать что-то отдаленно похожее, но по факту язык просто для этого не подходит.
Нет, потому что R - не язык программирования. R - язык статистического анализа. Для этого он подходит хорошо, а языком общего назначения он отродясь не был.
Проще жить в статических рамках, ну ок, хотя по моему практическому опыту R - прекрасно подходит для обработки данных, и создания Web-приложений, да, на NodeJS будет эффективнее в большом ентерпрайзе с хайлоадом, но для внутренних продуктов - почему нет?
Ничего "легкого" в этом нет. Нормальная поддержка Swagger-спек?
есть там swagger
Асинхронности?
да, из коробки
ORM
ORM - зло )) сначала весело и легко, потом медленно и больно
Валидации структур?
а в чем проблема? что не так строг как Rust?
но по факту язык просто для этого не подходит.
не участвуй в holywar, пустое это - говорю я себе, но иногда, когда все делится строго на 0 и 1 - бывает не сдерживаюсь ) что ж так строго то?
Почти все решения для R, которые я нашел навскидку для асинхронного HTTP и сваггера, не обновлялись уже несколько месяцев минимум (нет коммитов), а то и несколько лет. Это не значит, что не существует более свежих и широко используемых, конечно, но немного настораживает. И я согласен, что ORM - зло, но все-таки лучше, когда есть возможность на нем быстро собрать и сделать миграции, чем совсем без него писать все руками.
Так что да, я даже не считаю это за холивар - R действительно не подходит для решения задач общего назначения. Это не делает его плохим языком, хотя лично мне его синтаксис кажется весьма неудобным по сравнению с промышленными языками. Просто за пределами его основной области (статистический анализ) он несравним с более крупными игроками, а то, что питон по функциональности даже в анализе практически перегнал - не очень хороший знак для языка в целом. Скорее всего, он так и останется академическим, и это отлично для него. Лучше расти вглубь, чем вширь.
ORM - зло, но все-таки лучше, когда есть возможность на нем быстро собрать и сделать миграции, чем совсем без него писать все руками.
зачем руками то? dplyr/dbplyr транслирует dplyr-глаголы соединенные пайпами в родной SQL в любую поддерживаемую БД
Это не делает его плохим языком, хотя лично мне его синтаксис кажется весьма неудобным по сравнению с промышленными языками.
если брать базовый R - да, тут не поспорить, сначала непривычно на общих задачах, но как только работаем с данными (и не важно, статистика это или нет) - как раз язык во всей красе себя показывает
R действительно не подходит для решения задач общего назначения
Ну как так то??? не подходит - нельзя и невозможно, или не подходит - так не принято?
а то, что питон по функциональности даже в анализе практически перегнал
эмн, в чем меряли этот факт? кол-ве вопросов на stackoverflow? метрика то какая? ) если что - мое мнение о причинах популярности питона-а у нас в стране я выше по треду озвучивал
P.S. я поясню - я не топлю за то что - а давайте R везде применять, нет, я просто триггернулся на крайности - "не подходит, невозможно, неудобно, криво" и т.д.
это давно не так в задачах вокруг данных, от их добычи до выдачи пользы наружу
dplyr/dbplyr транслирует dplyr-глаголы соединенные пайпами в родной SQL в любую поддерживаемую БД
Я могу на основе этого подхода в проекте завести миграции, которые можно будет одной командой накатывать и откатывать? Нет же?
это давно не так в задачах вокруг данных, от их добычи до выдачи пользы наружу
для работы с данными, анализа их и построения статистики - несомненно, я с этим и не спорил. Я говорил именно про применение в качестве языка общего назначения. Представьте себе сайт веб-приложений из нескольких вебсервисов, например. Там, где нужна интеграция с биллингами, внешними API, работа с отложенными задачами, конвертации форматов данных. Кто для этой задачи возьмет R? Да никто, потому что он для этого не подходит. Если вы фанатик, то вы сможете все это при помощи такой-то матери реализовать, да, но зачем, если гораздо проще взять языки, лучше подходящие для этой задачи?
Вот поэтому я и говорю - R решает задачи статистики и делает это отлично. Он удобен для статистиков и аналитиков, математичен и лаконичен. Но когда речь идет о написании коммерческого решения на бэкенде, с интеграциями, дальнейшим развитием и поддержкой, он не подходит.
Представьте себе, вот очень даже и работает. Пока джависты пыхтят и классы рисуют, прототип на R уже в среде и бизнес понимает, что хотеть надо совсем не то, что они сначала просили.
плюс не могу поставить, на дано пока, но поддерживаю - больная это боль!
Пока джависты уже пыхтят и пишут код, бизнес до сих пор ищет хотя бы одного разработчика на рынке, способного поддерживать легаси на R. И как эту ерунду интегрировать с их вебсайтом и настроить для нее мониторинг. В итоге просто нанимают джуна на питоне, который за пару вечеров переписывает модельку на аналогичную откуда-нибудь из scikit-learn, и это перестает быть проблемой.
Джуны про регэкспы не слышали, а Вы заливаете, что он тут задачу возьмет и решит левой задней. Какую модельку? Что аналогичного?
Ага, прогноз пополнения остатков для Озона нарисует.
Как там учили??? fit-predict.
Подумайте сначала внимательно что Вы пишете. Николай, ну ведь DS -- это же не ваше поле. Много делали проектов по аналитической поддержке, бизнес-аналитике? Не агрегацию за месяц, а полный цикл от формирования требований и выработки алгоритмов решения на имеющихся огрызках данных, до вывода в прод на 24x7?
Драйвера и сервера -- это другое и не аналогичное.
Хоть людей своим комментариями не сбивайте с толку.
"Модельку аналогичную найдет..."
Если учесть, что я работаю архитектором по построению DS-решений... Если бы вы имели дело с коммерческой разработкой подобных вещей, то наверняка знали бы, что в случае классического ML особых изысков бизнес не требует, чаще всего достаточно взять ансамбль простых моделей, какой-нибудь xgboost и все будет работать. На каком языке будут эти модели - не особо важно, но питон лучше и легче интегрируется с остальными компонентами системы.
А про то, что примерно весь DL (там, где он реально нужен) сейчас на питоне, вам уже ниже рассказали в деталях в других комментариях, не буду повторяться.
Архитектор -- круто, так что тогда в штыки так воспринимаете и закрываетесь?
В проде должно быть все равно, что там в кубере/докере/опеншифте крутится. API и response time.
ML -- это маленькая вишенка на торте, чтобы до этого добраться нужно пропахать вдоль и поперек не один раз перед этим. Я нигде не писал слов ML/DL, это вообще на 80% инфраструктурные задачи, MLOps, как он есть.
Был компактный текст, затрагивающий ограниченный ряд вопросов. Не было никаких заходов в бигдату, в мл, в физику высоких энергий... Но ведь нет же.
На тезис "пандас медленный" следует реакция -- "а R на ноутбуке 10 Тб не перелопатит, зуб даю".
На тезис "индексы неудачно построены" -- "наберись опыта, а в промышленной разработке на R не пишут, а перепиши библиотеки, да ты пакетов в питоне не видел, да все вообще в excel считают" и пр...
Ну что это такое?
Вам пачку референсов коммерческих нужно? Ну право слово, не на площади же.
Так я не воспринимаю в штыки. У R есть сильные стороны и он отлично применим в своей нише. Но порой создается впечатление, что люди, которые топят за то, что он там, оказывается, умеет еще и какие-то вебсервисы и что-то еще, просто плохо знают текущие стеки в индустрии. Практически весь MLOps везде на питоне - MLFlow, DVC, Airflow. Пандас медленный, да. Но при правильном приготовлении пережевывает датасеты размером больше, чем R.
Вы все правильно написали, просто почему-то из этого делаете противоположный очевидному вывод - если вся индустрия пишет на питоне, найти питониста легко, найти обертку/модель/что угодно, которая есть в R, но нет в питоне, весьма сложно - так зачем брать R в реальном коммерческом стеке? Ну нет у него преимуществ толком, не-ту. Только для статистиков и аналитиков, только для академических целей. И это его сильная сторона, не надо его натягивать, как сову на глобус, на все подряд.
Ну не одним же MLOps-ом все живет, уже давал комментарий. Тем и задач выше крыши.
У нас ansible AWX вполне успешно оркестрирует R-овские докеры в проде. Да и airflow тоже может.
И не надо никакую сову натягивать, зачем животное мучать. Без этого все вполне органично встраивается и интегрируется.
H2O automl нравится. лучше джуниоров :)
Ну и почему опять MLOps?
Я не говорил про него в тексте.
Исследования, ad-hoc, различные аналитические приложения, rmarkdown отчеты в неимоверных количествах и сложности соответствующей, счетные сервисы в режиме черного ящика или API, да 100500 классов задач.
Если правда интересно, посмотрите предыдущие публикации.
но питон лучше и легче интегрируется с остальными компонентами системы.
лучше легче - потому и так вокруг питон?
В чем разница:
питон - обучили модель, сохранили в peakle, добавили в микросервис, используем;
R - обучили модель, сохранили в RDS, добавили в микросервис, используем;
в чем легкость у питона? другое дело - если не хотим прятать за API, и напрямую вызывать в airflow, ну ок, да, но это же не проблема языка R, верно? Просто есть выбранный стек, и все.
Да, аргумента "потому что и так вокруг питон" уже достаточно. Не говоря уже о том, что разница между питоном и R по части целевых библиотек и производительности не настолько большая, чтобы предпочитать узкоспециализированный язык общему. Достаточно даже просто посмотреть на объемы баз пакетов.
Ваша логика предельно понятна. Классический архитектурный подход. Думай глобально, решай локально.
Даже каждый непрограммист, который занимался стройкой, сталкивался с этим. А потом выясняется... здесь жесткости не хватает, здесь не учли структуру грунта, здесь мощности выделить не могут, здесь отступы нарушены, а тут не пролезает, а тут сэкономили две копейки ...
Но это все будет потом.
Да, аргумента "потому что и так вокруг питон" уже достаточно.
вот это, да - аргумент,
а то что R не подходит, потому что R - не аргумент )
Я могу на основе этого подхода в проекте завести миграции, которые можно будет одной командой накатывать и откатывать? Нет же?
и это ограничение языка???? когда-то и на питоне не было этого пакета, его написали, ибо было нужно
как и прекрасные targets и mlr3 для R - их тоже написали, потому что было надо
так при чем тут R и его ограниченность?
Представьте себе сайт веб-приложений из нескольких вебсервисов, например. Там, где нужна интеграция с биллингами, внешними API, работа с отложенными задачами, конвертации форматов данных. Кто для этой задачи возьмет R?
я так понял, весь тред не читали?
https://habr.com/ru/post/670250/comments/#comment_24419934
и это стартап, где надо результат сразу и что бы потом не отвлекало
Если вы фанатик, то вы сможете все это при помощи такой-то матери реализовать, да, но зачем, если гораздо проще взять языки, лучше подходящие для этой задачи?
фанат? хммм, а ведь да, фанатею от баз данных, анализа данных, BI, ML, статистики, разработки и вообще решения инженерных задач, и R в нашей экосистеме хорошо зашел, просто такой бизнес, получилось эффективно
Еще раз - я Вас не переубеждаю, мне это ни к чему, как и Вам, я просто против категоричных утверждений, и все )
и это ограничение языка????
это ограничение его экосистемы. Тот же Rust, например, несмотря на всю свою красоту и низкоуровневость, до сих пор не очень подходит для решения задач анализа данных в силу слабой интеграции с BLAS и отсутствием стабильного набора тулинга для подобных задач. Это не значит, что в будущем его нельзя будет развить в эту сторону, но это значит, что в текущем виде это не очень хороший выбор для подобного класса задач. То же самое в случае R и почти любых не-статистических задач.
весь тред не читали?
читал. Называется несколько мелких проектов для частных случаев. Это мило, но как это сравнимо с тысячами проектов и оберток в этих же сферах для питона? Судя по аргументам в том комментарии, R взяли просто потому что команда быстрее и проще всего умела на нем фигачить, а не потому, что он прям идеален для подобных задач. И это вполне логично, но никак не является аргументом в поддержку языка. Могли бы взять с тем же успехом любой другой, с которым просто умели работать
это ограничение его экосистемы
и в чем это ограничение? мне правда интересно
Называется несколько мелких проектов для частных случаев. Это мило, но как это сравнимо с тысячами проектов и оберток в этих же сферах для питона? Судя по аргументам в том комментарии, R взяли просто потому что команда быстрее и проще всего умела на нем фигачить, а не потому, что он прям идеален для подобных задач
все куда то ушло не туда, в идеальность-неидеальность, ну это ж такое, правда?
То же самое в случае R и почти любых не-статистических задач.
не согласен с такой категоричностью, ну да и ладно, многообразие мнений это хорошо
Увы, стиль "не читал, но осуждаю" превалирует.
R прекрасно заходит во всех вертикалях.
Где-то один, где-то вкупе с тяжелой артиллерией в виде баз, балансировщиков, серверов приложений, шин и пр.
За что я не люблю всяких "евангелистов языков",так это за откровенную неспособность реально относится к проблемам языка. То go с его "дженерики не нужны", то "r отлично заходит везде, а те вещи, которых там нет, вам не нужны".
Не думайте, пожалуйста, что вы умный, а все ошибаються. Очень часто наоборот.
Не любите -- Ваше право. Но давайте уж логику проследим.
1. Есть исходный текст. В нем нет никаких призывов, никаких бигдат и промышленных применений. Рассматривается ряд предельно конкретных вещей. С примерами и отсылками на доп. материалы.
2. В комментариях возникает масса вопросов далеко за пределами исходного текста. Я стараюсь ответить. Без каких-либо призывов, просто ответить.
3. Вы читаете комментарии, вырываете из контекста и делаете свои выводы, которые никак не относятся к исходному тексту.
Как относиться к Вашим высказываниям? С большим сомнением.
Вы ведь в курсе, что коммерческие решения во многих случаях представляют сборную солянку из языков и технологий. R себя там очень хорошо проявляет в качестве "мат. сопроцессора" и аналитического окна.
Но при чем здесь промышленная разработка и аналитика, как про нее изначально было написано? Что Вы в кучу мешаете все?
Есть масса других языков, которые более пригодны для промышленной разработки и куда производительнее.
https://habr.com/ru/post/488644/ -- прекрасный доклад. Golang рулит для многопоточных задачек.Полмира сидит на аналитических микросервисах на R. Ажур с радостью предоставит.
Стыдно за курсы тех "нескольких университетов". Честно, стыдно. Что хоть за универы?
Я на этом докладе был лично. То, что вы приводите его в пример, показывает, что вы вообще не понимаете, о чем речь - Go не является заменой питона, тем более в DS, и у него масса проблем с экосистемой. Он отлично подходит для быстрых асинхронных сетевых сервисов и вещей потипу параллельных ETL, но это весьма специфическая вещь.
Про полмира вы, мягко говоря, лукавите. Полмира сидит как раз на питоне, а R знает только по отдельным статьям, и то ищут, как те же вещи перетащить в питон. Ведущие университеты курсы переводят на питон.
P.S. Да, если что, вам "стыдно" за курсы Johns Hopkins University, например. Не говоря уже о том, что предложенный пойнт про "почему так методы называются" самоочевиден, с ним сложно спорить. Это еще одна из слабых сторон R.
Вы заметили, что я настойчиво пытаюсь вернуть в область DS, но вопросы задают вообще из других областей. Джависты, бигдатовцы, разработчики корп. систем. И вопрос был "вообще" и ответ был про промышленную разработку. И да, го для другого, но это не мешает показать, что питон не универсален. Есть вещи и получше для определенного класса задач. и голэнг модули куда приятнее в прод тащить, чем питон.
Видел я многие курсы, не надо старье пихать 20-ти летней давности. Курсы надо актуализировать периодически, хоть это и трудозатратно.
Утомили уже эти комментарии без привязки к темы, без ссылок, без доказательств. А также желание каждого второго облить грязью. Нацепили каски и давай палить, даже не прочитав от начала до конца. Ну вот с чего Вы взяли, что что-то там про го непонятно? Но есть другой факт, когда говорят про ds в энтерпрайзе, зачастую подразумевают %30-40 загрузки/перезагрузки данных. и ETL там выше крыши.
Есть хоть одно возражение к тезисам в исходном тексте? Там ведь масса материалов и ссылок была дана?
В области 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 не существует в принципе. Мимо.
Вот отсюда и подобная реакция на сей опус - он делает ряд мало связанных с реальностью заявлений и сравнивает бензопилу и швейцарский нож.
Панда ООП-шная. И сам питон по своей идеологии ООП-шный. И все там ООП пропитано снизу доверху
В панде почитайте про blockmanager. Просто почитайте.
Никуда не деться от множественного написания переменной. Факт, проверяемый каждым лично.
Генератор и пайп -- разные вещи. Хотел бы сказать генератор -- сказал.
Здесь не затрагивались распределенные вычисления. Это отдельная область. Считаем на одной машине.
Вы спутали профилировщики с бенчмаркингом. Это две разные вещи, ну просто поглядите хотя бы. Хотел бы я написать про профилировщик -- ну так бы прямо и написал. И в R хорошо и с этим и с другим.
https://rstudio.github.io/profvis/
https://r-prof.github.io/proffer/index.html
1) Нет. Не знаю, откуда вы это взяли, это просто неверно. Более того, несмотря на то, что все - объекты, именно ООП-подход в питоне довольно куцый и не очень удобный
2) Читал. Костыли для управления памятью есть везде, но только вот в пандасе они вполне работают. Более того, у меня был на практике случай, когда большой csv-файл спокойно прочитался пандасом в память (и не сильно много занял), а R выдал...сегфолт. Без объяснений, просто не работало
3) Я привел конкретный пример, как избавиться. Не говоря уже о том, что явное лучше неявного, а переменных без объявления в середине выражения быть реально не должно
4) Не настолько разные. Если вам просто нужно организовать цепочку вычислений, где следующий шаг получает результаты предыдущего - для этого есть генераторы. Пайп - это конструкция в первую очередь операционной системы, а в языках есть разные свои обертки, которые реализуют что-то похожее
5) Не понял, причем тут распределенные вычисления. Питоном тоже можно считать на одной машине
6) Профилировщик - сюрприз - в том числе может запускать бенчмарки по коду. По вашим ссылкам всего лишь простейшие инструменты для флеймграфов, при этом тот же Scalene умеет, например, в рандомизацию окружения, бенчмарки на GPU, бенчмарки многопоточных и многопроцессных программ, отдельный вывод статистики не только по user time vs kernel time, но и по Python time vs C time
P.S. Ваша нумерация ответов полностью игнорирует нумерацию в моем комментарии, в результате сбивает с толку и игнорирует часть пунктов, которые были упомянуты выше. Это не очень хороший прием в обсуждении
Давайте попробуем с сохранением нумерации.
Выхожу за рамки одномерных массивов из numpy. Попадаю во фреймы -- объекты. Работа с файлами, графиками, бд, модельками -- опять ООП.
Если читали, то видели архитектурные косяки панды? А что там было на практике -- неизвестно. Что, где, когда, при каких условиях... чем читали.
`query` никак не спасает в большом количестве случаев.
пайпы много функциональнее в R. И никак не генераторы. Вы просто почитайте, я же ссылку дал. Это не просто передача выход-вход. И они очень удобны. Обертками это не решается в питоне.
на одной машине
data.tableвсех обыгрывает, не надо огород городить. есть еще `apache arrow` как хорошее дополнение.бенчмарк алогоритмических конструкций. ну не дают профилировщики полноты картины, что надо при оптимизации вычислений.
1) Вы сейчас пытаетесь россказать, что любой вызов метода через точку - уже ООП? Нет, так не работает. В случае Pandas большинство вещей - это либо методы самого модуля pd, либо методы датафрейма. Откуда там ООП (наследование, полиморфизм, инкапсуляция?) - решительно непонятно
2) Видел, конечно. В R их не меньше, управлять памятью вообще непросто в случае больших датасетов. Но вот выпадать в сегфолт некрасиво
3) спорно. В любом случае, упоминать имя датафрейма постоянно уже не нужно, а других пунктов вы особо и не приводили
4) вы привели внешний модуль, который умеет в цепочечные вызовы. Во-первых, в pandas есть pipe. Во-вторых, в питоне есть масса модулей, которые позволяют делать похожие вещи, потипу toolz или pipetools. И да, это не фича языка
5) я вам привел пример - не обыгрывает. В моем случае пандас справился лучше, да еще и, при грамотном указании типов, в памяти может занимать меньше
6) все прямо наоборот. Бенчмаркинг - всего лишь одна из функций профилировщика. Именно профилировщики и дают полную картину, а простой бенчмаркинг - нет
Причем тут точка? Что мы видим при вызове типа переменной пандаса? Правильно, `<class 'pandas.core.frame.DataFrame'>`. Есть класс, есть методы, есть внутренние объекты-классы (`Series`). Есть частные методы вместо общих функций. Этого вполне достаточно для констатации, что здесь применяется ООП подход. Не данные в центре, а какие-то абстрактные классы. Функциональный подход при работе с данными ближе к математическому мышлению и гораздо удобнее, в т.ч. в конвейерной обработке пайпами. И да, я ООП, в его попытках зажать у себя данные и наслоить методов, просто не перевариваю для счетных задач еще с BC++ 1.0, этот скафандр в гамаке.
Упоминать какой-то частный мифический опыт -- тот еще аргумент. И *niх иногда валится в `kernel panic`, бывает. Надо в деталях разбираться.
Я могу приводить много раз, но Вы не смотрите описание по ссылкам, не смотрите примеры кода в предыдущих публикациях (https://magrittr.tidyverse.org/index.html). Что это просто Вам совершенно далеко, что для архитектора вполне понятно.
Я могу 100500 раз пытаться предложить посмотреть, но это все равно не поможет. Пока сами не прочитаете, не поймете, почему итератор не годится. Да просто потому что в пайпе я могу передавать весь объект и тут же менять его по ссылке + использовать его же внутри вычисления как через
., без именования. Классический вариант -- использование его в качестве аккумулятора в цикле при итерационных операциях. Масса задач и алгоритмов решаются проще и экономнее с таким подходом.Пример -- воспроизводимый код. Ничего Вы не привели, только слова разные говорите, я пример же приводил, адресую еще раз: https://h2oai.github.io/db-benchmark/. Этот архитектурный пафос встречал много лет и все по одному сценарию. Отдельные архитекторы вообще "облачка" рисуют и "зуб дают". У вас лучше, видно же, что в инфраструктурных вещах, в го и т.д. Вы хороши. Здесь же -- "из общих соображений". И чаще всего на конкретных задачах общие подходы оказываются неудобными. Все вроде по правилам и по корп. стадартам, а на выходе --- убогая поделка и задача не решается. Изначаль ведь про civil DS речь шла, не я лез на архитектурное поле, а Вы насильно тащите. Научной деятельностью занимались или сразу все бросили? Лего модель хороша для типовых прямоугольных задач.
Ну что здесь спорить? Вы по ссылкам ходили? Смотрели, что требуется при отладке алгоритмов? Когда у Вас Монте-Карло или сложный процессинг или сложные итерационные вычисления -- надо оптимизировать каждый отдельный шаг. 10 мс помноженные на 10^10 дают очень ощутимый вклад. Взгляд сверху не дает картины. Зачем смешивать телеском с микроскопом? А если разницы не видите, то для архитектора простительно. Это все в стиле бизнеса "зачем думать о мелочах, маржа все покроет". Ну да, ну да. Ровно до того момента, пока она есть. Системы реального времени писали? Если бы я хотел глобально рассуждать, то так и писал бы. Есть основания. Но нет, здесь был частный вопрос. Паяльник в руки берете когда-нибудь? А осциллограф? Или машины меняете при пепельнице забитой? А вот нету новых машин в наличии нынче...
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) Ваш пункт похож на цитату из Сорокина, вот можно по ссылке посмотреть. Судя по всему, вы просто осознали свою ошибку и теперь просто "бычите" и переходите на личности. Рекомендую вам вот это видео, чтобы понять, о чем вообще речь.
4) я привел только частный пример, один из вариантов, но Вы все равно упомянули аккумуляторы и fp в виде reduce. ожидаемо.
5) polar -- он же arrow. Это другая штука, доступная сама по себе во всех платформах. Все исходники тестов на гитхабе. И я знаю, что там нет явного лидера -- я за этим отчетом лет 5 смотрю. Зачем скрывать? Все меняется и новые технологии и подходы дают улучшение. И да, на практике используется не один data.table, а в связке с arrow. Но это хорошо стало с 7-го релиза последнего.
6) да просто утомило. еще раз, если не видите разницы между телескопом и туннельным микроскопом -- я ничего поделать не могу. мне приходилось считать задачи в квантах и дочищать косяки так, чтобы от 10^5 дней доходить до 2-3-х суток счета. Да, циклы процессора и миллисекунды иногда играют роль.
Давайте закрывать тему, все эти обменами кто чего не читал и кто чего не смотрел. Вы ведь явно что-то хотите мне доказать? Но зачем по одной точке делать глобальное суждение обо всем? Ваш опыт я примерно понял, много писали, я полистал и прошлые публикации на хабре, с моим опытом Вы не знакомы, я нигде особо тут не пишу. Гораздо интереснее в реальности пересекаться, чем тут конфронтацией заниматься. С половиной тезисов согласились -- ну давайте и остановимся на этом. И не надо исходный посыл тащить на свое архитектурное поле. У меня не было планов переубеждать на 100% кого-либо. Я предоставил альтернативную точку зрения. Будет возможность раскрыть инфу, я отвечу и на ваши вопросы по MLOps фактами, наберитесь немного терпения. Вы не на все вопросыы отвечате. Ссылки хорошие. Мне, например нравится подход и работы https://www.brendangregg.com/. И ряд других материалов и книг.
4) да, потому что всё это, чем вы хвастаетесь в R - всего лишь сахар над этими самыми fp-примитивами. Он есть много где, включая питон
5) arrow - всего лишь формат представления. Polars - не arrow, а набор методов поверх, как и многие другие библиотеки. Даже pandas его сейчас использует, как промежуточное представление
6) я очень за вас рад, но R тут ни при чём. Можно с тем же успехом оптимизировать код на Numpy и сильно выиграть в итоге по скорости и памяти
Моя претензия в том, что ваши заявления не базируются на аргументах - в статье почти все ваши набросы неверны или неточны, что я выше и разобрал. Это похоже на "синдром утёнка", когда человек начинает считать лучшим то, что просто первым познал.
Вы молодец и отлично знаете инструмент, которым пользуетесь, но пока что всерьез показать людям, что на него стоит переходить с более мейнстримных языков у вас, к сожалению, не получилось.
+1 за Брендана, его книжка Systems Performance есть у меня в бумаге
У меня не было цели всех перетаскивать на R. Но постоянно наблюдаю как аналитики мучаются с пандасом. Это для них текст, а не для матерых архитекторов. Просто посмотреть и подумать. R реально удобен для расчетов, мне много чего приходилось пробовать, начиная от фортрана. Круто, когда вся команда состоит из спецов Вашего уровня, но на практике половина команды типового проекта будет состоять из джунов или людей с опытом 2-3 года. И надо с ними строить.
Упоминание "синдрома утенка" просто смешно. Еще раз, Вы же не знаете ничего про мой опыт и список выполненных проектов. Лучше просто не говорить. Вы хороший оппонент, в целом, приятно видеть серьезный подход.
Но я здесь не собирался выступать на Вашем поле, меня более алгоритмические вещи интересуют и решение настоящих задач, а не простые агрегаты map/reduce или автомл.
Кстати, Вы ведь в курсе, что кроме кровавого энтерпрайза существуют другие миры? Экономисты, логисты, маркетологи, медики, биологи и биоинформатики, бизнес-консультанты, аудиторы и др. Там задачи бывают порой крайне сложные и объёмные. И простыми агрегатами там не отделаться.
Я не ожидал, что взрослые дяди налетят и начнут натягивать на млопс и бигдату, хотя об этом и звука не было. Ну не для вас это все было, не для вас.
Bfs/dominator говорит что-либо? А msa? А задачи эконометрики? Mau/dau/ltv? WGS?
А там тоже люди работают. И они тоже Хабр читают. https://letnyayashkola.org/about/
Многие комментаторы превратили весь поток в ярмарку тщеславия.
Позиция «все, кто не в ит — люди второго сорта», очень популярная на хабре. И у неё даже название существует. Но реальность совсем другая. В 99% ит является центром затрат, а прибыль генерит«аналитик и продавец с экселем». И когда заболеете, не бигдатой лечитесь, а на лекарства да на врачей уповаете. И хочется, чтобы поезда ходили по расписанию и полки в магазинах были не пустые.
Разрабы далеко не все так пафосно выступают, когда после аудита попадают в категорию D (балласт). Кончаются красивые слова. Либо профит, либо убытки. Посмотрите прошлую публикацию, она не из воздуха возникла. Не стоит забывать местным участникам, что заветная смс-ка от банка далеко не всегда вашими усилиями приходит. Количество цетропупских советов тут зашкалило.
Для «мочилова» на вашем поле надо экзоскелет из кладовки достать, есс-но одного R недостаточно. Вас много, я один отбиваюсь от вопросов не по исходному тексту.
Nothing personal, just business.
Go не является заменой питона, тем более в DS, и у него масса проблем с экосистемой.
Можно пожалуйста раскрыть тезис про экосистему?
Ну, во-первых, Go до сих пор оправляется от войны между разными способами управлять в нем пакетами. Да, формально go modules победили, что не мешает все равно до сих пор некоторым проектам использовать dep и прочие альтернативы. Да и домены сайтов в импортах модулей смотрятся специфически.
Во-вторых, в Go пока что мало стабильных и готовых к продакшену модулей для сложных вещей. Например, толковый ORM вроде как есть, но иногда в нем встречаются совсем детские ошибки. С миграциями все сложно. С XML неймспейсами Go работать, внезапно, не умеет в принципе, ни через стандартную библиотеку, ни через внешние. Только адские костыли.
В-третьих, разные модули используют разные подходы, например, к остановке горутин. Где-то надо внутрь прокидывать Context, где-то канал, а где-то вообще это не настраивается и приходится переопределять что-то самому. Хранение глобальных переменных в контексте - очевидный антипаттерн, но, тем не менее, тоже иногда используется.
Можно еще много чего вспомнить. Непонятно зачем существующие в языке массивы, указатели на интерфейсы. Не очень хорошего качества http-модуль в стандартной библиотеке, который иногда течет по памяти. append(), результат которого нельзя присваивать не той же переменной, что у него в аргументе. Это все рано или поздно пофиксят или переделают, но пока что смотрится довольно незрело, несмотря на то, что даже сейчас языка проще и удобнее для написания быстрых асинхронных сетевых сервисов просто нет.
Ну удобство - оно субъективно. Я, например, Go не рассматриваю именно из-за неудобства синтаксиса во многих моментах и безальтернативности правил написания кода в языке. Так еще и позиция его создателей играет роль, которые сознательно ухудшают скорость работы программ ради скорости сборки и не дают это отключить
Лично мне Rust удобнее, поскольку спасает от гораздо большего количества ошибок и многое позволяет, гораздо больше Go. При том же объеме кода микросервисы на Rust (выглядят 1 в 1 как ExpressJs с тайпскриптом) работают в 8 раз быстрее Go, в 10 раз быстрее ExpressJs и в 30 раз быстрее Spring. Сам язык я считаю по уровню сложности наравне с Java/C#, так что проблема лишь в его молодости, из-за которой специалистов мало (но в него вцепились крупные корпорации намертво, так что вопрос времени)
>>Вот почти уверен что скобки и избыточность упоминания df в срезах df[(df.col1==...) & (df.col1>...)] скоро уберут.
Это невозможно без изменения самого языка. Выражение (col==...) должно быть вычислено первым а переменная col1 - не определена.
В текущем питоне можно либо превратить это в вызов функции df.slice(col1==...) но смысла нет, либо заменить строкой df["(col1==..."] но и это плохо.
Я R-ом пользуюсь каждый день и обучаю ему студентов. И проблема в том, что чем глубже в R, тем страшнее им пользоваться для сложных проектов, потому что base R построен по-принципу "удобство важнее надёжности" и "костылей в куче много не бывает". Неправильные индексы не то что ошибку, ворнинг не дают. Зачем, если можно вернуть NA или NULL, хуман сам разберётся. И это только самый базовый, но постоянно используемый функционал. Вот человек не поленился копать и там такие глубины ада разверзлись... https://github.com/ReeceGoding/Frustration-One-Year-With-R
Позитив что медленно, но верно это всё фиксят. Строки уже не факторы по-умолчанию, && и || наконец выдают ошибку при более чем одном элементе (а не молча игнорируют всё кроме первого элемента). Но ударение на слово "медленно".
Аналитика и промышленное программирование сильно отличаются.
Весь Tidyverse стек построен именно в контексте работы кода в проде.
Немного писал здесь: https://habr.com/ru/post/543552/
Приходите в группу в телеграме -- подскажем.
Да, Tidyverse действительно гораздо строже и поэтому гораздо надёжней. (Честно говоря, я вообще плохо понимаю кому нужен R без Tidyverse, но на вкус и цвет...) Но от базового R всё равно ни куда не денешься. И Tidyverse постоянно меняется, pivot_longer/wider это уже у нас 3-я версия функционала? Я до сих пор им не могу простить, что они устроили с summarize превратив его в универсальную функцию, которая и mutate, и исходный summarize, и вообще хоть сколько строк можно, давай всё.
Приходите в телеграм канал, разберемся. Хадли и его команда, действительно, очень хорошо систематизировали. И, конечно же, data.table, который просто превосходен.
И, конечно же, data.table, который просто превосходен.
Да, метапрограммирование R позволяет создавать альтернативные способы работы. Но это создаёт диалекты, которые не похожи друг на друга до такой степени, что видя код можно и не угадать что это всё R. Для меня это диллема, потому что я бы учил студентов только Tidyverse, но при этом они банально не смогут понимать код на базовом R который им может встретится в книгах (они психологи, так что нельзя рассчитывать, что они сами быстренько разберуться). Приходится давать оба варианта (и data.table уже никуда не влазит, но может и попробую в следующем семестре впихнуть невпихуемое).
Не знаю, какая у Вас программа, но и data.table можно по верхам в один день вместить. Глубинам все равно не обучить, только практика и самостоятельное набивание шишек даёт устойчивое знание.. Но за руку провести по шоколадной фабрике и дать краткий обзор — возможно. У человека остаётся воспоминание, что есть разные методы и подходы, позже сможет сознательно вернуться сам.
Пока tidyverse развивался, функции претерпевали изменение. Это нормально. Сейчас многое застабилизировалось, главное, что здесь применяются лучшие практики разработки ПО. Читали про жизненный цикл функций в tidyverse?https://www.tidyverse.org/blog/2021/02/lifecycle-1-0-0/
Решили и выбрали Python не директора курсов и вузов, не тренеры, а... сами аналитики, их работодатели и другие программисты, которым переход на Python+Pandas и интероперабельность такой связки показались выше, чем с R.
Ну то есть выбор-то уже был сделан, наличием питон-стека на предприятии или наличия опыта в питоне, а не потому что R это фу, остальные причины - экономика рынка труда и вкусовщина, кому то синтаксис питона красив и понятен, а я после C++ и подобных не могу себя заставить питонить ))
Про R многое можно сказать, но стоит начать с главного - к нему отсутствует вменяемая документация. Помнится, я сталкивался с тем, что вычисление квартилей работает иначе, чем это документировано - чтобы найти причины, пришлось залезть аж в фортрановские исходники. Ну просто замечательный язык, где авторы просто подключают неведомые сторонние либы вообще без документации и комментариев в них, и даже не находят нужным протестировать получаемые результаты. Использовать этот черный ящик для сложных задач типа машинного обучения, серьезно? Мне это очень напоминает подход авторов пакета GMT, которые делают ровно так же - волосы дыбом становятся, если почитать их исходники и чэнджлог, где одни сторонние библиотеки заменяют другими раз за разом, каждый раз получают разные результаты и никак не могут договориться, какой же результат считать правильным! На питоне, при всех его недостатках, я ни разу не сталкивался с тем, чтобы метод и результат вычислений абсолютно не соответствовал документации.
P.S. Вместо pandas можно использовать Sqlite3, в среде Jupyter Notebook запросы выполняются с помощью %sql (или %%sql) и результаты легко преобразуются в датафрейм pandas.
Вместо pandas можно использовать Sqlite3
Лучше R + apache arrow или DuckDB - очень удобно и очень быстро ;)
По R сейчас просто изумительная документация. Дайте вопрос, приведу ответ.
И книги прекрасные выпущены и переведены.
По квантилям -- вот пример. https://www.rdocumentation.org/packages/stats/versions/3.6.2/topics/quantile
Все написано, 9 вариантов различных вычислений (ну так уж накопилось в науке), есть ссылки на научные публикации.
А CRAN вообще закрутил гайки и ввел репрессии в части CI/CD по репозиторию пакетов.
Смотрим исходники:
See R-3.2.2/src/library/stats/R/quantile.R
r_quantile <- function(x, probs)
{x <- sort(x)
n <- length(x)
nppm <- n * probs
j <- floor(nppm)
if ( nppm > j ) {
qs <- if (j<n) x[j+1] else x[n]
} else {
qs <- x[j]
}
qs
}
Как итог, получаемые результаты несовместимы ни с одной стандартной реализацией. А теперь покажите, где в документации R сказано, что они взяли и сломали реализацию вычисления квартилей, используя функцию floor() вместо необходимого round()? Нарушать без предупреждения реализацию базовых функций - такое только в ранних версиях PHP лет двадцать назад случалось, и то там быстро чинили.
Без репрекса сложно понять. Да и код исходной фунции сильно сложнее:
https://github.com/wch/r-source/blob/trunk/src/library/stats/R/quantile.R
там же еще есть параметр type, который влияет на логику расчетов.
просто это серьезный вопрос, требующий тщательной подготовки примеров в коде. Вы точно уверены, что все параметры правильно выставляли: https://www.amherst.edu/media/view/129116/original/Sample+Quantiles.pdf ?
Я уверен, что ни один из вариантов вычисления этой функции не возвращал ожидаемый результат, в отличие от Python Numpy. Как видим, код реализации внутренних функций R безобразный, недокументированный и не комментированный, потому что вот это вот вообще нечитаемо:
if(type == 7) { # be completely back-compatible
и вы ничего не можете понять, глядя в этот код. По сути, существует единственная неопределенность вычисления квартилей дискретного распределения, которая сводится к тому, что считать медианой для четного количества элементов - если взять среднее от двух элементов, то оно не является членом исходного ряда, в то время как медиана по определению должна им являться (в том числе, это приводит к тому, что медиана целочисленного ряда оказывается дробным значением, что не всегда допустимо), поэтому стандартный подход это вернуть левое или правое значение, ближайшее по величине к этому среднему. В R же реализовано нечто неведомое.
Набор безапеляционных утверждений.
Вот статья из Statistical Computing, за автором известного математика Rob J. Hyndman, где описаны все подходы к вычислению квантилей. https://www.amherst.edu/media/view/129116/original/Sample+Quantiles.pdf
Пакеты в R построен в полном соответствии с ней. Если действительно хотите разобраться в вопросе -- давайте в конструктивный диалог в телеграм канал. Различные участники помогут. Если не хотите, а просто вбрасываете слоганы -- ну пусть будет так.
Насколько мне помнится, разработчики R официально гордятся тем, что они презирают такие низменные материи, как оптимизация программ, это идеология языка. К примеру, уже для несложной обработки CSV файла (оценка распределения данных, подсчет регрессий и корреляций… все эти алгоритмы отлично распараллеливаются до такой степени, что можно просто построчно данные с диска считывать и обрабатывать, несложно самому за несколько часов написать реализацию, которой хватит знаменитых 640 КБ памяти) в несколько гигабайт в R можно было получить ошибку, что программе не удалось аллоцировать больше 64 ГБ памяти (независимо от доступной RAM и свопа, там внутренний лимит был), в то время как на Python+Pandas хватает 8 ГБ - даже если данные загрузить в память целиком. В общем, в свое время у меня было много заказов от университетов по портированию их «научного багажа» с R (и Matlab, но это отдельная история) на Python, потому что данных стало больше и обработать их на R невозможно даже на университетских кластерах, в то время как на Python+Numpy+SciPy+Pandas+Dask то же самое легко сделать на типовом лаптопе. Впрочем, с помощью Dask на типовом лаптопе (8 GB RAM, по тем временам) можно и терабайты данных обработать, и даже без модификации программы запустить ее на многоядерном сервере или кластере серверов с автоматическим распараллеливанием и удобной панелью визуализации. Так что R это конкурент Microsoft Excel, а не Python с его научными библиотеками.
Вам просто сильно не повезло и у Вас совсем нерелевантный опыт.
Досадно, что так получилось.
В реальности все прекрасно работает.
Дело в руках (или в очках).
Хм. А давайте предположим что выяснится что у большинства такой вот "досадный нерелевантный опыт" и "дело в руках (или в очках)".
О чём это по вашему будет говорить?
Ваш случай легко проверяется на практике. От разговоров переход на стенд и простая демонстрация как надо было делать. Факты -- вещь упрямая. Делал так бесчисленное количество раз.
Посмотрите https://github.com/gedeck/practical-statistics-for-data-scientists
Там примеры к книге на R и Python.
С вычищенными комментариями во всех случаях R лаконичнее.
Про перформанс ссылку давал, можете поглядеть, там очень обширные тесты.
Ваш случай легко проверяется на практике.
У вас есть статистика?
Факты — вещь упрямая. Делал так бесчисленное количество раз.
Какие "факты"? Если у вас всё нормально получается, то и у всех остальных автоматом должно всё нормально получаться? И в принципе не может быть иначе?
Посмотрите https://github.com/gedeck/practical-statistics-for-data-scientists. Там примеры к книге на R и Python.
С вычищенными комментариями во всех случаях R лаконичнее.
Ну так давайте допустим что я посмотрел и получил "досадный нерелевантный опыт". И большинство других людей посмотрели и тоже получили его же. О чём по вашему будет говорит такая вот гипотетическая ситуация?
А потом можно будет обсудить насколько эта гипотетичская ситуация совпадает или не совпадает с реальностью. Если в этом ещё будет необходимость...
Понимаете, разговор плавно переходит в тон обоюдных наездов.
Это неприятно и деструктивно. Тем более что мы вообще ничего не знаем про опыт оппонента. Я мог бы много чего рассказать и показать, частично рассказывал на митапах. Если Вам действительно что-то интересно, приходите в группу в телеграм. Гладко все бывает только на бумаге.
Вы по моему не особо понимаете что я пытаюсь до вас донести. У вас всё хорошо и всё работает. Есть какие-то единомышленники у которых тоже всё хорошо и всё работает.
Но вы в статье задаёте вопрос: почему у нас есть такой хороший и замечательных язык R, но при этом им мало кто хочет пользоваться. А пользуются все не таким хорошим и замечательным питоном.
И когда вам люди говорят что они пробовали R и у них это не работало, то вы удивляетесь и хотите им обьяснить как это делать правильно. Приглашаете в телеграм, на митапы, даёте полезные ссылки. И так далее и тому подобное.
И не видите что на самом деле "поезд уже ушёл". Потому что люди не хотят в телеграм, на митапы и читать кучу полезных ссылок и разбираться. Они хотят взять и чтобы сразу работало. Ну максимум глянуть что-то на stackoverflow. И похоже с питоном оно так получается. А с R не получается. И в этом-то и проблема...
Ничего сразу нигде не работает. Все требует больших усилий по освоению. А если уж и работает, то в R с этим куда проще.
Никакой поезд никуда не ушел, да и поезда нет никакого. Спиральное развитие. А первоначально входящие на этот рынок труда могут критически посмотреть на спектр предлагаемых инструментов и возможностей. Просто не стоит воспринимать питон "даром богов".
С утверждением "я попробовал и у меня не получилось" работать ну никак невозможно. Даже поддержка тикет не откроет в такой постановке вопроса.
На западе R занимает сегмент примерно такой же как питон. Целая индустрия. Это у нас исторический перекос возник.
Если есть серьезный вопрос, то он требует тщательного разбора с `reprex`, уточнениями по разным моментам и т.д. Формат комментариев для этого совсем неудобен. Вот и все.
Ничего сразу нигде не работает. Все требует больших усилий по освоению.
У меня приходят практиканты с нулевым опытом, а иногда даже знаниями по питону. Я им даю питон и они через пару недель спокойно что-то там на нём себе делают. С R я лично так естественно не пробовал. Но даже по вашим словам получается что скорее всего оно так работать не будет.
А первоначально входящие на этот рынок труда могут критически посмотреть на спектр предлагаемых инструментов и возможностей.
Первоночально входящие смотреть могут что угодно. Вот только они обычно ничего не решают.
С утверждением "я попробовал и у меня не получилось" работать ну никак невозможно. Даже поддержка тикет не откроет в такой постановке вопроса.
А никого никакие тикеты и не интересуют. Вася попробовал Р и у него не получилось. Потом он попробовал питон и у него получилось. Для Васи тема закрыта. И если таких Вась много, то вот вам и ответ на вопрос почему питон популярнее.
Вы посмотрите на вопросы начинающих и не очень.
Нет никакого "попробовал и получилось". Опыт накапливается через множество шишек. И чаще всего, если руку не ставить, то код будет являться скопищем антипаттернов.
Практиканты -- это любопытно. Где это так? Если искорка осталась, можете дать тест драйв для R, результаты могут превзойти ожидания.
Вы посмотрите на вопросы начинающих и не очень.
Смотрю. И вижу людей у которых сходу не получилось. То есть что-то не так с порогом вхождения. По крайней мере для меня это выглядит так что у R он выше чем у питона.
Практиканты — это любопытно. Где это так?
В смысле "где"? На фирме. А у вас на фирмах практикантов нет?
Если искорка осталась, можете дать тест драйв для R, результаты могут превзойти ожидания.
Так нет этой самой искорки. И откуда ей взяться то? В той нише где мы применяем питон он нас в принципе устраивает. Наши клиенты тоже в основной своей массе использует его. Зачем нам что-то менять?
Со "студентами" вообще морока.
Очень много времени до выхода на безубыточость.
3-4 месяца надо учить методам командной работы и промышленной разработки, чтобы их код можно было в гит вливать.
С прошедшими "экспресс" курсы приходится проводить предварительную зачистку, выкорчевывать сорняки антипаттернов. В обучении же "быстрей-быстре", без какого-либо серьезного фундамента. Если я сажусь и переписывают несколько строчек, получая ускорение в 1000 раз -- ну это непозволительная роскошь для кода в проде.
Искорки нет -- понятно. Выгорание, рутина сжирает. Не Вы первый, не Вы последний.
Если я сажусь и переписывают несколько строчек, получая ускорение в 1000 раз — ну это непозволительная роскошь для кода в проде.
А если нет этого ускорения? Или если оно никого не интересует? Ну то есть вам принципиально будует скрипт бегать 0,1 секунду или 0,0001 секунду? А если между запусками скрипта у вас "человеческий фактор" на 20-30 секунд?
Искорки нет — понятно. Выгорание, рутина сжирает. Не Вы первый, не Вы последний.
Не-не-не. Искорка у меня есть. Но в других контекстах. Питон это у нас так, ниша. Зачем мне там "гореть"?
Я мог бы ответить на большинство Ваших вопросы (они достаточно типичны), но формат перепалок в комментариях очень неудобен. Я постарался максмально четко раскрыть ответы, но матрешки бесконечной глубины требуют бесконечного времени, которого нет ни у кого.
Тематика "What-If" требует погружения в конкретный кейс и составление модели. Я частенько занимаюсь симуляцией и цифровыми двойниками, чтобы немного понимать сложность этого вопроса. Маловероятные ветки на первых итерациях нужно прибивать сразу, иначе Ктулху утащит.
Выше я дал отсылку на код апстрима R, который ужасен и работает некоректно. Вы сами этот код даже понять не смогли, хотя я привел сокращенную его версию, демонстрирующую проблему. И вместо того, чтобы заняться проверкой и починкой, вы имеете наглость заявить, что это просто программистам на R «не повезло», что они R используют? Ок, больше не будем, я с этого и начал свой комментарий. Далее, про обработку больших данных - вот у меня есть открытый проект на Python - пакет спутниковой интерферометрии, размер обрабатываемых данных от пары гигабайт (меньше никак не получится, в силу природы исходных данных) до терабайт - попробуйте сделать аналог на R, раз уж вы утверждаете, что R это нечто большее, нежели замена Excel, и вы умеете им пользоваться. В репозитории есть ссылки на «живые» Jupyter ноутбуки на Google Colab, ждем от вас альтернативной реализации на R, также работоспособной на Google Colab за сравнимое время. Ссылка на репозиторий: https://github.com/mobigroup/gmtsar Лично мне для получения вменяемых результатов для подобной обработки на R приходилось писать либы на фортране с оберткой на R (да, не на си даже), причем на Python+Numpy обработка все равно выполняется на порядок быстрее (потому что можно избежать лишних копирований и работать с одним экземпляром данных).
Поглядел проект — здорово. Когда-то тоже приходилось считать квантовые эффекты и взаимодействие света с веществом. Гигабайтами не пугайте, считаем-считаем. И терабайты тоже.
Но так вот наскакивать и грубо публично хамить незнакомому человеку — ну негоже это для учёного. Не находите?
Так ведь наскакивали и грубо публично хамили именно вы - что мол руки кривые (см. выше), а теперь еще и спрашиваете, нормально ли это? Нет, не нормально. Более того, по сути перечисленных проблем R и по показанным кейсам вам и сказать нечего, кроме вот хамства. То есть мало того, что R очень проблемный язык, так еще и его сторонники вот так себя ведут, ну и какой нормальный человек захочет в такое комьюнити? На всякий случай процитирую вас:
у Вас совсем нерелевантный опыт.
В реальности все прекрасно работает. Дело в руках (или в очках).
Так что, проверять и править core libraries R будете или ограничитесь оскорблениями? Вы просили примеров проблем - вам их показали. Проблему с избыточными копированиями данных в этом же коде уже тоже подробно обсудили, вдобавок. В Python+Numpy подобных проблем нет (как и многих других, отравляющих работу в R, типа F-ordering и C-ordering при использовании внешних библиотек и прочих).
Вы не показали никаких кейсов, только какие-то куски кода с гитхаба и много-много-много слов.
1. Что именно в медиане для четного числа чисел Вас не устраивает? Поддерживается аж 9 вариантов вычислений, которые описаны в статье в уважаемом журнале. Wolfram Alpha считает и не переживает -- можете поглядеть: https://www.wolframalpha.com/input?i=median&assumption={"F"%2C+"MedianCalculator"%2C+"list"}+->"{1%2C+2%2C+3%2C+4}"&assumption={"C"%2C+"median"}+->+{"Calculator"}. Откуда Вы взяли свою версию расчетов? Можно привести источник? Можете привести воспроизводимый пример, чтобы показать, что считается в питоне правильно и не так в R? Не словами, а цифрами. Вы же, в конце концов, околонаучный сотрудик? Сравним с Wolfram, Matlab, Maple, Statistica и т.д. Не нравится stats::quantile, возьмите https://sebkrantz.github.io/collapse/reference/fnth.html
2. Что Вы так рьяно рветесь править core library без наличия доказательной базы? И не забывайте правил корректировки любого софта -- если обещали обратную совместимость -- надо поддерживать. Да даже если отложить разработку -- на любом научном семинаре требуют (раньше точно требовали) предъявлять веские доказательства своих утверждений.
3. По активному упоминанию фортрана и "того времени" я полагаю, что Вы еще на 386 это писали. Но не надо сравнивать свой опыт использования R в 2004-м году с нынешней парадигмой. Все совсем иное.
И как можно закрыть вопрос безапеляционными утвержениями, что в R все работает через копии, если и окружения работают по ссылкам и весь пакет data.table работает по ссылкам? То, что Вы его не упоминаете и игнорируете как раз и показывает, что познания в R откровенно слабы.
4. Чем Вам сдались F-ordering и C-ordering? Это всё протуберанцы фортрана. Ну вот правда? Кто из читателей вообще в курсе этих штук? Какая разница как матрицы индексируются? Кэширование и все такое -- тонкая материя, время теряют далеко не там. Тем более, что Вы можете сами указать порядок свертки, а в памяти они все равно живут одномерным куском, меняются атрибуты и формула адресации через индекс.
5. А что мне остается думать, когда Вы раз за разом пеняете на те вещи, которые либо давно неактуальны, либо вообще непрозрачно сформулированы, либо противоречат реальным фактам (поглядите бенчмарки в конце)? Басни Крылова вспоминаются, это что, запрещено?
Горьковский радиофак -- это знаковое место. Но сдается, что мне найдется что паритетно ответить на многие вещи из Вашего профиля.
Интересно, но ничего не понятно!
Вы знаете как считаются квантили и ранги? И всякая непараметрическая статистика как устроена?
ясно
Это еще цветочки. В R еще и на месте сортировку выполнить нельзя, то есть необходимо передать копию данных в функцию сортировки, которая вернет такой же по размеру упорядоченный результат, итого мы уже имеем две избыточные копии данных (и необходимость их удаления в дальнейшем). Так что экземпляры одних и тех же данных тут множатся, как кролики, сжирая уйму памяти. И да, хотя нам нужен на самом деле только поиск значения, в R реализации использование сортировки означает поиск и перестановку данных. Итого, имеем два избыточных экземпляра данных, один из которых активно модифицируемый, вместо необходимого и достаточного единственного не модифицируемого исходного экземпляра данных. Ясно, что в итоге и потребление памяти растет кратно, и время обработки, причем еще и нелинейно от объема данных.
Почитал статью. Почитал обсуждение.
Сделал для себя вывод, что для анализа статистики и разной механизации, мне по прежнему хватает php и немножечко javascript :)
Да вы просто гость из параллельной вселенной! Но здорово, что заглянули на кофеёк.
Сделал для себя вывод, что для анализа статистики и разной механизации, мне по прежнему хватает php и немножечко javascript :)
Как сделавший когда-то многое с помощью php - поддержу, что можно и на этом стеке, но на R/python все же быстрее и удобнее )
Доводилось один раз видеть код аналитики, написанной на php, и разбираться в его логике работы. Хотелось бы развидеть.
Самый короткий путь и самый эффективный инструмент - не которые знаешь :)
Я не знаю питон совсем, и верю автору, что R лучше для обработки таблиц. Но в восхвалении R автора периодически заносит.
Что представляет собой
data.frameв классическом Computer Science? Это список указателей на массивы. Массивы — это колонки. Так было на ассемблере, так было на С/С++, Паскале и т.д
какой "классический Computer Science" имеет тут в виду автор - я не знаю, думаю, просто выпендривается. С и Паскаль содержат такие типы данных как структуры/записи, и таблицы реализуются массивом структур. Это одинаково компактно по памяти по сравнению с колоночным хранением.
Механизм NSE (Non-Standard Evaluation) вкупе с пайпами позволяет упомянуть имя датафрейма только в первой строчке и больше его не использовать
NSE - жуткая штука, работает магически, отлаживать её страшно. Но я соглашусь с тем, что компактный язык запросов в функциональном языке можно сделать только макросами или специальным парсером.
Computer Science: https://en.wikipedia.org/wiki/Computer_science. Кстати, многие западные курсы имеют аббревиатуры CS-XXX, оно отсюда проистекает.
Почитайте по ссылкам про структуру pandas, про BlockManager, полистайте внутреннее представление сами. Про R объекты можете почитать в картинках здесь: https://www.brodieg.com/2019/02/18/an-unofficial-reference-for-internal-inspect/
NSE отличная штука. Как только поймете иерархию окружений (по сути аналог стека вызовов) и про отложенное разыменование все встает на свои места. Во тнеплохие статьи:
- https://milesmcbain.xyz/the-roots-of-quotation/
- https://www.brodieg.com/2020/08/11/quosures/Хотите сами во всем разобраться -- спускайтесь в ассемблер. Как Даниэль делает, например, здесь: https://lemire.me/blog/2021/10/09/for-software-performance-can-you-always-trust-inlining/
Не встревая в спор R vs Python, замечу, что если ЯП А в нише сильно популярнее ЯП Б в той же нише, а вы считаете, что первый сильно лучше, то тут есть как минимум 3 варианта: 1) вы ошибаетесь в том, что ЯП А лучше, 2) вы ошибаетесь, что ЯП А лучше в этой нише или в том, как вы видите нишу, 3) в этой нише выбор ЯП вторичен по сравнению с какими-то другими факторами.
В индустрии постоянно есть очень странные популярные технологии. Ну вот, например, VB/VBA/VBS - в 2001-2003 годах это был язык популярнее нынешнего Python. Даже тогда было сложно придумать язык программирования более ущербный, чем VB. Но интеграция в Windows, Office и IIS вместе с низким порогом вхождения, возможность использовать COM/OLE и куча готовых примеров работали на VB. И таких примеров можно привести десятки - где-то сыграли накопленные наработки (как в Fortran году к 1998), где-то низкий порог входа (VB, PHP старых версий), где-то удачное стечение локальных маркетинговых обстоятельств (как в РФ с 1С в учёте), где-то удачный инструментарий, где-то преподавание в ВУЗах на этом ЯП, где-то еще какие-то факторы.
Если вы хотите сделать R более популярным, чем Python, и считаете, что он лучше подходит, то ищите не те места, где он сильнее, а где слабее и смотрите, как его усилить.
Все логично. Я вот вижу основную слабость в недостоточном информационном поле. Многие даже не в курсе, что существует что-то кроме питона. И эта публикация как раз и дает ответ в этом канале -- да есть и да, по ряду параметров лучше.
Я бы предложил не отмахиваться только "слабым информационным полем". Всё-таки, например в SQL Server, например, R пришёл раньше Python.
В любом случае - спасибо за статью.
Да почему же. Люди вполне себе в курсе что существует что-то кроме питона. Вот только мало кто хочет переучиваться, менять существующие процессы, переписывать всю кодовую базу и так далее и тому подобное.
То есть не видят они смысла заваривать кашу ради "по ряду параметров лучше"....
Мало кто хочет, согласен.
Но, с другой стороны, есть масса внешних факторов, которые почти ежедневно требуют изучения нового, перестройки, изменений. Нет теперь такой стабильности, что после школы пошел на завод и там проработал до пенсии. Так что, как в небезызвестной игре ["Перестройка"](https://www.youtube.com/watch?v=7uDrgNkQu14) наступает момент, когда надо прыгать.
Но, с другой стороны, есть масса внешних факторов, которые почти ежедневно требуют изучения нового, перестройки, изменений.
Угу. Вот только если человек скажем двадцать лет работал в куче разных фирм и везде был питон, то вы вряд ли его убедите что ему надо срочно учить что-то другое.
И самое главное если у вас есть фирма, в которой всё на питоне, то попробуйте убедите начальство что надо срочно всё менять и переучивать весь персонал.
наступает момент, когда надо прыгать.
Ну так вот если он действительно наступит, то есть если питон по какой-то причине в принципе больше не будет вариантом, то люди начнут искать альтернативы.
А пока просто есть ситуация когда какая-то альтернатива "лучше по ряду параметров", то из-за этого никто особо дёргаться не будет.
Не существует только 1 и 0. Все время смешанные состояния.
Касательно больших контор - там вообще есть все и на всех языках. А еще есть конкурирующие внутренние подразделения :)
Ну тогда ваш оппонент тем более прав. И вы что-то не видите. Потому что иначе давно бы уже питон вытеснили.
В природе вообще все описывается колебательными процессами.
При низкой добротности все может за один цикл затухнуть экспоненциально. При высокой -- будет перекачка энергий.
https://studme.org/412961/meditsina/lisy_zaytsami_zhivut
Но все это не имеет ни малейшего отношения к исходной теме. Описаны недостатки питона, Вы можете сами все воспроизвести и проверить.
Основная слабость этой публикации - манипуляция.
> ООП и DS плохо совместимы
Этот раздел причем к python? Сам по себе язык мультипарадигменный, а numpy убирает затраты памяти на дополнительную адресацию примитивных типов
> Недостаточность базовых типов данных
А есть прям существенная разница между built-in data-type и built-in library в этом случае? И опять же, numpy
> Векторизация
numpy
> Pandas
Пандас не для тех, кому нужна скорость работы, он для тех, кому нужна прототипизация. А тот вариант, который используется при скорости работы вы откинули. Ну да.
> Отсутствие полноценной конвейерной обработки (pipe)
Нечитаемость чего-то это субьетивщина. Я вот R считаю нечитаемым, потому что практически не имею с ним дело (как и вы с Python, похоже)
> Производительность
> Про практическую непригодность pandas для данных чуть больше небольших давно известно но старательно умалчивается.
> Про Dask, polars,… не говорим — это другая весовая категория и на подобные решения найдется масса альтернативных нейтральных ответов. Тот же Clickhouse.
А почему polars то внезапно out-of-scope? Сам по себе polars может быть практически drop-in заменой pandas
> Бенчмарки
Пакет для R нашли, а поискать подходящий пакет для python - это не судьба.
> Заключение
Вся статья - полная профанация. Реальное преимущество можно было бы показать, если бы вы сфокусировались на "standart r" и "standart python", но это в целом никого не интересует
питон изначально объекто ориентированный, он так проектировался. почитайте базовые типы. Все есть объект, народ это постоянно разжевывает, например: https://www.pythonmorsels.com/everything-is-an-object/
почитайте про пайпы по приведенным сслыкам. перенос по точке в питоне -- это просто костыль через форматирование.
разница между базовыми типами и суррогатами огромная. почитайте ссылки про missing data, например
в R и прототипирование и скорость и компактность можно получить одним махом в
data.tableприведите аналогичный пакет для бенчмарка -- это будет ответ.
Polars -- слизан с `apache arrow` который сам по себе хорош и универсален. И он не может заменить пандас целиком.
Да, и для решения этой проблемы у вас есть numpy. Или массив с методами это тоже катастрофа?
Я читал про пайпы, я знаю про пайпы, я использовал пайпы в linux. Да, они удобные, да с форматированем выглядит не так классно. Но это субьетивная оценка про "нечитаемость". Нечитаемость чего-то всегда субьективна.
Опять же, для аналитики в рамках numpy это решено, нет?
Это аргумент для "standart R"
Хороший вопрос, надо будет найти. Я то не из DS
Так-то он не слизан, а "обертка". И почему он не может pandas заменить? Я не эксперт, но беглым взглядом вроде почти все есть. Часть можно дописать через стандартные функции
питон изначально объекто ориентированный, он так проектировался. почитайте базовые типы. Все есть объект, народ это постоянно разжевывает, например: https://www.pythonmorsels.com/everything-is-an-object/
питон изначально объекто ориентированный, он так проектировался. почитайте базовые типы. Все есть объект, народ это постоянно разжевывает, например: https://www.pythonmorsels.com/everything-is-an-object/
Питон отличный язык, тут нет вопросов. Но вот применительно к DS задачам -- масса неудобств. Они реально неудобства, но пока в детали не погрузишься, все кажется простым и надуманным.
Мне, правда, не хочется ни оставлять серьезные вопросы без ответа, ни разводить холивар. Очень-очень много специфики выплывает на микроуровне.
А бесконечная сумма малых величин дает значимый дефект. Приходите в группу в телеграм, если интересно. DS аналитики действительно другими вопросами и категориями мыслят.
Опять же, я не спорю с этим фактом. Вполне логично ожидать, что язык, который разрабатывался для задач аналитики, будет для них удобнее.
Но мне показалось, что статье немного не про это. Ведь если писать про это, то сразу возникает вопрос "ага, а для чего тогда R менее удобен", ответ на который, скорее всего, вернет нас к тому, что проблема не в информировании.
Из личного опыта. В R я вляпался поле Python потому, что новые коллеги пишут на нем. Было больно, но через полгода я акклиматизировался. Сейчас мне очень нравится связка tideverse + ggplot для анализа данных. Но, в то же время, чтобы обучить нейросеть, первый пункт это - установить библиотеку, чтобы вызывать Python! Не костыль, а прямо-таки забор!
Не знаю о какой именно нейросети идет речь, но в R нынче подвезено почти все и многое нативно.
Еще такая штука есть: https://www.tidymodels.org/
И через reticulate python код сосуществует вперемешку с R-овским в одном ноутбуке
Вот он, reticulate, мне и не нравится совсем. По факту, вся работа с tensorflow идет через него и через Python. А tidymodels просто делает это удобным https://www.tidymodels.org/learn/models/parsnip-nnet/. Вот тут https://torch.mlverse.org/ люди портируют PyTorch под R без Python-а в середине, но им еще много работать...
люди портируют PyTorch под R без Python-а в середине
делают интерфейс в R для libtorch, с ней же и PyTorch работает
Если еще важный момент. Как быстро и дорого заменить человека на питоне и на R? И это во многом является решающим фактором.
из практики 1-1.5 мес достаточно для уверенного старта.
Это джун. Актуальны спецы уровнем минимум пару лет. Сколько таких на рынке? Какая у них ЗП. За сколько найдется спец? Если переучивать, Какая вероятность, что кто то захочет переучиваться. Сколько других вакансий на R. Смотрите более масштабно.
Давайте не переходить рубикон и не переходить на личности. Начинают сыпаться вопросы министерского уровня, если не выше.
Это ни в коем случае не оскорбления. Это прямые вопросы, которые должен учитывать лид\продакт при старте проекта. Отсюда и проблема, что выбирают не всегда лучшее техничесское решение. А наиболее удобное и дешевое решение в поддержке.
Много лет играю в тендеры всякие. В зависимости от матрицы приоритетов и методики оценки и рисков в т.ч. возможна любая степень вариативности результата.
Но вопросы применительно к проектной активности важные. Но именно здесь я сфокусировался на технике, оценочная часть в 90% случаев оставляет сильный осадок субъективности. Это не только про ЯП и даже далеко не про них.
Не хотелось сейчас туда залезать, да и предпосылок нет.
может просто потому, что низкий барьер входа в Python? мм ?
далее популярность растет...
PS крещение Руси помните?
нет низкого порога, он везде одинаков и минимально таков:
- изучение базовых типов;
- изучение конструкций языка;
- изучение типовых операций и подходов для решаемых задач.
если и из этого сделать "брифли", то ценность такого специалиста вызывает большие сомнения.
ну ок. А популярность откуда?
Hidden text
Ну Вы вопросы задаете...
Это ж кого спрашивать и как считать.
И питон надо разделять. Отдельно для DS страту вытягивать.
По приведенным в публикации фактам и тезисам у Вас вопросы есть?
А то задаете мне какие-то отстраненные вопросы как гуглу.
Люди, работающие с R, должны знать статистику, а люди, знающие статистику, должны знать, что то, чем вы занимаетесь в этой статье называется систематической ошибкой отбора.
Вы отобрали примеры, когда R лучше Python, проигнорировав случаи где все наоборот, и, никак не учли актуальность ваших примеров.
Приведу только один пример, который для меня является решающим в выборе R vs Python. 99% нейросетевого коммюнити использует Python, и, работая с R, исследователь оказывается в изоляции, не может использовать код из свежих (и не очень свежих) статей, и, имеет огромные проблемы при взаимодействии с коллегами.
Вовсе нет.
Я же писал в ответах, что в рамках одного ноутбука можно запускать куски кода и на R и на SQL и на python. Ставится питон (желательно чистый, без анаконд), ставятся через pip пакеты и пишется микс без проблем, если надо.
Правда, нет никаких проблем. Нет ИЛИ, есть И.
И Apache Arrow как средство межплатформенного обмена.
А в тексте фокус на самых базовых вещах, фундаменте любых преобразований.
Как-то странно сравнивать специализированный язык (R) с языком общего назначения (Python).
Есть набор датасетов, который вполне может быть размером 50-80% RAM.
Применительно же к простым прямоугольным данным введение прослойки в ООП на ровном месте увеличивает накладные расходы на CPU и RAM, иногда до неприемлемых масштабов.
Память дешевая, а время дорогое. Оверхэд ООП незаметен на фоне того, сколько памяти сжирается при распараллеливании вычислений путем запуска нескольких экземпляров интерпретатора R.
В R все прекрасно. С версии 4.1 даже есть нативный пайп |>, встроенный в синтаксис языка. Но давно существующий пакет magrittr обладает широким спектром различных пайпов и позволяет очень элегантно и компактно проводить сложные расчеты. Код при этом становится предельно понятным даже при беглом взгляде.
На мой взгляд, пайпы превращают R в write-only language. Пару раз доводилось срочно исправлять чужой код с пайпами (там и без них можно было голову сломать из-за сложности обработки), с тех пор заворачивал такое во время ревью.
IMHO как писали выше - дело в том, что python общего назначения + cython + c/c++. Ну и общее назначение вплоть до всякой дичи через win32com. Ну и не понятно, почему всякие прибамбасы типа dask не учитываются.
А почему он, а не я?
Суть статьи в одном предложении. Если выбрали Python, тогда, просто возможно, людям так удобнее?
Анализ данных в Питоне - это далеко не только pandas. Лично я ей не пользуюсь.
Согласен, что ФП гораздо ближе к анализу данных, чем ООП. Хотя объекты со многими атрибутами удобны для объединения данных (собственно, точка - это когда 3 числа, а не 3 элемента разных векторов).
Питон просто очень удобный и гибкий язык. ФП и ООП, а также обычное императивное программирование (да, есть языки, где с ним сложновато) в нём представлены.
Я ранее писал про свой фреймворк для анализа данных на Питоне, если интересно: https://habr.com/ru/post/490518/ Он использует ленивые вычисления, может работать в PyPy (в этом смысле оптимизирован) и более высокоуровневый, чем С++ (но если нужна не гибкость, а скорость, то я пишу на С++ также).
А в реальной вселенной вся гражданская аналитика использует Excel...
Как кто-то метко пошутил: "Python - лучший язык №2 для чего угодно".
Что на практике выливается в то, что владея R - ты великолепный статист, но владея Python - ты чуть менее великолепный статист, но при этом ещё и программист общего назначения. Что лучше сказывается на зарплате и карьерных перспективах. Нишевые языки всегда будут лучше Python'а в своих нишах. Но змей от того и толстый, что подъедает за всеми ними недоеденное.
О, неоднократно ломалась на повторных именах фрейма и индексах, тут люто плюсую, спасибо автору, что показали питон трезвого человека
Правда ведь так проще и понятее?
df[val < 0.5 | val2 == 7]
Не очень. Потому что в таком коде нужно держать в голове, откуда имена — из таблицы или же из моих переменных — и такой код хрупок по отношению к переименовыванию колонок. Шило на мыло, если честно.
Очень даже "очень". Аргумент что это может быть переменная вообще лишен смысла в контексте этой строчки кода
Генрих дело говорит.
Хардкодить что?
0.5? Так может это абсолютная величина, определяемая алгоритом.
И второй вариант тоже можно.
Классическим разрабам и инфраструктурщикам это все может быть странным, но в дата мире правила совсем другие.
Разработчикам и инфраструктурщикам это все понять сложно. Тут надо в бизнесе разбираться, мат. модели придумывать и задачи решать с тем, что есть на руках, а не полосатой палочкой потоками управлять или какие-то модельки на каком-то хгбусте как-то тренировать.
Мысль не ясна. Вы правда хотите что-то из этого узнать, или так... просто для приличия спрашиваете. Или для того, чтобы попытаться задать другой "хитрый вопросик"? Ваша карма 0хE1 -- круто, но мне не нравится что на вполне корректные ответы лепите минусы. Хотя и ++ и haskel у вас в обойме. Похоже, что эффект из https://habr.com/ru/post/497114/.
Есть масса механизмов что да как, но это надо погружаться в детали. Механизм иерархии окружений и лукапа переменных по дереву. Есть интерес -- будут ответы. Зачем свысока смотреть, здесь написано то, что написано. А что осталось за скобками -- не для публичных бесед, они только фейспалм вызывают.
Я бы предпочёл не ругаться. Радости не доставляет, правда. Если действительно интересно, то могу детально пояснить. В глубине не все просто и очевидно.
Но реально удобнее в телеграме, в группе или peer-to-peer. Полагаю, стригальщики большинство вопросов смогу дать ответ. Если есть сомнения — поглядите прошлые публикации.
не лишён смысла в контексте этой строчки кода , так как переменные там вполне могут быть.
То что вполне могут у Вас быть это понятно, я писал о том что конкретно в строке df[val < 0.5 | val2 == 7] нет никаких неопределенных ситуаций, val и val2 не могут быть переменными иначе фильтрация не имеет смысла.
Только теперь непонятно, что в выражении
df[val < threshold]— переменная, а что — кусок датафрейма.
Для кого не понятно? Для автора кода который сам задекларировал threshold ? Если val не в списке переменных окружения то явно что это из датафрейма. Для код-ревьювера? Если есть практика ревьювить в команде (где это кому-то не понятно) - значит в таких командах есть и правила написания кода. В таком случае никто не мешает писать код как "деды на R в универах" или питонисты:
df[df$val < threshold]Hidden text
(надеюсь знаком $ вместо "." не задел тонкую душевную натуру какого-нибудь питон-снобиста, если так - будет новый повод обсудить какого цвета фломастеры вкуснее)
На самом деле когда у тебя в скрипте 200+ строк кода и на каждый шаг обработки надо раз 5 повторить название фрейма перед каждым столбцом - начинаешь ценить возможность писать более лаконичный код.
Тут тоже не понятно что имел в виду автор коммента:
и такой код хрупок по отношению к переименовыванию колонок.
А что питоновкий код становится мегазащищенным при переименовании колонок при явном написании датафрейма?
Ключевые слова:
Non-standard evaluation, environment hierarchy, variable lookup.
Lisp quote/unquote.
Там найдете ответы на более сложные случаи.
А про сортировку -- странный абстрактный вопрос. Если требуется получить n-ый по магнитуде элемент массива -- Вы что делаете при этом? Многие вещи на поверхности кажутся странными по причине неглубокого погружения. Все ссылки в тексте есть.
Ассерты Вам в помощь.
Добро пожаловать в data-driven мир.
Никаких контрактов и обязательств.
Если могут подвести -- подведут.
Если не могут -- все равно подведут.
Дело в том, что с данными надо мыслить совсем иначе.
И код строить на других принципах.
На практике такой код работает более чем стабильно и надежно.
Надо только понимать, что делаешь и какую задачу решаешь.
И неплохо иметь опыт промышленной разработки, чтобы понимать все плюсы, минусы и последствия своего кода.
А джун он везде джун -- лепит антипаттерны и косяки и даже не понимает этого.
У него ничего не триггернет написать `SELECT *`.
Наставник ему нужен долгое время.
Прочитала статью по диагонали.
Считаю, что цель данной статьи - дезориентация в пространстве, навязывание своего мнения и попытка отгородить специалистов в данной области от своей вакансии, дабы крепче держаться на месте.
Но крепче держаться не получится, мир изменился и темпы освоения информации выросли как и требования к специалистам (одного инструмента для работы недостаточно).
А с того момента, где в комментариях написано, что в ВУЗах (да ещё в каких) проблема с кадрами, можно вообще прекращать читать, теряется адекватность полностью.
Кто за всех решил, что python удобен для «гражданской» аналитики?