Comments 68
Типобезопасность. Python – это динамически типизированный язык, а это значит, что вы должны быть осторожными при работе с ним. Ошибки несоответствия типов (например, передача строки (string) в качестве аргумента методу, который ожидает целое число (integer)) могут время от времени случаться.

Если для вас это в самом деле большая проблема, то можно использовать новомодные type hints и или очень строгий статический анализатор, или дополнительные проверки в рантайме, что сделает еще его менее производительным.


В качестве компромисса можно такое сделать для функций, которыми вы инициализируете данные.

При этом джаве почему то записали в преимущества строгую(сильную) типизацию (наверное имелась ввиду статическая?), а питону нет, хотя питон тоже строго типизированный язык.
ИМХО, в недостатки стоит добавлять слабую типизацию (как у JS), а не динамическую, динамическая при работе с данными скорее только плюс, ведь объёмы кода не сильно большие.

На мой взгляд, типизацию вообще нельзя добавлять в минусы, так как это дискуссионный вопрос. Но такие штуки вроде всегда субъективные)

динамическую, динамическая при работе с данными скорее только плюс

Прошу прощения, но не могли бы Вы немного прояснить этот вопрос, желательно с примерами кода? Я не стёба ради, просто хочу разобраться в этом вопросе раз и навсегда. Сам я динамическую типизацию просто тихо ненавижу. И не понимаю как на подобном языке можно написать что-то превышающее тысячи строк. С другой стороны я вижу огромные, в десятки и сотни тысяч строк пакета на том же питоне и джаваскрипте. Т.е. люди с этим как-то справляются и это медицинский факт, с которым не поспоришь. С третьей стороны есть куча народа, утверждающего что динамическая типизация это очень круто и гораздо удобнее статической. С четвёртой — никто из них так и не смог мне толком объяснить в чём же тут крутость и удобство. Вот и прошу хоть кого нибудь, покажите пожалуйста убедительный пример, где динамическая типизация даёт очевидное преимущество перед статической. Очень хочется в этом разобраться хотя бы для общего развития.
С третьей стороны есть куча народа, утверждающего что динамическая типизация это очень круто и гораздо удобнее статической

Кому как, удобно до какой-то степени, для меня это максимум несколько сотен строк, я лучше разобью на несколько модулей. Чем больше кода, тем сильнее выигрывает статическая типизация.
Я лишь говорил что это плюс в плане работы с обработкой данных, так как там по моему скромному опыту объёмы кода не большие.
Смотря что Вы делаете. Если просто хотите посмотреть на данные и обучить простую сетку на tensorflow, то да, согласен. Но если Вы разрабатываете какой-то свой алгоритм, и решили (как это почему-то модно) сделать прототип на питоне, могут быть и неприятности. Начиная от того что сам по себе язык не быстрый (хотя и порядком шустрее R или матлаба), и заканчивая динамической типизацией. Сам я последнее время сильно полюбил Scala, хотя начал ей пользоваться исключительно в как обёрткой над джаваскриптом(проект scala.js, впрочем с 2015-го года уже официальная платформа для языка). Хотя сейчас намеренно её забросил и всерьёз занялся хаскелем. Просто потому что понял что функциональному стилю на скале не научишься, слишком уж многое она позволяет. А чтобы полноценно ей пользоваться нужно для начала изучить что-то гораздо более строгое.
Хотя сейчас намеренно её забросил и всерьёз занялся хаскелем.

Если вам ещё и контекст машинного обучения интересен, посмотрите, например, на Grenade. Оно изящное.

Спасибо! Обязательно гляну подробнее, описание по крайней мере очень интригующее. Хотя вообще Haskell я выбрал скорее как учебный язык, предполагая в будущем ориентироваться на Scala. Уж больно Scala тетка мягкая да сердобольная. Позволяет всяким раздолбаям писать код, какой их левая пятка на правой ноге пожелает. В итоге ничему функциональному научить не может. А мистер Haskell Curry учитель строгий. С ним не забалуешь и не пораздолбайствуешь. Как язык для продакшена это делает Scala очень привлекательной, но для обучения функциональной парадигме на мой взгляд только Haskell и ничего кроме него.

