N_>Ну во первых, наверное не синтаксис требует ломать голову. Синтаксис проще некуда.
Не синтаксис, а процесс программирования. Мне сейчас функциональные языки в этом отношении кажутся похожими на forth, написание любой программки это тренинг мышления, попытка понять через месяц что написал тоже
N_>Во вторых, любые нетривиальные задачи, которые стоят перед программистами требуют "ломать голову". И от этого по словам Брукса (Мифический человеко-месяц) никуда не деться. N_>Ну и в третих, то, что функциональный стиль труднее воспринимается — это не правда. Часто рекурсивные программы проще. А на императивных языках, из-за того, что рекурсия неэффективно компилируется тот же алгоритм начинает напоминать грамматику в форме Грейбах (как говорите "A +B C"). Хуже от этого может и не становится, но изящность теряется. N_>Если бы у вас было бы математическое образование (а похоже, что оно у вас не математическое), то вы бы когда-то изучали логику и вам было бы проще "переключать мозг" в "нужную" сторону. А пока, вы мне напоминаете того, кто всю жизнь работает с грамматиками "A +B C" и так привык к этому, что "A + B" кажентся непривычным.
По математике, я нормально воспринимаю мат. символику, и раньше немного программировал на Прологе, вот пролог почем-то у меня не вызвал никакого оторжения было сначало непривычно а потом наооборот легко.
Здравствуйте, borisman2, Вы писали:
B>У меня вопрос следующий.
B>Я изучал ФЯ главным образом по языку Clean. Как работвют основные конструкции, что почем, я понял. Однако куда реально это применить — не знаю.
Вот у меня тоже самое, правда только с ocaml.
Правда на ocaml можно и императивно писать, но бессмысленно C++ лучше приспособлен для этого.
B>Иными словами, необходимы конкретные примеры применения ФЯ как внутри ИЯ проектов, так и в самостоятельных проектах, полностью написанных на ФЯ.
Здравствуйте, FR, Вы писали:
N_>>Ну во первых, наверное не синтаксис требует ломать голову. Синтаксис проще некуда.
Да.
FR>Не синтаксис, а процесс программирования. Мне сейчас функциональные языки в этом отношении кажутся похожими на forth, написание любой программки это тренинг мышления,
Да.
FR>попытка понять через месяц что написал тоже
Нет.
Стиль синтаксиса С++ просто не подходит для ФЯ. Хотя бы потому, что у ФЯ с С++оидами довольно мало общего и для большинства элементов языка просто нет эквивалентов.
FR>По математике, я нормально воспринимаю мат. символику, и раньше немного программировал на Прологе, вот пролог почем-то у меня не вызвал никакого оторжения было сначало непривычно а потом наооборот легко.
С ФЯ будет точно так же Меня поначалу Хаскелевские конструкции вроде [ x | xs <- [ [(1,2),(3,4)], [(5,4),(3,2)] ],
(3,x) <- xs ] тоже пугали, а теперь в Ocamlе их очень не хватает.
Позволю себе привести цитату из Капитана Врунгеля
Поразмыслив над этим, я решил было вовсе изгнать все морские термины
из своего лексикона, заменив их теми словами, которые с давних пор су-
ществуют в обычном нашем живом языке.
Результат, однако, получился весьма нежелательный: первая же лекция,
прочитанная мною в соответствии с принятым решением, доставила много не-
нужных огорчений как мне, так и моим слушателям.
Начать с того, что лекция эта продолжалась втрое дольше против обыч-
ной, ибо оказалось, что в морском языке есть немало терминов, вовсе не
имеющих замены. Я же, не желая отступать от принятого решения, каждый
раз пытался заменить эти термины их пространными толкованиями. Так, к
примеру, вместо слова рея я каждый раз говорил: "Круглая деревянная бал-
ка, несколько утолщенная в средней части, горизонтально подвешенная на
высоком тонком столбе, вертикально установленном на судне..." Вместо
слова руль я принужден был повторять: "Вертикальная пластина, с помощью
рычага или нового специального привода поворачивающаяся на вертикальной
оси, укрепленной на подводной части задней оконечности судна, служащая
для изменения направления движения последнего..."
Сожалея при этом о напрасной трате времени, потребного для неоднок-
ратного произнесения этих определений, я старался выговаривать их одним
духом, скороговоркою. А так как слов, требующих подобных разъяснений,
попадалось немало, лекция моя стала походить на заклинание волшебника
или на камлание шамана. И вполне естественно, что слушатели мои, несмот-
ря на все старание, в котором я не имею оснований сомневаться, ничего из
моих объяснений не усвоили и, более того, не поняли.
Огорченный неудачей, я тем не менее не пал духом. Терпеливо и внима-
тельно я снова проработал этот вопрос, и после всестороннего изучения
имеющихся на эту тему трудов и литературных источников, сопоставив их с
собственными наблюдениями, я пришел к выводу, что: морская терминология
есть не что иное, как специальный морской инструмент, которым каждый мо-
ряк обязан владеть столь же уверенно и искусно, сколь уверенно плотник
владеет топором, врач — ланцетом, а слесарь — отмычкой.
Здравствуйте, FR, Вы писали:
B>>У меня вопрос следующий.
B>>Я изучал ФЯ главным образом по языку Clean. Как работвют основные конструкции, что почем, я понял. Однако куда реально это применить — не знаю.
FR>Вот у меня тоже самое, правда только с ocaml. FR>Правда на ocaml можно и императивно писать, но бессмысленно C++ лучше приспособлен для этого.
Императивно — это без темплейтов, функций высшего порядка, строгой типизации, автоматической сборки мусора и модульности? Для этого лучше приспособлен простой С.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, FR, Вы писали:
N_>>>Ну во первых, наверное не синтаксис требует ломать голову. Синтаксис проще некуда. INT>Да.
FR>>Не синтаксис, а процесс программирования. Мне сейчас функциональные языки в этом отношении кажутся похожими на forth, написание любой программки это тренинг мышления, INT>Да.
Это плохо, это значит что язык мешает работать.
FR>>По математике, я нормально воспринимаю мат. символику, и раньше немного программировал на Прологе, вот пролог почем-то у меня не вызвал никакого оторжения было сначало непривычно а потом наооборот легко.
INT>С ФЯ будет точно так же Меня поначалу Хаскелевские конструкции вроде [ x | xs <- [ [(1,2),(3,4)], [(5,4),(3,2)] ], INT>(3,x) <- xs ] тоже пугали, а теперь в Ocamlе их очень не хватает.
ладно видно будет может и привыкну.
INT>Позволю себе привести цитату из Капитана Врунгеля
Врунгель это хорошо но не к месту, и ИЯ и ФЯ не повседневные языки.
INT>Императивно — это без темплейтов, функций высшего порядка, строгой типизации, автоматической сборки мусора и модульности? Для этого лучше приспособлен простой С.
Ну не надо ИЯ сводить только к процедурному программированию, есть еще и ООП, тоже насквозь императивный.
А С++ на самом деле лучше приспособлен для исперативного стиля просто потому что на Ocaml не удобно писать в императивном стиле.
Здравствуйте, FR, Вы писали:
FR>Ну не надо ИЯ сводить только к процедурному программированию, есть еще и ООП, тоже насквозь императивный.
ООП, как ни странно, работает лучше, если использовать его только там, где оно действительно необходимо.
FR>А С++ на самом деле лучше приспособлен для исперативного стиля просто потому что на Ocaml не удобно писать в императивном стиле.
Нет. Я приводил пример Эратосфена.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, FR, Вы писали:
FR>>Ну не надо ИЯ сводить только к процедурному программированию, есть еще и ООП, тоже насквозь императивный. INT>ООП, как ни странно, работает лучше, если использовать его только там, где оно действительно необходимо.
Это верно не только для ООП.
FR>>А С++ на самом деле лучше приспособлен для исперативного стиля просто потому что на Ocaml не удобно писать в императивном стиле. INT>Нет. Я приводил пример Эратосфена.
Я ничего кроме вот этой страшной конструкции ни нашел:
let addprime arr n size = fold (fun a i -> set a (i*n)) [2..(size/n)] arr
let sieve size = fold (fun a i -> if get a i then addprime a i size else a) [2..size] (make size true)
Здравствуйте, FR, Вы писали:
FR>Я ничего кроме вот этой страшной конструкции ни нашел: FR>
FR>let addprime arr n size = fold (fun a i -> set a (i*n)) [2..(size/n)] arr
FR>let sieve size = fold (fun a i -> if get a i then addprime a i size else a) [2..size] (make size true)
FR>
Упс. Это был не Ocaml. Это был как раз пример чисто функционального решета.
Вот работающий код на Ocaml.
open Array
let sieve size =
let arr = make (size+1) true in
for i = 2 to size do
if arr.(i) then
for j = 2 to (size)/i do
arr.(j * i) <- false
done
done;
arr
let show_last n =
let arr = sieve n in
let i = ref n in
while not arr.(!i) do i := !i - 1 done;
print_int !i;;
show_last 3000000;;
(*
Если нужно вывести все простые...
let show n =
let arr = sieve n in
for i = 2 to n do
if arr.(i) then Printf.printf "%d " i
done;;
*)
Считает до 3000000 в native-code около секунды. Большие размерности надо уже реализовывать черз модуль Bigarray.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Императивно — это без темплейтов, функций высшего порядка, строгой типизации, автоматической сборки мусора и модульности?
И чем все это мешает императивности? В C#2 в той или иной степени есть все что ты перечислил. В С++ из этого списка не хватает только сборки мусора.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
INT>>Императивно — это без темплейтов, функций высшего порядка, строгой типизации, автоматической сборки мусора и модульности? WH>И чем все это мешает императивности? В C#2 в той или иной степени есть все что ты перечислил. В С++ из этого списка не хватает только сборки мусора.
В С++ не работает нормально ничего из перечисленного. Все сделано на уровне макросообразных конструкций.
В С# есть сборка мусора и модульность. Строгой типизации — нет, делегаты какие-то мутные, темплейтов нет.
Здравствуйте, VladD2, Вы писали:
VD>Там все еще забавнее. В ОКамле алгоритмы в императивном стиле. Возми к примеру хип-сорт. Так что... Да и редко когда код на функциональном языке оказывается сильно короче того же С. И частенько хваленый хаскель сливает по черному (например, в Spell Checker или в Word Frequency).
Причем тут вообще Haskell? Никто никогда нигде не утверждал, что он работает быстро, тем более на задачах связанных с интенсивной работой с массивами. Его прелесть совсем в другом.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>Вот работающий код на Ocaml.
FR>Это уже вполне понятно FR>Но все равно не вижу смысла писать в таком стиле на ocaml.
Задача сугубо императивная, поэтому и стиль такой. Блин, нашли что обсуждать, ей богу, еще бы перемножение матриц сравнивали. Если на то пошло, нужно смотреть более функциональные задачи. У меня, например, есть пара парсеров на OCaml. Один интерпретор примитивного языка, а другой конвертатор из bnf в sml yacc. Могу их выложить, хотя я ими не очень доволен, писал их когда еще слабо разбирался в функциональном стиле.
Здравствуйте, Quintanar, Вы писали:
FR>>Это уже вполне понятно FR>>Но все равно не вижу смысла писать в таком стиле на ocaml.
Q>Задача сугубо императивная, поэтому и стиль такой. Блин, нашли что обсуждать, ей богу, еще бы перемножение матриц сравнивали.
Странно, что ты про это сказал Вот здесь как раз лежит модуль работы с матрицами. Перемножение, конечно, фигня, а вот нахождение обратной можно и посравнивать...
Ocaml — язык общего назначения. ИО и ОО в нем, как минимум, не хуже, чем в С++.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Ocaml — язык общего назначения. ИО и ОО в нем, как минимум, не хуже, чем в С++.
Да, но нет никакого смысла городить огород из-за еще одного императивного языка. На таких примерах совершенно не понять, в чем ФЯ-ки лучше императивных.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>В С++ не работает нормально ничего из перечисленного. Все сделано на уровне макросообразных конструкций.
Правда чтоли?
INT>В С# есть сборка мусора и модульность. INT>Строгой типизации — нет,
Это как это нет? Есть! Причем как компаилтайм так и рантайм. INT>делегаты какие-то мутные,
Делегаты как делегаты в чем проблема то? INT>темплейтов нет.
Я про C#2 говорил.
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
INT>>В С++ не работает нормально ничего из перечисленного. Все сделано на уровне макросообразных конструкций. WH>Правда чтоли?
#ifdef stuff_h
#define stuff_h
...
#endif
Это не макросообразная конструкция?
Темплейты — почему они не могут определяться только в хедерах? Не потому ли, что ониявляются просто замаскированными макросами? Не говоря уж о других их "приятных" особенностях...
INT>>В С# есть сборка мусора и модульность. INT>>Строгой типизации — нет, WH> Это как это нет? Есть! Причем как компаилтайм так и рантайм.
Была бы строгая — не были бы возможны контейнеры.
INT>>делегаты какие-то мутные, WH>Делегаты как делегаты в чем проблема то?
Когда я ими пользовался, мне они показались неудобными и неинтуитивными. Может, с непривычки.
INT>>темплейтов нет. WH>Я про C#2 говорил.
Он уже вышел? Я просто не в курсе. Может, дашь ссылку?
Здравствуйте, Nick_, Вы писали:
N_>Ну во первых, наверное не синтаксис требует ломать голову. Синтаксис проще некуда. N_>Во вторых, любые нетривиальные задачи, которые стоят перед программистами требуют "ломать голову". И от этого по словам Брукса (Мифический человеко-месяц) никуда не деться.
И все же многие мысли могут быть изложены проще.
N_>Ну и в третих, то, что функциональный стиль труднее воспринимается — это не правда.
Ну, значит огромная толпа программистов тебе врет. Понятно, что к такому стилю тоже можно привыкнуть, но привыкание дается крайне болезненно. Это как с слепым методом письма. Понятно, что после привычки писать им проще и быстрее, но вот чтобы привыкнуть нужно долго издеваться над собой и без специальных тренажеров и тренировок сделать это не просто.
N_> Часто рекурсивные программы проще.
Проще она в исконно рекусивных алгоритмах. То есть там где она есть по логике программы. В том же QuickSort-е, например. А вот когда ею заменяют циклы, то все уже не так просто. Оно даже может оказаться короче, но вот для восприятия получается даже сложнее.
N_> А на императивных языках, из-за того, что рекурсия неэффективно компилируется тот же алгоритм начинает напоминать грамматику в форме Грейбах (как говорите "A +B C"). Хуже от этого может и не становится, но изящность теряется.
С эффективностью сейчас проблем нет. Пролемы есть в излишней информации которую требуется вносить программисту для решения задачи в импиративном стиле. А рекурсия уже давно оптимизируется современными компиляторами.
N_>Если бы у вас было бы математическое образование (а похоже, что оно у вас не математическое), то вы бы когда-то изучали логику и вам было бы проще "переключать мозг" в "нужную" сторону.
Образование у меня не математическое, но логику я изучал. Требование же переключения мозга плохо в принципе. Это резко сокращает круг тех кто сможет освоить и применять подобный подход на практике.
Кстати, здесь принято общаться на ты. Да и "вы" с маленькой буквы выглядит нехорошо.
N_> А пока, вы мне напоминаете того, кто всю жизнь работает с грамматиками "A +B C" и так привык к этому, что "A + B" кажентся непривычным.
То есть я путаю черное с белым? А может быть все же это поклонники функционального стиля привыкнув к непривычному пытаются объяснить что только так и надо, и что это совсем привычно? Еще раз проведу аналогию со слепым методом печати. Да освоив его писать становится просто, но утверждение, что осваивать там нечего, и что это самый естественный стиль печатанья мягко говоря долеки от релий мира.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.