На самом деле, в каком-то смысле, этот вопрос не имеет смысл в 2010х, когда большинство (или большинство самых распространенных) языков являются языками многих парадигм. Зачем себя ограничивать только функциональным программированием? Возможно, кому-то ответ покажется очевидным, но если появляются такие статьи как "Десять причин не использовать статически типизированный функциональный язык программирования", то придется дискутировать и объяснять противную точку зрения. «Десять причин...» основаны на иронии и, похоже, автор подразумевает, что упомянутые недостатки даже не требуют обсуждения, а только ироничных замечаний. Но это не так, давайте пройдемся по этим десяти причинам.
Читать полностью »
Рубрика «функциональное программирование» - 47
А есть ли причины использовать статически типизированный функциональный язык программирования?
2013-08-21 в 19:04, admin, рубрики: Программирование, функциональное программирование, языки программирования, метки: функциональное программирование, языки программированияПрограммируем императивно в Хаскеле, используя линзы
2013-08-20 в 6:19, admin, рубрики: haskell, Программирование, функциональное программированиеХаскель получает много нелестных отзывов, потому что в нём нет встроенного инструментария для работы с изменениями и состояниями. Поэтому, если мы хотим испечь полный состояний яблочный пирог, нам необходимо для начала создать целую вселенную операторов для работы с состояниями. Однако за это уже заплачено с лихвой и это уже пройденный этап, и сейчас программисты на Хаскеле наслаждаются более элегантным, лаконичным и мощным императивным кодом, чем даже то, что вы можете найти в само-описывающих императивных языках. Впрочем, вы и сами сможете в этом убедится.
Линзы
Ваш билет к элегантному коду — это библиотека линз (lens). Читать полностью »
Lenses в Картинках
2013-08-11 в 17:15, admin, рубрики: applicatives, functors, haskell, monads, линзы, переводы, функциональное программированиеПеред тем как начать читать пост, вы должны быть знакомы с понятием функтор. Читайте этот пост, чтобы узнать больше
Предположим, вы хотите создать игру.
Семьи типов и Покемоны
2013-07-25 в 6:45, admin, рубрики: associated type synonyms, haskell, type class, type families, переводы, функциональное программированиеПредисловие
Когда я начал изучать Хаскель, я был почти сразу поражён. Для начала, нырнув с головой в актуальные рабочие проекты, открыл, что большинство настоящих библиотек используют языковые расширения, присутствующие только в GHC (Glasgow Haskell Compiler). Это меня покоробило слегка, прежде всего потому, кто захочет использовать язык настолько немощный, что будет необходимо использовать расширения, присутствующие лишь у одного поставщика. Ведь так?
Хорошо, я решился снова это осилить и узнать всё об этих расширениях, и я вывел три горячих топика для общества Хаскеля, которые решали похожие проблемы: Обобщённые Алгебраические Типы Данных, Семьи Типов и Функциональные Зависимости. Пытаясь найти ресурсы, которые обучают о них, я смог найти только статьи, описывающие, что это такое, и как их использовать. Но никто, на самом деле, не объяснял зачем они нужны!.. Поэтому я решил написать эту статью, используя дружественный пример, пытаясь объяснить зачем всё-таки нужны Семьи Типов.
Вы когда-нибудь слышали про Покемонов? Это замечательные существа, которые населяют Мир Покемонов. Вы можете считать, что они как животные с экстраординарными способностями. Все покемоны владеют стихией, и все их возможности зависят от этой стихии. Например, покемон Огненной стихии может дышать огнём, в то время как покемон Водной стихии может брызгать струями воды.
Покемоны принадлежат людям, и их специальные способности могут быть использованы во благо для продуктивной деятельности, но некоторые люди всего лишь используют своих покемонов для борьбы с другими покемонами других людей. Эти люди называют себя Тренерами Покемонов. Это может сначала звучать как жестокое обращение с животными, но это очень даже весело и все, похоже, рады, включая покемонов. Имейте в виду, что в мире покемонов, кажется, всё в порядке, даже если 10-летние покидают дом, дабы рисковать своими жизнями ради того, чтобы стать самыми лучшими Тренерами Покемонов, как будто никто и никогда таковыми не становился.
Мы собираемся использовать Хаскель для того, что бы представить ограниченную (и даже несколько упрощённую, да простят меня фанаты) часть мира покемонов. Читать полностью »
Python: декорируем декораторы. Снова
2013-07-23 в 15:28, admin, рубрики: python, горшочек-не-вари, декораторы, функциональное программирование, метки: python, горшочек-не-вари, декораторы, функциональное программирование В прошлом году на Хабре уже была очень развёрнутая статья в двух частях о декораторах. Цель этой новой статьи — cut to the chase и сразу заняться интересными, осмысленными примерами, чтобы успеть затем разобраться в примерах ещё более мудрёных, чем в предыдущих статьях.
Целевая аудитория — программисты, уже знакомые (например по C#) с функциями высшего порядка и с замыканиями, но привыкшие, что аннотации у функций — это «метаинформация», проявляющаяся только при рефлексии. Особенность Питона, сразу же бросающаяся в глаза таким программистам — то, что присутствие декоратора перед объявлением функции позволяет изменить поведение этой функции:
Как это работает? Читать полностью »
Как из одной прикольной фигни сделать еще более прикольную фигню или функциональный язык на коленке
2013-07-15 в 10:32, admin, рубрики: Алгоритмы, ненормальное программирование, Программирование, функциональное программирование, метки: Программирование, функциональное программирование «Бросая в воду камешки, смотри на круги, ими образуемые; иначе такое бросание будет пустою забавою.»
К.Прутков
Однажды, бесцельно тратя рабочее время и деньги работодателя с помощью серфинга интернета, наткнулся я на описание языка Whenever и на некоторое время был очерован. Язык поражает своей безумной простотой. Принципы его таковы:
1) Строки кода программы обязательно будут исполнены когда-нибудь, однако порядок их исполнения вообще никак не связан с порядком, в котором они записаны.
2) Переменные? У нас нету даже контроля за порядком исполнения, нам не нужны никакие переменные.
3) Структуры данных? Да вы шутите!
То есть программа трактуется как набор (пул) строк на выполнение и интерпретатор выбирает оттуда строку наугад, выполняет ее команды и выкидывает из пула. И так пока в пуле ничего не останется. Надо признать, что автор сего безумия почти выдержал концепцию. Почти, потому что все же организовать порядок выполнения в программе можно, так же, как и завести переменные, используя возможность добавления строк в пул выполняемых.
Мягкое введение в Coq: структуры данных и функции высших порядков
2013-07-03 в 8:01, admin, рубрики: coq, формальная верификация, функциональное программирование, метки: coq, формальная верификацияПары и списки
В предыдущих частях мы научились задавать новые типы данных, определять функции над ними и доказывать их корректность с помощью распространенных тактик. Настало время определить некоторые структуры данных и функции высших порядков (далее ФВП) над ними.
Читать полностью »
Тройка полезных монад
2013-07-02 в 5:17, admin, рубрики: haskell, monads, reader, state, writer, монады, переводы, функциональное программированиеВнимание: перед тем как читать текст ниже, вы уже должны иметь представление о том, что такое монады. Если это не так, то прежде прочитайте вот этот пост!
Перед нами функция half:
И мы можем применить её несколько раз:
half . half $ 8
=> 2
Всё работает как и ожидалось. Но вот вы решили, что хорошо бы иметь лог того, что происходит с этой функцией:
half x = (x `div` 2, "Я только что располовинил " ++ (show x) ++ "!")
Что ж, отлично. Но что будет если вы теперь захотите применить half несколько раз?
half . half $ 8
Вот то, что мы хотели бы, чтобы происходило:
Спойлер: автоматически так не сделается. Придётся всё расписывать ручками:
finalValue = (val2, log1 ++ log2)
where (val1, log1) = half 8
(val2, log2) = half val1
Фу! Это ни капли не похоже на лаконичное
half . half $ 8
А что, если у вас есть ещё функции, имеющие лог? Напрашивается такая схема: для каждой функции, возвращающей вместе со значением лог, мы бы хотели объединять эти логи. Это побочный эффект, а никто не силён в побочных эффектах так, как монады!
Читать полностью »
Встраиваемый язык для .NET, или как я переспорил Эрика Липперта
2013-06-27 в 13:57, admin, рубрики: .net, lens, Программирование, функциональное программирование, метки: .net, lensПредисловие
Случается, что навязчивая идея так прочно заседает в голове, что ты возвращаешься к ней снова и снова на протяжении многих лет. Пытаешься подойти к проблеме с другой стороны, воспользоваться новыми знаниями, или же просто начать все еще раз с чистого листа — и так до тех пор, пока вопрос не будет исчерпан раз и навсегда. Для меня такой идеей-фикс стали языки программирования. Сам факт того, что одна программа позволяет создавать другие программы, в моих глазах наделял ее непостижимой фрактальной красотой. Написание такой программы самому стало лишь вопросом времени.
В первый раз время наступило после второго курса. Я был уверен, что полученных знаний языка C мне хватит, чтобы в одиночку написать и компилятор, и виртуальную машину, и всю стандартную библиотеку к нему. Задумка была элегантна и дышала романтикой юношеского максимализма, но вместо этого результатом двух лет прилежной работы стало монструозное нечто. Даже несмотря на то, что виртуальная машина подала признаки жизни и смогла исполнить довольно несложные скрипты на псевдоассемблере, который помог написать боевой товарищ fornever, проект был вскоре заброшен. Вместо этого было решено написать язык для платформы .NET, чтобы нахаляву получить автоматическую сборку мусора, jit-компилятор и все прелести огромнейшей библиотеки классов. Компилятор был реализован всего за полгода, исходный код выложен на CodePlex, и с ним я успешно защитил диплом.
Однако чего-то по-прежнему не хватало. При всех своих преимуществах, разработанный для диплома язык требовал явного объявления всех типов и функций, не имел никакой поддержки generic'ов, не умел создавать анонимные функции, да и вообще область его применения была неясна. Решение изобрести еще один велосипед пришло спустя год, когда мне написал знакомый, учившийся на моей же кафедре на два года младше. Он предложил «помочь» ему в написании дипломной работы, и я согласился. К новому языку были поставлены следующие требования:
- Взаимодействие с любыми доступными типами .NET без явного импорта
- Поддержка generic'ов
- Поддержка анонимных функций и замыканий
- Наличие хоть какой-нибудь практической ценности
Вышеупомянутый fornever изъявил желание поучаствовать, и работа закипела. Он принимал активное участие в создании дизайна языка и написал парсер на F#, а я занялся описанием синтаксического дерева и внутренней инфраструктуры.
На днях знакомый защитил-таки свой диплом, поэтому репозиторий проекта на Github теперь открыт для всех желающих. Дальше в статье я расскажу о том, что в результате получилось, какие подводные камни встретились на пути, и почему у статьи такой желтый заголовок.Читать полностью »
Развитие пользовательских типов данных в программировании
2013-06-26 в 5:14, admin, рубрики: c++, fortran, haskell, perl, ооп, Программирование, функциональное программирование, метки: c++, fortran, haskell, perl, Лисп, Программирование Хотелось бы остановиться и посмотреть на развитие языков программирования с точки зрения развития пользовательских типов данных (ПТД).
Сразу хочу оговориться, под пользователями понимаются программисты, как люди, пишущие код на этих языках. Ну, и те, кто этот код сопровождает или просто читает.
Пользовательские типы данных — это типы данных, которые могут быть созданы пользователем на основе того, что доступно в языке.
Пользователи желают иметь примерно такие типы данных
Пользователи хотели иметь возможность составлять данные так, как они сами того хотят. Хотели, хотят, и наверняка будут хотеть. Всё больше, всё разнообразней и сильнее.
Именно поэтому полезно проследить за развитием пользовательских типов данных в программах и языках программирования.
Читать полностью »