Как стать автором
Обновить
1
0

Пользователь

За что я не люблю всяких "евангелистов языков",так это за откровенную неспособность реально относится к проблемам языка. То go с его "дженерики не нужны", то "r отлично заходит везде, а те вещи, которых там нет, вам не нужны".

Не думайте, пожалуйста, что вы умный, а все ошибаються. Очень часто наоборот.

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

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

  1. Да, и для решения этой проблемы у вас есть numpy. Или массив с методами это тоже катастрофа?

  2. Я читал про пайпы, я знаю про пайпы, я использовал пайпы в linux. Да, они удобные, да с форматированем выглядит не так классно. Но это субьетивная оценка про "нечитаемость". Нечитаемость чего-то всегда субьективна.

  3. Опять же, для аналитики в рамках numpy это решено, нет?

  4. Это аргумент для "standart R"

  5. Хороший вопрос, надо будет найти. Я то не из DS

  6. Так-то он не слизан, а "обертка". И почему он не может pandas заменить? Я не эксперт, но беглым взглядом вроде почти все есть. Часть можно дописать через стандартные функции

  • питон изначально объекто ориентированный, он так проектировался. почитайте базовые типы. Все есть объект, народ это постоянно разжевывает, например: https://www.pythonmorsels.com/everything-is-an-object/

  • питон изначально объекто ориентированный, он так проектировался. почитайте базовые типы. Все есть объект, народ это постоянно разжевывает, например: https://www.pythonmorsels.com/everything-is-an-object/

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

Проблема (для автора коммента и языка) то в том, что у автора коммента выше, язык R в голове таким не считается.

  1. Ну, я то читаю. И развитие языка сейчас не выглядет как остановленное, особенно после 3.4

  2. А зачем они нужны, если есть numpy?

  3. Даже перемножение матриц и asyncio куски?

Основная слабость этой публикации - манипуляция.

> ООП и DS плохо совместимы

Этот раздел причем к python? Сам по себе язык мультипарадигменный, а numpy убирает затраты памяти на дополнительную адресацию примитивных типов

> Недостаточность базовых типов данных

А есть прям существенная разница между built-in data-type и built-in library в этом случае? И опять же, numpy

> Векторизация

numpy

> Pandas

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

> Отсутствие полноценной конвейерной обработки (pipe)

Нечитаемость чего-то это субьетивщина. Я вот R считаю нечитаемым, потому что практически не имею с ним дело (как и вы с Python, похоже)

> Производительность

> Про практическую непригодность pandas для данных чуть больше небольших давно известно но старательно умалчивается.

> Про Dask, polars,… не говорим — это другая весовая категория и на подобные решения найдется масса альтернативных нейтральных ответов. Тот же Clickhouse.

А почему polars то внезапно out-of-scope? Сам по себе polars может быть практически drop-in заменой pandas

> Бенчмарки

Пакет для R нашли, а поискать подходящий пакет для python - это не судьба.

> Заключение

Вся статья - полная профанация. Реальное преимущество можно было бы показать, если бы вы сфокусировались на "standart r" и "standart python", но это в целом никого не интересует

R - настоящий "универсальный клей",

значит это к аналитике данных не имеет отношения


Это же именно та проблема, про которую пишут. Вне рамок "аналитики" R не нужен (или является экзотическим) и это вытесняет его из рынка, так как специфические языки не нужны.

Лол, что. Остановил?) А вы точно разбираетесь в том, что пишите?

Почему? Если помещение небольшое, а у нас все-таки помещение с большим люфтом допустимых температур, в чем проблема иметь только один датчик?

Особенно жалко, что для большинства ФП в языке это какая-то возможность писать в фунциональном стиле.

Как признаком того, что язык является объектно-ориентированным является факт, что в нем есть объекты (а иногда и без них пытаются обойтись).

Понятно, что C++ - отдельный ЯП, но обычно, когда говорят C, то подразумевают и C++. Зачм использовать в 2022г чистый C - мне не очень понятно.

Абсолютно за те же, зачем использую С++ в 2022 году, когда есть куча более полезных языков. Ну и это очень странная позиция "говорят про одно, подразумевают другое", мы тут в сообществе программистов или HR?

Как мило. Ну в таком случае, история вообще не знает безопасной
разработки софта. Вообще на любом ЯП. Под безопасной разработкой в
контексте С подразумевается безопасная работа с указателями.

Boost "решает" эту проблему так же, как и любой другой способ навернуть умных указателей. То есть он закрывает довольно узкую прослойку проблем, а куча других остается. Ну и как бы, решение проблемы снаружи языка всегда решают проблему довольно фрагментировано. Приходится использовать либу, которая решила не подключать boost? Добро пожаловать в проблемы.

Я понимаю, что тут идет отсылка к куче undefined моментов в C++, но мой поинт был скорее в том, что прямое управление памятью - это небезопасно

Дело не в религиозной ненавести. awk и sed довольно нишевые тулы, которые используются раз в столетие и очень быстро забываются. В добавок, они имеют довольно необычный синтаксис и в итоге, что бы понять, что делает команда написанная недели три назад тратится столько времени, что проще переписать на любой другой язык.

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

PS: Ну и да, bash-скриптов на продакшене существовать не должно, имхо.

Да нет, очень правильная аналогия. Вот в олимпиаде есть метание ядра, которое отлично можно сравнить с cobol, к примеру.

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

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

Мммм, не поможет. embedded процессор и реальный отличаются как небо и земля. Виртуализации, оптимизации и прочий мотлох

Потому что так хочет заказчик :)

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

И тут на поле боя выходит golang, rust, dlang и так далее. То есть нет, в каких-то маргинальных формах их основные фишки вполне себе существовали, но как основное мейнстримное течение явное не использовались.

Причем нельзя же сказать, что эти фишки входят в 20% языка, которые можно не осваивать.

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

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

Помимо того факта, что Boost это все-таки С++, не совсем ясно, почему он курит в сторонке.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность