Ответ на »сообщение 1270« (Сергей Перовский)
___________________________
Удастся ли реализовать такое взаимопонимание, если это будут разные языки? В .Net - удастся :)

Ответ на »сообщение 1268« (Сергей Перовский)
___________________________
Если удастся понять области применимости стилей (парадигм) программирования, тогда имеет смысл рассуждать - надо ли иметь универсальный язык или удобнее собирать программу из разноязыких модулей. Делать ли функциональный язык с вкраплениями императивного или наоборот. Пока, за неимением универсального языка, выбора у нас нет и нам придется собирать программу из разноязыких модулей.

Кстати, эта тема несколько пересекается с темой DSL, как внешних, так и внутренних. Но думаю, что никто не захочет спорить с тем, что DSL-языки - это не совсем полноценные языки. В том же Лиспе благодаря макросредствам можно использовать встроенный Prolog, но его полнота, производительность и синтаксис (все-таки отличный от нативного) будут оставлять желать лучшего. А если синтаксис и семантика реализуемого языка сложнее (у Пролога они довольно простые), то тут явно могут возникнуть принципиальные проблемы. Вы подумайте, например, что кто-то может сказать будто Haskell нам не нужен, т.к. мы его можем реализовать как DSL в Лиспе, - правда смешно звучит? В случае разномодульности мы сможем использовать уникальные особенности нужных нам языков по полной программе. С появлением .Net это стало делать удобно и приятно. За это Microsoft - огромное спасибо!
И раз речь пошла о моем любимом .Net, хочу еще сказать о так называемой "дисциплине" программирования. Если подразумевать эту самую дисциплину в смысле хотя бы Дейкстры, а не в смысле отсутствия "побочных эффектов", то IMHO, если у человека нет дисциплины в ООП, то не будет и в ФП :) И одной из важнейших задач является не то, как при помощи  языка заставить человека писать хорошо, а то, как минимизировать последствия того, если он пишет плохо. Попросту говоря, сделать так, чтобы дилетант своей программулькой не подвесил систему. И такие VM как Java и .Net не в последнюю очередь были созданы ради этого.

Ответ на »сообщение 1269« (Артем)
___________________________
"Каждая революция от чего-то отказывается".
Мне понятно рассуждение о большей строгости функциональных языков.
Отказавшись от понятия состояния, от понятия переменных функциональное программирование действительно позволяет писать более надежные программы. И действительно предъявляет более высокие требования к программистам.
Я вижу, что такой инструмент хорошо подходит для описания реакции системы на однократное воздействие, но не годится для построения полноценной диалоговой системы, которая обязана иметь текущее состояние.
Война с императивным стилем программирования мне тоже понятна: в начале императивный стиль программирования был единственным, т.к. отражал устройство компьютера. Постепенно выяснилось что ДЛЯ ОПРЕДЕЛЕННЫХ ЗАДАЧ удобнее использвать другую идеологию. Я уже много раз приводил в пример SQL - сейчас уже мало кто будет писать запросы к БД в императивном стиле, а когда-то это был единственный способ. Но предлагать на основании победы SQL на своем участке фронта, что нужно все программировать на SQL опрометчиво. Вместо кидания камней друг в друга, давайте попробуем провести границу. У каждого будет свое мнение по поводу ее местоположения, но я надеюсь, что каждый понимает, что она есть.

Вот для затравки:
Я думаю, что интерфейс будет очень сложно создать в функциональной парадигме - то, что человек видит на экране представляется ему именно объектами, имеющими текущее состояние. Представляется, что отдельные обработчики событий хорошо реализуются в функциональном стиле: на входе текущее состояние системы и пришедший сигнал, на выходе новое состояние. Но для этого нужно, чтобы функциональный язык понимал структуру объекта, состояние которого изменяет. Удастся ли реализовать такое взаимопонимание, если это будут разные языки?

Ответ на »сообщение 1264« (Сергей Перовский)
___________________________
Артем, не надо провокаций. Кто и что глупое, вопрос спорный. Ну, суть вопроса сводилась не к скобкам, а к тому, почему тут кто-то на наших глазах променял один идеал на другой. :) Могу и более развернуто сказать. Понимаете, если кто-то вам впаривает после прочтения очередной статьи по очередному языку, что вот он, единственно правильный путь, а вы, кто им не пользуется, - олухи и недотепы, то естественно возникает желание поиронизировать.
Так, меня снова несколько развеселили проповеди об очередной "панацее" - чистом ФЯ Haskell и о насаждаемой им "дисциплине" программирования. В впринципе, можно привести кучу контрдоводов по поводу дисциплины и чистоты. Только глупое это занятие. Лучше почитать хорошие книжки или статьи вменяемых авторов, которые подходят к вопросу взвешенно и основательно.
Не хочу, чтобы меня превратно поняли. Да, у меня есть свое мнение, мне больше нравится сочетание ООП и ЛП, а из ФЯ я собираюсь попробовать использовать смешанный OCaml. Но я не собираюсь в нарциссическом припадке утверждать, что все остальные пути - для плебеев от программирования.

