Mads Torgersen, C# Language PM, написал в своем блоге пост с говорящим названием: "Is C# becoming a functional language?". Автор демонcтрирует различные фичи функционального программирования на примере C# 3.0, отвечая на поставленый в название вопрос: "to some degree".

As many of you will be aware, C#3.0 is adding a significant number of new language features. While the overall driving force behind putting these features in is the support of LINQ (Language INtegrated Query), the way we do it is strongly inspired by functional programming techniques. Moreover, we strive to make the new features as general-purpose as possible (with the exception of query expressions – they are undeniably tied to the querying domain!), so they do come out as features that will enable more of a functional style of programming.

This begs the question: Are we making C# a functional language?

This of course is a vague question. First of all, what exactly is a functional programming language? What does it take to qualify? Rather than trying to define the canonical list of language features that you have to have to be functional, I think it makes more sense to define it as “a language that supports a functional style of programming.”

....

На LtU давеча пробегала концепция "fuctional OO programming" (которая, мол, и есть самая правильная): http://lambda-the-ultimate.org/node/2007 (и далее по ссылками).

Программирование, в котором функциональный стиль не используется, остроумно названо дисфункциональным

Здравствуйте, VladGalkin, Вы писали:

Я бы не сказал что он поддерживает функциональный стиль. Он поддерживает функциональные фичи. Для того чтобы поддерживать функциональный стиль, компилятор как минимум должен оптимизировать код написанный в данном стиле. Хотя бы корневую рекурсию (используемый стек то ограничен). А этого здесь нет.

GZ>Я бы не сказал что он поддерживает функциональный стиль. Он поддерживает функциональные фичи. Для того чтобы поддерживать функциональный стиль, компилятор как минимум должен оптимизировать код написанный в данном стиле. Хотя бы корневую рекурсию (используемый стек то ограничен). А этого здесь нет.

Кстати, недавно с удивлением узнал, что оказывается поддержка хвостовой рекурсии встроена в CLR — команда tail ret, если не ошибаюсь.

Здравствуйте, VladGalkin, Вы писали:

VG>Mads Torgersen, C# Language PM, написал в своем блоге пост с говорящим названием: "Is C# becoming a functional language?". Автор демонcтрирует различные фичи функционального программирования на примере C# 3.0, отвечая на поставленый в название вопрос: "to some degree".

Опять-таки, ответ на этот вопрос зависит от того, с какой стороны стороны на него смотреть. Появились ли функциональные возможности — да!, появились ли функциональные возможности — нет! Возможность определения ламбды сама по себе не является свидетельством функциоанальности языка, хоя бы потому, что ламда является побочным следствием ФЯ, возникшем из-за стремления сократить и без того огромное количество функций в программе. Основной подход функционального программирования — принципиальное отрицание состояния как такового — не реализован даже опционально и не будет реализован никогда ни в этом языке, ни в никаком другом, претендующим на современность.
Честно говоря, мне непонятны все эти попытки связать нововведения в языке с "поддержкой функционального программирования". Функциональное программирование как парадигма устарела еще в 70-ых годах вместе с процедурным программированием, подвидом которого оно является. Все эти лямды следует рассматривать лишь как синтаксический сахар (как и вывод типа). призванный сократить запись и освободить программиста от рутинных объявлений.

Здравствуйте, LaPerouse, Вы писали:

LP>Честно говоря, мне непонятны все эти попытки связать нововведения в языке с "поддержкой функционального программирования". Функциональное программирование как парадигма устарела еще в 70-ых годах вместе с процедурным программированием, подвидом которого оно является. Все эти лямды следует рассматривать лишь как синтаксический сахар (как и вывод типа). призванный сократить запись и освободить программиста от рутинных объявлений.

Ну да, конечно. Поразительный факт состоит только в том, что функциональное программирование начало развиваться только в конце 70-х. Именно тогда появились ML и первый функциональный диалект Lisp — Scheme. Если вы не понимаете фундаментальной разницы между императивным и функциональным подходом к написанию программ, лучше не позорьтесь, промолчите.

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, LaPerouse, Вы писали:

LP>>Честно говоря, мне непонятны все эти попытки связать нововведения в языке с "поддержкой функционального программирования". Функциональное программирование как парадигма устарела еще в 70-ых годах вместе с процедурным программированием, подвидом которого оно является. Все эти лямды следует рассматривать лишь как синтаксический сахар (как и вывод типа). призванный сократить запись и освободить программиста от рутинных объявлений.

Q>Ну да, конечно. Поразительный факт состоит только в том, что функциональное программирование начало развиваться только в конце 70-х. Именно тогда появились ML и первый функциональный диалект Lisp — Scheme. Если вы не понимаете фундаментальной разницы между императивным и функциональным подходом к написанию программ, лучше не позорьтесь, промолчите.

