| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 912 22-08-2006 04:33 |   |
Ответ на »сообщение 907« (Артем)
___________________________
>>>Все дело в том, что при задании рекурсии нам всегда придется проанализировать, не произойдет ли при ее использовании комбинаторный взрыв. Если нет - используйте рекурсию на здоровье.
Ну наконец-то.
А то опять инструмент хвалят и критикуют без четкого осознания области применимости.
Не бывает плохих и хороших инструментов (методов, алгоритмов), бывает использование к месту и не к месту.
Посмотрите раздел "головоломки" на круглом столе: там есть несколько задачь, решенных сочетанием аналитических и переборных методов - вот пример грамотного сочетания подходов.
| № 911 22-08-2006 03:41 | |
| № 910 Удалено модератором | |
| № 909 22-08-2006 03:13 | |
Ответ на »сообщение 612« (Geniepro)
___________________________
Теперь мне остается надеяться, что вы таки представите цифры по прогону представленного алгоритма на mercury.
Язык доступен для скачивания. За чем же дело встало ?
>>>Хе-хе... А он в отпуск ушёл, ему не до Меркурия... :-)
Не только поэтому. Я не вижу смысла тратить часы на скачивание лишних мегабайтов и изучение очередного языка лишь для того, чтобы получить какие-то измерения, которые можно заменить несколькими минутами логических рассуждений.
| № 908 22-08-2006 03:03 | |
Кстати, почему-это были проигнорированы довольно странные временные результаты итеративного умножения матриц 200x200 в LispWorks? Алгоритм-то не рекурсивный, а все-равно медленнее чем в том же Delphi как-минимум в 44 раза? (сообщения 715 и 721)
| № 907 22-08-2006 02:36 | |
Ответ на »сообщение 893« (Jack Of Shadows)
___________________________
Упертые императивщики в своем неприятии рекурсии, доходят до абсурда. Призывают программистов реализовывать низкоуровневой машинный механизм рекурсии своими ручками. :))
Более того, у них, как вы видите, это считается своеобразным тестом на "правильно обученного" программиста.
Правильно обученный программист оказывается должен бороться с рекурсией всеми мыслимыми способами.
Интересно, кого здесь вы считаете упертым императивщиком? И что, вообще, вы понимаете под термином императивщик? Приверженца ООП? Так тут уже говорили, что ООП программистам доступна как рекурсия, так и итерация. Я лично уже ...надцать раз говорил, что однозначный выбор между рекурсией и итерацией - это глупость. Для каждого случая мы в отдельности решаем, что выбрать. Часто - это компромисс между производительностью и выразительностью. Хотя и это не 100% правило. То же умножение матриц в итеративном плане более выразительно, чем в рекурсивном.
А у меня за 17 лет практики и работу во множетсве компаний и на множетсве больших и маленьких проектов ни разу не возникло необходимости в столь невероятно требовательных алгоритмах.
Все дело в том, что при задании рекурсии нам всегда придется проанализировать, не произойдет ли при ее использовании комбинаторный взрыв. Если нет - используйте рекурсию на здоровье.
P.S. Я подозреваю, что после второго витка "дискуссии" о преимуществах рекурсии и итерации мы можем снова выйти на тему переполнения стека. И кто-то снова скажет нам о переполнении в ООП и отсутствии такового в ФЯ.
Может, убьем в зародыше?
| № 906 22-08-2006 02:22 | |
Ответ на »сообщение 627« (SJ)
___________________________
Меня интересуют "физические" основы представления структур данных в различных языках и, в связи с этим, возник один вопрос.
В Haskell, Lisp и, я так понимаю, в большинстве других ФЯ "базисной" структурой являются списки.
Не могу сказать ничего определенного насчет Haskell, но в Лиспе это далеко не так (цитата из документа, который лежал в свое время по адресу fare.tunes.org/tmp/emergent/kmachine.htm):
Analysis of the storage on existing Lisp Machines indicated that only about 20 percent of the storage was actually stored in lists (the rest being vectors, structures, or classes)
Это было сочтено настолько важным, что в очередном поколении Лисп-машин от LMI выкинули поддержку CDR-coding, который до этого считался одной из их ключевых особенностей. С тех пор, конечно, утекло немало воды, но у меня есть некоторые основания думать, что это утверждение остается в силе.
Нигде не смог найти точного описания, что из себя представляет такой массив на "физическом" уровне: связанный список с указателями, для которого используется механизм индексации или это "настоящий" массив, в котором все элементы занимают смежные поля памяти и индексация выполняется путем вычисления адреса как в "обычных" массивах в императивных языках?
По крайней мере, в одной из достаточно старых Лисп-систем, внутренним устройством которой я интересовался, массивы реализуются именно как непрерывная область памяти. Весьма вероятно, что в остальных системах сделано то же самое. Впрочем, с учетом роста производительности железа, современные системы могут использовать и другие внутренние представления, но на этот счет я ничего конкретного сказать не могу, кроме "Use the Source, Luke!" :-)
| № 905 22-08-2006 02:20 | |
Ответ на »сообщение 904« (Антон Григорьев)
___________________________
Антон, спасибо за чистку.
Я срываюсь, а так не хочется загаживать тему.
| № 904 22-08-2006 02:15 | |
сообщение от модератораinfo21, вы опять занялись провокациями? Судьба обероновских веток вас ничему не научила?
Jack of Shadows, вы тоже зря поддаётесь на эти провокации. Я же знаю, что вы умеете не делать этого.
| № 903 22-08-2006 01:02 | |
Ответ на »сообщение 902« (Trurl)
___________________________
Это доказывает преимущество "подумать хорошенько" над "немного подумать" :)
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
