Comments 22
Питон в целом лучше для ml, cv, nlp, big data задач ну и кучи всего остального, прикладного.
R больше для академической среды, где ты написал программулинку, построил график, выпустил статью и был таков (в плане, что код не нужно поддерживать).
Для контраста можно на R что-нить тоже несвойственное выложить - телеграм-бота или тетрис. И вот тогда окажется что все "доводы - контрасты" - так себе. И R, и Pandas очень близки и делают одно и то же, одинаково бесплатно. Но один падает, другой растет.
Пока как-то ни разу не убедительно. Может, дальнейшие примеры реально что-то покажут, но пока ни одного такого примера, где в питоне было бы прям криво, а где-то в другом языке прям хорошо, я не увидел.
С R не знаком, с Python работаю каждый день. Вскоре появится нужда научить жену азам предобработки и агрегации данных. И вот посмотрев на этот один пример, будто бы синтаксису R будет проще обучить человека, который даже SQL не знает.
Про плюсы python уже пару человек тут высказали главное.
Я понимаю, что это перевод, и автор не узнает моего и так нахрен никому не интересного мнения. Нельзя так писать, вбросил и "на этом пока закончу".
Примеры на R+tidyverse и Python+pandas не особо отличаются визуально, и надо понимать, что отсутствие кавычек и скобочек в R работает благодаря такой фишке как метапрограммирование (напоминает lisp-макросы). Вам повезло, если у вас что-то простое и оно работает, а вот если надо разобраться, почему оно не работает - удачи, я не осилил, проще переписать совсем другим способом.
Мне кажется, хорошими языками для data science были бы Scheme или OCaml.
R и python разные вещи, абсолютно и по назначению и по широте применения и по гибкости, R только под одну задачу в институте.
В нашем институте биологи тоже используют R.) Интересно, это просто так совпало или просто биологи его любят с давних пор?
Можно взять другую библиотеку (polars) и разница с R будет минимальна и читаема.
import polars as pl
from palmerpenguins import load_penguins
penguins = pl.from_pandas(load_penguins())
result = (
penguins
.drop_nulls(subset=["body_mass_g"])
.groupby(["species", "island"])
.agg(
body_weight_mean = pl.col("body_mass_g").mean(),
body_weight_sd = pl.col("body_mass_g").std(),
)
)
Спасибо, с вашим комментом пришло понимание, чем R удобнее: действительно, в R нет такого количества скобочек.
pipe - оператор "|>" упрощает сборку конвейера обработки данных, так как хорошо ложится в логику научного поиска, проб и ошибок.
Добавить новую операцию легко в любом месте цепочки конвеера, без необходимости контроля скобок глубины вложения функций, что было бы связано с возвратом в начало цепочки.
...но в R неудобные библиотеки создания интерактивных веб-приложений. Порты известных библиотек предоставляют ограниченное число переменных, что обедняет функциональность R в презентации результатов.
В Pandas конвейеры делают 3-мя способами:
внутри скобок ( )
с df.pipe()
сторонним инструментом (в sklearn, например)
Допускаю что R тут чуть-чуть читаемее. Но Python отыграется на списковых включениях, декораторах и др. мелком сахарке. Плюс DS-ник почти всегда свой ETL-конвейер в python оформляет как пакет/либу, с документацией, доктестами, CI/CD, контейнерами и вот этим вот всем. Экосистема Python выглядит тут гораздо более зрелой и массовой чем R, а размеры сообщества и число звезд на гитхабе и сравнивать нечего. Но, повторюсь, оба инструмента прекрасны.
но в R неудобные библиотеки создания интерактивных веб-приложений
Вы пробовали Shiny и она показалась вам неудобной?
Те результаты, которые можно получить в Shiny, визуально отталкивающие, базовые, удручающе несовременные. Сделать страничку широкодоступной можно на платном сервере, что ограничивает студенческий или исследовательский эксперимент.
Я также работаю с библиотеками Leaflet, Plotly, GGraph, визуализируя карты и графики, так получается неплохая и презентабельная интерактивность, но в них беда: в R для этих инструментов доступно весьма ограниченное число настроек, не позволяющее реализовать те замыслы, которые в базовых библиотеках легко доступны. И идеологии разные, зоопарк.
Сделать страничку широкодоступной можно на платном сервере, что ограничивает студенческий или исследовательский эксперимент.
Вы точно с Shiny работали? На https://www.shinyapps.io/ можно бесплатно размещать, если что-то небольшое. Если большое - то берете свой хостинг и ShinyServer - он opensource. Если еще более продвинутое, с контейнеризацией, то ShinyProxy. Есть еще вариант с ShinyLive - когда все ваше приложение исполняется на wasm-runtime в браузере пользователя. И хостить надо просто статику, то есть достаточно гитхаба. Визуально кастомизировать Shiny приложения можно практически неограниченно.
Насчет leaflet и plotly - не знаю, что у вас было ограниченно. Но javascript по логике ближе к R, чем к Питону и, на мой взгляд, взаимодействие было логичней.
Не знаю python, но очень интересно, как работает agg ? У меня есть такая гипотеза: внутри agg используется синтаксис с именованными параметрами, а p.col("...").mean() - это не значение, а функция, в которую внутри agg будет передан сам dataframe, из которого оно уже извлечёт столбец и посчитает значение. Получается, что у agg неспецифицированы параметры, они всегда должны быть именованными, и она сама разбирает, что за параметры ей были переданы. Не очень понятно только, зачем скобки.
Вода. Много воды. Примеры неубедительные. Можно было подвергнуть критике
Ужасную документацию. Серьезно. У какой-то ноунейм библиотеки на java например для работы с exel документация в 100 раз лучше, чем у python-библиотек. Приходится лезть на гитхаб, открывать код, спускаться сквозь кучу слоев абстракции предоставляемого API, чтобы понять а что же делает этот код и какие данные на вход ожидает.
Проблем с документацией добавляет kwargs. Потому что что? Фичу добавили, а в доки параметр не прописали. Оно и понятно, если функция/метод вызывает функцию, передавая ей kwargs, а та тоже вызывает функцию, тоже передавая kwargs, то это ж везде надо дублировать доку на каждый ключ словаря. Почему в языках без kwargs такой проблемы нет? А какую проблему kwargs решает? - Проблему гиганстких сигнатур методов (пришлось бы все аргументы явно перечислять для всех функций в цепочке вызовов). А как решают в других языках эту проблему? Создают отдельных класс с полями. Всё. Задокументировал только этот класс и нет проблем. Добавил потом поле, фичу в функцию и доку для поля 1 раз. Всё.
Предоставление конвейерной обработки данных строго за счет библиотек и у каждой по своему (несовместимо с другими библиотеками, так что приходится добавлять адаптеры).
Из предыдущего пункта плавно вытекает плохая встроенная в язык реализация ФП (имхо удобнее для анализа данных)
Отсуствие нормальной поддержки аннотаций типов для библиотек. Там все еще изобилует нетипизированный код. Статическая типизация и борьба с компилятором - это конечно боль для людей которым нужно просто писать бизнеслогику и запускать интерактивно код, но типизация помогает искать и исключать ошибки. И когда добавили аннотации в Python для удобства разработчика, а не компьютера - это было круто. Но некруто когда спустя много лет, mypy бессилен с проверкаами на типы кода вызывающего библиотечные функции.
Нейминг порой убивает. Вроде snake_style, но startswith, tolist и т д.
Что еще (помимо R и Matlab) могло бы стать лучшим инструментом для анализа данных, если бы было более популярным (и потому с большим числом готовых решений и устоявшихся библиотек):
Ruby (лучшая поддержка ООП)
Scala Spark (типизация, ФП)
Julia (скорость, типизация)
Jupyter кстати поддерживает эти языки. А у Julia есть своя альтернатива в виде Pluto. Но как по мне, у Julia пока полный хаос с библиотеками (много маленьких, часто долго приходится выбирать нужную).
Но некруто когда спустя много лет, mypy бессилен с проверкаами на типы кода вызывающего библиотечные функции.
Гляньте на https://github.com/python/typeshed , там есть типизация для библиотек в которых типы не добавлены авторами.
R прекрасен для анализа данных, переход на Python после R - это как с феррари пересесть на ладу. Но денег в R нет, поэтому он умер. RStudio теперь занимается разработкой пакетов для Python. Так что помянем.
Почему Python — не лучший язык для data science. Часть 1 — опыт разработчика и исследователя