Повторяю — функциональное программирование является разновидностью процедурного, нравится вам это или нет. Единственное отличие заключается в подходе к хранению состояния. Если задаться целью, можно и на С писать почти в функциональном стиле. Разница между императивным и функциональным программированием мне понятна, что и позволило мне прийти к такому умозаключению.

Здравствуйте, LaPerouse, Вы писали:

LP>Повторяю — функциональное программирование является разновидностью процедурного, нравится вам это или нет. Единственное отличие заключается в подходе к хранению состояния. Если задаться целью, можно и на С писать почти в функциональном стиле. Разница между императивным и функциональным программированием мне понятна, что и позволило мне прийти к такому умозаключению.

Не является функциональное программирование разновидностью процедурного, нравится вам это или нет.
Объяснения по поводу того, что можно писать на С переадресуйте любителям С++. Я, например, знаю, что многие прекрасно пишут в объектно-ориентированном стиле на С и не жалуются. Тот факт, что на С можно, хоть и через Ж, писать в любом стиле, ничего не означает.

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, LaPerouse, Вы писали:

LP>>Повторяю — функциональное программирование является разновидностью процедурного, нравится вам это или нет. Единственное отличие заключается в подходе к хранению состояния. Если задаться целью, можно и на С писать почти в функциональном стиле. Разница между императивным и функциональным программированием мне понятна, что и позволило мне прийти к такому умозаключению.

Q>Не является функциональное программирование разновидностью процедурного, нравится вам это или нет.
Q>Объяснения по поводу того, что можно писать на С переадресуйте любителям С++. Я, например, знаю, что многие прекрасно пишут в объектно-ориентированном стиле на С и не жалуются. Тот факт, что на С можно, хоть и через Ж, писать в любом стиле, ничего не означает.

Прекрасно, давайте по пунктам. Единственным, я подчеркиваю, единственным ощутимым различием ФП от ИП является то, что в ФП запрещается "заморозка" состояния,в ИП — она разрешается. Вследствие чего появляется ЗАВИСИМОСТЬ ОТ ПОРЯДКА ВЫПОЛНЕНИЯ КОМАНД. Снадби любой процедурный язык способами более эффективной записи вызовов функций + встрой в язык некоторые операторы для обработки списков (что в нормальном языке реализуется библиотеками) — и получится чистейший функциональный язык. Остаеются только ленивые вычисления реализовать, но они не являются необходимым условием функциональности языка.

Впрочем, я никого не переубеждаю. Хочется вам думать, что ФП не являются вчерашним днем — думайте, кто же запрещает? Это не изменит аморальной сути функционального программирования.

LaPerouse wrote:
> Повторяю — функциональное программирование является разновидностью
> процедурного, нравится вам это или нет.
Да даже близко не является. Процедурное программирование — это
подмножество императивного стиля.

Функциональное программирование — это совершенно другой стиль.
Ортональный ООП и противоположный императивному.

LaPerouse wrote:
> Прекрасно, давайте по пунктам. Единственным, я подчеркиваю, единственным
> ощутимым различием ФП от ИП является то, что в ФП запрещается
> "заморозка" состояния,в ИП — она разрешается.
Нет. Единственным, я подчеркиваю, единственным ощутим различием является
ФП от ИП является использование ФВП — Функций Высших Порядков. ВСЁ

Порядок вычислений — не важен, есть функциональные языки с
eager-вычислениями, в которых порядок вычислений вполне определен.

Лямбды — это действительно просто сахар, хотя такой же необходимый для
ФП, как и циклы for/while для ИП, которые являются сахаром над if/goto.

ФП невозможен без какой-либо формы ФВП. А вот процедурные языки —
вполне возможны. В некоторых процедурных языках даже нельзя взять
указатель на функцию, а значит ФП не может быть подмножеством
процедурного стиля.

Здравствуйте, Igor Trofimov, Вы писали:

iT>Кстати, недавно с удивлением узнал, что оказывается поддержка хвостовой рекурсии встроена в CLR — команда tail ret, если не ошибаюсь.

Появилась в 2.0 и дико тормозит. Меж тем обычный goto решает все проблемы на ура.

Здравствуйте, Cyberax, Вы писали:

C> ФП от ИП является использование ФВП — Функций Высших Порядков. ВСЁ

Прости, ты в курсе, что в С и Паскале есть поддержка ФВП?

Если, да, то ответь на вопрос: Почему никто не считает эти языки функциональными?

VladD2 wrote:
> C> ФП от ИП является использование ФВП — Функций Высших Порядков. *ВСЁ*
> Прости, ты в курсе, что в С и Паскале есть поддержка ФВП?
В классическом Паскале, по-моему, нет.

