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

Комментарии 78

# функциональную версию функции factorial из главы 12

Так это фрагмент книги?
Да. Это мое авторское дополнение в книгу Starting Out with Python, которую я перевел. Можете свериться с оригиналом))

Авторское дополнение в чужую книгу? Это вообще как?

Открывая статью по функциональному подходу в python, ожидаешь map, filter, reduce, и что-то по стандартной библиотеке типа модуля operator. Вместо этого лямбды, вложенные функции и тернарные операторы.


Видя конвейеры, ожидаешь yield, но никак не императивный list.append.

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

Пнятно. Вопрос уровня джуника: что такое итераторы, чем итераторы отличаются от генераторов?


Если намёк не понятен: с целью статьи, которую вы себе сами поставили, вы не справились. "Пора за парты"

Итератор — это объекты, которые используют метод next() для получения следующего значения последовательности. Генератор — это функция, которая производит или выдает последовательность значений с использованием метода yield.

А в чем проблема? Вы можете просто без выкрутас и выпячивания сказать, что вот тут я сделал опечатку/ошибку? Комплексы… одни комплексы…
У вас есть возражения по сути поста, или же вы судите только по одежке, которая, как ВАМ кажется, не так скроена)))? Аргументы в студию, плиз
У вас есть возражения по сути поста

Язык python подтяните хотя бы до уровня джуника, вот и все возражения

Значит, по сути вопроса никаких возражений. Пока что с вашей стороны пустое бла-бла-бла…

Стиль изложения напоминает учебник для старших классов

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

"Лес(хвойный)"(идея) не соответствует табличке при входе ("Тропические леса Амазонки").


Цель — продемонстрировать именно конвейер

А название статьи такое всеобъемлющее — "Функциональное ядро на Python"

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

Хм. Теперь немного лучше — "Функциональное ядро в виде конвейера на Python".
Хочу спросить — а в каком ещё виде встречаются функциональные ядра, кроме как в виде конвейера?
И какие ещё бывают ядра? Подозреваю, объектно-ориентированные и императивные.
Пушечные и клеточные не предлагать.


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

Бывают в виде двоичного дерева и ориентированного ациклического графа, например. Только без напыщенности. Проще надо быть, проще. Ушло некоторое время на то, чтобы освоится с форматированием.
Только без напыщенности. Проще надо быть, проще.

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

)) Принято. Благодарю за подсказку. Поменял введение в статье.
Главная задача этого поста – показать один мало применяемый на языке Python архитектурный шаблон под названием «функциональное ядро — императивная оболочка», в котором функциональное программирование смешивается с императивным программированием в попытке свести на нет недостатки каждого из них. Известно, что функциональные языки слабы при взаимодействии с «реальным миром», в частности с вводом данных пользователем, взаимодействием с графическим интерфейсом или другими операциями ввода-вывода.
Я заметил на хабре одну неприятную вещь — тут практически отсутствует сотрудничество и взаимопомощь. Наверно невдомек, что автору требуется немало усилий, чтобы собрать материал и написать статью. Хотя бы за это нужно уважать их труд. А сотрудничество приведет только повышению качества материалов.

За последние 7 дней с тех пор, как я разместил тут первый аргументированный пост, я услышал безосновательные призывы к запрету для меня доступа к профессии, обвинении меня в полной некомпетентности и просто грубость. Из психологии знаю, что подобного рода суждения характерны для еще несформировавшихся личностей либо закомплексованных людей. Надеюсь, что они не представляют большинство профессионального сообщества.

Шаблоны поведения «на шоссе» не стоит переносить в интеллектуальную сферу.
Я заметил на хабре одну неприятную вещь — тут практически отсутствует сотрудничество и взаимопомощь. Наверно невдомек, что автору требуется немало усилий, чтобы собрать материал и написать статью. Хотя бы за это нужно уважать их труд

