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

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

У вас ошибка в статье:

# y = k * x + b
def get_linear(k, b):
return lambda x: k * x + b

# y = k * x^2 + b
def get_linear(k, b):
return lambda x: k * x ** 2 + b

Вторая функция видимо должна называться get_poly2 что-ли
да, спасибо, поправил
>> shifter, x_scaler, y_scaler, combine — это функции второго порядка, т.к. они принимают не только скалярные аргументы, но и другие функции

Вроде как, функции, которые принимают как параметры другие функции, называются функциями высшего порядка. Функции второго порядка это тоже самое что функции высшего порядка?

Разумеется. Функция второго порядка принимает «обычные» функции (первого порядка), хотя можно написать фукнцию например третьего порядка, которая принимает функцию второго (которая, в свою очередь, принимает функцию первого)
Функции первого, второго и т.д. порядков — это терминология из ФП или «самоназвание»? Обычно в документации упоминаются только функции высшего порядка. Может стоит определиться уточнить термины, что бы не было путаницы?

Кстати, гугл тоже ничего не знает о ваших функциях :)
Не знаю, возможно «самоназвание», я лишь пояснил, что имел в виду автор
Гугл слишком молодой. Недавно попадалась книжка (к сожалению, было совсем неинтересно запоминать её название и автора) по какой-то высокой математике, в которой были даны примерно такие определения:
Функция, оперирующая скалярами — 1 порядок.
Функция, среди аргументов которой есть функция n порядка, или она таковую возвращает, — n+1 порядок.
Высший порядок — n>=2.
Дальше я ту книжку не читал, но там ещё много страниц про функан было.
Да, вы правы, есть термин «функции высшего порядка» :) Исправил. «Функции первого порядка» — тоже вроде как нет такого понятия, поэтому я их изменил на «простые функции»
Заметок по функцианальному программированию не хватает на хабре.

А ведь тема очень интересная, и если другие языки/парадигмы способствуют идеям написать свою web-framework, компилятор под .net/java, своё мегакрутое ORM или флейму императивный C# vs. императивная Java, то ФМ способствует тому, что программист начитает интересоваться lambda-исчеслением, мат.логикой/исчеслением секвенций, системой категорий и автоматическими системами доказательств. По мойму это здорово.

Сам в последние время занимаюсь прикладным программированием на nemerle (гибридный язык) активно используя алгебраические типы данных, pattern matching и стремясь к чистоте методов, функций; а так же читаю статьи про ФП (в основном haskell) и очень хочится во всем этом разобраться и попробывать haskell, так как начинаю видеть, что решения на нем получаются более правильными и простыми. Тем, кто только начинает погружаться в мир ФП рекомендую блоги: thesz, deni-ok, рекулярно читать lambda-the-ultimate, а так же познакомиться с статьей Евгения Кирпечева про монады и статьей про многопоточное программирование здесь.
Хочу попробовать написать серию статей про Хаскель, так как информации практической недостаточно, всё сводится к объяснениям монад и достаточно тривиальным примерам, к которым большинство относится достаточно скептически.
А вот примера разработки какой-нибудь несложной программы, но с многопоточностью и ГУИ, я не видел.
Думаю интересно будет проиллюстрировать возможности haskell на примере создания простого языка и реазизации парсера, интерпритатора.
спасибо, статья хорошая, хотя оценки не совсем адекватны.
очень жду продолжения и надеюсь что вы вскорее сможете ее перенести в блог пайтона.
Очень интересная серия, благодарю за ссылку
На rsdn'e есть хорошая статья «Функциональное программирование для всех»: rsdn.ru/article/funcprog/fp.xml
В последнее время про функционарное программирование упоминается все чаще.
Возврат к старым традициям?
… и это не может не радовать. Все больше языков перенимают эти возможности, которые доступны программистам на Lisp или Haskell. Наконец-то рекурсия начинает становиться не чем-то непозволительно дорогим, а вполне рядовым инструментом программиста. Некоторые рантайм-окружения уже даже поддерживают оптимизацию хвостовой рекурсии (тот же CLR, например). На мой взгляд, производительность современных компьютеров дошла до той точки, когда можно применять данные методы без сильной оглядки на производительность.

Увы, некоторые возможности не будут реализованы еще долго — например, те же макры из Lisp. Если такое встроить в какой-нибудь C#, то по производительности это будет хуже, чем рекурсия во времена четырехкилобайтного стека.
С последнем пунктом вы ошибаетесь. Макры идеально встроены в язык nemerle (очень похожий на C#), но в котором бОльшая часть языковых конструкций, таких, как for, if, while,… — макросы. В nemerle можно легко определять свои макросы и тем самым расширять язык. Сами макросы в немерле раскрываются на этапе компиляции и поэтому производительность не падает.
Ух ты, вы меня заинтересовали! Обязательно посмотрю, спасибо.
Кроме всего прочего, функциональный код лучше подходит для автоматического исполнения многопоточно. А Intel/AMD сейчас пропагандируют многоядерность.
Для полноты стоит ещё упомянуть модуль functools.
Спасибо за статью, стало более-менее понятно что ФП из себя представляет.

Вы не затронули тему применения. Для каких задач используется ФП?
Как я и написал, с чистым ФП я дела не имел. Здесь, как я вижу, есть любители Хаскелла, они могут рассказать подробней.

Я занимался с Lisp, а Lisp — это мультипарадигменный язык. Самое сложное и красивое, что мне удавалось реализовать при помощи функционального стиля и что я ни за что не стал бы делать в императивной форме (поскольку мне дорог мой мозг как память) — это задача о семи ферзях. Она очень изящно реализуется рекурсией на списках. Кода не просите, т.к. это было очень давно. Могу лишь подсказать, что это была задача из SICP.

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

На мой взгляд, ООП больше пригодна для программирования сверху-вниз (top-down design, т.е. когда сначала реализуется общая структура системы, а затем уточняются ее детали, реализуются методы и т.п.), в то время как функциональный стиль больше способствует подходу снизу-вверх (bottom-up design, когда сначала пишутся маленькие кусочки будущей системы, а потом синтезируются все более сложные ее части).

Так что, как заключение, я могу сказать что ФП — такой же стиль программирования, доступный каждому продвинутому программисту. Чтобы развеить «мифы» о том, что функциональный стиль и Lisp — чистое теоретизирование, могу посоветовать почитать книгу P. Siebel. Practical Common Lisp, а также M. Pilgrim. Dive Into Python (последняя не конкретно про функциональный стиль, но автор очень умело его использует, на мой взгляд; крайне советую почитать).
Поскольку я одно время довольно плотно занимался с Lisp, я хотел бы немножко рассказать об этом.


Я занимался с Lisp, а Lisp — это мультипарадигменный язык.


Небольшой урок русского языка.
Чем вы занимались с Lisp? Заниматься можно с Катей, Светой и т.п. Правильно говорить «занимался Lisp».
Очень здорово, сейчас как раз делаю диплом на Python, работаю с алгоритмами, где фп очень хорошо применимо. Материалов по фп в Python немного, так что жду продолжения.
Спасибо за статью. ))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории