Есть ли какие-либо объективные причины для того, почему оператора труб из пакета R magrittr, например %>%, следует избегать, когда я программных пакетов в R?
В частности, я хочу знать, могут ли использование операторов труб вызвать конфликты кодирования или (положительно или отрицательно) повлиять на производительность. Я ищу конкретные конкретные примеры таких случаев.
Как и все расширенные функции, написанные в R, %>% несет много накладных расходов, поэтому не используйте его в циклах (это включает в себя неявные циклы, такие как семейство *apply или групповые петли в пакетах, таких как dplyr или data.table). Вот пример:
library(magrittr)
x = 1:10
system.time({for(i in 1:1e5) identity(x)})
# user system elapsed
# 0.07 0.00 0.08
system.time({for(i in 1:1e5) x %>% identity})
# user system elapsed
# 15.39 0.00 16.68
Добавление зависимостей к пакету не должно восприниматься слишком легко. Говоря в целом, каждый пакет, от которого зависит ваш пакет, является риском для будущего обслуживания всякий раз, когда обновление зависимостей, или в случае, если зависимость останавливается поддерживаются. Это также делает его (немного) сложнее для людей, чтобы установить ваш пакет - хотя это заметно только в тех случаях, когда интернет-соединение ненадежно. Но если кто-то хочет поместить ваш пакет на флэш-накопитель для установки где-нибудь, им также необходимо убедиться, что у них есть все ваши зависимости (и зависимости ваших зависимостей...).
База R и пакеты по умолчанию имеют долгую историю, и R-Core очень осознает, что не вносит изменений, которые будут ломать нисходящие зависимости. magrittr намного новее, похоже, что он был первым на CRAN в феврале 2014 года.
Практически говоря, magrittr была стабильной и кажется низкой зависимостью от риска. Особенно, если вы импортируете только %>% и игнорируете более эзотерические операторы, которые он предоставляет (как это делают dplyr, tidyr и т.д.), Вы, вероятно, вполне безопасны. Его популярность почти гарантирует, что даже если ее создатель откажется от нее, кто-то возьмет на себя обслуживание.
Парадигма трубопровода инвертирует кажущийся порядок применения функций по сравнению со стандартным функциональным программированием. Независимо от того, имеет ли это неблагоприятные последствия, зависит от функции семиотики (моя первоначальная ошибка была предназначена для "семантики", но spielchucker, хотя я имел в виду semiotics, и это казалось ОК). Мне кажется, что трубопровод создает код, который менее читабельен, но это потому, что я тренировал свой мозг, чтобы посмотреть на кодирование из "наизнанку". Для сравнения:
y <- func3 ( func2( func1( x) ) )
y <- x %>% func1 %>% func2 %>% func3
По моему мнению, первый из них более читабельен, поскольку информация "течет" наружу (и последовательно влево) и заканчивается в самой левой позиции y, где, когда информация во втором идет вправо и затем "поворачивается и отправляется влево". Парадигма трубопровода также позволяет использовать приложение без аргументов, которое, я думаю, увеличивает вероятность ошибки. Программирование R только с использованием позиционного параметра часто приводит к сообщениям об ошибках, которые являются полностью непостижимыми, тогда как дисциплинирование всегда (или почти всегда) использование имен аргументов имеет гораздо более информативные сообщения об ошибках.
Мои предпочтения были бы для парадигмы трубопровода, которая имела бы последовательное направление:
y <- func3 %<% func2 %<% func1 %<% x
# Or
x %>% func1 %>% func2 %>% func3 -> y
И я думаю, что это была часть оригинального дизайна pkg- magrittr, который, я считаю, включал "левый канал", а также "правую трубку". Таким образом, это, вероятно, проблема дизайна человеческих факторов. R имеет право на правую ассоциативность, и типичный пользователь парадигмы трубопровода dplyr/magrittr обычно подчиняется этому правилу. У меня, вероятно, синдром жесткого мозга, и все, что вы, молодые парни, вероятно, будущее, поэтому вы делаете свой выбор. Я действительно восхищаюсь целью Хэдли по рационализации ввода и обработки данных, чтобы файлы и SQL-серверы рассматривались как обобщенные последовательные устройства.
Пример, предложенный Дэвидом Робинсоном, предполагает, что отслеживание аргументов является большой проблемой, и я полностью согласен. В моем обычном подходе используются вкладки и пробелы, чтобы выделить иерархию:
func3 ( func2(
func1(x, a), # think we need an extra comma here
b, c), # and here
d, e, f)
x %>% func1(a) %>% func2(b, c) %>% func3(d, e, f)
Понятно, что это облегчается с помощью редактора, поддерживающего синтаксис, при проверке отсутствующих запятых или скобок, но в примере выше, который не был выполнен с одним, метод stacking/spacing показывает, что я считаю синтаксической ошибкой. (Я также быстро добавляю имена аргументов при возникновении трудностей, но я думаю, что это будет одинаково применимо к тактике кода трубопровода.)