Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 2072 02-03-2007 19:40 | |
Ответ на »сообщение 2071« (AVC)
___________________________
А вы обсуждение читали ?
Там вроде и ответ на ваш вопрос есть:
Потактовых, с учетом конвееров? ;-)
№ 2071 02-03-2007 18:11 | |
Ответ на »сообщение 2068« (Geniepro)
___________________________
Он там с товарищем недавно сделал на Хаскелле потактовую модель RISC-процессора (out-of-order multiply issue RISC with bypass logic and address computation instruction look-ahead).
Времени у них ушло на это - пять месяцев...
Кстати, он упоминал , что нечто подобное делала на Си какая-то команда из 10 программистов за четыре года...
Приведенные цифры неправдоподобны.
У нас за полгода пара ребят (конечно, способных) сделала RISC-процессор (в смысле довела до топологии).
(Написание программного эмулятора, ассемблера, компилятора Си и т.д. -- на мне.)
Чем занимались 10 программистов в течение 4-х лет остается пока загадкой.
Насколько я понимаю, автор блога с товарищем физический уровень не моделировали.
Поэтому остается предположить, что перед нами довольно рядовая задача дискретного моделирования (если нет, пусть Сергей Перовский меня поправит).
Откуда 5 месяцев?
№ 2070 02-03-2007 17:45 | |
http://blogs.nubgames.com/code/?p=22
Отличная статья про хаскель для закоренелых императивщиков.
То есть тех самых которые недоуменно чешут затылке, взяв в руки хаскель, "а как с этой штукой ввод/вывод делать ?"
На примере считывания текста с файлов а также с командной строки, показывается как полностью вытащить всю функциональность (то есть то что вы будете делать с данными) из императивной части, и реализовать ее как чистую функцию, которая передается в модуль, занимающийся непосредственно IO.
Отличные примеры. Короткие, понятные, без высоколобой лабуды про монады и прочую заумь.
№ 2069 02-03-2007 17:42 | |
Ответ на »сообщение 2067« (Geniepro)
___________________________
int kleene (int x, int y)
{
return (y+1 == x) ? y : kleene (x, y+1);
}
По поводу кода (ясное дело, игрушечного) возникла мысль, что вот надо же, иногда цикл намного выразительнее рекурсии.
Например:
PROCEDURE Kleene(x, y: INTEGER): INTEGER;
BEGIN
WHILE y+1 # x DO INC(y) END;
RETURN y;
END Kleene;
Откуда, возможно, один шаг до
PROCEDURE Kleene(x, y: INTEGER): INTEGER;
BEGIN
ASSERT(x > y);
RETURN x-1;
END Kleene;
>>>Чрезмерно усердный компилятор переоптимизировал программу и нарушил логику её работы...
Не зря info21 относится с подозрением к (уж слишком) оптимизирующим компиляторам. :)
№ 2068 02-03-2007 17:42 | |
Ответ на »сообщение 2065« (AVC)
___________________________
Какое именно моделирование имеется в виду?
В принципе, для этого существуют VHDL-симуляторы и т.п.
Это если разрабатывать процессор.
Он там с товарищем недавно сделал на Хаскелле потактовую модель RISC-процессора (out-of-order multiply issue RISC with bypass logic and address computation instruction look-ahead).
Времени у них ушло на это - пять месяцев...
Кстати, он упоминал , что нечто подобное делала на Си какая-то команда из 10 программистов за четыре года...
PS. А вообще, наверное, лучше полистать его блог, чем читать пересказы от третьих рук... :о))
№ 2067 02-03-2007 17:02 | |
Мда, забавная всё-таки эта штука - С++... Да ещё и в исполнении Майкрософта...
Оказывается, Visual C++ 2005 умеет разворачивать хвостовую рекурсию в цикл! Не ожидал...
#include <stdio.h>
#include <Windows.h>
int kleene (int x, int y)
int dec (int n)
int main()
Функция kleene переводится на ассемблер в такой вид:
_x$ = 8 ; size = 4
_y$ = 12 ; size = 4
kleene PROC
; return (y+1 == x) ? y : kleene (x, y+1);
start:
mov eax, DWORD PTR _y$[esp-4]
mov edx, DWORD PTR _x$[esp-4]
lea ecx, DWORD PTR [eax+1]
cmp ecx, edx
je SHORT exit
mov DWORD PTR _y$[esp-4], ecx
mov DWORD PTR _x$[esp-4], edx
jmp start
exit: ret 0
kleene ENDP
Круто! Много ли вы знаете компиляторов императивных языков с поддерхкой хвостовой рекурсии?
Кстати, при проверке этого кода у меня возникла проблема - программа постоянно показывала, что время выполнения равно 0 мс, хотя хорошо заметно было, что она работает несколько секунд.
Стал разбираться в том же ассемблерном листинге - оказалось, что переменные st и ft получали значения сразу же друг за дружкой, и только после этого вызывалась функция dec.
То есть выполнение программы шло совершенно не в том порядке, какой указал я!!!
Чрезмерно усердный компилятор переоптимизировал программу и нарушил логику её работы...
Вот вам и оптимизирующий компилятор С++...
Стоило заменить на (пляски с бубном):
int main()
как всё нормализовалось, а результат показал аж целых 5.6 секунды! Вапще круто!!! :о))))
Для сравнения - аналогичная программа на Хаскелле (GHC 6.6):
import Time
main = do st <- getClockTime; print st
print $ dec (1000000000::Int)
ft <- getClockTime; print ft
dec :: Int -> Int
dec n = f (n, 0)
where
f (x, y) | y+1 == x = y
| otherwise = f (x, y+1)
выполняется чуть менее, чем за 4 секунды! (Celeron 1.8)
Это к вопросу о супер-пупер оптимизирующих компилерах С++...
№ 2066 02-03-2007 16:02 | |
Ответ на »сообщение 2064« (Max Belugin)
___________________________
>>>Не знаю на чем проще всего моделировать ассемблер, но скорее всего не на другом ассемблере. Вполне возможно, и тут такая же штука...
Пока не очень понял, о чем именно идет речь.
Что значит "моделировать ассемблер"?
Если речь идет о программной модели процессора, способной "исполнять" программы, то у Вирта такие "модели" были в "Алгоритмы + структуры данных = программы", а также в Compiler Construction как 1996, так и 2005 года (что любопытно, целевые процессоры в этих изданиях разные).
№ 2065 02-03-2007 15:48 | |
Ответ на »сообщение 2063« (Max Belugin)
___________________________
>>>http://thesz.livejournal.com -- блог человека, который профессионально занимается моделированием процессоров на хаскелле
Какое именно моделирование имеется в виду?
В принципе, для этого существуют VHDL-симуляторы и т.п.
Это если разрабатывать процессор.
Если же речь идет о простом программном эмуляторе, который используется для отладки программ еще до выхода реального процессора, то на Си или Обероне можно управиться за день. (По крайней мере, у меня это никогда не занимало больше 2-3 дней.)
№ 2064 02-03-2007 13:53 | |
к »сообщение 2063« мысль: Не знаю на чем проще всего моделировать ассемблер, но скорее всего не на другом ассемблере. Вполне возможно, и тут такая же штука...
№ 2063 02-03-2007 13:46 | |
Ответ на »сообщение 2061« (AVC)
___________________________
Но надо хорошо все продумать, прежде чем запрещать побочные эффекты для функций, иначе у нас будут проблемы с КА, генераторами случайных чисел и т.д.
http://thesz.livejournal.com -- блог человека, который профессионально занимается моделированием процессоров на хаскелле
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|