Согласен, я тоже рекомендую учиться ФП сразу с погружения в чистый хардкор.


Более того, я бы сказал, что на хаскеле ещё труднее писать «неправильно» и продакшен-код, поэтому, при достаточном скилле людей у вас в команде, для прода он вполне подходит.

Начиная от того что сам по себе язык не быстрый (хотя и порядком шустрее R или матлаба)

Я бы хотел уточнить. Вы же про Python говорите? Сам по себе или его расширения? И почему вы ставите рядом по скорости R и Matlab? R медленный. И никто это не скрывает. А вот Matlab в развернутых тестах находится между C++ и Java. Python к ним подтягивается если использовать что-то тип Numba или PyPy.

Например, мне нужно создать таблицу, с которой я потом буду проводить операции. В случае с динамической типизацией я делаю что-то типо такого:


matrix = matrix(4,5)

В той же java мне приходится написать вот такую штуку


Matrix<String, String, String, Integer,String> = new Matrix<>(4,5);

Раньше нужно было дублировать это полотно еще в правой части выражения. А в случае, если вы заранее не знаете типы, то вам приходилось делать все Object и потом использовать приведение типов.


Основное преимущество динамической типизации — вам нет необходимости продумывать грамотную структуру интерфейсов и контейнеров, которая в любом случае будет где-то не удобна и вы будете ее обходить.


Ну и да, при помощи динамической типизации возможно обходить плохие дизайны библиотек.


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


В случае статической типизации эта проблему нельзя решить, в случае динамической вы можете продублировать интерфейс этого класса.

То что вы пишете про матрицы — это некоторый недостаток системы типизации Java, а не статической типизации вообще.

Возможно, но я, к сожалению, не знаю бы системы типов, которая бы справлялась удачно с задачами:


  • Создание универсальный контейнеров без большой кучи синтаксического сахара. 12 колонок заранее неопределенных типов без их указания, например.
  • Возможность обходить недостатки системы типов, а не застрявать в ней. Например, обходить проверку на класс и возможность подсовывать объект своего класса как наследник или объект нужного класса.

Я не очень понимаю, что значит 12 колонок заранее неизвестных типов, и как это можно именно статически типизировать, если тип заведомо известен только при выполнении? Ну да, есть всякие API взаимодействия с внешними системами, которые не являются статически типизированными, и да, это в общем слабое место.


А так хаскель например все это довольно успешно решает. Даже в Java с сильными ограничениями системы типов возможны какие-нибудь HList, они вполне себе удобны, и статически гарантируется, что вы в n поле всегда имеете определенный тип — или оно не скомпилируется. Ну то есть при всех возможных недостатках у статической типизации все же есть явные преимущества.

Я не очень понимаю, что значит 12 колонок заранее неизвестных типов, и как это можно именно статически типизировать, если тип заведомо известен только при выполнении?

Ну вот я это и имел ввиду.


Ну то есть при всех возможных недостатках у статической типизации все же есть явные преимущества.

Поэтому нужно выбирать :)

Ну вот я это и имел ввиду.

Но ведь где-то рано или поздно так или иначе вы указываете список типов, которые вы можете обработать. Иначе это не более чем перекладывание набора байтиков из одного места в другое, что можно снова спокойно делать со статической типизацией.

Тогда лучше adhoc/parametric polymorphism уж.


Кто, кстати, и где определяет, какие методы у пришедшего вам объекта есть? Он же вам не прям так, с методами чтобы, приходит.

Кто, кстати, и где определяет, какие методы у пришедшего вам объекта есть? Он же вам не прям так, с методами чтобы, приходит.

Всмысле? Определяется во время вызова метода, собственно.


def function(a):
    print a.doSomething()

Если у объекта а есть метод, он выполнится, нет — упадет ошибка.


Тогда лучше adhoc/parametric polymorphism уж.