Ответ на »сообщение 1263« (Артем)
___________________________
>>>Да дело и не в скобках. Фиг с ними, со скобками. Просто, нам тут раньше говорили об идеальном языке, который нельзя было разработать, который надо было открыть. Что Лисп - закон природы. Проходит некоторое время, и мы уже видим, как нам рассказывают о дисциплине чистых ФЯ и о чудесных свойствах Haskell.


(+1) Дело не в скобках.
Дело вообще не в синтаксисе.
Давайте не будем обсуждать, что лучше begin-end или {} - уже неинтересно.
Ветка называется "функциональное программирование", а не Лисп.
То, что в некоторых случаях функциональный подход дает прекрасные результаты бесспорно. Гораздо важнее понять, в каких случаях ждать успеха от функционального подхода не следует.
Я думаю, все участники дискуссии понимают, где выгодно использовать SQL, а где бессмысленно. Хотелось бы услышать такие рекомендации по функциональному подходу.
Если удастся понять области применимости стилей (парадигм) программирования, тогда имеет смысл рассуждать - надо ли иметь универсальный язык или удобнее собирать программу из разноязыких модулей. Делать ли функциональный язык с вкраплениями императивного или наоборот.

Ответ на »сообщение 1266« (Geniepro)
___________________________
У Вас какое-то предубеждение против синтаксиса Лиспа - но это нисколько не означает, что Лисп чем-то плох... Просто у Вас предубеждение, вот и всё... Да нет у меня предубеждения против скобок. Если нравится - пишите себе на здоровье.
Ответьте честно, Geniepro. Я вот смотрю, вы интересуетесь и Лиспом, и Хаскелем, и Сисалом, может еще чем-нибудь. А программы вы на них пишете?

Ответ на »сообщение 1263« (Артем)
___________________________

Да дело и не в скобках. Фиг с ними, со скобками.

Скобки - это всего лишь дело привычки, не более того! У Вас какое-то предубеждение против синтаксиса Лиспа - но это нисколько не означает, что Лисп чем-то плох... Просто у Вас предубеждение, вот и всё...
Я лично не заморачиваюсь этими скобками - все равно от них никуда не деться... :-))
Если их и не видно на синтаксическо поверхности - всё равно они есть!


А потом нам что, про  SISAL начнут рассказывать?

SISAL, увы, вымер, а зря... Как я понимаю, там итеративные операции, напоминающие обычные циклы, именно автоматически распараллеливались! (Язык-то параллельный!) В этом-то и была его главная фишка!


Нельзя ли остановиться на чем-то одном?

Если бы только это было возможно, мы бы до сих пор в машинных кодах программировали...
Ну действительно, зачем нужны все эти Pascal/Oberon/Ada/С/С++/C#/Java/Smalltalk/Lisp/Haskell/Ocaml/Prolog и ещё три тысячи языков программирования (или сколько их там уже)...
Ведь всё можно сделать в машкоде! :-))

Ответ на »сообщение 1236« (Артем)
___________________________
Вы знаете, может я был неправ насчет вашего пренбрежительного отношения ко всему сообществу программистов. Приношу свои извинения. Судя по подробному описанию одного из подтипов дураков, вас кто-то на работе серьезно достал. :) Сочувствую вам. :) Видно мне легче, - неадекватные личности, которые есть на моей работе, так сильно мне не докучают :)
Отчасти вы правы. Но дело не в отдельном человеке. "Я не знаю, как там в Лондоне, я там не был" - наверное Вагиф может больше порасказать, но, после некоторого промежутка времени работы в одном из НИИ бывшего минсреднемаша СССР, я отчётливо уразумел ПОЧЕМУ СССР О_Б_Я_З_А_Н БЫЛ ПРОИГРАТЬ ХОЛОДНУЮ ВОЙНУ.

"Дураков не пашут, не сеют, они сами рОдятся."

Ответ на »сообщение 1250« (Артем)
___________________________
>>>Или вам еще обилие глупых скобок не надоело? :)
Артем, не надо провокаций. Кто и что глупое, вопрос спорный.

Ответ на »сообщение 1261« (Geniepro)
___________________________
Говоря об обилии скобок в Лиспе, можно привестив пример тот же карринг.