Привыкайте, таковы особенности крупных ресурсов. Тут непрерывно проходит огромное количество материалов, и большинство из них низкого качества. Помогать и поддерживать все эти «немалые усилия авторов» желание пропадает примерно после недели присутствия на Хабре. Поэтому поддерживают (действительно поддерживают) те статьи, в которых изначально есть ценность, но есть устранимые недостатки. Статьи, которые для основной аудитории Хабра не имеют ценности, чаще просто ругают :)
Учебники для старшеклассников, к слову, не имеют ценности для основной аудитории Хабра. Да, ваша статья будет в топе выдачи поисковиков, свои просмотры вы получите. Но реакция аудитории будет вот такая.
Да, уж, «полив ушатами ледяной воды» — это стиль не только вашего портала, но и всей страны. Но все же эмоциональщина должна быть за пределами обмена мыслями. Разве я не прав? Базар должен быть на базаре…
вашего портала

Это не мой портал. Я сюда захожу исключительно почитать что-то мне интересное и почесать языком в досужее время.
Но все же эмоциональщина должна быть за пределами обмена мыслями.

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

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

Но даже если это изложение и страдает от этого, то зачем запикивать. Просто пройти мимо или вежливо указать… нельзя что-ли? Но аргументов нет. Даже для научпопа этот базар неприемлем.

10 дней я не переживу. Брошу-ка я это гиблое дело, хотя материалы есть. мазохизм — это не ко мне)
Образованный человек в любой среде должен оставаться образованным.

Образованный, умный и вежливый — это три ортогональных измерения.
Даже значительная часть публики небезызвестного udaff.com — далеко не глупые люди, а некоторые авторы аффтары весьма талантливы. Но при этом внутривидовые отношения там сами (возможно) знаете, какие. Притом, что тамошним завсегдатаям уже в массе своей по 40-50 лет исполнилось :)
Вы играете в слова… Эти понятия всегда были взаимосвязаны.

Однако ж, вы только посмотрите на минуса напротив всех моих комментов!))

Я вижу, тут подавляющее число — образованцы…

)
Вы играете в слова… Эти понятия всегда были взаимосвязаны.

Ни в коем случае. Ум — это способность анализировать, делать выводы, принимать решения, хороший ум это ещё и быстро делает, в режиме реального времени. Образование, это библиотека знаний в долговременной памяти. Собственно, в аналогии с компьютером ум — это процессор, образование — свалка данных на винте. Два слабо связанных между собой качества. К примеру, цыганский пацан, не умеющий даже читать, но постоянно решавший проблемы «как найти себе пожрать» и «как выкрутиться из ситуации, чтобы морду не набили», на поверку окажется намного умнее, чем условный отличник школы, который тщательно вызубрил литературу, высшую математику и биологию. Впрочем, отличники тоже бывают разные, одни добиваются высоких оценок за счёт прилежности, другие как раз за счёт ума, но это другая история, не будем углубляться в дебри.
А вежливость вообще зависит от воспитания, индивидуального психотипа и банально от настроения, но никак не от образования или ума.
))
Это слишком широкие понятия, чтобы рассуждать однозначно. НО:
Разве может умный человек позволить себе распущенность? Ведь он же умный и предвидит последствия…
А из образованности вытекает вежливость, а вежливость предполагает, что она исходит от образованного, хотя не всегда.
Разве может умный человек позволить себе распущенность?

Да, вполне. Это раньше общество съедало за что-то непотребное. Сейчас-то приемлемые рамки поведения стали намного шире.
Ведь он же умный и предвидит последствия…

Хм. А какие могут быть последствия в том, чтобы в грубоватой форме откомментировать контент неизвестного человека в интернетах, которого в общем-то никогда в жизни не увидишь? А если и вдруг и встретитесь, все равно друг друга не узнаете.
А из образованности вытекает вежливость

