Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2842 13-04-2007 12:35 | |
Ответ на »сообщение 2841« (Сергей Перовский)
___________________________
Человек много к чему не приспособлен - например к научной деятельности.
Не путайте. Не к научной деятельности, а к просчету шагов на незнакомой территории, неважно что это, охота на незнакомой местности, проектирование незнакомого проекта, или попытка слишком далеко просчитать какое нибудь физическое явление.
Человек во всех сферах, включая и науку, двигается одним и тем же способом. Наощупь, шаг за шагом.
В науке каждый шаг вперед опирается на огромное количество экспериментов и проверок.
И сделать сразу несколько непроверенных шагов у вас просто не получится. Вы ошибетесь уже на втором.
А что предлагают апологеты "грамотного проектирования" ?
Они предполагают что существует набор методик, которые позволят даже не пройдясь по незнакомой территории, только лишь сбором первичной информации, сразу построить весь план пути от начала до конца. И далее ему следовать.
Посмотрите, во всех до единого книгах по ООП, говорится. что раз построив модель, иерархию классов и их взаимосвязей, переделывать ее уже невозможно (слишком дорого)
А другого пути (строить по ходу) у ООП нет. Это считается неграмотным. Да и невозможно тоже. Почему ?
Что из себя представляет такая вот методика построения архитектуры ?
Бетон видели как делается ?
В форму укладываются длиннющие и очень крепкие железные пруты, арматура.
Затем все это заливается цементом.
Как цемент прихватило, поздно уже что то менять. Только ломать и заново строить.
В ООП роль этой пронизывающей все и все связывающей арматуры играет состояние, структура данных, размазанное по всей иерархии классов. И цемент (функции) жестко к этой арматуре привязан, в виде методов классов.
Как начинаете строить, все, поздно уже дергаться.
В ООП практически нет возможности поиграться, быстро построить и выбросить десятки разных иерархий классов, чтобы выбрать одну правильную.
Слишком тяжело и затратно построить даже одну иерархию.
Поэтому всегда на практике только одна архитетура и строится.
Это равносильно попытке выиграть партию в шахматы с первого раза.
В ФЯ нет арматуры связывающей весь проект. Чистые функции как лего-кубики. Легко строятся, легко разбираются. Легко выкидываются.
Поэтому стоимость эксперимента в ФЯ чрезвычайно низка. Поэтому первые дни вместо того чтобы придумывать иерархию классов (и 100% ошибиться), программист играется с автономными функциями, быстро нарабатывая инструментарий, и отбрасывая неудачные решения. Это легко. Это дешево. Это быстро. И самое главное, это гарантированно выводит на правильный путь, и резко увеличивает шансы на успешное решение задачи.
№ 2841 13-04-2007 12:15 | |
Ответ на »сообщение 2840« (Jack Of Shadows)
___________________________
>>>Нет на самом деле такой вещи как грамотное проектирование. Не приспособлен человек для такой деятельности.
Я бы так категорично не утверждал.
Человек много к чему не приспособлен - например к научной деятельности.
Однако на этом основании утверждать, что наука не существует, я бы не стал.
Почему мне интереснее играть в "шахматы" 6х6? Потому, что я хорошо понимаю, что без изучения огромного количества "самых лучших книг по теории игры" вероятность успеха 0% при игре с мало-мальски образованным шахматистом.
Книги по теории игры, это опыт тысяч шахматистов, наработать который самостоятельно невозможно.
Так что теория столь же необходима, как и собственный опыт. Тут противопоставлять не нужно.
Часто заказчик может уточнить свои требования только увидев некоторый прототип.
Но "физик должен паять лучше лудильщика", в смысле, чтобы не попасть в 80% проектов на выброс, разработчик должен быть в теме не хуже заказчика.
Должен уметь правильно выбрать математический аппарат, а уже к нему язык программирования. Тогда и прототип можно быстро построить и выбрасывать его не придется, а только дописывать.
№ 2840 13-04-2007 11:45 | |
Ответ на »сообщение 2836« (AVC)
___________________________
Конечно, (ничем) "незамутненное состояние" сознания гораздо лучше, чем "грамотное проектирование". ;)
"Грамотное проектирование" это миф, живущий в рекламных слоганах оберонщиков.
Нет на самом деле такой вещи как грамотное проектирование. Не приспособлен человек для такой деятельности.
Вот для изучения обстановки на собственном опыте - прекрасно приспособлен.
Когда люди показывают на примеры "грамотного проектирования" то на самом деле это примеры использования уже наработанного опыта на точно такой же задаче.
Для эксперимента: Возьмите человека, прекрасного программиста, не знакомого с шахматами (шашакми, го, нардами, любой настольной игрой открытого типа). Научите его всем шаманствам "грамотного проектирования".
Дайте ему задание сыграть в шахматы, ну хотя бы с обычным любителем, и выиграть.
Уже сздесь он в выигрыше. Поскольку игра открытого типа, вся информация как на ладони.
Это в отличии от обычного проекта, где программист видит лишь верхушку айсберга, все остальное от него скрыто.
Дайте ему правила шахмат.
Уже здесь он в выигрыше, поскольку полных спецификаций задачи для программирования он никогда не получает. В шахматах он сразу получает ВСЕ условия задачи, да еще и прекрасно сформулированные.
Дайте ему самые лучшие книги по теории игры.
Уже здесь он в колоссальном выигрыше, поскольку в реальном проекте никто никогда не даст ему легко усваиваемый и сконцентрированный опыт лучших из лучших, и готовые наработки большей части проекта (дебют, миттельшпиль, ендшпиль)
Пусть он все это усвоит (ни разу не сев за доску), а потом применит свои недюжинные познания в "грамотном проектировании" игры, и выиграет свою первую в жизни партию сходу.
Вероятность успеха ? 0% !!!
Путь к победе ? Десятки может и сотни провальных проб. Это несмотря на весь обьем готовой инфы, ему предоставленной. Это несмотря на маленький набор взаимодействующих обьектов, с четко описанными взаимосвязями, это несмотря на очень ограниченное и полностью просматриваемое поле действий.
В реальном проекте ? Информации как обычно кот наплакал, да и ту приходится клещами выдирать,
Набор взаимодействующих обектов большой, количество обьектов и их взаимосвязи описанны неполно и часто неверно, поле действия невидно, и без наработки нескольких лет опыта в этой области не будет видно.
Вы хотите сказать что в таких условиях кто то может сходу, с первого захода, успешно рещить задачу ?
Ха ха ха!!
Поэтому процент провальных проектов среднего и большого размера с традиционным подходом к проектированию настолько высок - 80% !!!
Единственный путь к успешному решению задачи в таких условиях это путь множества проб, экспериментов.
Не можете вы делать никаких выводов пока сами все не потрогаете, не увидите. Не можете вы составить план, и построить "архитектуру". Разве что на песке своего воображения и самомнения.
Функциональые языки с REPL - идеальное поле для быстрых экспериментов в предметной области, нарабатывания знаний по ним, и создания слоя кода нижнего уровня, фундамента, на котором в последствии можно будет строить программу.
Это и есть тот самый способ множества проб (множества проигранных игр) при помощи которых нарабатывается опыт, и человек находит выигрышную стратегию, и ключ к успешному решению задачи.
Именно поэтому ФЯ используются для быстрого прототипирования (понимания задачи и нарабатывания опыта) и потом уже этот опыт переносится на реализацию задачи на ИЯ, поскольку на ФЯ программа не уложится в жесткие рамки ограниченных рессурсов железа.
Но это было раньше. Сейчас с каждым днем все больше и больше задач можно оставлять на ФЯ после прототипирования, просто потому что они уже работают на доступном железе. А зачем делать одну и ту же работу два раза, если и первая реализация вполне подходит ?
№ 2839 13-04-2007 09:30 | |
№ 2838 13-04-2007 09:30 | |
№ 2837 13-04-2007 09:24 | |
Ответ на »сообщение 2835« (Geniepro)
___________________________
Этот пример ярко демонстрирует, насколько легко изучать Хаскелл людям с незашоренным разумом и незамутнённым сознанием! :о)
Буквально сегодня провел пед. эксперимент. Как уже "жаловался" в Оберон-ветке, занимаюсь с группой первокурсников, которые "не тянут" из-за того, что в школе не было вообще ничего, а на первом курсе вуза - только сухая конкретика языка С++. Строить алгоритмы и вообще программировать их не учит никто.
Увы, из-за того, что нужно подготовить к сдаче конкретного экзамена, нет времени на другой язык, приходится оставаться в рамках С++, высекая существенное и отсекая мишуру.
Так вот, изучение функций и рекурсии я поставил до изучения алгоритмов с управляющими операторами.
Т.е. сначала показываем, как можно писать программу в чистых выражениях, без явного управления состоянием, а уже потом вводим остальную часть ИЯ - операторы.
Люди, знающие математику, усвоили рекурсию с полнамека. Конкретно покажет следующее занятие, но понимание темы было заметно высокое.
№ 2836 13-04-2007 09:12 | |
Ответ на »сообщение 2835« (Geniepro)
___________________________
С огромным интересом и удовольствием почитал статью об одном занятном эксперименте по прототипированию военного ПО:
К сожалению, так и не смог найти описания задачи. :(
Этот пример ярко демонстрирует, насколько легко изучать Хаскелл людям с незашоренным разумом и незамутнённым сознанием! :о)
Конечно, (ничем) "незамутненное состояние" сознания гораздо лучше, чем "грамотное проектирование". ;)
№ 2835 13-04-2007 06:58 | |
С огромным интересом и удовольствием почитал статью об одном занятном эксперименте по прототипированию военного ПО:
P. Hudak, M. P. Jones, "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity"
Этот эксперимент был проведён осенью 1993 г. по заказу ВМФ США агентством US ARPA совместно с Office of Naval Research (ONR) и Naval Surface Warfare Center (NSWC).
Эксперимент заключался в быстром прототипировании ПО для упрощённого варианта важной части системы ПВО США: geometric region server (geo-server), входящего в NSWC's AEGIS Weapons System (AWS).
Этот гео-сервер должен был обработать набор данных о расположении военных судов и дружеских, коммерческих, а также вражеских, самолётов, и определить нарушении зон безопасности, ну и тому подобное...
Прототипы создавались на нескольких известных языках: Haskell, Ada, Ada-9x, C++, AWK, и на нескольких экспериментальных языках, разработанных именно для прототипирования подобного ПО: Rapide, Griffin, Proteus и Relational Lisp. Затем прототипы были отданы независимым экспертам для оценки по нескольким параметрам, в том числе: понятность, компактность, расширяемость, пригодность для поддержки и развития, эффективность выполнения и т.д.
Результаты сравнения:
Язык Строк Строк Время разра- Общая
кода документации ботки (часов) оценка
(1) Haskell . . . . . 85 . . 465 . . . . . 10 . . . . A
(2) Ada . . . . . . . 767 . . 714 . . . . . 23 . . . . B
(3) Ada9x . . . . . . 800 . . 200 . . . . . 28
(4) C++ . . . . . . 1105 . . 130 . . . . . --
(5) Awk/Nawk . . . . 250 . . 150 . . . . . --
(6) Rapide . . . . . 157 . . . 0 . . . . . 54
(7) Griffin . . . . . 251 . . . 0 . . . . . 34
(8) Proteus . . . . . 293 . . 79 . . . . . 26 . . . . A
(9) Relational Lisp . 274 . . 12 . . . . . 3 . . . . A-
(10) Haskell . . . . . 156 . . 112 . . . . . 8
Решение 1 (на Хаскелле), сделанное вторым автором статьи (с небольшой помощью со стороны первого), из 85 строк кода имело 20 строк входных данных, 29 строк синонимов типов и сигнатур типов (которые в принципе могут быть убраны - типы может вывести компилятор) и всего 36 строк собственно кода решения задачи. Большую часть времени авторы уделили документированию программы (видимо, старались сделать её образцово-показательной), поэтому потратили аж 10 часов.
Тем не менее, общая оценка этой программы выглядит явно заниженной, потому что у программы на Proteus'е при той же общей оценке многие частные параметры были оценены ниже, чем аналогичные в хаскеллевской.
Решение 10 (тоже на Хаскелле) было проделано выпускником колледжа, которому дали описание Хаскелла и 8 дней на изучение языка, затем дали спецификацию задачи и этот студент сумел всего за 8 часов написать этот прототип.
Этот пример ярко демонстрирует, насколько легко изучать Хаскелл людям с незашоренным разумом и незамутнённым сознанием! :о)
Решение 2 (на Аде) является референсным (контрольным), так как разработано ведущим программистом NSWC. Любопытно, что эту программу эксперты оценили хуже остальных...
Решения 4 (на С++) и 5 (на Awk) представил один и тот же программист, причём он почему-то не указал времени работы над ними, поэтому они не были оценены.
Для программы на С++ ему пришлось написать ещё 595 строк тестовой программы (вдобавок к 1105 уже имевшимся строкам).
А вот неплохой результат на скриптовом языке Awk (250 строк) показал некоторую пригодность его для подобных дел.
Решение 6 (на Rapide) выбивается из этого ряда, потому что не удовлетворяло требованиям задачи.
К тому же, для этого языка на тот момент не было транслятора. Так же, впрочем, как не было трансляторов и для языков Ada9x (3) и Griffin (7).
Решение 7 (на Griffin, 251 строка) потребовало от своих авторов ещё и написания дополнительных 200 строк библиотеки, похожей на стандартный модуль Prelude в Хаскелле.
Решение 9 (на варианте Лиспа) демонстрирует поразительную "взрывную" скорость прототипирования программ на Лиспе - автор решения потратил на него всего 3 (три) часа! Правда, он уделил очень мало внимания документированию программы, что, конечно же, значительно сэкономило ему время...
Несмотря на это (почти отсутствующую документацию), эта программа была оценена выше, чем образцовая программа на Аде, что противоречит распространнёному мнению о Лиспе как о диком и непонятном нагромождении круглых скобок... :о))
Общий вывод статьи таков: функциональное программирование прекрасно подходит для быстрого прототипирования серьёзного и важного программного обеспечения.
Исходники программ можно найти в отчёте:
J.A.N.Lee, B.Blum, P.Kanellakis, H.Crisp, and J.A.Caruso. ``ProtoTech HiPer-D Joint Prototyping Demonstration Project'', February 1994. Unpublished; 400 pages.
Подробный отчёт о решении на Хаскелле:
W.E. Carlson, P. Hudak, and M.P. Jones. ``An experiment using Haskell to prototype "geometric region servers" for navy command and control''. Research Report 1031, Departmentof Computer Science, Yale University, November 1993.
И вообще о прототипировании на ФП:
P. Henderson. ``Functional programming, formal specification, and rapid prototyping''. IEEE Transactions on SW Engineering, SE-12(2):241–250, 1986.
№ 2834 13-04-2007 06:07 | |
Ответ на »сообщение 2826« (Jack Of Shadows)
___________________________
>>>на меня сразу набросятся с требованиями соответствия реализации каким нибуль правилам снукера.
Насчет правил, это не ко мне, я с удовольствием играю с компьютером в шахматы на доске 6х6 :)
Меня интересуют задачи, в которых существуют внутренние события - соударение шаров очень характерный пример. Мне кажется, что именно тут лежит граница эффективного применения функционального подхода.
№ 2833 13-04-2007 03:14 | |
Ответ на »сообщение 2827« (Trurl)
___________________________
>>>Странно, все набросились на правила шахмат, и никто не обращает внимание, что это совсем не интерактивная программа. ;-)
Началось с того, что я просто удивился мотивировке искажения правил.
После этого для меня уже отошло на второй план, интерактивная это программа или нет.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|