| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 2302 30-03-2007 00:14 |   |
Ответ на »сообщение 2300« (Trurl)
___________________________
Программы а не шифр. То что вы показали называется обфускацией. Делается на любом языке простым переименованием всех функций и переменных на одно-двух буквенные бессмыссленные сочетания.
| № 2301 30-03-2007 00:08 | |
Ответ на »сообщение 2290« (Geniepro)
___________________________
sum $ map (\c -> read [c]) $ show $ product [1..100]
А сколько времени она считает сумму цифр 100! и сколько будет читать то же для 1000! ?
| № 2300 30-03-2007 00:01 | |
Ответ на »сообщение 2290« (Geniepro)
___________________________
>>>Мне очень понравилась статья Пола Грэма (Paul Graham) "Краткость - сила" , где он обосновывает своё мнение о том, что чем выше уровень языка и чем он удобнее, тем короче программы, на нём записанные.
G:(,"O";,"A";,"B";"AB"); R:("+";"-")
g:((0; 0 1; 0 2; 1 2)
(0 1; 0 1; !4; 1 2)
(0 2; !4; 0 2; 1 2 3)
(1 2; 1 2; 1 2 3; 1 2 3))
r:((!2; !2);(!2; ,1))
rh:
bt:
sl:
ch:sl[g;r]
pr:sl[;]
fm:/,/x,\:/:y),"}"]}
solve:
split:':0,1+&{x _in"+-?"}'s}
case:
in:@'0:"blod.in"
"blod.out" 0: case'!#in
;-)
| № 2299 29-03-2007 23:36 | |
Ответ на »сообщение 2295« (Jack Of Shadows)
___________________________
Понятно ведь что выигрывая в мелком случае, в больших задачах этот выигрыш суммируется.
Задачка которую здесь решили на хаскеле и на обероне, четко этот выигрыш показывает. Код уменьшился на половину.
А я кажется пропустил эту задачу. А где на нее можно посмотреть?
| № 2298 29-03-2007 14:10 | |
Ответ на »сообщение 2296« (Сергей Перовский)
___________________________
Вот в зависимости от наиболее подходящего способа разбиения и придется выбирать парадигму программирования :)
Я пробовал оба подхода, видел обе стороны.
А вы ?
| № 2297 29-03-2007 13:52 | |
Ответ на »сообщение 2290« (Geniepro)
___________________________
>>>n! means n * (n - 1) * ... * 3 * 2 * 1
Сразу вспоминается ядовитое: языки, оптимально подходящие для вычисления факториала... ;)
| № 2296 29-03-2007 13:30 | |
Ответ на »сообщение 2295« (Jack Of Shadows)
___________________________
>>>Так ведь любая самай сложная задача разбивается на меньшие, более простые, и так до тех пор пока вы не получите набор мелких однострочных задачек, которые записываются последовательно.
Вот в зависимости от наиболее подходящего способа разбиения и придется выбирать парадигму программирования :)
Вы безнадежны :P
| № 2295 29-03-2007 10:35 | |
Ответ на »сообщение 2292« (Сергей Перовский)
___________________________
Никто и не отрицает, что на простеньких математических задачках ФП очень эффективный инструмент.
Так ведь любая самай сложная задача разбивается на меньшие, более простые, и так до тех пор пока вы не получите набор мелких однострочных задачек, которые записываются последовательно.
Понятно ведь что выигрывая в мелком случае, в больших задачах этот выигрыш суммируется.
Задачка которую здесь решили на хаскеле и на обероне, четко этот выигрыш показывает. Код уменьшился на половину.
Далее чем больше задача - тем больше выигрыш.
То есть если в такой мелкой задаче вы получили выигрыш в 50%, в больших задачах получите - 70-80%
К сожалению осознание этого может придти к вам только с вашим опытом, которого вы избегаете как черт ладана.
Сергей, зачем сотни раз перетирать одно и тоже ? Вы много раз задаете один и тот же вопрос. И каждый раз получаете на него один и тот же ответ. Не ждите и не надейтесь. Другого ответа не будет.
Вам уже пора просто ПЕРЕСТАТЬ задавать один и тот же вопрос. Вы безнадежны. Вы будете сидеть и ничего не делать и уговаривать себя ничего не делать, пока вас жаренный петух в голову не клюнет.
То есть на работе просто не потребуют вдруг осваивать ФП.
Судя по вашей специальности, вы в безопасности. С вами это вряд ли когда приключится. Вам "повезло".
Меня когда то судьба заставила в далеком 92 году, на заре моей программистской карьеры плотно засесть за лисп. Не пару програм в паскалевском стиле написать. А полностью перейти на функциональный стиль.
Не будь этой оказии, я бы сейчас вместе с вами, с пеной у рта отстаивал бы ООП.
| № 2294 29-03-2007 10:21 | |
Ответ на »сообщение 2285« (AVC)
___________________________
Так где же (цвай таузенд тойфель!!) эта запись все-таки имеет место быть?
Где -- снаружи?
Снаружи ведь еще одна функция, которая также не может писать в "глобальные данные".
Снаружи означает что вот эта вот стрелочка <- отсутствует в функции преобразующей данные. Она находится СНАРУЖИ, в коде который эту функцию вызывает.
Если же функция вызывается из другой ЧИСТОЙ функции, то это означает что требуется ДАЛЬНЕЙШЕЕ преобразование данных. Опять на вход подаются одни данные, на выход результат преобразования.
И так до тех пор пока все преобразования не выполнены и ГОТОВЫЙ результат, не всплывает на уровень, где эта стрелочка <- живет. То есть в код помеченный IO
К тому же, писать данные где-то "снаружи", а не с помощью метода объекта, -- выглядит как нарушение инкапсуляции.
MyObject := TObject.Create() это значит не снаружи ? Это не нарушение инкапсуляции ?
А MyObject.PropVal := 10; - это не снаружи ?
| № 2293 29-03-2007 10:15 | |
Ответ на »сообщение 2292« (Сергей Перовский)
___________________________
Боюсь, что даже на такой, в общем простенькой задаче, решение на ФЯ будет и не компактнее и не понятнее, чем в ОО языке.
А вы не бойтесь. Ваши страхи необоснованы :))
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