Мне лень искать ссылки, но поверьте на слово, если хотите, что исследования показывают, что люди с развитым интеллектом матерятся чаще, чем среднестатистические :)
))
Ладно. Не вижу предмета спора. Но
Я уже 4-й года подписан в TradingView, мировом портале для экономистов и трейдеров. Мои первые скрипты на pinescript были наивными, но никто ни разу не позволил себе грубость и все такое. Уверен, даже ставили плюсы авансом. С тех пор мои скрипты регулярно входят в пятерку лучших, а за это время так и не было никаких инсинуаций. Я не в плане выпячивания, а в плане отношения — сомневаюсь, что у меня что-то получилось бы, если бы сыпались оскорбления и пр. мерзости. Замечу, что все мое общение там проходит в английском сегменте, и я, имея негативный опыт, даже не помышляю переходить на русский сегмент.

Мне кажется, проблема в самих наших людях — общество болеет, а те кто здоров, принимает статус-кво как должное. рационализирует.

Сам в первой статье хамил налево и направо — а теперь удивляется. Смешно

Улыбнуло про «сам хамил»
Ну-ну. Т.е. даже попадание в RO на несколько дней (скорее всего — по жалобе на хамство) ничему клиента не научило.
вы не устали еще выпячиваться)
Айтишному сообществу присущ снобизм — это проистекает из того, что исторически так сложилось, что учишься сам. Не на чём-то готовом, а лопатишь большие горы информации, выискивая нужную тебе сам. Соответственно, появляется существенный повод обоснованно считать, что главный рабочий орган этого процесса — мозг — так же больше прокачан по сравнению с другими, как у дровосека спина и руки или у певца горло и диафрагма.
Я называю такие рассуждения рационализацией сложившегося ненормального статус-кво. Говорю это, имея современный опыт общения в англоязычном сегменте и опыт общения со спецами до нашей эры, когда компьютеры занимали комнаты. Я тогда, молодой спец из непрофильной кафедры, только осваивал Pascal, и ощущал бескорыстную помощь.
Он же сложился не просто так. Если по Паскалю на английском примерно три миллиарда учебников и методичек, и это один базовый вектор, то на русском их три с половиной штуки, и это другой базовый вектор. Оба вектора задают дальнейшее складывание статусов-кво.
)) Вы снова рационализируете тренд на невежливое и не бережное общение.
Я исхожу из того, что никто никому ничего не должен. Так жить проще.
Атомизация общества в действии. Не хочу скатываться к назидательству. Замечу только, что жить в обществе и быть свободным от него невозможно.

Я тоже никому ничего не обязан. Но при этом меня воспитывали относиться с априорным уважением и не позволять себе унижать кого-либо. Это ничего мне не стоит. Если мне не нравится, я прохожу мимо. Если вижу ошибку, сообщаю, что вот тут вот ошибка, без выкрутасов. Все просто.
Так легко прослыть занудой. И, кстати, занудливость у вас достаточно сильная.
Мда… Если мне не нравится, я прохожу мимо.
Хорошо, на зануде и остановимся)
Я тоже никому ничего не обязан. Но при этом меня воспитывали относиться с априорным уважением и не позволять себе унижать кого-либо. Это ничего мне не стоит

Скажем так, способ вашего воспитания — не единственный, и не факт, что самый правильный. Если все будут проходить мимо плохих штук, то кто же будет с ними бороться?
И да, если что, я тоже зануда :)
НЛО прилетело и опубликовало эту надпись здесь
служба-служба-СЕРВИС-служба… паттерн