> Если, да, то ответь на вопрос: Почему никто не считает эти языки
> функциональными?
Это не их основной стиль. Нет поддержки функциональных конструкций
непосредственно в языке.

Здравствуйте, Cyberax, Вы писали:

>> Прости, ты в курсе, что в С и Паскале есть поддержка ФВП?
C>В классическом Паскале, по-моему, нет.

Значит на счет С ты согласен?

>> Если, да, то ответь на вопрос: Почему никто не считает эти языки
>> функциональными?
C>Это не их основной стиль. Нет поддержки функциональных конструкций
C>непосредственно в языке.

Правильно. Теперь становится очевидно, что наличие ФВП само по себе ще не дотсточно чтобы о языке можно было сказать, что он функциональный или поддерживает функциональный стиль.

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

С С/С++ этих возможностей явно недостаточно. В Хаскеле почто только они и есть. В ОКамл их более чем достаточно...

VladD2 wrote:
>> > Прости, ты в курсе, что в С и Паскале есть поддержка ФВП?
> C>В классическом Паскале, по-моему, нет.
> Значит на счет С ты согласен?
Ну да, С как и Perl может быть WOP-языком (Whatever Oriented Programming).

> C>Это не их основной стиль. Нет поддержки функциональных конструкций
> C>непосредственно в языке.
> Правильно. Теперь становится очевидно, что наличие ФВП само по себе ще
> не дотсточно чтобы о языке можно было сказать, что он функциональный или
> поддерживает функциональный стиль.
Естественно, это необходимое, но не достаточное условие.

Просто тут был тезис, что ФП — это подмножество процедурного
программирования. Я привел пример свойства, которым процедурное
программирование не обладает, но которое необходимо для ФП. Вот и все.

Здравствуйте, Cyberax, Вы писали:

C>Ну да, С как и Perl может быть WOP-языком (Whatever Oriented Programming).

Не может. Мордой лица не вышел.

C>Просто тут был тезис, что ФП — это подмножество процедурного
C>программирования. Я привел пример свойства, которым процедурное
C>программирование не обладает, но которое необходимо для ФП. Вот и все.

Процедурному программированию по фигу есть ВФП или нет.
В некотором смысле процедурное программирование и функциональное конечно схожи. Однако процедурное программирование точно так же имеет много общего и с ООП.

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

Я могу перечислить такие возможности:
1. Возможность производить все вычисления в виде выражений (ен стэйтментов). Это же позволяет обходится без именения состояния.
2. Возможность использовать рекрусию без ограничения.
3. Возможность манипулировать с функциями как со значениями. Эту возможность часто путают с ФВП. Меж тем ФВП есть малая толика того что подразумевается под данным пунктом. Например, функции нужно уметь помещать в списки и применять к спискам (в том числе и к спискам функций).
4. Иметь краткий синтаксис для объявления простых объектов (а ля POD в С++). Желательно, чтобы эти объекты поддерживали неизменяемость и полиморфизм.
5. Наличие сопоставления с образцом.

Все эти пункты желательны, но не за исключением первого и второго не обязательны. Современные ФЯ обладают всеми этими возможностями. Императивные языки поддерживают их ряд. C# поддерживает довольно гибкую работу с функциями, но все же не не совсем такую же чистую как в языках проектировавшихся для использования функционального стиля.

VladD2,

C>> ФП от ИП является использование ФВП — Функций Высших Порядков. ВСЁ

VD>Прости, ты в курсе, что в С и Паскале есть поддержка ФВП?

Это указатели на функции что-ли?

VladD2 wrote:
> C>Ну да, С как и Perl может быть WOP-языком (Whatever Oriented Programming).
> Не может. Мордой лица не вышел.
Может-может. Даже точный GC к нему прикручивается (см. GCC). Другое
дело, что ничего не делается просто.

> C>Просто тут был тезис, что ФП — это подмножество процедурного
> C>программирования. Я привел пример свойства, которым процедурное
> C>программирование не обладает, но которое необходимо для ФП. Вот и все.
> Процедурному программированию по фигу есть ВФП или нет.
Собственно, я с этим не спорю — я это утверждаю. Может посмотришь на те
посты, на которые я отвечал.

Здравствуйте, Igor Trofimov, Вы писали:
iT>Кстати, недавно с удивлением узнал, что оказывается поддержка хвостовой рекурсии встроена в CLR — команда tail ret, если не ошибаюсь.
Ее изобретали любители ФП. Реализация оказалась связана с проблемами с CAS: для работы CAS необходимо иметь доступ к неразрушенному стеку. В итоге, реализаторам пришлось эмулировать нормальный стек через технологическое отверстие, что оказалось медленнее, чем наивная реализация. Я не в курсе, существует ли решение для этой проблемы.