| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1462 08-11-2006 04:18 |   |
Ответ на »сообщение 1458« (Jack Of Shadows)
___________________________
Ответ на »сообщение 1456« (al_mt)
___________________________
Дык об этом мы тут талдычим с самого начала этой ветки!
Посмотрите в заголовке:
Они сьедают в десятки раз больше рессурсов чем императивные языки.
:)))
Просто время пришло. Рессурсы уже не жалко. Они уже дешевле чем время программиста.
Рессурс сейчас это вы, а не гигабайтная пластинка в несчастных 50 баксов.
ИМХО неверный вывод из верной посылки. По мере въезжания в идеологию ФЯ, устаканиваюсь в мысли, что "ещё не время". Даже нынешних гигабайтогерц маловато будет. И распараллеливание не спасёт, пока не сделают многопроцессорное железо, способное держать параллельную передачу данных "все-ко-всем" или хотя бы "один-ко-всем".
ФЯ применимо, как средство первичного анализа/формализации. Очень применимо. Минусом является необходимость для разработчиков постоянно переходить между ФЯ и ИЯ парадигмами, на каждой итерации разработки. Применимо, в случае технологического разделения аналитиков/проектировщиков и кодеров, хотя и тут затрудняет общение...
| № 1461 08-11-2006 04:13 | |
Ответ на »сообщение 1460« (Артем)
___________________________
Присваивание даже в таком чистом функциональном языке как Хаскель есть. Не говоря уж о лиспе.
С ограничениями, но все же.
И ? Что сказать то хотели ?
Без императивности то никуда. Но лучше эту императивность свести к минимуму.
Если до вас за все эти жаркие споры не дошло (хотя уже сколько раз говорилось что без императивности никуда), то придется наверное по буквам что ли. Функциональное программирование НЕ МОЖЕТ СУЩЕСТВОВАТЬ само по себе, без императивного выхода во внешний мир. Во всяком случае не на машинах существующей архитектуры.
И все о чем мы говорим - это МИНИМИЗИРОВАНИЕ имепративности до необходимого уровня а не полная замена.
Так что никуда присваивание не денется и из лиспа и из хаскеля и из процесса обчучения программистов.
Но вот отодвинуть его куда подальше, скажем на последний пятый уровень в курсе программирования, или в монады в хаскеле - святое дело.
| № 1460 Удалено модератором | |
| № 1459 08-11-2006 03:49 | |
Ответ на »сообщение 1457« (Артем)
___________________________
Посмотрите сами историю сообщений, как вы хаяли ООП и императивность в его лице.
Артем, ООП и обьекты это две бааальшие разницы.
ООП я хаял и хаять буду. ООП это не универсальная парадигма программирования в отличие от ФЯ / ИЯ - а частный инструмент, который по стечению обстоятельств на какое то (надеюсь короткое) время стал доминирующим.
| № 1458 08-11-2006 03:45 | |
Ответ на »сообщение 1456« (al_mt)
___________________________
Дык об этом мы тут талдычим с самого начала этой ветки!
Посмотрите в заголовке:
Они сьедают в десятки раз больше рессурсов чем императивные языки.
:)))
Просто время пришло. Рессурсы уже не жалко. Они уже дешевле чем время программиста.
Рессурс сейчас это вы, а не гигабайтная пластинка в несчастных 50 баксов.
| № 1457 Удалено модератором | |
| № 1456 08-11-2006 03:38 | |
Ага, дошло.
Да действительно в ФЯ это решается просто и логично, а в ИЯ нужно вводить понятие "события".
В реальных проектах это делается ведением глобального события, к обработке которого, новосоздаваемые объекты должны подключаться в динамике. Только ИМХО cells здесь особо не при чём :) всё дело в волшебных пуз.. тьфу! в идеологии ФЯ. Затык, как справедливо было замечено предыдущими ораторами, в ограничениях по "железу".
реальная реализация такого подхода в ИЯ - т.н. "ресурсное программирование":
- вся функциональность поделена между объектами;
- все внешние события любого объекта обрабатываются централизованно, через ядро;
Накладные расходы при реализации в ИЯ 3-5% Выгоды коллосальные. Главный недостаток - это довольно сложно.
В ФЯ всё делается легко и естественно, но вот накладные расходы... мммм... затруднюсь даже и оценить. Смутно подозреваю, что при решении задачи "в лоб" они будут расти квадратично :( А при минимальной оптимизации линейно, но запросто съедят и 50%... Однако этот недостаток не принципиальный. Полученный в результате промежуточный код на каком-нить C++ не сложно оптимизировать...
| № 1455 08-11-2006 03:33 | |
Ответ на »сообщение 1452« (Артем)
___________________________
Вариантов куча. Не вижу никаких преград для того, чтобы реализовать такую фичу в том же .net. Мало того, при желании ее можно написать за несколько дней.
Так я потому и поднял упоминание о cells, что в первую очередь интересен сам подход, а не его конкретная реализация в Lisp.
| № 1454 08-11-2006 03:30 | |
Ответ на »сообщение 1452« (Артем)
___________________________
Не вижу никаких преград для того, чтобы реализовать такую фичу в том же .net. Мало того, при желании ее можно написать за несколько дней.
С удовольствием бы посмотрел как вы за несколько дней утрете нос программистам MS - У них это и за несколько лет не получилось.
По поводу CLOS - прекрасная обьектная модель. Обьекты это типы данных господин Артем. Императивности в них ровно столько же сколько скажем в типе данных integer.
cells при желании можно использовать с любым типом данных а не только с обьектами.
Например
var
x, y : integer
x := ?f: y+5;
После чего меняете значение y и наблюдаете как автоматом меняется значение x.
Вот такой вот своеобразный OnChange навешенный на простенький integer.
Просто в таком применении cells был бы совершенно бесполезен.
Нечто вроде интересной игрушки.
Обьекты же хороши именно как способ классификации, хранения, разграничения доступа и сохранения целостности данных, Что то вроде базы данных в памяти. Вот и все, никакого секрета.
| № 1453 08-11-2006 03:16 | |
Ответ на »сообщение 1446« (Как слышно? Приём!)
___________________________
2) А теперь представим, что Вы задействовали связи в цикле! :)
Любой кто в Дельфи хотя бы один раз пользовался TDataSet.BeforeScroll - на эти грабли наступал :))
Я не исключение. Devil is in details действительно.
Дык в связке интсрумент - программист, умный всегда программист. Инструмент может быть мощным, слабым, громоздким, легким, универсальным, частным, но никогда умным.
cells не будет за вас программы писать :))
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