Автор просил конструктивной критики, и я постараюсь быть конструктивным. Будучи апологетом и популяризатором функционального подхода, я вижу, что статьи в которых ФП подаëтся, как "ещё один способ решить задачу" вызывают у читателей раздражение. Для того, чтобы убедить в эффективности функционального мышления и нужны примеры, в которых сложное остаётся сложным, но становится управляемым, доказуемым, гибким, расширяемым, универсальным, теоретически согласованным и так далее. Простые примеры, которые становятся сложнее от использования функциональной парадигмы не работают. Ту же композицию функций (базовое свойство, делающее функции моноидом, позволяющее делать то, что называется fusion, имеющее мощную теоретическую основу) лучше демонстрировать не на примере арифметических вычислений, а на примере бизнес-логики хитрой игры, транслятора DSL или принимающего решения искусственного интеллекта, где выделение функционального ядра, действительно позволяет увидеть что использование чистых функций даëт какие-то преимущества перед иными способами организации кода. На простых примерах использование композиции в не предназначенном для этого языке (без макросов и метапрограммирования, без легковесного каррирования, статической типизации, data-driven подхода и тому подобных инструментов) превращается во вкусовщину и аскезу и вызывает у новичков, а тем более, у профи, недоумение. Функциональное программирование в Python — это функции высших порядков, замыкания, оптимизация хвостовой рекурсии и комбинаторы обработки коллекций. Всë это позволяет написать и лямбда исчисление, и функторы и комонады и линзы… Но они не нужны в Python, они не облегчат жизнь программиста и не окупят потраченное на изучение этих концепций время, при том, что это классные штуки, открывающие массу возможностей, но в своей экосистеме.

Признайтесь, что этот кусок был взят из текста для другого языка. Почему я так думаю? Настоящая хвостовая рекурсия на Python невозможна. Python не выполняет никакой оптимизации стека… Хотя могу и ошибаться, т.к. приводимые мной тут примеры были написаны 3 года назад, и с тех пор мои интересы несколько поменялись.

Но вашу аргументацию принимаю и считаю ее весомой. У меня, кстати, есть несколько функциональных ядер для моделей ML, но есть и много функциональных игрушек. Но тут их не оценят, а я как-то потерял интерес сюда заходить после ушата хейта за последние дни.

Вы меня смутили тем, что в Python нет оптимизиции хвостовой рекурсии. Оказалось, что, действительно, нет, но с помощью декораторов можно написать рекурсивную функцию, а она будет переписана в цикл. Непонятно только зачем писать рекурсию там, где есть циклы… а если задача принципиально рекурсивна (использует рекурсивные типы), то хвостовая рекурсия не сделает жизнь проще.
Мне кажется, вам стоит рассказывать именно о непростых примерах, даже не обязательно полезных, но существенно более сложных чем факториал и числа Фибоначчи. Если в вашем арсенале они есть, делитесь!

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

Это не совсем так. Можно написать полностью функциональный код, превратив итеративный процесс в цикл. При этом он сохранит чистоту, прозрачность по ссылкам и даже денотационную и аксиоматическую семантику. Собственно, это и делают трансляторы PureScript, Elm, и даже GHC. Рекурсия необходима, если в языке нет иных способов организации цикла, или если задача не является примитивно-рекурсивной. Во всех остальных случаях функциональность и рекурсия помогают друг другу, но не являются необходимыми.

Разумеется, можно и с циклом. Но мы же говорим, по крайней мере, я имею в виду *чистый* функциональный код, основанный на, опять же, чистом функциональном мышлении. Цикл вносит процедурность. Изначально ЛИСП не имел циклов, только рекурсию.

На Python функциональность имплементируется, именно, так, как вы говорите. Пишутся функции с итерациями и в императивном стиле и даже в ООП-стиле. Потом они каррирутся и вуаля. Вот пример приведения объектного метода из точечной нотации в функциональный вид:
def splittext(t): return t.splitlines()

которую можно вставлять в тот же конвейер.

Чистая функция не перестанет быть чистой от цикла внутри.

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

Приведите определение чистой функции.

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

В моем репо есть пример программы, где нет ни одного присваивания — только функции

Ваше определение отличается от классического. В частности, про присваивание, мне кажется, вы сами придумали. Достаточно, чтобы результат функции был одинаковый для одинаковых аргументов, и в процессе исполнения не было сайд-эфектов https://en.m.wikipedia.org/wiki/Pure_function. С практической точки зрения это даёт возможность заменять вызовов функции её результатом, когда он известен, и это не влияет на поведение программы (ссылочная прозрачность). Если эти ограничения соблюдаются, то детали реализации не должны волновать.

