Pull to refresh

Comments 14

Кстати, всегда удивлялся, почему люди, которые рассказывают нам о том, как миру нужны [профессиянейм], сами занимаются популяризацией/преподаванием/лекциями, а не [профессиянейм]
А, увидел рекламу курсов и все стало ясно
Всегда удивлялся, как люди комментируют, не вникнув в суть. Я работаю data engineer'ом уже несколько лет, если что. И в тексте об этом прямо написано несколько раз.
Код на Java, но все равно очень полезно

Как будто в этом что-то плохое
Вовсе нет, просто я больше из лагеря Scala :) Это чистая вкусовщина, имхо, многострочные классы на старой версии джавы читать в книжке как-то уж очень неудобно.

Не очень понял чем Вам R не угодил? Откуда такая брезгливость?

Это не совсем брезгливость. R — неплохой язык, когда на коленке надо поиграть с данными и немного их поанализировать. Но это если ты аналитик, проходишь курсы или работаешь только в академической среде.

Проблема R в том, что к продакшену он отношения не имеет, с точки зрения инженера это какой-то неявный вырвиглазный DSL, 95% функционала которого уже давно перенесено в библиотеки в Python. И в большинстве случаев боевая система будет именно на Python, поэтому R там делать особо нечего. Единственная ниша — крайне редкие экзотические модели, которые до сих пор не перенесли.
Она работоспособна в принципе, но, по моему личному мнению, нет смысла использовать крайне специфический узкоспециализированный язык в сфере, в которой Python справляется не хуже. И для бизнеса нет ничего хорошего в завязке на R, разве что у них есть постоянный источник качественных академических кадров, которые на нем пишут.
Такое — это частные примеры решения задач, которые в большинстве своем сделаны людьми из академической среды, не программирующими на промышленных языках.

Артем, со всей очевидностью, это утверждение не имеет железобетонной аргументации. Будучи автором упомянутых статей уточню несколько деталей, чтобы внести ясность:


  1. Не знаю, какие именно промышленные языки подразумеваются и при чем они в контексте конкретных задач. В целом, у нас в команде используются C++, Erlang, Go, Java, JS, Python, R. Опыт успешного использования измеряется десятками лет. Но в тегах про R упоминаются только задачи для R, что логично.
  2. Промышленные языки (C++, Java) хороши для разработки фундаментального или коробочного ПО. Для бизнес-задач, которые локальны, изменчивы (контекст постоянно "плывет") и связаны с анализом всевозможных "грязных" данных R и Python подходят оптимально. Интересная публикация, если что: What are the Most Disliked Programming Languages?. Если речь идёт ещё и о создании различных АРМ-ов для обычных бизнес-пользователей, то тут Python-у приходится не очень сладко.
  3. В целом, в бизнес сегменте основным трендом является как раз наличие множества различных частных задач. В этих задачах нет стройной структуры, присущей как промышленной разработке, так и академической среде. Но 80% таких задачек и являются отображением реального бизнеса на цифровую матрицу.
    EARL 2017 явно это демонстрирует.
  4. Большие данные не всегда являются свидетельством "белой стороны". Во многих случаях они возникают из-за непонимания сути задач, которые нужно решать, поэтому пытаются собирать всё и вся на всякий случай. Однако, классическая методика проведения эксперимента (физика, химия, биология, ...) подразумевает наличие теории, которая проверяется этим экспериментом. Из теории ясно вытекает, что нужно измерять, как много измерений может потребоваться, какие диапазоны надо проверять, что отсекать. Сам по себе абстрактный эксперимент, без теории, имеет нулевую пользу. Есть хорошее высказывание, что академику Павлову для своей теории не требовалось несколько миллионов собак, ему хватило сорока. Но если действительно требуется собирать и обрабатывать петабайты, то и для этого этого тоже есть различные инструменты.

Что касается Python, то это прекрасный язык. Но он:


  1. отнюдь не универсален;
  2. не совсем промышленный. Элементарная попытка задеплоить интегрированное в корпоративный ландшафт python решение на версии, старше той, которая есть в дистрибутивах *nix (в enterprise это обычно RHEL) в условиях полной изоляции от интернета и ограниченном наборе инструментов, в т.ч. запрещено использование докера (обычная ситуация в enterprise сегменте, обусловленная политикой безопасности) требует наличие нескольких бубнов и хотя бы одного шамана. Как пример, в Go можно притащить один exe и не иметь головной боли.
пишу на R, делаю модель.
Лог регрессию или дерево решение конвертирую в sql запрос и ставлю на продуктив в БД.
модели на кластер строю и запускаю с помощью sparklyR
problems?
Sign up to leave a comment.