Тогда опять же накладываются ограничения от системы типов, которая если была неудачно реализована или неудачно применена, портит все.

Если у объекта а есть метод, он выполнится, нет — упадет ошибка.

Откуда берётся вот тот код, который исполняется, когда вы вызываете doSomething?

Вам в общем случае?
Это может быть класс. Это может быть динамически собранный объект, это может быть строка, к которой добавили этот метод.


Вариантов много. Да, не все из них удобные, но...

Ну, та часть вашей программы или инфраструктуры, где у вас создаётся/добавляется этот метод, вполне может вместо него создать экземпляр типа. В простейшем случае всё это может выглядеть как


class HasSmth a where
    doSomething :: a -> Result

class HasSmthElse a where
    doSomethingElse :: a -> OtherResult

data Object where
    ObjectHasSmth :: HasSmth a => a -> Object
    ObjectHasSmthElse :: HasSmthElse a => a -> Object

А ещё есть такое, например.

Возможно наилучшее решение тут опциональная статическая типизация. Тип Any в scala, dynamic в dart, * в ActionScript3 и т.п. Хочешь что-то такое совсем уж эдакое, явным образом отказывайся от статического типа и пиши на свой страх и риск. Впрочем это есть и на С. На чистом С даже, а не на плюсах. Передавай указатель на данные как *void, и делай с ними что хочешь. Однако из своего опыта программирования на С/C++ (как образец языка с опциональной статической типизацией), могу сказать, что необходимость в подобном возникает всё-таки достаточно редко. В 90% случаях заранее известно с какими данными будет работать код.

Проблема с Any в том, что для использования какого-то конкретного метода все равно нужно приводить его к какому-то типу (простите, если я ошибаюсь, мне всегда казалось, что это так).


Ну и динамическая типизация не является необходимой, она просто поощряет другой подход к разработке, что позволяет, например разрабатывать библиотеки более гибко и делать страшные вещи с программой, вплоть до полной замены одного класса в runtime другим. Мне кажется, в том же C++ такое вряд ли можно сделать.


Но за это нужно платить чего-то в духе "undefined is not a method" или "expected string, got int".

Проблема с Any в том, что для использования какого-то конкретного метода все равно нужно приводить его к какому-то типу (простите, если я ошибаюсь, мне всегда казалось, что это так).

Всё верно. Однако чем это плохо? На том же питоне или джаваскрипте Вы тоже всегда проверяете, что за объект пришел. Только там Вам приходится деконструировать его по частям. Скажем смотрим, словарь это или массив, если словарь что у него на первом месте, что на втором и т.д. А Any Вы сразу можете проверить на множество заранее определённых типов и увидеть что же конкретно пришло. Если же пришло что-то неизвестное на момент написания кода, Вы и обработать это не сможете вне зависимости от языка. Единственно что Вы можете, это передать данные какому-то другому обработчику, который возможно знает что с ними делать, либо сообщить об ошибке.

Ну и динамическая типизация не является необходимой, она просто поощряет другой подход к разработке, что позволяет, например разрабатывать библиотеки более гибко и делать страшные вещи с программой, вплоть до полной замены одного класса в runtime другим. Мне кажется, в том же C++ такое вряд ли можно сделать.

Вот этот момент меня тоже всегда очень интересовал. На плюсах такое сделать разумеется не получится, но мне всегда было очень интересно ЗАЧЕМ. Всё равно меняете Вы что-то в классе с помощью какого-то написанного Вами же(или другим человеком) кода, в ответ на какие-то события или данные. Т.е. чуда не происходит, и за Вас компьютер думать не начинает. На плюсах вместо полной замены класса в рантайме я всегда могу понять, что такие-то и такие-то данные для моего класса не годятся и передать их куда-то ещё. В крайнем случае подгрузить плагин из динамической библиотеки. Зато если в своих исходниках я вижу такой-то и такой-то класс, я твёрдо знаю что делает он то-то и то-то, всегда и везде. Как число пи в математике. Как в исходниках на джаваскрипте понять, что в этом месте программы такой-то класс уже полностью или хотя бы наполовину изменен, мне например не очень ясно. А вообще не знаю, можете запинать меня ногами, покрыть вечным позором и ненормативной лексикой, но по моему глубокому убеждению, программы мы пишем в первую очередь для людей, а не для компьютеров. Такая вот современная латынь(в средние века язык врачей, юристов и ученых, где важна была точность). Поэтому стремиться надо даже не к элегантности и красоте. А к ПОНЯТНОСТИ.
На том же питоне или джаваскрипте Вы тоже всегда проверяете, что за объект пришел.

