Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
№ 1132 04-09-2006 11:13 | |
Ответ на »сообщение 1118« (Geniepro)
___________________________
Ответ на »сообщение 1117« (Артем)
___________________________
"Почему никто не использует функциональные языки" Филип Вадлер
http://www.softcraft.ru/paradigm/fp/whynotfp.shtml
Там как раз анализируются причины незатребованности ФЯ...
Не устаю восхищаться Игорем Анатольевичем: хорошо выбрал ("умение выделять главное -- главный показатель ума") и перевел пару текстов -- вот кого бы ведущим этой ветки.
Помнится, как-то он сказал, что для ФЯ еще не было своего Вирта...
№ 1131 04-09-2006 11:12 | |
Ответ на »сообщение 1130« (Артем)
___________________________
Не могли бы вы привести исходник вашего 64-битного кода на F# ? :)
let dec32 n =
let f32 x y z =
let rec f232 x y z = if (y+1)=x then z else f232 x (y+1) (z+1)
in if x=1 then 0 else f232 x y z
in f32 n 0 0
let dec64 n =
let f64 x y z =
let rec f264 x y z = if (y+1L)=x then z else f264 x (y+1L) (z+1L)
in if x=1L then 0L else f264 x y z
in f64 n 0L 0L
let rec testtail k v = if k=1 then v else testtail (k-1) (v+1)
let test n = testtail n 1
let Nd32 = 1000000000
let Nd64 = 1000000000L
let st = System.DateTime.Now
let r = dec32 Nd32
let ft = System.DateTime.Now
let t = time ft - time st
do System.Console.WriteLine("dec32 == , time == ", Nd32, r, t)
let st2 = System.DateTime.Now
let r2 = dec64 Nd64
let ft2 = System.DateTime.Now
let t2 = time ft2 - time st2
do System.Console.WriteLine("dec64 == , time == ", Nd64, r2, t2)
PS. Ну про Release-то я знаю... :-))
ЗЗЫ. Кстати, понять не могу, выделил в C#-проге эти циклы в отдельные функции - 64битная стала выполняться за те же 6 сек.. Что за дела? почему в теле main она работала 7.3 сек?
№ 1130 04-09-2006 09:53 | |
Ответ на »сообщение 1129« (Geniepro)
___________________________
Действительно, на С# 32-битный расчёт в полтора раза быстрее, чем на F#, но 64-битный - на 20% медленнее!
Не могли бы вы привести исходник вашего 64-битного кода на F# ? :)
Кстати, а как Вы включаете оптимизацию в .NET? А то я, признаюсь, не в курсе... - Кнопкой включаю :)
Если быть точным, то это не оптимизация .Net, а оптимизация компилятора C#. (VS:Project/MyProject properties/Build/Optimize code)
№ 1129 04-09-2006 09:32 | |
Ответ на »сообщение 1124« (Артем)
___________________________
Так почему же тогда в следующем примере на C#, вы выбрали 64-битный?
Да, я так и думал, что Вы мне именно ЭТО припомните... :-))
Но дело в том, что этот тест я проводил и с 32-битными числами, и с 64-битными. Да, я недоглядел, и выложил куски кода с разными разрядностями. В этом виноват!
НО! Те значения времени выполнения я привёл для 64-битных тестов!
Ну хорошо, я немного приукрасил результаты, реально должно выглядеть так: bits C# F# Haskell(GHC)
32 1.2s 1.8s 5.8s
64 7.3s 6.0s ??? (не знаю, как указать int64 в Хаскеле)
Действительно, на С# 32-битный расчёт в полтора раза быстрее, чем на F#, но 64-битный - на 20% медленнее!
Кстати, я, оказывается, зря наезжал на компилятор GHC - нужно просто уметь им пользоваться! :)
Скомпилировал им (с ключём оптимизации -O ) ту же самую функцию Клини
dec:: Int -> Int
dec n = f n 0 0 where
f x y z = if x==1 then 0 else f2 x y z where
f2 x y z = if (y+1)==x then z else f2 x (y+1) (z+1)
и она тут же перестала нагружать стек и выполнилась более-менее быстро, хотя и в три раза медленнее, чем та же функция на F#.
В-общем, всё-таки не стоит считать Хаскель просто игрушкой. ;-)
Как видите, миллиард влазит и в 32-битный целый. :)
Спасибо, вижу! :))
ЗЫ. Кстати, а как Вы включаете оптимизацию в .NET? А то я, признаюсь, не в курсе... :-))
№ 1128 04-09-2006 07:51 | |
Ответ на »сообщение 1127« (Артем)
___________________________
Сложность все больше становится неконтролируемой.
Боюсь, что и ФП с этой проблемой не покончит :)
Так 20-летний пример внедрежа ООП в массы показывает, что это и не требуется. Достаточно под видом борьбы с кризисом переключить внимание всех на нечто такое особое, что подается как панацея. Пока разберутся в чем дело, успеют по уши погрязнуть в том, что для них станет привычным, удобным и без непременной совместимости с чем любое новое (или хорошо забытое старое) будет просто отторгаться.
Программисты IMHO упорно хотят облегчать себе жизнь, требуя по максимуму самых невероятных наворотов в языках и инструментах (даешь скрещивание ФП с ООП, а заодно уж и с генетическим программированием!), часто не понимая, что одно из самых важных, бесценных и утраченных качеств - чувство меры. Часто нужно идти на сильные ограничения и самоограничения, чтобы плод твоего творчества/труда поддавался последующему разумному контролю по сложности и через 3-5 лет не шел в корзину, а мог находить свое развитие и применение.
ФП имеет свои плюсы. Имеет и существенные минусы, из которых производительность - это по большому счету ерунда. Вот что реально дает ФП для контроля сложности софтверных проектов разного масштаба, направленности и времени жизни - гораздо интереснее было бы услышать в этой ветке.
№ 1127 04-09-2006 07:27 | |
Ответ на »сообщение 1123« (bb)
___________________________
Сложность все больше становится неконтролируемой.
Боюсь, что и ФП с этой проблемой не покончит :)
№ 1126 04-09-2006 07:10 | |
Ответ на »сообщение 1124« (Артем)
___________________________
Пардон, я вместо F#-вского Haskell-вский тектст запхал в прошлом сообщении. Но суть от этого не меняется.
let rec f2 x y z = if (y+1) = x then z else f2 x (y+1) (z+1)
let f x y z = if x = 1 then 0 else f2 x y z
let dec n = f n 0 0
let Nd = 1000000000
do Printf.printf "dec %d = %d\n" Nd (dec Nd)
№ 1125 04-09-2006 07:08 | |
Ответ на »сообщение 1118« (Geniepro)
"Почему никто не использует функциональные языки" Филип Вадлер
http://www.softcraft.ru/paradigm/fp/whynotfp.shtml
Понятно теперь, откуда Jack черпает лозунги:
Функциональное программирование прекрасно, оно - радость созерцания. Как только кто-то поймет функциональное программирование, он немедленно перейдет к нему. Массы, которые застряли в устаревшем императивном и объектно-ориентированном программировании, делают это из слепого предубеждения. Они просто не понимают.
№ 1124 04-09-2006 06:47 | |
Ответ на »сообщение 1121« (Geniepro)
___________________________
Ув. Geniepro! Как вы думаете, какой тип для x,y,z выбирается в результате type inference?
dec n = f n 0 0
f x y z = if x == 1 then 0 else f2 x y z
f2 x y z = if (y+1) == x then z else f2 x (y+1) (z+1)
main = print (dec 1000000)
Так почему же тогда в следующем примере на C#, вы выбрали 64-битный?
long x, y, z;
const long N = 1000000000L;
x = N; y = 0; z = 0;
while ((y+1) != x)
Здесь (если у вас, конечно, не 64-битная Винда) идет эмуляция 64-битной арифметики. Для корректного сравнения надо было написать так:
int x, y, z;
const int N = 1000000000;
x = N; y = 0; z = 0;
while ((y + 1) != x)
Как видите, миллиард влазит и в 32-битный целый. :)
Даже без включения оптимизации (надеюсь, вы знаете, что и в .Net можно включить оптимизацию) код выполнился гораздо быстрее.
Вывод. Вот такие горе-тесты, как в сообщении 1088, и дают искаженную картину производительности.
P.S. Gienpro! Не обижайтесь. Просто тесты должны быть более продуманы...
№ 1123 04-09-2006 06:29 | |
Ответ на »сообщение 1122« (Сергей Перовский)
___________________________
Кстати, многие аргументы могут быть перенесены и в ветку по Оберонам.
Внешне - да, а по сути - вряд ли. ФП - это практически другой мир в сравнении с привычным императивным и ООП. Кризис программирования с начала 70-х не только не преодолен, но все больше усугубляется. Сложность все больше становится неконтролируемой. В этой ситуации что-то кардинально иное (как было в свое время с ООП) будет с большей легкостью подхвачено софтверной индустрией. Так что у функционального программирования через n-е число лет все шансы занять трон, вытеснив оттуда ООП. Со сложностью можно бороться по-разному. Упрощения а-ля Оберон рынку не выгодны. Давно пора бы это всем нам понять. А другая парадигма - вполне. Это деньги и новый рынок.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|