У начинающего специалиста по данным (data scientist) есть возможность выбрать один из множества языков программирования, который поможет ему быстрее освоить данную науку.
Тем не менее, никто точно не скажет вам, какой язык программирования лучше всего подходит для этой цели. Ваш успех как специалиста в данной области будет зависить от множества факторов и сегодня мы постараемся их рассмотреть, а в конце статьи вы сможете проголосовать за тот язык программирования, который вы считаете наиболее подходящим для работы с данными.
Специфичность
Будьте готовы к тому, что по мере углубления в область науки о данных, вам раз за разом прийдется заново «изобретать велосипед». Кроме того, вам необходимо будет в совершенстве овладеть различными пакетами программ и модулями для выбранного вами языка программирования. Насколько хорошо вы сможете все это усвоить, зависит, в первую очередь, от наличия предметно-ориентированных пакетов программ для выбранного ЯП.
Универсальность
Ведущий специалист по данным обладает хорошими всесторонними навыками программирования, а также умением проводить расчеты и анализировать. Большая часть повседневной работы в области науки о данных направлена на поиск и обработку исходных данных или корректировку данных. К сожалению, никакие новороченные пакеты для машинного обучения вам не помогут для данных целей.
Эффективность
В быстро развивающемся мире коммерческой науки о данных есть множество возможностей быстро получить желаемую работу. Тем не менее, именно благодаря быстрому развитию области науки о данных ее постоянно сопровождают технические недароботки, и только упорная практика сможет свести к минимуму такие недочеты.
Производительность
В некоторых случаях очень важно оптимизировать производительность вашего кода, тем более при работе с большими объемами особо важных данных. Однако скомпилированные языки обычно намного быстрее, чем интерпретируемые. Аналогично, статически типизированные языки значительно более отказоустойчивы, чем динамически типизированные. Таким образом, единственным компромиссом является снижение производительности.
В некоторой степени, каждый из представленных ниже языков программирования обладает одним параметром в каждой из двух групп: универсальность — специфичность; производительность — удобство.
Учитывая эти основные принципы, давайте рассмотрим некоторые из наиболее популярных языков программирования, которые используются в науке о данных. Вся информация, о приведенных ниже языках программирования, основывается на моих собственных наблюдениях и опыте, а также опыте моих друзей и коллег.
R
R, который является прямым потомком старшего языка программирования S, был выпущен в далеком 1995 году и с тех пор становится все совершеннее. Написанный на таких языках как C и Fortran данный проект сегодня поддерживается Фондом языка R для статистических вычислений (R Foundation for Statistical Computing).
Лицензия:
Бесплатная
Преимущества:
- Отличный набор высококачественных предметно-ориентированных пакетов с открытым исходным кодом. R имеет в своем распоряжении пакеты практически для любого количественного и статистического применения, которое можно только себе представить. Сюда входят нейронные сети, нелинейная регрессия, филогенетика, построение сложных диаграмм, графиков и многое-многое другое.
- Вместе с базовой установкой в довесок нам предоставляется возможность установки обширных встроенных функций и методов. Кроме того, R прекрасно обрабатывает данные матричной алгебры.
- Возможность визуализации данных является немаловажным преимуществом наряду с возможностью использования различных библиотек, например ggplot2.
Недостатки:
- Низкая производительность. Здесь нечего сказать: R не является быстрым ЯП.
- Специфичность. R прекрасно подходит для статистических исследований и науки о данных, но он не так хорош, когда дело доходит до программирования для общих целей.
- Другие особенности. R имеет несколько необычных особенностей, которые могут сбить с толку программистов, привыкших работать с другими ЯП: индексирование начинается с 1, использование нескольких операторов присваивания, нетрадиционные структуры данных.
Наш вердикт – идеальный вариант для первоначальных целей
R – мощный язык, который отличается наличием огромного выбора приложений для сбора статистических данных и визуализации данных, а тот факт, что он является ЯП с открытым исходным кодом, позволяет ему собрать большое количество поклонников среди разработчиков. Именно благодаря своей эффективности для первоначальных целей этому языку программирования удалось достичь широкой популярности.
Python
В 1991 году Гвидо ван Россум представил язык программирования Python. С тех пор этот язык стал чрезвычайно популярным ЯП общего назначения и широко используется в сообществе специалистов по данным. В настоящее время основными версиями являются Python 3,6 и Python 2,7.
Лицензия:
Бесплатная
Преимущества:
- Python – это очень популярный, широко используемый язык программирования общего назначения. Он имеет обширный набор специально разработанных модулей и широко используется разработчиками. Многие онлайн-сервисы предоставляют API для Python.
- Python очень прост в изучении. Низкий порог вхождения делает его идеальным первым языком для тех, кто занимается программированием.
- Такие программные пакеты как pandas, scikit-learn и Tensorflow, делают Python надежным вариантом для современных приложений в области машинного обучения.
Недостатки:
- Типобезопасность. Python – это динамически типизированный язык, а это значит, что вы должны быть осторожными при работе с ним. Ошибки несоответствия типов (например, передача строки (string) в качестве аргумента методу, который ожидает целое число (integer)) могут время от времени случаться.
- Например, в случае если имеются конкретные цели статистического анализа и анализа данных, то обширный набор пакетов языка R дает ему преимущество перед Python. Кроме того, существуют более быстрые и безопасные альтернативы Python среди языков программирования.
Наш вердикт – удобен во всех отношениях
Python является хорошим вариантом для целей науки о данных (data science), и это утверждение справедливо как для начального, так и для продвинутого уровней работы в данной области. Большая часть науки о данных сосредоточена вокруг процесса ETL (извлечение-преобразование-загрузка). Эта особенность делает Python идеально подходящим для таких целей языком программирования. Библиотеки, такие как Tensorflow от Google, делают Python очень интересным языком для работы в области машинного обучения.
SQL
SQL («язык структурированных запросов») определяет, управляет и запрашивает реляционные базы данных. Язык появился в 1974 году и с тех пор претерпел множество видоизменений, но основные его принципы остаются неизменными.
Лицензия:
Есть бесплатные и платные варианты.
Преимущества
- Очень эффективен при работе с запросами, обновлениями, а также при обработке реляционных баз данных.
- Декларативный синтаксис делает SQL очень читаемым языком. Нет никакой неопределенности в том, что SELECT name FROM users WHERE age > 18 должен делать!
- SQL очень часто используется в различных приложениях, так что знакомство с ним может очень пригодиться. Модули, такие как SQLAlchemy, упрощают интеграцию SQL с другими языками.
Недостатки:
- Синтаксис SQL может показаться достаточно сложной задачей для тех, кто привык к императивному программированию.
- Существует множество различных вариаций SQL, таких как PostgreSQL, SQLite, MariaDB. Все они достаточно разные, поэтому ни о какой совместимости не может быть и речи.
Наш вердикт – эффективный, несмотря на время
SQL более полезен в качестве языка для обработки данных, чем в качестве передового аналитического инструмента. Тем не менее, так много процессов в области науки о данных зависит от ETL, а долговечность и эффективность SQL лишний раз свидетельствуют о том, что такой ЯП должен знать каждый специалист по данным (data scientist).
Java
Java – это чрезвычайно популярный язык общего назначения, который работает на виртуальной машине Java Virtual Machine (JVM). Это абстрактная вычислительная система, которая обеспечивает плавную переносимость между платформами. В настоящее время поддерживается корпорацией Oracle.
Лицензия:
8-я версия – бесплатная
Преимущества:
- Универсальность. Многие современные системы и приложения разработаны с помощью языка Java. Огромным преимуществом такого ЯП является способность интегрировать методы науки о данных непосредственно в существующую кодовую базу.
- Строгая типизация. Обеспечение типобезопасности не пустой звук для Java, и в случае разработки критически важных приложений для работы с большими данными эта особенность как никогда важна.
- Java – это высокопроизводительный, скомпилированный язык общего назначения. Это делает его пригодным для написания эффективного производственного кода ETL, а также алгоритмов машинного обучения с использованием вычислительных средств.
Недостатки:
- «Многословность» языка Java делает его не лучшим вариантом для проведения специальных анализов и разработки более специализированных статистических приложений.
- Java не имеет большого количества библиотек для передовых статистических методов по сравнению с некоторыми предметно-ориентированными языками, например R.
Наш вердикт — серьезный претендент на звание лучшего языка для работы в области науки о данных
Много чего можно сказать в пользу изучения Java как языка для работы в области науки о данных. Многие компании оценят возможность беспрепятственной интеграции готового кода программного продукта в собственную кодовую базу, а производительность и типобезопасность Java являются его неоспоримыми преимуществами. Тем не менее, к недостаткам такого языка можно отнести тот факт, что у него отсутствуют наборы специфических пакетов, которые доступны для других языков. Несмотря на такой недостаток, Java является языком программирования, которому обязательно стоит уделить внимание, особенно если вы уже знаете R или Python.
Scala
Функционирующий на JVM язык программирования Scala был разработан Мартином Одерски в 2004 году. Это язык с несколькими парадигмами, позволяющий использовать как объектно-ориентированные, так и функциональные подходы. Кроме того, структура кластерных вычислений Apache Spark написана на Scala.
Лицензия:
Бесплатная
Преимущества:
- Используя Scala и Spark, у вас появляется возможность работать с высокопроизводительными кластерными вычислениями. Scala – это идеальный выбор для тех, кто работает с большими объемами данных.
- Мультипарадигматический. Для программистов, работающих со Scala, доступны как объектно-ориентированные, так и функциональные парадигмы программирования.
- Scala компилируется в байт-код Java и работает на JVM. Это позволяет ему взаимодействовать с языком Java, делая Scala очень мощным языком общего назначения. Кроме того, он также хорошо подходит для работы в области науки о данных.
Недостатки:
- Если вы только-только собрались работать со Scala, то будьте готовы изрядно «поломать» голову. Лучше всего загрузить sbt и настроить IDE, например Eclipse или IntelliJ, с помощью специального плагина Scala.
- Есть мнение, что синтаксис и система типов Scala являются достаточно сложными. Таким образом, программистам, привыкшим работать с динамическими языками, например Python, придется несладко.
Наш вердикт – идеальный вариант для работы с большими данными
Если вы решили использовать кластерные вычисления для работы с большими данными, то пара Scala + Spark – это идеальное решение. Более того, если у вас уже есть опыт работы с Java и другими статически типизированными языками программирования, то вы непременно оцените эти возможности Scala. Однако, если ваше приложение не имеет ничего общего с большими объемами данных, работа с которыми может оправдать добавление всех составляющих Scala, вы, скорее всего, добьетесь большей производительности, используя другие языки, такие как R или Python.
Julia
Выпущенный чуть более 5 лет назад, Julia произвела впечатление на мир вычислительных методов. Язык добился такой популярности благодаря тому, что несколько крупных организаций, включая некоторые в финансовой отрасли, почти сразу начали использовать его для своих целей.
Лицензия:
Бесплатная
Преимущества:
- Julia – это скомпилированный язык JIT («точно в срок»), благодаря которому удается достичь хорошей производительности. Этот язык является достаточно простым, он предусматривает возможности динамической типизации и сценариев интерпретируемого языка, такого как Python.
- Julia был предназначен для проведения численного анализа, он также может рассматриваться в качестве языка программирования общего назначения.
- Читаемость. Многие программисты, работающие с данным языком, считают, что такая особенность является его наибольшим преимуществом.
Недостатки:
- Незрелость. Поскольку Julia является достаточно новым языком, некоторые разработчики сталкиваются с нестабильностью во время работы с его пакетами. Тем не менее, базовые средства языка считаются стабильными.
- Еще одним признаком незрелости языка является ограниченное количество пакетов программ, а также небольшое число поклонников среди разработчиков. В отличие от устоявшихся R и Python язык программирования Julia не располагает большим количеством пакетов программ (пока что).
Наш вердикт – язык, который себя еще проявит
Да, главная проблема языка Julia – это его молодость, однако его нельзя за это винить. Поскольку Julia был создан лишь недавно, он пока что не может конкурировать со своими основными конкурентами, Python и R. Будьте терпеливыми и вы поймете, что существует множество причин обратить пристальное внимание на этот язык, который, непременно, сделает выдающиеся шаги в ближайшем будущем.
MATLAB
MATLAB – это признанный язык для численных расчетов, используемый как в научных целях, так и в индустрии. Он был разработан и лицензирован MathWorks, компанией, созданной в 1984 году, основной целью которой являлось коммерциализация программного обеспечения.
Лицензия:
Цены варьируются в зависимости от выбранного вами варианта языка
Преимущества:
- MATLAB, предназначенный для численных вычислений, хорошо подходит для использования количественного анализа со сложными математическими требованиями, такими как обработка сигналов, преобразования Фурье, матричная алгебра и обработка изображений.
- Визуализация данных. MATLAB имеет ряд встроенных возможностей построения графиков и диаграмм.
- MATLAB часто можно встретить во многих курсах бакалавриата по точным наукам, таким как физика, инженерия и прикладная математика. Таким образом, он широко используется в этих областях.
Недостатки:
- Платная лицензия. Вне зависимости от выбранного вами варианта (для научных, личных целей или целей компании) вам придется раскошелиться на дорогостоящую лицензию. Наш совет: обратите внимание на бесплатную альтернативу – Octave.
- MATLAB – это не лучший язык программирования для общего назначения.
Наш вердикт – лучший вариант для целей, требующий значительных математических расчетов
Благодаря своему широкому использованию в различных количественных вычислениях как для научных целей, так и для целей индустрии, MATLAB стал достойным вариантом для применения в области науки о данных. Он прийдется вам как нельзя кстати, если для ваших ежедневных целей необходима интенсивная, продвинутая математическая функциональность, собственно, для чего MATLAB и был разработан.
Другие языки
Существуют и другие популярные ЯП, которые могут представлять интерес для специалистов по данным. В этом разделе представлен их краткий обзор.
C++
Зачастую, C++ не используется в области науки о данных. Тем не менее, он имеет молниеносную производительность и широкую популярность. Главной причиной, по которой C++ не обрел популярности в области науки о данных, является его неэффективность для такой цели.
Как написал один из участников форума:
«Предположим, что вы пишете код для проведения какого-либо специального анализа, который, вероятно, будет запускаться только один раз. Так вот, вы предпочли бы потратить 30 минут на создание программы, которая будет работать в течение 10 секунд или потратить 10 минут на программу, которая будет работать в течение 1 минуты?»
И этот парень прав! Тем не менее, C++ станет отличным выбором для реализации алгоритмов машинного обучения, оптимизированных на низком уровне.
Наш вердикт – не лучший выбор для повседневной работы, но если дело касается производительности...
JavaScript
Ввиду того, что за последние несколько лет платформа Node.js активно развивалась, язык программирования JavaScript все больше и больше обретал черты серверного языка. Однако его возможности в области науки о данных и машинного обучения на сегодняшний день достаточно скромны (тем не менее, не стоит забывать про brain.js и synaptic.js!). К недостаткам JavaScript можно отнести:
- Слишком рано для него, чтобы вступить в игру (Node.js всего 8 лет!)...
- Платформа Node.js и вправду быстрая, но всегда найдутся те, кто будет активно критиковать JavaScript.
К неоспоримым преимуществам Node.js можно отнести его асинхронный ввод-вывод, его растущую популярность, а также тот факт, что существует множество языков, которые компилируются с JavaScript. Так что вполне возможно, что в недалеком будущем мы увидим полезный фрейморк для работы в области науки о данных с возможностью обработки с помощью ETL в режиме реального времени. Другой вопрос: будет ли это актуально на то время…
Наш вердикт – предстоит еще много чего сделать, для того чтобы JavaScript считался достойным языком для работы в области науки о данных
Perl
Perl известен как «швейцарский армейский нож языков программирования» из-за его универсальности как языка сценариев общего назначения. Он имеет много общего с Python, являясь динамически типизированным языком сценариев. Но ему еще очень далеко до той популярности, которую имеет Python в области науки о данных.
Это немного удивительно, учитывая его применение в областях, в которых используются методы количественного анализа, например в биоинформатике. Что касается науки о данных, то у Perl есть несколько недостатков: у него не получится быстро стать популярным в данной области, а его синтаксис считается недружелюбным. Кроме того, со стороны его разработчиков не наблюдается никаких попыток создания библиотек, которые могли бы быть использованы в области науки о данных. А как мы с вами знаем: зачастую все решают правильные действия в подходящий момент.
Наш вердикт – полезный язык сценариев общего назначения, но с его помощью вам уж точно не устроится на работу специалиста по данным...
Ruby
Ruby – это еще один динамически типизированный интерпретируемый язык общего назначения. Тем не менее, похоже, что у его создателей нет никакого желания сделать его пригодным для работы в области науки о данных, как в случае с Python.
Это может показаться странным, но все вышеуказанное так или иначе связано с доминирующим положением Python в области научных исследований, а также с положительными отзывами людей, пишущих на этом языке. Чем больше людей выбирают Python, тем больше разрабатывается для него модулей и фреймворков, и тем больше программистов отдают свое предпочтение Python. Проект SciRuby был создан для того, чтобы внедрить в Ruby функциональность научных вычислений, например, матричной алгебры. Но, несмотря на все эти потуги, Python на данный момент по-прежнему лидирует.
Наш вердикт – не совсем правильный выбор для науки о данных, но в вашем резюме знание Ruby не помешает
Заключение
Ну вот мы с вами и рассмотрели короткое руководство по языкам программирования, которые ближе всего подступили к области науки о данных. Важным моментом здесь является понимание того, что вам больше нужно: специфичность или универсальность языка, его удобство или эффективность.
Я регулярно использую R, Python и SQL, так как моя текущая работа в основном сосредоточена на разработке существующих конвейеров данных и ETL-процессов. Эти языки совмещают правильный баланс общности и эффективности для выполнения этой работы с возможностью использования более совершенных статистических пакетов R, когда это необходимо.
Однако, возможно, вы уже неплохо набили руку в Java, или вам не терпится испробовать в действии Scala для работы с большими данными, или, может быть, вы без ума от проекта Julia.
А может вы зубрили MATLAB на парах в институте или не прочь дать SciRuby шанс показать себя? Да у вас могут быть сотни разных причин! Если так, то оставьте свой комментарий внизу – ведь для нас действительно важно знать мнение каждого из вас!
Спасибо за внимание!
Комментарии (68)
sshikov
06.09.2017 22:37Аналитические возможности SQL довольно ограничены: объединение, суммирование, вычисление и усреднение – вот и все, на что он способен.
Так и хочется спросить "Что вы такое курили"? Во-первых, уже много лет как все основные производители позволяют расширять свои СУБД путем создания своих функций (и включают в поставку расширенные их наборы). По вашему, какой-нибудь PostGIS — это просто усреднение, и это все, на что он способен? Я уж молчу про то, что функции (скалярные и аггрегирующие) можно писать уже сто лет в обед. А OLAP расширения? Не, не слышали?
Нет никакой неопределенности в том, что SELECT name FROM users WHERE age > 18 должен делать!
Да-да. Особенно если имеются пользовательские типы данных, и колонка age такого типа (JSON, например, или geometry). Да и операторы определять тоже зачастую можно.
Так что никакого интереса JavaScript для этой области не представляет.
А ничего, что существуют такие продукты, как d3, например. Или множество пакетов для работы с геоданными (типа GeoJSON/TopoJSON например), или Turf/JS?
Динамически типизированные языки сценариев, такие как R и Python, имеют намного лучшую производительность.
Это вы по сравнению с Java, на минутку. Можно ссылочку на то место, где описана лучшая производительность Python по сравнению с Java (JIT)?
SirEdvin
07.09.2017 10:22Это вы по сравнению с Java, на минутку. Можно ссылочку на то место, где описана лучшая производительность Python по сравнению с Java (JIT)?
Стоит учесть, что большинство решений для data science написаны с сишными биндингами. Производительность языка тут не всегда играет роль.
А ничего, что существуют такие продукты, как d3, например. Или множество пакетов для работы с геоданными (типа GeoJSON/TopoJSON например), или Turf/JS?
Потому что нужно рисовать графики на web-страничках? Тут разбирается похожий вопрос.
sshikov
07.09.2017 20:05Стоит понимать, что сишние биндинги доступны в Java точно также, как и в Python.
И да, нужно графики. Есть какие-то сомнения в том, что это нужно (в качестве результата того же обучения)?
SirEdvin
07.09.2017 22:05Стоит понимать, что сишние биндинги доступны в Java точно также, как и в Python.
Ну и это сравнение производительности сишных биндингов получится.
И да, нужно графики. Есть какие-то сомнения в том, что это нужно (в качестве результата того же обучения)?
Да, они нужны. Но они не будут основным инструментов, а скорее, вспомогательным. Например, Python + Jupyter + Bokeh работает через d3, но именно на javascript вы вроде не пишите.
sshikov
07.09.2017 22:10Ну и это сравнение производительности сишных биндингов получится.
Именно это я и хотел сказать — что исходное утверждение из поста имеет мало смысла и ни на чем не основано. Если и есть разница в производительности — то ее надо мерять и подтверждать.
Но они не будут основным инструментов, а скорее, вспомогательным.
Я не стану спорить, да, в основном javascript в таких задачах язык вспомогательный, но реально без UI, диаграмм, веба большАя часть обработки данных бессмысленна.
sshikov
07.09.2017 20:31И кстати — вы пробовали когда-нибудь запускать скажем на хадуповском кластере что-нибудь на Python, если там сишные биндинги? Я вас уверяю, вам почти гарантированы знатные пляски с бубном. Так что да, не только производительность.
SirEdvin
07.09.2017 22:03PySpark вроде должен успешно справляться со своей задачей, но java, разумеется, в этом плане должна быть лучше, так как писалось под нее.
sshikov
07.09.2017 22:16Практически нужно как минимум собирать нативные библиотеки под ту же архитектуру (и иметь эту архитектуру строго одинаковой), как-то учесть зависимости, которые могут быть, сами эти зависимости где-то достать и все это упаковать. И как-то на все ноды кластера доставить — что в итоге приводит к необходимости установки всех питоновских библиотек статически на каждую ноду.
Может это в более новых версиях и поменяется, и будут питоновские библиотеки в виде докер контейнеров сами разворачиваться — но пока это знатный геморрой.
SirEdvin
07.09.2017 22:23Стоит заметить, что для python есть anaconda и jupyter-parallel, если вам нужны распределенные вычисления.
Ну и не сказал бы, что установка всех питоновских либ на каждый узел — это гемморой. Все равно их надо как-то поднимать, можно просто ansible-скриптами раскатывать.
sshikov
09.09.2017 17:24Ну, я не говорил, что это не решаемая проблема. Но в сравнении с Java/Scala — еще какой гемор (ну вернее так — если вам нужны native либы, то вы и с Java будете эту проблему иметь, только в профиль).
Во-первых, раскатывать должны специально обученные люди, после проверки на соседнем маленьком кластере. Позволять это обычному пользователю очевидно нельзя.
Второе — представьте, что вы установили по просьбе Пети на все ноды версию 1.х некоей либы. И тут приходит Вася, и говорит, что хочет версию 2.х. В варианте Java/Scala такая проблема если и есть, то стоит намного менее остро.
Ну и еще — типовой пром кластер как правило растет, так что разворачивание нод — вполне типовая повседневная задача. Если на них еще нужно каждый раз новый набор либ раскатывать — это по всякому дополнительная работа.
Ну и кстати — что если вдруг вы завтра заимели новые ноды, с более новым процессором, который научился выполнять какие-то новые инструкции, типа векторных вычислений — то по хорошему на такие ноды нужно новую версию либы, чтобы воспользоваться преимуществами. Впрочем, это наверное не особенность Python — такая же фигня будет и с любым другим инструментом.
eugenk
07.09.2017 23:47Стоит учесть, что большинство решений для data science написаны с сишными биндингами. Производительность языка тут не всегда играет роль.
Что тоже кстати как и всякая медалька, о двух сторонах. Пока Вы пользуетесь какой-то библиотекой и не выходите за её рамки, всё прекрасно. Та же numpy например. Но стоит Вам захотеть чего-то бОльшего, начнутся проблемы. Кстати сишные биндинги для питона мне пока писать не приходилось. Не думаю что это особо сложно, но хотелось бы в рамках одного проекта обходиться одним языком.SirEdvin
07.09.2017 23:49К сожалению, если вам вот нужен performance и вы упретесь в python, то этого вам не избежать. Впрочем, с java так же история, разве что в нее упираться дольше.
Но обычно можно просто докупить серверов, если архитектура приложения позволяет.
eugenk
08.09.2017 00:16С явой проблема всё-таки не так остра, она достаточно быстрая сама по себе. Кстати для неё биндинги я уже писал, играясь с андроидом. С ней мне другое не нравится. Уж больно жруча она до памяти. Сейчас с теми же продуктами от JetBrains почему-то стало приличнее, но года три назад это было НЕЧТО… Я с Pycharm на WingIde тогда ушел. Работать было просто невозможно.
epee
07.09.2017 16:49А OLAP расширения? Не, не слышали?
OLAP использует MDX. а тут как бы речь про SQLsshikov
07.09.2017 20:05Это откуда у вас такие данные про MDX?
epee
08.09.2017 10:18ru.wikipedia.org/wiki/MDX_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D0%BE%D0%B2)
sshikov
09.09.2017 17:08Давайте начнем с начала — пост как-бы не про SQL, а про то, какой язык выбрать для обработки данных. Я имел в виду, что есть много разных расширений SQL, включая расширения для OLAP (и MDX не единственный вариант — если вы посмортите в вики на страницу OLAP, то там вы даже не найдете упоминания MDX вообще).
Ну то есть, вы можете конечно считать, что MDX это не SQL, но по-моему это логичное продолжение расширений SQL для определенных задач. И считать, как автор, что SQL ничего не умеет — это слегка неправильно.
Listrigon
06.09.2017 22:53+1Вот всё присматриваюсь к R и не могу понять принесет ли он мне какую-либо пользу если есть обычная ERP система, в которой есть набор среднестатических отчетов о зарплатах, об объемах работ, ценах с группировками, фильрацией и прочим?
fireSparrow
07.09.2017 07:57Я бы посоветовал Python с библиотекой Pandas.
Listrigon
07.09.2017 08:29В целом то, что есть в SQL Server нас пока полностью устраивает, просто при установке он прдлагает еще установить и R, отсюда и вопрос об целесообразности/профита использовать это встроенное средство разработки.
potan
07.09.2017 00:35+1Perl хорош в обработке текстов, в том числе для предварительной обработки данных, представленных в тестовом виде. Как единственный язык в анализе данных он ни куда не годится, но как вспомогательный инструмент часто бывает полезен.
alexmikh
07.09.2017 01:29Не до конца понимаю, как можно Python сравнивать с SQL.
Это языки для совсем разных задач.
В целом советую подходить к вопросу выбор от задачи и иметь в виду, что много обучающих материалов используют Python :)
BosonBeard
07.09.2017 01:45Раз уже вспомнили Perl и JS то могли бы и .net платформу вспомнить, на C#, F# (и др.net языках, как следствие) есть фреймворки, неудобные, но видимо кому-то нужные раз их пишут.
Vitvitsky
07.09.2017 12:01Сложно представить работу только на одном языке. Вот вы, вот задача, вот база данных.
Понятно, что можно выкачать данные с помощью ERP в .csv/.xlsx и что-нибудь с этим сделать несложное в Excel(т.е. не касаясь ЯП). Или взять пакет в R, написать команду извлечения на SQL, и что-нибудь сделать в R(или вместо R подставить Python). Опять же в этих языках часть пакетов написана на C++.
evseev
07.09.2017 13:34-2Сам я этим не занимаюсь, но в связи с тем, что этим занимается моя жена, я немножечко в теме. И что меня сразу удивило, что SQL вынесен как отдельный язык. А что можно делать такую работу и при этом ни иметь с ним дело? Как по мне это выбор без выбора. SQL просто нужен. И я бы не стал писать про понятность и однозначность синтаксиса. С простыми запросами все ясно. А если вы пишите действительно сложные запросы, то там черт ногу сломит. А если при этом у вас в базе сотни тысяч строк, а то и миллионы и писать запрос постепенно его усложняя- вообще не вариант просто потому, что это займет часы, то вы точно не будете говорить о простоте и понятности.
Почему Matlab-у написали в качестве недостатка платность? Даже если говорить о самой дорогой коммерческой лицензии, то я бы не сказал, что это безумно дорого. $2500 для фирмы, которой нужен специалист подобного направления это совсем не большие деньги. Это всего-лишь месячная зарплата. Может две. Это много? Давайте посмотрим. Рядом с Matlab упоминалась Octave. То, что она сильно не дотягивает до него- пока не очень важно. Она дико ме-е-е-дленная. Что бы понять всю глубину глубин под дико я понимаю примерно 1000 раз. Т.е. то, что Matlab делает за минуту Octave делает почти 17 часов!!! Если вы никуда не спешите, то нет проблем. Хотя это все-таки то же перебор. А если у вас emergency и нужно срочно понять где лажа? Вы написали модель (или подправили под конкретный случай), опробовали на части данных, запустили процесс. Т.е. пару часов уже ушли. Но это еще не конец. Моделирование идет уже 10 часов, а результата все нет. Ваш начальник уже весь седой, заказчик охрип и медленно понимает, что его ждут финансовые потери, а может быть и суды, а у вас Octave не спеша колбасит циферки. Все-еще думаете, что $2500 это дорого? А если нужна научная или студенческая лицензия, то там и говорить не о чем.
И вообще я бы разделил статью как минимум на две части. О удобных и о быстрых. Ну или хотя-бы ввел показатель времени расчета одного и того-же на разных языках. Какой-бы ни был R классный он медленный. Если вам нужно анализировать громадные объемы — это большая проблема. И если с Python можно ускорится при помощи PyPy или Numba примерно до скорости С++, то с R и Octave вам остается только ждать сутками, а это приемлемо далеко не во всех случаях.
И еще я бы не стал писать «Какой язык». Я бы писал «Какие языки». У каждого из них есть свои сильные и слабые стороны. Скажем если вы все делаете на Matlab, то Python вам точно лишним не будет. Даже просто что бы помочь привести данные к нужному виду или автоматизировать процессы.evseev
09.09.2017 18:05Вот так заминусуют и разбирайся теперь. Толи дурак, то ли просто кто-то обиделись.
bfDeveloper
07.09.2017 15:26Многие хвалят D(dlang) для датамайнинга. Есть превосходная библиотека mir
Есть и другие (ebay tsv-utils). D на уровне по простоте, при этом однозначно лидер в соотношении простота/производительность.eugenk
07.09.2017 23:58Кстати давно меня интересует. Возможно текущий проект по работе напишу всё-таки на нём. Благо там лишь бы работало, а жестких требований по языку нет. Для обсуждаемой темы большой недостаток — это отсутствие ядра поддержки для jupyter. Я например сейчас вообще жизни себе не представляю без этого инструмента и не совсем понимаю как обходился без него раньше. Впрочем ядро конечно тоже можно написать, не бином Ньютона.
SirEdvin
Если для вас это в самом деле большая проблема, то можно использовать новомодные type hints и или очень строгий статический анализатор, или дополнительные проверки в рантайме, что сделает еще его менее производительным.
В качестве компромисса можно такое сделать для функций, которыми вы инициализируете данные.
prostofilya
При этом джаве почему то записали в преимущества строгую(сильную) типизацию (наверное имелась ввиду статическая?), а питону нет, хотя питон тоже строго типизированный язык.
ИМХО, в недостатки стоит добавлять слабую типизацию (как у JS), а не динамическую, динамическая при работе с данными скорее только плюс, ведь объёмы кода не сильно большие.
SirEdvin
На мой взгляд, типизацию вообще нельзя добавлять в минусы, так как это дискуссионный вопрос. Но такие штуки вроде всегда субъективные)
eugenk
Прошу прощения, но не могли бы Вы немного прояснить этот вопрос, желательно с примерами кода? Я не стёба ради, просто хочу разобраться в этом вопросе раз и навсегда. Сам я динамическую типизацию просто тихо ненавижу. И не понимаю как на подобном языке можно написать что-то превышающее тысячи строк. С другой стороны я вижу огромные, в десятки и сотни тысяч строк пакета на том же питоне и джаваскрипте. Т.е. люди с этим как-то справляются и это медицинский факт, с которым не поспоришь. С третьей стороны есть куча народа, утверждающего что динамическая типизация это очень круто и гораздо удобнее статической. С четвёртой — никто из них так и не смог мне толком объяснить в чём же тут крутость и удобство. Вот и прошу хоть кого нибудь, покажите пожалуйста убедительный пример, где динамическая типизация даёт очевидное преимущество перед статической. Очень хочется в этом разобраться хотя бы для общего развития.
prostofilya
Кому как, удобно до какой-то степени, для меня это максимум несколько сотен строк, я лучше разобью на несколько модулей. Чем больше кода, тем сильнее выигрывает статическая типизация.
Я лишь говорил что это плюс в плане работы с обработкой данных, так как там по моему скромному опыту объёмы кода не большие.
eugenk
Смотря что Вы делаете. Если просто хотите посмотреть на данные и обучить простую сетку на tensorflow, то да, согласен. Но если Вы разрабатываете какой-то свой алгоритм, и решили (как это почему-то модно) сделать прототип на питоне, могут быть и неприятности. Начиная от того что сам по себе язык не быстрый (хотя и порядком шустрее R или матлаба), и заканчивая динамической типизацией. Сам я последнее время сильно полюбил Scala, хотя начал ей пользоваться исключительно в как обёрткой над джаваскриптом(проект scala.js, впрочем с 2015-го года уже официальная платформа для языка). Хотя сейчас намеренно её забросил и всерьёз занялся хаскелем. Просто потому что понял что функциональному стилю на скале не научишься, слишком уж многое она позволяет. А чтобы полноценно ей пользоваться нужно для начала изучить что-то гораздо более строгое.
0xd34df00d
Если вам ещё и контекст машинного обучения интересен, посмотрите, например, на Grenade. Оно изящное.
eugenk
Спасибо! Обязательно гляну подробнее, описание по крайней мере очень интригующее. Хотя вообще Haskell я выбрал скорее как учебный язык, предполагая в будущем ориентироваться на Scala. Уж больно Scala тетка мягкая да сердобольная. Позволяет всяким раздолбаям писать код, какой их левая пятка на правой ноге пожелает. В итоге ничему функциональному научить не может. А мистер Haskell Curry учитель строгий. С ним не забалуешь и не пораздолбайствуешь. Как язык для продакшена это делает Scala очень привлекательной, но для обучения функциональной парадигме на мой взгляд только Haskell и ничего кроме него.
0xd34df00d
Согласен, я тоже рекомендую учиться ФП сразу с погружения в чистый хардкор.
Более того, я бы сказал, что на хаскеле ещё труднее писать «неправильно» и продакшен-код, поэтому, при достаточном скилле людей у вас в команде, для прода он вполне подходит.
evseev
Я бы хотел уточнить. Вы же про Python говорите? Сам по себе или его расширения? И почему вы ставите рядом по скорости R и Matlab? R медленный. И никто это не скрывает. А вот Matlab в развернутых тестах находится между C++ и Java. Python к ним подтягивается если использовать что-то тип Numba или PyPy.
SirEdvin
Например, мне нужно создать таблицу, с которой я потом буду проводить операции. В случае с динамической типизацией я делаю что-то типо такого:
В той же java мне приходится написать вот такую штуку
Раньше нужно было дублировать это полотно еще в правой части выражения. А в случае, если вы заранее не знаете типы, то вам приходилось делать все Object и потом использовать приведение типов.
Основное преимущество динамической типизации — вам нет необходимости продумывать грамотную структуру интерфейсов и контейнеров, которая в любом случае будет где-то не удобна и вы будете ее обходить.
Ну и да, при помощи динамической типизации возможно обходить плохие дизайны библиотек.
Например, есть библиотека, которая реализует быструю сериализацию объекта. Но проблема в том, что она работает только с классами-наследниками своего базового класса. А у вас своя иерархия классов, в которую это не вписывается.
В случае статической типизации эта проблему нельзя решить, в случае динамической вы можете продублировать интерфейс этого класса.
sshikov
То что вы пишете про матрицы — это некоторый недостаток системы типизации Java, а не статической типизации вообще.
SirEdvin
Возможно, но я, к сожалению, не знаю бы системы типов, которая бы справлялась удачно с задачами:
sshikov
Я не очень понимаю, что значит 12 колонок заранее неизвестных типов, и как это можно именно статически типизировать, если тип заведомо известен только при выполнении? Ну да, есть всякие API взаимодействия с внешними системами, которые не являются статически типизированными, и да, это в общем слабое место.
А так хаскель например все это довольно успешно решает. Даже в Java с сильными ограничениями системы типов возможны какие-нибудь HList, они вполне себе удобны, и статически гарантируется, что вы в n поле всегда имеете определенный тип — или оно не скомпилируется. Ну то есть при всех возможных недостатках у статической типизации все же есть явные преимущества.
SirEdvin
Ну вот я это и имел ввиду.
Поэтому нужно выбирать :)
0xd34df00d
Но ведь где-то рано или поздно так или иначе вы указываете список типов, которые вы можете обработать. Иначе это не более чем перекладывание набора байтиков из одного места в другое, что можно снова спокойно делать со статической типизацией.
SirEdvin
На самом деле, нет. Мне хватает для этого утиной типизации. Мне все равно, что пришло в метод, если оно поддерживает функции, которые я хочу вызвать.
0xd34df00d
Тогда лучше adhoc/parametric polymorphism уж.
Кто, кстати, и где определяет, какие методы у пришедшего вам объекта есть? Он же вам не прям так, с методами чтобы, приходит.
SirEdvin
Всмысле? Определяется во время вызова метода, собственно.
Если у объекта а есть метод, он выполнится, нет — упадет ошибка.
Тогда опять же накладываются ограничения от системы типов, которая если была неудачно реализована или неудачно применена, портит все.
0xd34df00d
Откуда берётся вот тот код, который исполняется, когда вы вызываете
doSomething?SirEdvin
Вам в общем случае?
Это может быть класс. Это может быть динамически собранный объект, это может быть строка, к которой добавили этот метод.
Вариантов много. Да, не все из них удобные, но...
0xd34df00d
Ну, та часть вашей программы или инфраструктуры, где у вас создаётся/добавляется этот метод, вполне может вместо него создать экземпляр типа. В простейшем случае всё это может выглядеть как
А ещё есть такое, например.
eugenk
Возможно наилучшее решение тут опциональная статическая типизация. Тип Any в scala, dynamic в dart, * в ActionScript3 и т.п. Хочешь что-то такое совсем уж эдакое, явным образом отказывайся от статического типа и пиши на свой страх и риск. Впрочем это есть и на С. На чистом С даже, а не на плюсах. Передавай указатель на данные как *void, и делай с ними что хочешь. Однако из своего опыта программирования на С/C++ (как образец языка с опциональной статической типизацией), могу сказать, что необходимость в подобном возникает всё-таки достаточно редко. В 90% случаях заранее известно с какими данными будет работать код.
SirEdvin
Проблема с Any в том, что для использования какого-то конкретного метода все равно нужно приводить его к какому-то типу (простите, если я ошибаюсь, мне всегда казалось, что это так).
Ну и динамическая типизация не является необходимой, она просто поощряет другой подход к разработке, что позволяет, например разрабатывать библиотеки более гибко и делать страшные вещи с программой, вплоть до полной замены одного класса в runtime другим. Мне кажется, в том же C++ такое вряд ли можно сделать.
Но за это нужно платить чего-то в духе "undefined is not a method" или "expected string, got int".
eugenk
Всё верно. Однако чем это плохо? На том же питоне или джаваскрипте Вы тоже всегда проверяете, что за объект пришел. Только там Вам приходится деконструировать его по частям. Скажем смотрим, словарь это или массив, если словарь что у него на первом месте, что на втором и т.д. А Any Вы сразу можете проверить на множество заранее определённых типов и увидеть что же конкретно пришло. Если же пришло что-то неизвестное на момент написания кода, Вы и обработать это не сможете вне зависимости от языка. Единственно что Вы можете, это передать данные какому-то другому обработчику, который возможно знает что с ними делать, либо сообщить об ошибке.
Вот этот момент меня тоже всегда очень интересовал. На плюсах такое сделать разумеется не получится, но мне всегда было очень интересно ЗАЧЕМ. Всё равно меняете Вы что-то в классе с помощью какого-то написанного Вами же(или другим человеком) кода, в ответ на какие-то события или данные. Т.е. чуда не происходит, и за Вас компьютер думать не начинает. На плюсах вместо полной замены класса в рантайме я всегда могу понять, что такие-то и такие-то данные для моего класса не годятся и передать их куда-то ещё. В крайнем случае подгрузить плагин из динамической библиотеки. Зато если в своих исходниках я вижу такой-то и такой-то класс, я твёрдо знаю что делает он то-то и то-то, всегда и везде. Как число пи в математике. Как в исходниках на джаваскрипте понять, что в этом месте программы такой-то класс уже полностью или хотя бы наполовину изменен, мне например не очень ясно. А вообще не знаю, можете запинать меня ногами, покрыть вечным позором и ненормативной лексикой, но по моему глубокому убеждению, программы мы пишем в первую очередь для людей, а не для компьютеров. Такая вот современная латынь(в средние века язык врачей, юристов и ученых, где важна была точность). Поэтому стремиться надо даже не к элегантности и красоте. А к ПОНЯТНОСТИ.
SirEdvin
Я бы не назвал это проверять. Утиная типизация позволяет не делать этого в целом :)
Понятность порождает лишний код, лишний код порождает дублирование, дублирование порождает сложность поддержки, сложность поддержки порождает рассинхронизацию кода, а она в свою очередь уменьшает понятность.
Разумеется, что это проблема не языка, а больше архитектурная. Но мне нравится в более динамических языках то, что они позволяю тебе высунуть наружу интерфейс, со сложной внутренней реализацией и просто разрешить людям его использовать. А тот, кому вдруг нужно будет полезть внутрь, будет страдать, к сожалению. Например, декораторы для кеширования и параллельного программирования в python. Можно глянуть вот тут внизу статьи.
И это тоже понятность, на мой взгляд. Но да, она не дает полного понимания того, что делает программа, что не есть хорошо. Но лично я готов за это платить.
0xd34df00d
Технически в С и плюсах не опциональная статическая, а слабая статическая типизация.
eugenk
Большое спасибо, пожалуй первый за долгую историю моих попыток завязать разговор на эту тему, толковый ответ (хотя Вам тут совершенно правильно заметили, что говорите Вы скорее не о статике вообще, а о системе типов конкретной явы). А то обычно рассказывают как удивительно гибок питон, а я не понимаю, что он может такого, чего я не сделаю хотя бы на том же С++ и даже на чистом С, причём гораздо более безопасно и контролируемо. Т.е. по-Вашему наверно получается что динамическая типизация переносит часть трудностей в будущее. Из времени обдумывания кода, на время его отладки. Любопытно! И кстати многое объясняет. Есть программисты по складу мышления стратеги, любящие обдумывать и планировать. А есть тактики, любящие конкретно заставить код работать. Наверно первым нравится статическая типизация, вторым динамическая. Впрочем не скрою, что мне как лентяю и раздолбаю, ещё очень нравится автокомплит, который по очевидным причинам нормально работает только со статическими языками. Для динамических языков у меня слишком плохая память :)
SirEdvin
Тут вы не правы. На самом деле, он отлично работает и для языков с динамической типизацией, пока не начинает происходит всякая магия в духе замены одного класса другим при помощи декоратора, добавление функционала и прочее. Но после магии уже ничего не помогает :(
eugenk
Ну я чисто по практике сужу. Скажем в той же Idea. Пишем на javascript, пока пользуемся чистым языком, всё более не менее. Подключаем jquery, уже начинаются проблемы. Подключаем plumb.js и начинаем гнусно материться. Переходим на typescript или scala и радостно вздыхаем :)
0xd34df00d
Это проблема конкретной библиотеки, не надо пользоваться такими библиотеками. То есть, да, динамическая типизация позволяет что-то вокруг этого накостылять, но это звучит как «отрежу себе ноги ради бесплатного проезда в автобусе».
SirEdvin
Ну, у меня таких случаев было аж целых два, в итоге пришлось переписывать эту библиотеку под свой класс и добавлять в проект (на Java). К счастью, библиотеки были маленькие.
Но и тут еще стоит учитывать такие случаи. Например, вам нужно число, все операции по которому будут записываться в него. Скажем, число с историей. В случае языка с динамической типизацией вопроса, а как же его использовать в других библиотеках нет.
А в случае со статической в тех, языках, которые я знаю, с этим будут проблемы, вплоть до отказа от такой задачи.
0xd34df00d
Почему? Берёте и создаёте свой тип данных и пишете реализацию тайпкласса Num и прочих для него:
Если завтра днём не забуду, наваяю пример и приду сюда с ним.
SirEdvin
Это если ваша система типов позволяет. Например, я не особо представляю, как сделать такое в Java или C#.
В том же C++ вроде так не получится сделать с библиотеками, которые работают с числами.
А вот в Python пожалуйста.
0xd34df00d
Не надо рассматривать языки с паршивой и нецельной системой типов и на базе этого рассмотрения говорить, что любая статическая система типов — отстой.
В плюсах если у меня библиотека параметризована типом чисел (а все адекватные библиотеки так работают, dlib, eigen, и так далее), то вы вполне можете в неё подсунуть произвольный тип с переопределённым operator+ и прочими.
SirEdvin
К сожалению, я работал только с такими, поэтому и нет примера нормальных.
Не скините пример, библиотеки, пожалуйста, если можно?
0xd34df00d
Ну, опять же, dlib. Правда, например, если вам какой-нибудь градиентный метод оптимизации захочется использовать, то из соображений эффективности библиотека требует, чтобы это были относительно каноничные флоаты или даблы.