Я бы не назвал это проверять. Утиная типизация позволяет не делать этого в целом :)


А вообще не знаю, можете запинать меня ногами, покрыть вечным позором и ненормативной лексикой, но по моему глубокому убеждению, программы мы пишем в первую очередь для людей, а не для компьютеров. Такая вот современная латынь(в средние века язык врачей, юристов и ученых, где важна была точность). Поэтому стремиться надо даже не к элегантности и красоте. А к ПОНЯТНОСТИ.

Понятность порождает лишний код, лишний код порождает дублирование, дублирование порождает сложность поддержки, сложность поддержки порождает рассинхронизацию кода, а она в свою очередь уменьшает понятность.


Разумеется, что это проблема не языка, а больше архитектурная. Но мне нравится в более динамических языках то, что они позволяю тебе высунуть наружу интерфейс, со сложной внутренней реализацией и просто разрешить людям его использовать. А тот, кому вдруг нужно будет полезть внутрь, будет страдать, к сожалению. Например, декораторы для кеширования и параллельного программирования в python. Можно глянуть вот тут внизу статьи.


И это тоже понятность, на мой взгляд. Но да, она не дает полного понимания того, что делает программа, что не есть хорошо. Но лично я готов за это платить.

Технически в С и плюсах не опциональная статическая, а слабая статическая типизация.

Большое спасибо, пожалуй первый за долгую историю моих попыток завязать разговор на эту тему, толковый ответ (хотя Вам тут совершенно правильно заметили, что говорите Вы скорее не о статике вообще, а о системе типов конкретной явы). А то обычно рассказывают как удивительно гибок питон, а я не понимаю, что он может такого, чего я не сделаю хотя бы на том же С++ и даже на чистом С, причём гораздо более безопасно и контролируемо. Т.е. по-Вашему наверно получается что динамическая типизация переносит часть трудностей в будущее. Из времени обдумывания кода, на время его отладки. Любопытно! И кстати многое объясняет. Есть программисты по складу мышления стратеги, любящие обдумывать и планировать. А есть тактики, любящие конкретно заставить код работать. Наверно первым нравится статическая типизация, вторым динамическая. Впрочем не скрою, что мне как лентяю и раздолбаю, ещё очень нравится автокомплит, который по очевидным причинам нормально работает только со статическими языками. Для динамических языков у меня слишком плохая память :)
Впрочем не скрою, что мне как лентяю и раздолбаю, ещё очень нравится автокомплит, который по очевидным причинам нормально работает только со статическими языками

Тут вы не правы. На самом деле, он отлично работает и для языков с динамической типизацией, пока не начинает происходит всякая магия в духе замены одного класса другим при помощи декоратора, добавление функционала и прочее. Но после магии уже ничего не помогает :(

Ну я чисто по практике сужу. Скажем в той же Idea. Пишем на javascript, пока пользуемся чистым языком, всё более не менее. Подключаем jquery, уже начинаются проблемы. Подключаем plumb.js и начинаем гнусно материться. Переходим на typescript или scala и радостно вздыхаем :)
В случае статической типизации эта проблему нельзя решить, в случае динамической вы можете продублировать интерфейс этого класса.

Это проблема конкретной библиотеки, не надо пользоваться такими библиотеками. То есть, да, динамическая типизация позволяет что-то вокруг этого накостылять, но это звучит как «отрежу себе ноги ради бесплатного проезда в автобусе».

Ну, у меня таких случаев было аж целых два, в итоге пришлось переписывать эту библиотеку под свой класс и добавлять в проект (на Java). К счастью, библиотеки были маленькие.


