Комментарии 10
Интересные мысли. Если не сложно — подкиньте ссылок по сабжу.
Мысли из головы, но вот, например, как можно реализовать try/catch в перле. Ещё можно почитать про
with в питоне, про использование блоков в ruby, ну и для полного просветления стоит познакомится с макросами в лиспе.
С точки зрения теории, ваши рассуждения в статье правильные, вопросов нет: убирается избыточность, явно описывается поток управления — всё красиво. Однако в проектах, где над кодом работает большая команда, такие штуки не работают — слишком сильно увеличивается порог вхождения в код. Чтобы дописать новую возможность или исправить ошибку, надо сначала разобраться с вашим подходом, понять все ваши абстракции, задать кучу вопросов коллегам и т.д. Пока пятый сотрудник научится этим добром пользоваться, первый уже застрелится.
Вы из элементарной и легко читаемой программы (пусть в 2 раза более длинной) сделали 4 строчки, которые можно понять, только чётко зная, что делают функции skip и retry, и приложив заметные усилия, чтобы слепить из map, filter, skip и retry картину в голове, что этот код должен делать.
Вы из элементарной и легко читаемой программы (пусть в 2 раза более длинной) сделали 4 строчки, которые можно понять, только чётко зная, что делают функции skip и retry, и приложив заметные усилия, чтобы слепить из map, filter, skip и retry картину в голове, что этот код должен делать.
То же самое можно сказать про любой фреймворк, библиотеку или просто собственные наработки внутри любого достаточно крупного проекта. Однако народ пишет на рельсах, django и jQuery, появляются и широко используются даже такие расширения языка как Moose и меняющие парадигму библиотеки как underscore.js, async.js и Functional Java. А некоторые так и вовсе пишут на разных лиспах, где расширение синтаксиса — повседневная процедура.
А если отбросить теоретические рассуждения, то мы уже используем подобный подход в своей работе. В команде 5 человек, пока никто не застрелился. Кроме того, подобные техники абстракции поощряются несколькими моими open source библиотеками, и люди их используют без проблем.
Так что, хоть некий порог и добавляется, но это вполне практичные вещи.
А если отбросить теоретические рассуждения, то мы уже используем подобный подход в своей работе. В команде 5 человек, пока никто не застрелился. Кроме того, подобные техники абстракции поощряются несколькими моими open source библиотеками, и люди их используют без проблем.
Так что, хоть некий порог и добавляется, но это вполне практичные вещи.
> То же самое можно сказать про любой фреймворк
То же самое говорю и про фреймворки. Пока что-то делаешь типовое, всё ок. Вы не сталкивались с ошибками в коде на каком-нибудь Django? Когда что-то не работает, а что — непонятно. Ловить их — очень увлекательное дело. Сапожники покраснеют, если слушать будут. Тем не менее, их используют, чтобы не изобретать велосипеды.
Понятно, что можно писать, на чём угодно и с какими угодно абстракциями. Просто не факт, что от этого лучше будет. В этом деле важно не переборщить.
То же самое говорю и про фреймворки. Пока что-то делаешь типовое, всё ок. Вы не сталкивались с ошибками в коде на каком-нибудь Django? Когда что-то не работает, а что — непонятно. Ловить их — очень увлекательное дело. Сапожники покраснеют, если слушать будут. Тем не менее, их используют, чтобы не изобретать велосипеды.
Понятно, что можно писать, на чём угодно и с какими угодно абстракциями. Просто не факт, что от этого лучше будет. В этом деле важно не переборщить.
Мне например легче читать функциональний вариант нежели императивный (возможно из за того что я плохо знаком с Python). В результате мы получаем и используем некий DSL, который да, нужно понимать. Минус в том, что этот DSL надо описать, и здесь Python не настолько удобен и местами избыточен. Но надо заметить один факт: мы получаем код, разбитий на маленькие кусочки. Декомпозиция в действии. Каждый кусочек можна расматривать отдельно, и что самое главное на мой взгляд, на основе этих мелким елементов можна построить все более и более сложные блоки, при этом сохраняя простоту и независимость каждого из них. Вот вам и повторное использование кода! Чем больше императивного кода, тем сложнее разобратся что же он делает в конце концов.
И да, и нет. При правильно подобранных названиях и хорошем знании языка такой код читается проще, даже если ты не знаешь конкретной функции. Мне из написанного не нравится только функция keep, её название не самое говорящее (более того, я не очень понимаю, почему skip не может сам справиться с задачей).
И retry, и skip говорят сами за себя. А уж map / filter питонист обязан знать.
И retry, и skip говорят сами за себя. А уж map / filter питонист обязан знать.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Абстрагирование потока управления