| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 622 09-08-2006 10:34 |   |
Ответ на »сообщение 620« (Geniepro)
___________________________
Господа, эта ветка превратилась в соревнование по скачиванию различных экзотических компиляторов и прогону на них 2-х строчек наивного алгоритма фибоначи.
Мне это не нравится.
Такие замеры бессмысленны. Мы топчемся на месте.
Для подавляющего большинства прикладных задач скорости современных компиляторов более чем в 10 раз превышают необходимую скорость для решения этих задач.
Именно поэтому разработка web приложений практически полностью завоевана скриптовыми динамическими языками.
Это несмотря на то что они от 10 до 100 (!!!) раз медленнее компилируемых.
Я хочу обратить внимание на кое что другое.
Это обсуждение началось с отличной новости о переходе Интела на многоядерную архитектуру.
Как вы думаете, что это означает для языков, которые не могут задействовать все ядра, а работают только на одном ядре ?
Что случится с такими языками когда количество ядер достигнет 8 или 16 (через 3-4 года) ?
ТО есть программы написанные на таких языках будут задействовать 1/8 или 1/16 процессора.
Если вы еще не поняли, я говорю о скриптовых языках. Php, Python, Ruby, Perl - все эти фавориты современного web development имеют один общий недостаток. Нет полной поддержки настоящей многопоточности (multithreading)
То есть многопоточность в них конечно реализована, но внутри свое виртуальной машины.
Это значит что на многопроцессорной (или многоядерной) системе все потоки выполняются в на одном процессоре (ядре). И насколько я знаю, решить эту проблему разработчики этих языков не в состоянии.
| № 621 09-08-2006 10:19 | |
Ответ на »сообщение 619« (Max Belugin)
___________________________
В лиспе и в хаскеле во время вычислений происходит автоматическое преобразование типов если число не помещается в отведенную ему ячейку. То есть грубо говоря integer привращается в BigInt а тот еще далье в HugeInt итд итп.
ФЯ могут позволить себе такую неэффективную трату памяти, поскольку никогда не создавались с целью экономии памяти.
Императивные языки до сих пор ведут себя так как будто им доступно всего 640 кб. :))
| № 620 09-08-2006 09:26 | |
Ответ на »сообщение 618« (SJ)
___________________________
Маленький вопрос к знатокам ФЯ - функциональные языки действительно имеют встроенные возможности по "склеиванию" сверхбольших чисел, которые выходят за рамки возможностей стандартных числовых форматов? Если это так, то это несомненный плюс этих языков. Значит в "математике сверхбольших числовых диапазонов" этим языкам нет альтернативы. Или я что-то тут не понимаю?
Я, правда, не знаток ФЯ, но как я понял, это зависит от конкретного языка и конкретной его реализации. Например, на Лиспе в системе CLisp проблем вроде нет:
(defun fact (n)
(cond ((eq n 1) 1)
(t (* n (fact (1- n))))
)
) (fact 100)
93326215443944152681699238856266700490715968264381621
46859296389521759999322991560894146397615651828625369
7920827223758251185210916864000000000000000000000000
Также и в Хаскелле в WinHUGS:
fact 0 = 1
fact n = n * fact (n - 1) fact 100
93326215443944152681699238856266700490715968264381621
46859296389521759999322991560894146397615651828625369
7920827223758251185210916864000000000000000000000000
А вот SML.NET в Visual Studio 2005 лажанул:
fun fact (0) = 1
| fact (n) = n * fact (n - 1) fact (100)
0
Может, я что-то ему не указал, не знаю... Но вот такой вот результат... :-( С наскока не получилось...
| № 619 09-08-2006 07:54 | |
| № 618 09-08-2006 06:07 | |
Когда в Haskell вычисляется число Фибоначчи с 1000-м номером или факториал 100, то это производит впечатление.
Маленький вопрос к знатокам ФЯ - функциональные языки действительно имеют встроенные возможности по "склеиванию" сверхбольших чисел, которые выходят за рамки возможностей стандартных числовых форматов? Если это так, то это несомненный плюс этих языков. Значит в "математике сверхбольших числовых диапазонов" этим языкам нет альтернативы. Или я что-то тут не понимаю?
>>>Почитаю, что такое этот Mercury, может, тоже скачаю, посмотрю...
>>>Что-то типа Хаскелля, что ли?..
Нет.
Haskell - это язык функционального программирования, он скорее родственник таких языков, как Lisp, Caml, Miranda и т.д.
Mercury - язык логического программирования. Он из той же группы, что и язык Prolog. Хотя я не знаю, какие еще языки, кроме Mercury и Prolog входят в эту группу.
| № 617 09-08-2006 04:01 | |
Ответ на »сообщение 616« (Geniepro)
___________________________
Какой смысл тут секунды мерять? Надо сгенеренный MSIL сравнивать.
| № 616 09-08-2006 03:49 | |
Ответ на »сообщение 615« (Jack Of Shadows)
___________________________
Окей, оставим эту сомнительную сингулярность, вернёмся к нашим баранам... :-)
Таки вставил я в Visual Studio хоть один ФП!
SML.NET - http://www.cl.cam.ac.uk/Research/TSG/SMLNET/dist/vssmlnet.tar.gz
Всего 3.6 мегабайта!
Хотя в описании упомянуты VS2002 и VS2003, но и в VS2005 она тоже интегрируется.
Компилятор не очень шустрый, особенно заметны тормоза при вводе текста программы - проверка синтаксиса существенно тормозит...
Не могу пока сравнить точно быстродействие программ на SML.NET с С#, но на глаз - примерно одинаково:
fun fib (1) = 1
| fib (2) = 1
| fib (n) = fib (n - 1) + fib (n - 2) static int Fib(int n)
при n=40 время выполнение на С# составило 2.8 сек, и практически столько же на SML.NET (не знаю пока, как время замерить, поэтому замерял на раз-два-три... :-) ).
Вариант на С# с типом long уже заметно медленнее, чем на SML.NET без указания типа.
Ну что ж, неплохо. Оптимизации нет, к сожалению, но хотя бы сопоставимо с С#...
Я пока не знаю ML, но всё равно доволен! :-)
| № 615 08-08-2006 15:19 | |
Ответ на »сообщение 614« (Geniepro)
___________________________
Офтопик. Откройте отдельную ветку про технологическую сингулярность.
Все одно лучше чем "информационные поля" :))
Там и поговорим.
| № 614 08-08-2006 15:13 | |
Ответ на »сообщение 607« (Jack Of Shadows)
___________________________
Ну а что там возможно будт через 50 лет, у меня на этот счет совя теория, и боюсь она вам не понравится. :))
Я ожидаю конца света к году эдак 2045-2050.
http://en.wikipedia.org/wiki/Technological_singularity
Хм. имхо, довольно сомнительно всё это. Псевдонаучные спекуляции.
Графики, конечно, интересны, но сколько уже было подобных прогнозов? И сколько из них сбылись?
Все эти страшилки а-ля Армагеддон, Терминатор-Х...
Поживём, увидим, и, скорее всего, через полвека будем только смеяться над этой "сингулярностью"...
Да, ещё дожить надо до того времени... :-) Вот как рухнет Луна на Землю, так и настанет конец света, а все эти сингулярности - только красные словца... Футуристы, блин...
А что Римский клуб на этот счёт говорит?
| № 613 08-08-2006 13:39 | |
Ответ на »сообщение 612« (Geniepro)
___________________________
А почему, кстати, такие сомнения по поводу автоматической мемоизации?
Сомнений нет. Есть желание увидеть цифры :))
А новость для меня прекрасная просто. Я тут стараюсь изо всех сил показать все выгоды которые дает ФП.
Говорил про автоматическое распараллеливание, что уже реализовано в хаскеле.
А тут еще и автоматическая мемоизация тоже реализована. И все это только на чистых ФЯ. Императивныйм ничего не светит.
Кстати, по-моему, так можно преобразовать далеко не каждую функцию.
И для чего, это, кстати, нужно? Какие выгоды даёт?
Любую чистую (то есть без побочных эффектов) функцию.
А нужно как раз для автоматического преобразования алгоритмов. Этим может заняться компилятор.
Или для генератора функций. По существу это параметризация функций, что то похожее на параметризацию типов и generics.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