Но и тут еще стоит учитывать такие случаи. Например, вам нужно число, все операции по которому будут записываться в него. Скажем, число с историей. В случае языка с динамической типизацией вопроса, а как же его использовать в других библиотеках нет.


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

Почему? Берёте и создаёте свой тип данных и пишете реализацию тайпкласса Num и прочих для него:


Prelude> :info Num
class Num a where
  (+) :: a -> a -> a
  (-) :: a -> a -> a
  (*) :: a -> a -> a
  negate :: a -> a
  abs :: a -> a
  signum :: a -> a
  fromInteger :: Integer -> a
  {-# MINIMAL (+), (*), abs, signum, fromInteger, (negate | (-)) #-}

Если завтра днём не забуду, наваяю пример и приду сюда с ним.

Это если ваша система типов позволяет. Например, я не особо представляю, как сделать такое в Java или C#.


В том же C++ вроде так не получится сделать с библиотеками, которые работают с числами.


А вот в Python пожалуйста.

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


В плюсах если у меня библиотека параметризована типом чисел (а все адекватные библиотеки так работают, dlib, eigen, и так далее), то вы вполне можете в неё подсунуть произвольный тип с переопределённым operator+ и прочими.

К сожалению, я работал только с такими, поэтому и нет примера нормальных.


Не скините пример, библиотеки, пожалуйста, если можно?

Ну, опять же, dlib. Правда, например, если вам какой-нибудь градиентный метод оптимизации захочется использовать, то из соображений эффективности библиотека требует, чтобы это были относительно каноничные флоаты или даблы.

Аналитические возможности 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)?

Это вы по сравнению с Java, на минутку. Можно ссылочку на то место, где описана лучшая производительность Python по сравнению с Java (JIT)?

Стоит учесть, что большинство решений для data science написаны с сишными биндингами. Производительность языка тут не всегда играет роль.


А ничего, что существуют такие продукты, как d3, например. Или множество пакетов для работы с геоданными (типа GeoJSON/TopoJSON например), или Turf/JS?

Потому что нужно рисовать графики на web-страничках? Тут разбирается похожий вопрос.

Стоит понимать, что сишние биндинги доступны в Java точно также, как и в Python.


И да, нужно графики. Есть какие-то сомнения в том, что это нужно (в качестве результата того же обучения)?

Стоит понимать, что сишние биндинги доступны в Java точно также, как и в Python.

Ну и это сравнение производительности сишных биндингов получится.


И да, нужно графики. Есть какие-то сомнения в том, что это нужно (в качестве результата того же обучения)?

Да, они нужны. Но они не будут основным инструментов, а скорее, вспомогательным. Например, Python + Jupyter + Bokeh работает через d3, но именно на javascript вы вроде не пишите.

Ну и это сравнение производительности сишных биндингов получится.

Именно это я и хотел сказать — что исходное утверждение из поста имеет мало смысла и ни на чем не основано. Если и есть разница в производительности — то ее надо мерять и подтверждать.


Но они не будут основным инструментов, а скорее, вспомогательным.

Я не стану спорить, да, в основном javascript в таких задачах язык вспомогательный, но реально без UI, диаграмм, веба большАя часть обработки данных бессмысленна.

И кстати — вы пробовали когда-нибудь запускать скажем на хадуповском кластере что-нибудь на Python, если там сишные биндинги? Я вас уверяю, вам почти гарантированы знатные пляски с бубном. Так что да, не только производительность.

PySpark вроде должен успешно справляться со своей задачей, но java, разумеется, в этом плане должна быть лучше, так как писалось под нее.

Практически нужно как минимум собирать нативные библиотеки под ту же архитектуру (и иметь эту архитектуру строго одинаковой), как-то учесть зависимости, которые могут быть, сами эти зависимости где-то достать и все это упаковать. И как-то на все ноды кластера доставить — что в итоге приводит к необходимости установки всех питоновских библиотек статически на каждую ноду.


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