(define foo_curried
    (lambda (x)
        (lambda (y)
            (foo x y)))))

И в OCaml:

let foo x y z = expr

Думаю, в Haskell похоже.

Да дело и не в скобках. Фиг с ними, со скобками. Просто, нам тут раньше говорили об идеальном языке, который нельзя было разработать, который надо было открыть. Что Лисп - закон природы. Проходит некоторое время, и мы уже видим, как нам рассказывают о дисциплине чистых ФЯ и о чудесных свойствах Haskell.

А потом нам что, про  SISAL начнут рассказывать? :) Нельзя ли остановиться на чем-то одном и попробовать написать несколько серьезных программ (или хотя бы одну), а не жонглировать примерчиками из учебников длиной в 10 строчек?

Я тут на rsdn читал одну статью про ФП, там есть классное замечание от редакции. Привожу его полностью.
Очень многие авторы, пропагандирующие ФЯ, перегибают палку и выдают желаемое за действительное. Например, поговорив об автоматическом распараллеливании кода, как в данном случае, заканчивают триумфальной тирадой об Эрланг, который никакого автоматического распараллеливания как раз и не производит. Вместо этого он предлагает идеологию, похожую на идеологию активных объектов, описанную в одной из статей этого номера. В Эрланг вводится понятие процесса, с которым можно взаимодействовать посредством асинхронных сообщений. Для упрощения этого в язык встроен небольшой, но мощный набор примитивов. Более того, до недавнего времени Эрланг вообще не осуществлял автоматическое выполнение разных процессов на разных процессорах системы (физических потоках ОС). Вместо этого Эрланг выполнял все свои процессы, размещающиеся в одном физическом процессе ОС, в рамках одного физического потока. Только недавно появилось сообщение о поддержке автоматического выполнения Эрланг-процессов в разных потоках ОС на SMP-системах. Фактически, имеется некоторый паттерн, встроенный в язык и не имеющий отношения к распараллеливанию вычислений, о котором так часто любят говорить приверженцы функциональных языков. Сколько-нибудь распространенных систем, реально автоматически распараллеливающих вычисления, пока нет. Возможно, некоторые исследовательские проекты и делают это, но они пока не покинули стен институтов.

К тому же возможности Эрланг проецируются на все функциональные языки как таковые. Фактически производится подмена предмета – если в Эрланг есть поддержка параллелизма, и Эрланг является функциональным языком, значит, это преимущество функциональных языков. Создается впечатление, что в не функциональных языках подобное невозможно или ужасно сложно. Однако это не так. К примеру, подход, очень похожий на используемый в Эрланг, используется в Sing# (модифицированном варианте C#), используемом при разработке экспериментальной ОС Singularity, о которой мы писали в одном из прошлых номеров.

К сожалению, это не единичный пример. Подобной болезнью страдают многие популяризаторы идей ФЯ. Увы, такой подход приводит к тому, что функциональное программирование из парадигмы программирования превращается в настоящую религию, отпугивающую многих потенциальных пользователей ФЯ фанатизмом и нетерпимостью.

Меж тем мир ФП – это необычайно интересный мир с множеством находок, практически неизвестных основой массе программистов. Что интересно, многое из мира ФП никак не связано с догматами ФП, а просто родилось и развивалось в этом мире, и только поэтому считается его частью. Интересно, что большинство ФЯ не являются таковыми на 100%. Они поддерживают все или большинство приемов ФП, но при этом позволяют программировать императивно. Есть только небольшое количество чисто функциональных языков, реально используемых ныне на практике. Пожалуй, самыми известными из них являются Haskell и Эрланг.

Большинство приемов ФП можно или использовать в императивных языках напрямую, или добавить в императивные языки в виде синтаксических конструкций. К сожалению, большинство ФЯ не только представляют функциональную парадигму, но и имеют семантику, очень непонятную программисту, привыкшему к С- или Паскале-подобному синтаксису. Сейчас появляются языки, пытающиеся ввести синтаксические конструкции, традиционные для ФП, в язык с традиционным С-подобным синтаксисом, например, Scala и Nemerle. Более того, даже изначально императивные языки программирования тем или иным путем впитывают некоторые концепции ФП. Так, в C++ функциональные веяния проникают через библиотеки (такие как STL и boost), а C# с каждой новой версией включает все больше и больше возможностей, традиционно относимых к функциональным.

Все это мы говорим к тому, чтобы читая этот и другие материалы по ФП, вы старались выделить интересные особенности этого стиля, и не обращали внимания на перегибы, периодически возникающие в изложении. Ведь и слепая вера, и слепое отрицание могут причинить только вред
Что говорить, лучше не скажешь.