Comments 33
Python — замечательная штука, да и вообще все уже придумано до нас :), но
- Абстрактно все сферические кони хороши. Преимущества и недостатки всегда рассматривают в контексте.
- Если речь идет о комплексном DS приложении, которое должно еще и предоставлять результаты простым пользователям в виде дашбордов, приложений, отчетов, hard-copy артефактов, то наличие Shiny начинает сильно перевешивать.
- Результат работы "поверхностно знакомых" специалистов, как правило, весьма посредственный. Программирование лишь частный случай. Настоящих профессионалов в любом деле всегда мало.
- Куча библиотек — это просто куча битов и байтов, до тех пор, пока на собственном опыте не наберешь шишки и не поймешь, что хорошо, что плохо и как это использовать. Наличие нескольких сетей фитнес-центров никак не сказывается на физической форме отдыхающих на диване. Кстати, аналогов stringi\stringr в python я пока не нашел. Может, конечно, не достаточно сильно искал...
- Никто и не говорит, что Python плохой. Это отличный язык и я с удовольствием периодически его использую с 2006 года. Речь о том, что R сильно недооценен в России. Хорошо знать один язык. А два — лучше.
Да, насчет Питона в DS был еще тот холивар, вот на сейчас точно уже не скажу, закончился ли он или где-то еще есть засады. Надоело находится в ожидании "вот-вот" все случится.
На протяжении нескольких лет камнем преткновения являлся вопрос портирования DS библиотек с 2.7 на 3.x.
Появлялись посты типа такого: "Will Scientists Ever Move to Python 3?" и сайты типа такого: "Python 3 Readiness".
И если обычные разработчики активно переходили на 3.x ветку и пользовались всеми новыми фичами, то DS до последнего держалась за 2.7.
При этом все понимали, что с переходом на 3.x придется от многих привычек отвыкать и переучиваться. Мрачное ощущение тратить время и силы на изучение и работу с инструментом дни которого сочтены и дата окончания задекларирована.
Другим плюсом является прозрачная интеграция C++ кода, что для нас крайне важно.
Сейчас уже думаем о переносе на R других проектов, правда, немного смущает некоторая неоднозначность синтаксиса самого языка и возможность появления обусловленных этим ошибок.
Если что-то смущает, можно обсудить и обменяться возможными вариантами решения. Скайп/телеграм/почта.
Это всегда полезно. И потому что помогает расширить community и потому что может привести к необходимости поиска ответа, переосмыслению устоявшихся ранее подходов.
На текущий момент мы постоянно смотрим новую информацию по пакетам R, интересные методики и реализации. Если что-то появляется интересное и более эффективное, проверяем и без жалости выкидываем старое. Из последних интересных перемещений (в ряде задач) с saveRDS/readRDS на http://www.fstpackage.org/
- В самом начале публикаций давал пояснение, почему мы перешли на R. Ничего с того момента не изменилось.
- Я не говорю об отдельных графиках, речь идет про полноценное приложение. С таблицами, закладками, элементами управления, контекстным drill-down, генерацией всевозможных всеформатных выгрузок, интеграцией с кучей внешних систем. Например, как описано в прошлой статье.
- Про stringi\stringr в картинках можно посмотреть здесь. Насчет графики — я подходил несколько раз к matplotlib аж с 2008, и все разы он не дотягивал до требований, приходилось откладывать. А функционал и семантика ggplot позволяет рисовать почти любые графики, какие только пользователям взбредут в голову. Приходится их просить не сдерживать себя в фантазиях :) А то, кроме кружочков ничего придумать не могут.
Артем, в смысле "нас" двое? Нет, много больше :)
Может, я не прав, но, как по мне, то программисты довольно консервативны. Особенно те, что работают в поддержке крупных компаний. Если у них есть некий отлаженный процесс, сформировавшийся набор используемых заготовок и билиотек, то сложно будет заставить все переделать на некой новой платформе. А подавляющей доле экономистов и аналитиков, практически, нечего терять кроме Экселя.
По моему опыту, там вообще вся эта тема фиолетова. Там надо говорить об исполнении плана, марже, воронке продаж, клиентах, соблюдению KPI и РЕЗУЛЬТАТАХ (иногда никто не знает, как они должны выглядеть, но они обязательно должны быть).
Движение снизу гораздо интереснее. Тем более, что специалист, который ничего нового не изучает и по сторонам не смотрит в один прекрасный день останется на обочине. Видел такие примеры тотальной неожиданной дисквалификации среди разработчиков. И это не "привилегия" разработчика, это касается множества обычных профессий, таких как, парикмахер, стоматолог, учитель, автомеханик и многие другие.
В такой форме комментария я 100% соглашусь. У меня именно таких примеров есть некоторое количество. Я ровно с этой целью и трачу время на публикации, чтобы заинтересованные люди могли ознакомиться с интересными возможностями, увидеть, что задачи решаются, причем решаются весьма элегантно и попробовать самим применить. А дальше уже как раз по сценарию внутренних коммуникаций в своей компании. Ведь неизвестному человеку извне весьма сложно пробиться к финансовым сотрудниками крупного холдинга :).
А бизнес, все-таки, интересует только результат. Демонстрация решения именно их задач на именно их данных — ключевой момент. Все остальное — пустой звук и игры разума.
Я совсем не специалист по R (от слова вообще), но за последний год он не раз и не два помогал мне в NLP и оценки алгоритмов для ML. Для моих крайне нетребовательных по скорости задач, R мне показался наиболее лаконичным и простым языком. Жаль, что ру—коммьюнити очень не большое. Доки с CRAN конечно читаю, но все равно 99% провожу на SO.
Поскольку стек у нас чуть больше, тут и go\python\Clickhouse\реляционные БД\JS+CSS+HTML, то, в зависимости от проекта, получается вовлеченными 4-6 человек разработчиков. На R получается 1-3 в зависимости от масштаба. И обязательно нужны люди, владеющие предметной областью. Сами shiny приложения получаются весьма компактными. При избыточном коде — вынос излишков в пакеты\функции и тотальное обкладывание автотестами и ассертами. Если возникают нюансы с пакетами — общаемся через github c разработчиками. Очень ждем выхода в продуктив асинхронных функций в shiny: An informal intro to async Shiny by Joe Cheng
При избыточном коде — вынос излишков в пакеты\функции и тотальное обкладывание автотестами и ассертами.
А вы не могли бы поделиться вашим опытом? Какой код уже можно назвать избыточным, чтобы начать выносить функции в зависимости/пакеты?
тут флейм получится, проще по почте\скайпу. да и на код надо глядеть.
грубо, использую 3 критерия:
- любой код > 1 экрана лучше посмотреть на предмет поджимания (вынос частей в функции\ применение функционального подхода);
- повторный блок copy-paste — претендент на функцию;
- чуть измененный copy-paste — претендент на параметризацию и свертку в функцию;
Использование R для «промышленной» разработки