Стоит заметить, что для python есть anaconda и jupyter-parallel, если вам нужны распределенные вычисления.


Ну и не сказал бы, что установка всех питоновских либ на каждый узел — это гемморой. Все равно их надо как-то поднимать, можно просто ansible-скриптами раскатывать.

Ну, я не говорил, что это не решаемая проблема. Но в сравнении с Java/Scala — еще какой гемор (ну вернее так — если вам нужны native либы, то вы и с Java будете эту проблему иметь, только в профиль).


Во-первых, раскатывать должны специально обученные люди, после проверки на соседнем маленьком кластере. Позволять это обычному пользователю очевидно нельзя.


Второе — представьте, что вы установили по просьбе Пети на все ноды версию 1.х некоей либы. И тут приходит Вася, и говорит, что хочет версию 2.х. В варианте Java/Scala такая проблема если и есть, то стоит намного менее остро.


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


Ну и кстати — что если вдруг вы завтра заимели новые ноды, с более новым процессором, который научился выполнять какие-то новые инструкции, типа векторных вычислений — то по хорошему на такие ноды нужно новую версию либы, чтобы воспользоваться преимуществами. Впрочем, это наверное не особенность Python — такая же фигня будет и с любым другим инструментом.

Стоит учесть, что большинство решений для data science написаны с сишными биндингами. Производительность языка тут не всегда играет роль.

Что тоже кстати как и всякая медалька, о двух сторонах. Пока Вы пользуетесь какой-то библиотекой и не выходите за её рамки, всё прекрасно. Та же numpy например. Но стоит Вам захотеть чего-то бОльшего, начнутся проблемы. Кстати сишные биндинги для питона мне пока писать не приходилось. Не думаю что это особо сложно, но хотелось бы в рамках одного проекта обходиться одним языком.

К сожалению, если вам вот нужен performance и вы упретесь в python, то этого вам не избежать. Впрочем, с java так же история, разве что в нее упираться дольше.


Но обычно можно просто докупить серверов, если архитектура приложения позволяет.

С явой проблема всё-таки не так остра, она достаточно быстрая сама по себе. Кстати для неё биндинги я уже писал, играясь с андроидом. С ней мне другое не нравится. Уж больно жруча она до памяти. Сейчас с теми же продуктами от JetBrains почему-то стало приличнее, но года три назад это было НЕЧТО… Я с Pycharm на WingIde тогда ушел. Работать было просто невозможно.
А OLAP расширения? Не, не слышали?

OLAP использует MDX. а тут как бы речь про SQL

Давайте начнем с начала — пост как-бы не про SQL, а про то, какой язык выбрать для обработки данных. Я имел в виду, что есть много разных расширений SQL, включая расширения для OLAP (и MDX не единственный вариант — если вы посмортите в вики на страницу OLAP, то там вы даже не найдете упоминания MDX вообще).


Ну то есть, вы можете конечно считать, что MDX это не SQL, но по-моему это логичное продолжение расширений SQL для определенных задач. И считать, как автор, что SQL ничего не умеет — это слегка неправильно.

Вот всё присматриваюсь к R и не могу понять принесет ли он мне какую-либо пользу если есть обычная ERP система, в которой есть набор среднестатических отчетов о зарплатах, об объемах работ, ценах с группировками, фильрацией и прочим?
В целом то, что есть в SQL Server нас пока полностью устраивает, просто при установке он прдлагает еще установить и R, отсюда и вопрос об целесообразности/профита использовать это встроенное средство разработки.
Perl хорош в обработке текстов, в том числе для предварительной обработки данных, представленных в тестовом виде. Как единственный язык в анализе данных он ни куда не годится, но как вспомогательный инструмент часто бывает полезен.
Не до конца понимаю, как можно Python сравнивать с SQL.
Это языки для совсем разных задач.

В целом советую подходить к вопросу выбор от задачи и иметь в виду, что много обучающих материалов используют Python :)

