| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1532 13-11-2006 10:45 |   |
Ответ на »сообщение 1531« (Сергей Перовский)
___________________________
Если в модели есть понятие времени, то и понятие состояния для нее естественно.
"Время" в моделях - всего лишь, "реперная точка", "зацепка", к которой цепляется учёный, не всилах описать (и, соответственно, - понять) все процессы, протекающие в исследуемой системе.
Ввводя время в модель, всё переворачивам всё с ног на голову.
Собственно, мы и само время-то измеряем за счёт процессов...
Взять хотя бы нашу отрасль. В конце концов, естественным образом мир завоюют асинхронные архитектуры процессоров и компьютеров. Сейчас общее тактирование необходимо просто потому, что это наши модели таковы. Но вы посмотрите, какие затраты происходят из-за этого, сколько попусту расходуется места на кристалле на разводку сигнальных и питающих проводников, сколько тратиться на поддержание фазовых сдвигов сигналов (не видели кручёные и завитые дорожки на платах - и на фиг оно сдалось?), сколько энергии расходуется на тактовые генераторы, делители-умножители, усилители сигналов, восстановители формы, сколько тепла они выделяют?... Вот она - адекватная модель вычислений? :о)
Там, где моделируется поведение сложной системы во времени, понятия модельного времени и состояния системы необходимы.
"Времени" или последовательности (очередности) взаимодействия элементов системы?
| № 1531 13-11-2006 10:27 | |
Ответ на »сообщение 1529« (Asc.)
___________________________
>>>модель никогда не будет тождественна самому объекту
+1
самому объекту тождествен только сам объект.
Почему в инструментах моделирования понятие объекта появилось на 25 лет раньше, чем в языках общего назначения? Потому, что это естественный аппарат имитационного моделирования. И вряд ли ООП подход уйдет из задач имитационного моделирования в обозримом будущем. Если в модели есть понятие времени, то и понятие состояния для нее естественно.
Функциональный подход, отвергая понятие состояния, тем самым отвергает понятие модельного времени. Там, где оно не нужно для задачи и является только отражением работы процессора в естественном времени, оно может быть безболезненно удалено. Там, где моделируется поведение сложной системы во времени, понятия модельного времени и состояния системы необходимы.
| № 1530 13-11-2006 10:18 | |
Ответ на »сообщение 1529« (Asc.)
___________________________
Любая модель - это и есть способ согласовать реальный природный процесс с ограничениями нашего сознания. В природе существует реальный объект, в нашем сознании - его модель.
То есть, - изначально, априори?
Кроме сформированных мышичных реакций там ничего нет. Мы сейчас даже не можем до конца представить себе как эти первичные реакции выкладываются в "абстракции"...
И эта модель никогда не будет тождественна самому объекту - во-первых, из-за наших "ограничений", во-вторых, потому что это никому и не надо: модель на то и модель, что она должна отражать только существенные для нас свойства реального объекта в удобной для человека форме.
Удобной для чего? В рамках какой совокупности действий и операций над моделью (хотя бы, я уже про манипуляцию над самим моделируемым объектом пока не говорю)...
В самой природе нет никаких объектов и состояний. Но человек за тысячи лет не смог уйти от описания природы в виде совокупности взаимодействующих объектов и их состояний.
Теперь вопрос - почему? Может просто потому, что не было адекватного инструмента для представления резултатов работы, "неатомистов"?
В квантовой физике понятие системы и ее состояния вообще является ключевым.
... всего лишь по причине удобства и привычности восприятия, антропоцентризма в описании явлений. Мне интересно, как тот же Фейнман явление распада нуклонов объяснял с точки зрения его теории? В абсолютном вакууме, пустоте, висел себе нейтрон. Ни он никого не трогал, ни его не трогали и вдруг - бац! - нет его, а вместо него куча всего в разные стороны полетела...
Так надо ли в 21 веке делать революцию и во имя торжества определенной парадигмы (ФЯ) полностью отказываться от другой (ИЯ)?
Не парадигмы а - адекватности строимых моделей.
... так и императивная и функциональная парадигмы должны не "отменять" друг друга, а дополнять и уточнять условия и эффективность применения для решения различных задач.
Правильно. Поэтому не отметать надо всё с порога, а понимать, что и в программировании есть "ньютон", а есть "фейнман", и не надо тужиться удобства подходов, применяемых для решения примера нахождения корней квадратного уравнения "натягивать" на всё подряд...
| № 1529 13-11-2006 07:47 | |
>>>Мы стремимся строить модели, адекватные природным процессам или
>>>будем дальше распространять на них природу наших собственных
>>>ограничений?
Пустой вопрос. Любая модель - это и есть способ согласовать реальный природный процесс с ограничениями нашего сознания. В природе существует реальный объект, в нашем сознании - его модель. И эта модель никогда не будет тождественна самому объекту - во-первых, из-за наших "ограничений", во-вторых, потому что это никому и не надо: модель на то и модель, что она должна отражать только существенные для нас свойства реального объекта в удобной для человека форме.
В самой природе нет никаких объектов и состояний. Но человек за тысячи лет не смог уйти от описания природы в виде совокупности взаимодействующих объектов и их состояний. В квантовой физике понятие системы и ее состояния вообще является ключевым. Так надо ли в 21 веке делать революцию и во имя торжества определенной парадигмы (ФЯ) полностью отказываться от другой (ИЯ)? Не уверен. Скорее я сторонник модели Н.Бора: принципа дополнительности. Как теория относительности и квантовая теория не "отменили" механику Ньютона, а только дополнили и уточнили ее модели при определенных условиях, так и императивная и функциональная парадигмы должны не "отменять" друг друга, а дополнять и уточнять условия и эффективность применения для решения различных задач.
| № 1528 13-11-2006 07:28 | |
Ответ на »сообщение 1527« (Владимир Лось)
___________________________
Подумалось...
Понравилось, решил ещё подумать... :о)
"Состояния" в природе НЕ встречаются. Они суть наши абстракции о совокупности этапов хода процессов во внещнем мире. Они помагают нам преодолеть нашу ограниченность (как в том, что у нас между ушами, так и в том, что у нас стоит под вентиляторами на материнках).
Мы стремимся строить модели, адекватные приодным процессам или будем дальше распространять на них природу наших собственных ограничений?
Процессор (совокупность процессоров), в отличие от мозга, не заняты тысячей миллионов "подзадач", отвечающих за жизнеспособность организма. У него не болит нога, не печёт в желудке, не хочется кушать, наконец... Его ничего "не отвлекает". Настроить всё это сонмище процов на наши задачи, а не эмулировать природу человеческого "пошагового" мышления (с "состояниями")!
В конечном итоге, системы должны будут представлять собой транспьютеры с десятками (а, может, и - сотнями) миллионов сопроцессоров на одном кристалле. Главные задачами теперь будут: создание архитектуры "общей шины" для такого конгломерата (для обеспечения перенастраиваемой связи между процессорами) и разработка компиляторов. Скорее всего, эти две задачи сольются в одну... :о)
| № 1527 13-11-2006 07:11 | |
Подумалось...
Необходимость в "поддержке состояния" отпадает по мере расширения многозадачности в прикладных системах. В каждой из этих "задач" (например, потоков), контроллируется отдельный аспект системы (а не "перелапачивается" всё в "одном большом цикле").
Тут приближаемся к другой крайности: при идеальных условиях распараллеливания мы приходим... к чистому функциональному подходу... :о) и....... ИСЧЕЗНОВЕНИЮ ОБЪЕКТОВ с сегодняшнем понимании ООП...
Таким образом:
- увеличение степени распараллеливания задач приводит к решениям в "функциональном стиле".
- в свою очередь, в ФЯ распараллеливание носит достаточно естественный характер.
Я думаю, "объекты", как средство архитектурного уровня, являются промежуточным, переходным средством в обозримом историческом периоде развития программирования. Появившись из структур и модулей, они сыграли свою роль "ограждающих" синтаксических и семантических средств в структурном и ОО-подходе, достаточно ярко они "блеснут", в пост-актив-обероновском мире, сыграв роль естественных "раделителей" контекстов потоков (активные объекты), и, наконец, сойдут со сцены, по мере "внедрения в сознание масс" функционального программирования.
Ales! (или - alas? :o) )
| № 1526 11-11-2006 09:35 | |
В Delphi обсуждаемый подход реализован в незабвенном VirtualTree. Почему не появились VirtualListBox, VirtualLabel и т.п. - другой вопрос. Самому интересно. Хотя может и появились.
Мне сей подход очень нравится, т.к. помимо удобства еще и сильно экономит ресурсы.
Вообще ФП вне всякого сомнения как минимум достойно изучения.
| № 1525 11-11-2006 03:01 | |
Я написал Кени Тилтону об идее макроса def-cells-var с symbol macros внутри.
Он ответил что идея ему понравилась и он уже добавил два новых макроса def-с-var и def-с-parameter в cells.
Причем что самое интересное, оказалось даже не нужно создавать обьект с один слотом. Любой символ в лиспе - уже обьект с несколькими слотами, только один из которых хранит его значение.
Вот вам и cells с поддержкой простых типов а не только обьектов.
Я думаю он скоро выложит код на CVS.
| № 1524 10-11-2006 18:43 | |
Ответ на »сообщение 1523« (Geniepro)
___________________________
А вот скажите, ведь эта супергибкость наверняка имеет оборотную сторону медали. Легко ли потом понять чужой код? Или даже свой через год?
С точностью до наоборот.
Если супергибкость как то и влияет на легкость чтения кода то только в лучшую сторону.
Сами знаете чем выше уровень абстракции и меньше низкоуровневых деталей мешается под ногами, тем легче понять что делает программа.
увидев (def-cells-var *my-var*) сразу легко понять что создается переменная чье состояние будет отслеживаться.
Каким бразом это уже вас не касается, хотя если есть желание разобраться, всегда можно опуститься на уровень ниже и посмотреть.
Легкость понимания/чтения кода напрямую зависит от того сколько лишнего упрятано или наоборот вывалено наружу.
Таким образом код-простыню на delphi, java, сишарп в которой расписаны все детали от самого низкого уровня до самого выского, и вывалена на общее обозрение куча локальных переменных, гораздо тяжелее читать нежели разбираться в аккуратно волженных друг в друга "матрешках" в лиспе.
Конечно это уже зависит от программиста. Писать плохо можно на чем угодно.
Но лисп (и вообще ФЯ) поощряет хороший стиль и упрятывание лишних деталей, в то время как ИЯ позволяет с легкостью плевать на все рекомендации.
| № 1523 10-11-2006 18:00 | |
Ответ на »сообщение 1522« (Jack Of Shadows)
___________________________
А вот скажите, ведь эта супергибкость наверняка имеет оборотную сторону медали. Легко ли потом понять чужой код? Или даже свой через год?
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
