| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 4172 16-02-2008 13:29 |   |
Ответ на »сообщение 4171« (Geniepro)
___________________________
http://www.cliki.net/pcond
Он кстати помощнее хаскелевского будет. В отличии от хаскеля эта библиотека поддерживает не только простенький unification но и сопоставлене функциям и даже regexp.
В хаскеле насколько я знаю только ведутся исследования на эту тему.
Вот она сила лиспа! Все что угодно можно играючи реализовать, не ожидая годами когда комитет сподобится что то добавить в язык.
| № 4171 16-02-2008 10:53 | |
Ответ на »сообщение 4170« (Jack Of Shadows)
___________________________
Теперь у меня есть практически идентичный хаскелю синтаксис pattern matching, currying и functional composition.
И это все в лиспе!! :))
А паттерн матчинг какой библиотекой делаете?
| № 4170 15-02-2008 23:30 | |
Ах какую приятную вещь я откопал для себя.
http://www.pasternacki.net/en/code/curly
Эта малюсенькая библиотека добавляет синтаксис currying и functional composition в лисп.
То есть вместо
(mapcar (lambda (x) (* 2 x)) '(1 2 3 4))
я могу писать
(mapcar [* 2] '(1 2 3 4))
И функциональная комозиция есть. В хаскеле для этого используются точки: fun1 . fun2 . fun3
а в этой библиотечке фигурыне скобки: {fun1 fun2 fun3}
Крррасота!!
Теперь у меня есть практически идентичный хаскелю синтаксис pattern matching, currying и functional composition.
И это все в лиспе!! :))
Так шта хаскелю придется подождать.
| № 4169 15-02-2008 15:11 | |
Ответ на »сообщение 4167« (Илья Ермаков)
___________________________
размерности таковы, что превышают объём оперативной памяти (т.е. надо делать собственный инфраструктурный слой для прозрачной буферизации-свопа, распределёнки и т.п.) Я повеселюсь, глядючи, как Ваша ФП-система в ответ на "коротенькую такую программку" красиво уйдёт в глубокое раздумье..
А зачем? Weak pointer's, которые делал info21 для своей знаменитой задачки, есть не только в Компонентном паскале, но и в том же Хаскелле, так что велосипед изобретать не надо )))
| № 4168 15-02-2008 13:13 | |
Ответ на »сообщение 4167« (Илья Ермаков)
___________________________
(т.е. надо делать собственный инфраструктурный слой для прозрачной буферизации-свопа, распределёнки и т.п.).
В чем проблема ? Хаскелевские библиотеки binary и ByteString как раз с этим справятся.
| № 4167 15-02-2008 12:50 | |
Ответ на »сообщение 4160« (Geniepro)
___________________________
А вот один из эрлангеров (недавно упоминавшийся здесь Джоэл Реймонт)
-- инвертирование огромнейшей матрицы с некоторыми вычислениями при этом.
А теперь представьте, что задача сводится далеко не только к численным матрицам, а размерности таковы, что превышают объём оперативной памяти (т.е. надо делать собственный инфраструктурный слой для прозрачной буферизации-свопа, распределёнки и т.п.). Я повеселюсь, глядючи, как Ваша ФП-система в ответ на "коротенькую такую программку" красиво уйдёт в глубокое раздумье... Мэйпл вот обычно уже и не выходит из него...
| № 4166 15-02-2008 11:00 | |
Ответ на »сообщение 4164« (Geniepro)
___________________________
Прикольно, надо это напечатать и на стенку вывесить :)
| № 4165 15-02-2008 07:28 | |
Ответ на »сообщение 4160« (Geniepro)
___________________________
При этом решение на Q выполнилось в четыре раза быстрее, чем на С++, и в три раза быстрее, чем на Фортране!
Некорректное сравнение. Правильнее сказать, что библиотека встроенных функций этого языка оказалась быстрее. Вот если бы на этом Q был написан в явном виде код, скажем, LU-факторизации, который бы всех уделал, это бы говорило о качестве языка и компилятора, но из данного примера такой вывод не следует.
| № 4164 15-02-2008 02:41 | |
Ответ на »сообщение 4162« (Александр Феоктистов)
___________________________
вот в этом выражении в операторе(функции?) inv скрывается наверно огромное количество отлаженного кода на асемблере ?
потому как я не верю в чудеса :)
Насчёт ассемблера -- не знаю, не видел исходников транслятора Q.
и мне кажется, если сравнить ФЯ со скриптовыми, то не видно большой разницы,
и там и там есть набор операторов, который решает набор типовых задач,
следовательно мощь языка тут напрямую зависит от богатства этого набора.
ЗЫ: это не наезд, скорее это просьба прояснить ситуацию, право ли моё предположение ?
На счёт мощности языков программирования недавно было обсуждение на RSDN'е, в результате которого выяснились такие физические свойства языков:
мощность языка = сила языка * скорость языка
Сопротивление языка, которое он оказывает при попытках думать и говорить на нем:
R = U / I = U^2 / P
(сопротивление, оказываемое языком, пропорционально квадрату напряжения, которое требуется для того, чтобы думать и говорить на нем. Но, при этом, оно обратно пропорционально его мощности).
Жо))
| № 4163 15-02-2008 02:40 | |
Ответ на »сообщение 4161« (QR)
___________________________
>>> Интересно, а автор этого "теста" прямо так и компилировал такой вот код:
>>> if (fabs(a[i][i] <= eps))
>>> ?
Да уж... :о) Честно говоря, не знаю. Авторы этой программы шесть лет назад
потратили на её разработку и отладку в двадцать раз больше времени, чем на Mathematica. То ли это был ну очень хитрый трюк, то ли они всё-таки мало времени уделили варианту на С/С++... :о)
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