Раз уже вспомнили Perl и JS то могли бы и .net платформу вспомнить, на C#, F# (и др.net языках, как следствие) есть фреймворки, неудобные, но видимо кому-то нужные раз их пишут.
Сложно представить работу только на одном языке. Вот вы, вот задача, вот база данных.
Понятно, что можно выкачать данные с помощью ERP в .csv/.xlsx и что-нибудь с этим сделать несложное в Excel(т.е. не касаясь ЯП). Или взять пакет в R, написать команду извлечения на SQL, и что-нибудь сделать в R(или вместо R подставить Python). Опять же в этих языках часть пакетов написана на C++.
Сам я этим не занимаюсь, но в связи с тем, что этим занимается моя жена, я немножечко в теме. И что меня сразу удивило, что SQL вынесен как отдельный язык. А что можно делать такую работу и при этом ни иметь с ним дело? Как по мне это выбор без выбора. SQL просто нужен. И я бы не стал писать про понятность и однозначность синтаксиса. С простыми запросами все ясно. А если вы пишите действительно сложные запросы, то там черт ногу сломит. А если при этом у вас в базе сотни тысяч строк, а то и миллионы и писать запрос постепенно его усложняя- вообще не вариант просто потому, что это займет часы, то вы точно не будете говорить о простоте и понятности.

Почему Matlab-у написали в качестве недостатка платность? Даже если говорить о самой дорогой коммерческой лицензии, то я бы не сказал, что это безумно дорого. $2500 для фирмы, которой нужен специалист подобного направления это совсем не большие деньги. Это всего-лишь месячная зарплата. Может две. Это много? Давайте посмотрим. Рядом с Matlab упоминалась Octave. То, что она сильно не дотягивает до него- пока не очень важно. Она дико ме-е-е-дленная. Что бы понять всю глубину глубин под дико я понимаю примерно 1000 раз. Т.е. то, что Matlab делает за минуту Octave делает почти 17 часов!!! Если вы никуда не спешите, то нет проблем. Хотя это все-таки то же перебор. А если у вас emergency и нужно срочно понять где лажа? Вы написали модель (или подправили под конкретный случай), опробовали на части данных, запустили процесс. Т.е. пару часов уже ушли. Но это еще не конец. Моделирование идет уже 10 часов, а результата все нет. Ваш начальник уже весь седой, заказчик охрип и медленно понимает, что его ждут финансовые потери, а может быть и суды, а у вас Octave не спеша колбасит циферки. Все-еще думаете, что $2500 это дорого? А если нужна научная или студенческая лицензия, то там и говорить не о чем.

И вообще я бы разделил статью как минимум на две части. О удобных и о быстрых. Ну или хотя-бы ввел показатель времени расчета одного и того-же на разных языках. Какой-бы ни был R классный он медленный. Если вам нужно анализировать громадные объемы — это большая проблема. И если с Python можно ускорится при помощи PyPy или Numba примерно до скорости С++, то с R и Octave вам остается только ждать сутками, а это приемлемо далеко не во всех случаях.

И еще я бы не стал писать «Какой язык». Я бы писал «Какие языки». У каждого из них есть свои сильные и слабые стороны. Скажем если вы все делаете на Matlab, то Python вам точно лишним не будет. Даже просто что бы помочь привести данные к нужному виду или автоматизировать процессы.
Вот так заминусуют и разбирайся теперь. Толи дурак, то ли просто кто-то обиделись.
Многие хвалят D(dlang) для датамайнинга. Есть превосходная библиотека mir
Есть и другие (ebay tsv-utils). D на уровне по простоте, при этом однозначно лидер в соотношении простота/производительность.
Кстати давно меня интересует. Возможно текущий проект по работе напишу всё-таки на нём. Благо там лишь бы работало, а жестких требований по языку нет. Для обсуждаемой темы большой недостаток — это отсутствие ядра поддержки для jupyter. Я например сейчас вообще жизни себе не представляю без этого инструмента и не совсем понимаю как обходился без него раньше. Впрочем ядро конечно тоже можно написать, не бином Ньютона.
Only those users with full accounts are able to leave comments. Log in, please.