А вы не читайте по утрам «советских газет» (с) ))

Русскоязычное Вики — это средство по насаждению заблуждений. Надо пользоваться корпоративными глоссариями, специализированными словарями и постами лидеров направлений. Одно только unit testing как «модульное тестирование» вызывает во мне негодование)). Unit в данном контексте — это единица кода, и она может быть строкой кода, блоком кода, функцией и только потом модулем. Правильный перевод мог бы быть «посегментное тестирование». А термин data mining как интеллектуальный анализ вызывает хохот. А что любой другой анализ НЕ интеллектуальный? Правильный перевод основан на горнодобывающей метафоре — добыча полезных ископаемых из данных, или же просто добыча полезных сведений из данных. И таких примеров десятки, если не больше.

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

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

Материал позаимствован на просторах иностранного интернета и не только. Присваивание означает наличие состояния и возможность иметь сайд-эффекты (побочные явления)

Я же дал ссылку на определение в англоязычной вики и почти дословный перевод). Более подробно и с контекстом — зачем вообще все это нужно — неплохо описано у Бартоша https://bartoszmilewski.com/2014/11/24/types-and-functions/

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

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


Также en.wikipedia.org/wiki/Side_effect_(computer_science)

Еще один пример программы без присвоений.

Локальная переменная определённо не является "волатильным объектом".

Под волатильностью имеется в виду мутируемость. Любая переменная, локальная или глобальная, от того и называется ПЕРЕМЕННОЙ, что она мутирует.

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

См. книгу

Однако поправлюсь в части, касающейся ОДНОразового присваивания:
Функциональные программы не имеют инструкций присваивания, то есть значение переменной в функциональной программе никогда не модифицируется после определения.

Отсюда

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

Конкретно в терминах компиляции и С/С++ все верно. Здесь же речь о ФП. Автор книги, цитату из которой я привел, имеет в виду более широкое значение, как способность модифицировать свое значение.

В англ.яз volatile = переменный, среди прочих значений

Даже если в языке два слова являются синонимами, как только они становятся терминами — они обрастают дополнительными смыслами и перестают быть взаимозаменяемыми.


volatile и mutable — это разные термины, даже в ФП их не смешивают.

автор сказал то, что сказал. Он не говорил о компиляторах))
>что вы имеете в виду, когда говорите о посторонних эффектах и является ли присваивание его проявлением?

А вы читать не умеете, похоже… по присланном вам ссылке, самое начало:

In computer programming, a pure function is a function that has the following properties:[1][2]

The function return values are identical for identical arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams).
The function application has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or input/output streams).

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


И эти люди будут запрещать мне ковыряться в носу (с) анекдот.
В комменте все прекрасно, кроме последнего. Мы не на базаре, не так ли. Это ресурс делового общения… Если хотите общаться, то надо вести себя по-джентельменски. Считайте это просто замечанием, не уроком, упаси боже. Мы разучились общаться — лаемся в основном.

ЛЮБАЯ операция закрепления за переменной значения чревата тем, что оно может быть перезаписано. Точка
С какой стати вы решили, что имеете право тут кого-то учить? Я буду указывать на ошибки в том тоне, в каком сочту нужным. Можете жаловаться (с)
В функциональных языках конвейеры находят широкое применение, и для их имплементирования даже существуют специальные синтаксические конструкции

pipe это пример вызова функции (function application), где функция и ее аргумент просто переставлены местами. Вызывать функции можно и в функциональных, и в императивных языках. Поэтому наличии такой конструкции в коде ещё ни о чем не говорит. Возможно вы выбрали не самый удачный пример. В том же F# пайп оператор обычно используется из-за особенностей местного тайпчекера, который выводит типы слева направо, но это отнюдь не является признаком ФП-ориентированного кода. Часто это просто завуалированная императивщина.


