Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2802 12-04-2007 12:22 | |
Ответ на »сообщение 2801« (AVC)
___________________________
В смысле мотивировки исключения рокировки и взятия на проходе.
Для рокировки имеет значение двигались ли до этого король или ладья.
Для взятия на проходе имеет значение с какой позиции стартовала пешка противника, и был ли после этого пропущен ход.
Как видите обе задачи нетрудные, но нагромождают лишние детали, с точки зрения маленькой учебной программки.
В отличии от вас, у меня нет никаких сомнений в том что автор достаточно квалифицирован, чтобы решить эти задачи, если ему придется за них браться.
В конце концов состояние всей доски он ведь сохраняет между ходами без проблем. Разве сохранять возможность взятия на проходе для КАЖДОЙ пешки (16), и возможность рокировки для короля и обоих ладьей (6) сильно сложнее ?
Нет. Просто работы много и заморачиваться для маленького примера неохота.
№ 2801 12-04-2007 11:49 | |
Ответ на »сообщение 2800« (Jack Of Shadows)
___________________________
>>>Бросилось в глаза...
В смысле ? Вы ожидали чего то большего от маленькой учебной программки размером в несчастные 200 строчек ?
В смысле мотивировки исключения рокировки и взятия на проходе.
№ 2800 12-04-2007 11:11 | |
Ответ на »сообщение 2799« (AVC)
___________________________
Бросилось в глаза...
В смысле ? Вы ожидали чего то большего от маленькой учебной программки размером в несчастные 200 строчек ?
№ 2799 12-04-2007 09:09 | |
Ответ на »сообщение 2798« (Jack Of Shadows)
___________________________
За часик можно в принципе составить себе общее представление.
Изучение кода думаю даст ответ на многие вопросы, которые постоянно возникают у императивщиков.
Бросилось в глаза...
* the capturing en passant and castling rules are the worst things from a programmers point of view, because they make moves depending on previous moves, thats why I ignored both rules in my implementation
* a depth of the game tree of 4 is already very, very slow
№ 2798 12-04-2007 03:21 | |
Я помню Сергей Перовский все пытался здесь выяснить как на хаскеле написать программу, которая оперирут сложным состоянием в течении долгого времени. Например шахматной партией.
Теперь у него такая возможность появилась:
http://www.steffen-mazanek.de/blog/2007/02/haskell-chess.html
Простенькие шахматы на хаскеле. Весь код - 12 kb
За часик можно в принципе составить себе общее представление.
Изучение кода думаю даст ответ на многие вопросы, которые постоянно возникают у императивщиков.
№ 2797 12-04-2007 03:01 | |
Ответ на »сообщение 2793« (Max Belugin)
___________________________
Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).
Если в языке Оберон использовать модули с контролем импорта на чтение, то многие вопросы снимутся сами собой. Для этого нужно ввести понятие read-only import (точнее, импорт с ограничениями) и его контроль на уровне верификатора (который гарантирует, что импортированные сущности не превышают свои полномочия).
Обеспечить жесткий контроль (из всех модифицируемых сущностей -- процедур и переменных -- можно использовать только немодифицирующие) в силах все тот же верификатор. Его, правда, надо спроектировать и написать. Но это задача не является неподъемно-неразрешимой. Монады тоже кто-то делал :)
№ 2796 12-04-2007 02:43 | |
Ответ на »сообщение 2795« (Jack Of Shadows)
___________________________
Руслан, вы говорите об искусственной ситуации, которую нужно еще специально создать.
Джек, я не пытаюсь других убедить, что ФП -- это плохо, а ИП -- супер. Наоборот, стараюсь, чтобы мы совместными усилиями выявили границы применимости и ограничения как ИП, так и ФП.
По ИП, думаю, уже многим из нас понятны изъяны, которые могут во всей красе предстать в самый неподходящий момент. Следовательно, нужно не лечить, а вести профилактическую работу (если, конечно, цена вопроса устраивает).
В ФП для реализации обособленного ИП-мира используются монады. В ИП для ФП-мира можно использовать модули. "Искусственность" модулей в этом смысле ровно такая же, как и монад.
№ 2795 12-04-2007 02:37 | |
Ответ на »сообщение 2791« (Руслан Богатырев)
___________________________
Абсолютно правильно поняли, с той разницей, что прочитать может, а изменить -- нет. Но если нужно, чтобы и прочитать не мог -- это реализуется просто отказом в "визе" (она не будет включена в список импорта). Вроде бы уже объяснял, но повторю.
Руслан, вы говорите об искусственной ситуации, которую нужно еще специально создать.
Я же говорю об обычной ситуации, в которой рабочий модуль импортирует самым обчным образом десятки других модулей и имеет доступ к глобальным переменным в них описанных.
И вот тут, то есть в самой обычной рабочей ситуации, компилятор вам не поможет. А насадить такую иезуитски жесткую дисципину в команде, чтобы ни один модуль ниоткуда не импортировал никакие глобальные переменные, вы не сможете в принципе.
В отличие от этого хаскель позволяет вам совершенно спокойно импортировать любые глобальные переменные, в том числе и mutable, но при этом гарантирует что никто не сможет иметь к ним доступа из чистых функций. ДАЖЕ из тех функций в которых имеется свое внутреннее состояние.
И вот такая гарантия дорого стоит. Дороже любых уговоров грамотно пользоваться модулями.
Уговорам я не верю.
№ 2794 12-04-2007 02:33 | |
Ответ на »сообщение 2793« (Max Belugin)
___________________________
Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).
Это верно. Внутри модуля гарантий нет. Но есть средства-подходы, позволяющие такую гарантию обеспечить/реализовать.
1. Отделенная от остального мира и "препарированная" функция-модуль (т.е. вырожденный модуль, внутри которого одна функция) гарантирует в определенной мере адекватную проверку подобного воздействия побочных эффектов. Следуя принципу No Paranoia, можно повышать гранулярность такого автономного ФП-модуля другими функциями.
2. Язык Оберон/КП не дает гарантий, но они могут быть обеспечены внеязыковыми средствами (верификатором). Точнее, средствами языка более высокого уровня (языка контроля -- языка для верификатора), который внедряется в базовый язык на уровне маркированных комментариев (подобно прагмам компилятора). Некие идеи в отношении этого описывал пару дней назад в ветке по Оберону. Гарантии -- включая контроль однократного присваивания.
На самом деле, глубинные отличия ФП от ИП довольно неплохо проведены в тьюринговской лекции недавно ушедшего от нас Джона Бэкуса (1977) "Можно ли освободить программирование от стиля фон Неймана? Функциональный стиль и соответствующая алгебра программ". На русском перевод у меня есть только в бумажном виде ("Лекции лауреатов премии Тьюринга. 1966-1985" -- М.: Мир, 1993). В оригинале (2,93 Мбайт) http://www.europrog.ru/paper/jb1977-01e.pdf
Бэкус проводит классификацию моделей:
1. Простые операционные модели (машина Тьюринга, конечные автоматы, сети Петри и т.п.)
2. Аппликативные модели (лямбда-исчисление, система комбинаторов Карри, системы ФП)
3. Модели фон Неймана (традиционные языки)
Разграничительная линия двух миров (ФП и ИП) проходит по связке "мир выражений -- мир операторов". Второй важный момент -- придание одной сущности разных имен (в ИП), то бишь ссылки на оригинал (в том числе через присваивание).
Поэтому, если в ИП имитируется мир ФП, то в этой "песочнице" надо установить повышенный контроль за упомянутыми вещами. Это возможно.
P.S. В рассуждениях относительно Оберона/КП можете спокойно держать в голове Delphi (по ключевым вещам он не шибко отстает, просто много наносного, от которого можно абстрагироваться).
№ 2793 12-04-2007 01:45 | |
Ответ на »сообщение 2792« (Руслан Богатырев)
___________________________
Насколько я понял, монада ST грубо говоря создает полностью закрытый изолированный мир в котором можно вычислять путем явного задания последовательности состояния этого мира.
Внутри него, например, нельзя явно или неявно изменить состояние ничего другого.
Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).
То есть например если есть другой модуль состояние которого изменяется, то можно его поюзать в функции и изменить его состояние. а в хаскелле надо передавать явно этот модуль в качестве параметра.
Еще, как мне кажется, джек описался упоминая монаду IO - он имел ввиду монаду ST.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|