Чудеса функционального программирования
Собственно, кратенько два обзора:
3D шутер Frag.
Создан на Haskell. Несмотря на всю его "ленивость" на нем можно писать и такие вот игрушки. Шутер очень похож на Quake3 и написан одним человеком. В нем использовался ранее разработанный DSL Yampa -- язык для гибридных систем с концепцией реагирующих систем (Functional Reactive Programming - FRP). Вся похожесть вытекает из поддержки The Quake 3 BSP level format, Q3Map2, and the MD3 format for models and animations. На странице можно глянуть скриншоты, симпатично.
Мозаический менеджер окон xmonad. То же Haskell, за ссылку спасибо squirl.
Ну конечно самое удивительное для программиста то, что первая версия была написана в 500 строк кода =). А так мозаический менеджер окон отличается от классических тем, что области окон не перекрываются -- пора выбрасывать мышь =). Здесь можно глянуть видеоролик , а здесь полюбоватся скриншотами.
Так же нашлась статья по его установке Как бросить обычные менеджеры окон и начать жить.
Например, f(0)=0 и f(1)=1. Функций которые удовлетворяют этим условиям дофига. Как функциональный язык будет угадывать какую именно функцию из этого 'дофига' автор хочет получить?
Функция имеет тело, то есть описание зависимости выходных параметров от входных. Такая зависимость может быть задана как аналитически, графичекси так и таблично.
Здесь основное отличие в том что используется модель вычисления без состояний -- функция будет одинаково работать на одинаковых входных данных.
А я вот постигаю функциональное программирование на Python.
Можно комбинировать: там где не могу изобразить функционально или питон не позволяет, скатываюсь до ООП... :)
Говорят еще JavaScript можно использовать как функциональный ЯП.
Говорят еще JavaScript можно использовать как функциональный ЯП.
Не то чтоб как функцинальный, но некоторые элементы ФП там есть.
Ресурсов жрет значительно меньше по сравнению в тем же PHP интерпретатором. Если в PHP для удержания коннекта на стриминге уходит несколько мегабайт, то тут 50кБ это уже типа вау как много. Как следсвие куча съкономленых ресурсов, на том же железе я могу обработать больше запросов.
Лично для меня это сейчас главное.
В некотором урезанном виде замыкания есть в Java (в виде локальных классов), и, кажется, анонимные делегаты C£ тоже что-то похожее.
Но вообще - согласен с мнением, что хаскелл - самый зрелый и мощный ФЯ из существующих чисто функциональных языков.
Можно сказать - лексическая оболочка над типизированным лямбда-исчислением ;)
Анонимные делегаты замыкаются на контекст, т. е. могут быть использованы функциями высшего порядка полноценно. Только вот синтаксис у них больно нечеловеческий. В си паунд 3 введены нормальные лямбда-выражения.
Мне вот лично всем ФП нравится, но несколько смущает отсутствие (или просто моё незнание?) вменяемых методик проектирования систем для чистых ФЯП. С другой стороны, после OCaml и Nemerle возвращаться к традиционному ООП как-то не хочется :)
Да, C# на фоне Nemerle смотрится очень слабо.
Лямбда-выражения в C# это отстой. Нормального функционального типа (аля int*string -> float) так и не сделали, а то что сделали, порой совсем не нужно. Их использование оправданно только в контексте LINQ, в остальном полный бесполезняк.
З.Ы. Почитываю книжку по Хаскеллю в свободное время.
Лямбда-выражения в C# это отстой. Нормального функционального типа (аля int*string -> float) так и не сделали, а то что сделали, порой совсем не нужно. Их использование оправданно только в контексте LINQ, в остальном полный бесполезняк.
З.Ы. Почитываю книжку по Хаскеллю в свободное время.
Я тоже, только вот его маловато (времени).
Учитывая замечания Green и Der Meister - пока что Python/Ruby мне кажутся более практическими, что ли, языками (на Раби я писал несколько утилит для обработки CSV-файлов). А Хаскелл - языком, изучая который можно понять все тонкости и принципы ФП - потому что это и есть кристаллизация всех принципов ФП, но несколько сложноватым для практического применения.
У меня скудный опыт в ФП, но приведу один маленький пример.
Год назад я уговорил препода по ЯП в универе попробовать Хаскелл вместо Пролога, который он обычно до этого давал.
Вещи вроде complex list/map/.. processing писались буквально в 3 строчки. Буквально (и выглядели по человечески красиво и по программистски элегантно). Но потом понадобилось сделать тривиальнейшую вещь - чтение из текстового файла (ленивое, конечно), вычисление чего-то и запись результата в файл.
Логика обработки была написана за минут 15 (по сути, потраченных на поиск и изучение логики работы нескольких стандартных функций). А вот работа с файлами... :rolleyes:
Я потратил день на чтение статей - что такое монада, сначала сугубо математических, из теории категорий, потом более приземленных и уже конкретно по хаскеллу.
Ближе к вечеру я решил, что вооружен теоретически и можно смело писать код. Я написал 5 строк, запустил в интерпретаторе. Они не работали, описание ошибки я долго не мог понять. В итоге проблема была кажется в том, что в одном месте "грязный" код (содержащий монады) вызывался из "чистого" (строго функционального, обеспечивающего отсутствие побочных эффектов и проч.), что запрещено в Haskell, где функциональное ядро языка четко отделено от подсистемы ввода-вывода.
Я час гуглил и написал по образцу некоторых примеров что-то работающее (кстати, код тех лабораторных остался, могу показать если кому вдруг станет интересно).
Я конечно, не говорю что я великий знаток хаскелла, не знаю как реализовано в программах указанных выше взаимодействие с системными API - но пока что мне кажется слабым местом (слабым с точки зрения удобства и простоты реализаций многих вещей) - вот эти связки, созданные для организации взаимодействия чистейшего функционального ядра языка и внешних API (событийных, в процедурном/OOP стиле и т.п.)
Надо будет разобраться, как это сделано в Питоне, и почему именно так. Объяснятся ли это тем, что Питон - не чисто функциональный язык, или чем-то еще.
P.S.
http://www.rsdn.ru/article/haskell/haskell_part1.xml
http://www.rsdn.ru/article/haskell/haskell_part2.xml
По этим статьям я пробовал :)
Может, кому пригодится...
Мне вот лично всем ФП нравится, но несколько смущает отсутствие (или просто моё незнание?) вменяемых методик проектирования систем для чистых ФЯП.
Мне так думается, что нужно просто смотреть код уже написаных и надежных приложений. Да и материалы то есть, другой вопрос, что в рунете их практически нет. Тут на родном языке порой совершенно не понимаешь, о чем вообще толкует автор, а уж читать на иностранном новые идеи и понятия это вообще труба. Поэтому и кажется, что почитать то нечего. Есть. Но нужно искать и искать, а потом читать и читать, но только на английском.
Но потом понадобилось сделать тривиальнейшую вещь - чтение из текстового файла (ленивое, конечно), вычисление чего-то и запись результата в файл.
Логика обработки была написана за минут 15 (по сути, потраченных на поиск и изучение логики работы нескольких стандартных функций). А вот работа с файлами... :rolleyes:
Не знаю, как там в хаскеле. Но вот я беру к примеру схожу проблему которая возникла буквально только что:
http://groups.google.com/group/erlang-russian/browse_thread/thread/39c8c2fb2ae3f2cb?hl=ru
Голову ломать разными монадами совершенно не нужно. Просто понимаешь базовую основу и пишешь.
Вообще меня Erlang очень сильно впечатляет. Там ведь не только сам язык, так сразу идет VM (и как следствие автоматическое портирование приложения на все платформы где VM может работать, а список этот приличный), а так же это еще и OTP где реализовано большая часть того, что может понадобиться в практике уже из коробки. Требуется лишь небольшая обязка callback модулями. Я уже не говорю о потребляемых ресурсах. Достаточно посмотреть на тот же ejabberd или Yaws. И сильно подозреваю, что в ближайшие годы будет расти интерес именно к этому языку (по крайне мере в рунете) как к языку общего назначения в контексте разработки под веб.
Вещи вроде complex list/map/.. processing писались буквально в 3 строчки. Буквально (и выглядели по человечески красиво и по программистски элегантно).
Согласен. Сейчас когда я порой пишу PHP код не, да и думается, что вот в Erlang-е вот этот кусок будет в коде и короче и нагляднее и удобнее.
Я бы с большим удовольствием занялся бы разработкой на данном языке в кем то, кто в нем очень сильно сечет. Но как ни жаль такого в ближайшие годы наверное не предвидиться. Если в столице людей по этому делу можно пересчитать по пальцам, то у нас в провинции их отродяся небыло )