Один из интересных вопросов в программировании это как собрать сложную программу из простых. ФП предлагает использовать только чистые функции и их композицию (composition). Это даёт некоторые гарантии того, что составленная таким образом программа будет работать правильно. Наличие только чистых функций может служить признаком ФП-ориентированной программы. Но в примерах в статье это явно не так — обычный императивный код с вводом/выводом и исключениями. Добавление ещё одной абстракции в виде pipe не делает его функциониональным. Возможно в этом основная претензия читателей.

Весомо). Однако не следует сводить pipe к особенностям F#. Он является неотъемлемой частью ФП еще со времен LISP. Гляньте сюда, если что.
Конвейер в том виде, который я предлагаю, позволяет (1) четче мониторить входы и выходы каждого шага внутри конвейера (2) легко отлаживать любой шаг и соответственно отлавливать дефекты, вставляя шаг debug, (3) но главное концентрировать всю логику в одном месте, которую легко уловить одним взглядом. Это что-то вроде нисходящего стиля программирования: корень — это pipe.

В Python от императивности никуда не деться, и поэтому предлагается имплементировать функциональное ядро.

Lisp мультипарадигменный. Вы можете находить похожие инструменты в разных местах, это нормально. Но раз уж речь шла о стиле программирования, то ситуации и способы их применения, диктуемые тем или иным стилем, будут совершенно разные. Даже в рамках одного языка. Причем, какие то стили могут оказываться более уместными, нежели другие. Отчасти это вопрос конъюнктуры. Но как бы то ни было, python последние лет 15 развивался в сторону различного синтаксического сахара, вместо обобщенных функций. map/reduce/filter на полном серьёзе даже собирались выпиливать в пользу listcompr
https://www.artima.com/weblogs/viewpost.jsp?thread=98196 Поэтому примеры вызывают некоторое недоумение (ну да и так можно, но смысл?).


Вообще, священный Грааль в ФП это compose. В интро про ФП я ожидал увидеть скорее его.

Вот тут я полностью согласен. Python скорее служит хорошим введением в ФП, если брать его функционал map/filter/reduce/zip и functools. Отсутствие оптимизации стека для хвостовой рекурсии в пределе делает невозможным полное и чистое ФП. Вместе с тем внедрение его принципов помогает четче излагать логику, избегать громоздкости ООП и смотреть на задачу под иным функциональным углом зрения, который ближе тому, как мы думаем.

Я наверно даже включу этот свой пассаж в статью)

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


У ФП есть одна небольшая проблема — это крутой порог входа. Ну то есть в начале все более-менее понятно, но очень быстро оказывается, что на одних только простеньких функциях и compose ни чего годного не построишь — их становится просто слишком много. Это как пытаться из отдельных песчинок собрать целое здание. Чтобы бороться со сложностью нужны более крупные и мощные паттерны. И тут перед вами внезапно появляется небольшое препятствие размером с Эверест — теоркат с его всем известными моноидами в категории эндофункторов. Бартош на одном из своих выступлений шутил, что изучению теорката он посвятил всю свою сознательную жизнь, а теперь приходят программисты и просят научить их как-нибудь по-быстрому за месяц. Год-полтора вполне реальный срок.

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

К сожалению, у нас ФП уделяется мало внимания. Рад, что есть сторонники)

Я отнюдь не сторонник, а практик. Просто ещё интересуюсь теорией, и хорошо понимаю, что ФП это специфичная модель, и отнюдь не панацея. Регулярно кто-то пытается хайпануть на экзотике не имея достаточно экспертизы, поэтому научпоп кишит бессмысленными выкрутасами и карго культом, от которых больше вреда чем пользы.

Категоричность всегда наносит больше вреда. Вам не стоит надевать на себя шлем, брать дубинку и превращаться в космонавта)

Повторяю, больше пользы — подсказывать пути, выходы и деликатно поправлять.)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Публикации

Истории