Кстати, а почему везде и все пишут что Р это

функциональный язык программирования (бывает что доходит и до того что не язык программирования)?

Хотя по Р есть даже курсы обьектно ориентированное программирование в Р?

R — мультипарадигменный язык, в нём есть и объекты, но они чаще всего списками просто представлены.

А в чем разница, от типичного обьектно ориентированного языка? Сори если глупый вопрос

Потому что обычно заточен под функциональный стиль, но не ограничивается только им, как какой-нибудь хаскель. То есть функция как объект - пожалуйста. Подход «я знаю, какая здесь нужна функция, остаётся подобрать правильные аргументы» - тоже поощряется.

Если честно, я даже не могу примеры привести чисто ОО-языка...

То есть на Р можно по сути делать всё тоже самое что C и Жаве, например?

Да. Это полноценный язык же.

сегодня по этой теме наткнулся на ироничный афоризм: "Everything in R is an object... and if it does something, then the type of object is function."

Ну да. Ещё замыкания вроде тоже признак функционального языка. Вот тут всплывало colnames(do) <- x. Так как Р у меня первый полноценный язык, мне норм. Но если приглядеться, то это же дичь. Результату вызова функции над объектом присваивается какое-то значение

я такой синтаксис не использую, мне кажется это скорей атавизм

А как переименовывать колонки? Меня вариант из dplyr как раз раздражает, если честно))

В data.table есть функция setnames()

А он как раз тоже не нравится. Потому что изменение объекта без присваивания. По ООПшному как-то))) но это дело вкуса, конечно

rename и rename_wth - очень удобные функции... особенно при использовании !! bang bang оператора )))

По ООПшному в петоне, наверное

Я знал, что обсуждение сведётся к нему, вот знал))

Потому что ООП — не совсем стиль R. Это данность. Вряд ли бы вы стали от Фортрана требовать ООПшных примочек (я утрирую, разумеется)

А что на Р можно скажем написать исполняемую программу?

Аналогичный вопрос был)))

Кстати, вроде в современном фортранеесть ООП))

Конечно. Более того, есть библиотеки, чтобы делать shiny приложения привычными экзешниками на винду))

Ого, вот насчет этого не знал

ООП вообще неприменимо для настоящей работы с данными. 90% памяти жрут исходные данные. никаких копирований, скрытых свойств и прочего полиморфизма. считайте, что у вас дерево и набор резцов (функции)

нет. каждый язык имеет свою специфику. на R вы с указателями точно не поработаете без Rcpp

Зачем тогда ооп все учат?

Ну, не все.

честно? сложно сказать, сильно от предметной области зависит. поговорите с промышленными разработчиками. они от сложности и надуманности С++ вообще не в восторге

В mlr3 неплохо ООП прикручено и к месту.

реально оно для работы с данными как пятая нога. несколько раз приходилось разрушать все это ООП-шные конструкции, как только давали полную нагрузку на прототип. данные жрут всю память и еще одно теневое копирование рушит все. так... на небольших сабсетах поиграться. либо для объектов типа логгера/коннекта к внешней системе

Я не проверял, где в mlr3 создаются дополнительные копии? Имеется ввиду, неужели такой большой оверхед при запуске xgboost/lightgbm/catboost отдельно и внутри пайплайна mlr3?

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

Ilya Shutov
скриншот из выложенной книги

Ой, не нужно сейчас... а то можно уйти в философию Гегеля относительно того какая же универсальная модель способна описать окружающий мирт

я ж не про деплой какой-то одной большой модели, которая еще и переобучается (в хорошем смысле) постоянно на новых данных. Тогда никакие обертки не нужны. А для тюнинга с гридсёрчем всяко нужен фреймворк. Можно самописный, но не факт что даже для частного случая экономнее mlr3 выйдет

mlr3 появился не просто так. автор честно признавался, что не может больше поддерживать mlr и дешевле все переписать.

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

кто хочет — читает. кто не хочет — не читает.

it depends