Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

Почему никто не использует функциональные языки

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

G>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>Почему никто не использует функциональные языки

В статье много интересных идей... Но! Это типичная рекламная статья от евангелиста данной технологии. Послушать аплогогетов нейронных сетей или ИИ — так совершенно непонятно, почему до сих пор по улицам не ходят андроиды, а мы все не в матрице... Тут применяются обычные рекламные трюки — декларируемые, потенциальные возможности выдаются за действительные, и делается вид — будто ещё чуть-чуть и функционаьные языки сравнятся с императивными, при этом очень существенные негативные факторы практически игнорируются (такие — как необходимость средств разработки и обучения — а это десятки миллиардов $). Обещается небо в алмазах, но как обычно забывают указать — как этого достичь.
В общем сам факт того, что статья написана 6 лет назад в 1998 году, а с тех пор воз и ныне там, если не хуже — показательно и свидетельсвтует само за себя...

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

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

G>>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>>Почему никто не использует функциональные языки

AF> В статье много интересных идей... Но! Это типичная рекламная статья от евангелиста данной технологии. Послушать аплогогетов нейронных сетей или ИИ — так совершенно непонятно, почему до сих пор по улицам не ходят андроиды, а мы все не в матрице... Тут применяются обычные рекламные трюки — декларируемые, потенциальные возможности выдаются за действительные, и делается вид — будто ещё чуть-чуть и функционаьные языки сравнятся с императивными, при этом очень существенные негативные факторы практически игнорируются (такие — как необходимость средств разработки и обучения — а это десятки миллиардов $). Обещается небо в алмазах, но как обычно забывают указать — как этого достичь.
Кажется, ты прочел какую-то другую статью. Ничего из перечисленного там нет.

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

AF> В общем сам факт того, что статья написана 6 лет назад в 1998 году, а с тех пор воз и ныне там, если не хуже — показательно и свидетельсвтует само за себя...
Если не хуже, говоришь? Откуда такие опасения? Откуда ты знаешь, где воз был и где он сейчас? У тебя есть статистика по количеству применений ФЯ по годам за последние 6 лет? Или ты просто смотришь, стоит-ли соответствующий SDK на твоем компе и у соседа, который на днях его удалил?

Наивно думать, что ситуация может измениться так стремительно — сегодня "никто", завтра — "все".

P.S.: Небольшой комментарий к теме "делается вид — будто ещё чуть-чуть и функционаьные языки сравнятся с императивными".

Фрагменты моей переписки с Eric Newhuis из FutureSource (мои вопросы — его ответы):

> Btw, recently noticed that you're looking for an Erlang developer.
> You using Erlang for feed parsers there in FutureSource, right?
Yes we're using Erlang for some feed parsing and also for other things as
well. Most of the legacy code is C++, however, and so there is still a
majority of parsing in C++.

But Erlang looks better to us every day.

> Interesting, how your management get convinced to use Erlang?
I am management. It takes a while. Start out with small project. Look
for the failures with C++. Solve them with Erlang.

Вот так. Вы все еще кипятите? А мы уже рубим!

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

G>Вот так. Вы все еще кипятите? А мы уже рубим!

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

G>Вот так. Вы все еще кипятите? А мы уже рубим!

Dear Gaperton.

Дай порубить ! ( Где,что,почем ( i love halyavah ) )

Цунцуяби

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

AF>> В статье много интересных идей... Но! Это типичная рекламная статья от евангелиста данной технологии. Послушать аплогогетов нейронных сетей или ИИ — так совершенно непонятно, почему до сих пор по улицам не ходят андроиды, а мы все не в матрице... Тут применяются обычные рекламные трюки — декларируемые, потенциальные возможности выдаются за действительные, и делается вид — будто ещё чуть-чуть и функционаьные языки сравнятся с императивными, при этом очень существенные негативные факторы практически игнорируются (такие — как необходимость средств разработки и обучения — а это десятки миллиардов $). Обещается небо в алмазах, но как обычно забывают указать — как этого достичь.
G>Кажется, ты прочел какую-то другую статью. Ничего из перечисленного там нет.
G>

G>Этот длинный список причин, по которым никто не использует функциональные языки, может выглядеть уныло, но я предпочитаю смотреть на светлую сторону. Люди не отвергают функциональные языки из-за глупости, скорее они отвергают их по целому ряду серьезных причин. Глупость непробиваема — другими проблемами мы можем заняться.

Намёк понятен Чего и Вам желаю... Я прочёл именно эту статью — и прочёл очень внимательно, так как сам интересуюсь функциональными языками. В этой статье хорошо описаны причины того, почему функциональные языки не распространены. Беда в том, что акценты ставятся совершенно иначе, чем их расставил бы человек не заинтересованный. Как обычно и бывает в рекламе.
Все описанные "причины" — показаны мелкими, незначительными и легко преодолимыми. Вот пример:

Задача обучения не является трудноразрешимой. В Software AG нашли, что они могут обучать программистов использованию Natural Expert на однонедельном курсе, который включал ленивые вычисления, полиморфные типы и функции высшего порядка. Как правило, студенты раздражались, когда компилятор неоднократно отвергал программы из за ошибок типизации, но были приятно удивлены, когда их программы наконец проходили контроль типов и работали правильно с первой попытки [8].

Из этого абзаца следует, что типичному функциональному языку (а именно в таком качестве, по тексту приводится Natural Expert) можно научить за неделю. Вы действительно считаете, что за неделю можно сделать готового разрзаботчика, который сможет эффективно выполнять реальную работу на каком либо языке? Однако этот факт спокойно умалчивается.
Кроме того, вот здесь говорится следующее:

Более важно то, что как показывает опыт, хотя эффективность помогает конкурировать с С, она вовсе не требуется для успеха. Tcl/Tk, Perl, и Visual Basic заняли видное положение с интерпретирующими реализациями. Java стал чрезвычайно популярным, имея эффективность гораздо ниже С. В функциональном мире Erlang достиг первых успехов как интерпретируемый язык.

Далее софистика на тему применимости языков и их эффективности. Но почему то в статье нет нигде упоминания очевидного факта — что у каждого из приведённых языков — своя область применения. Иногда она пересекается с областью применения других языков — иногда нет. Там где области применения пересекаются — у каждого языка обычно есть свои сильные стороны (как и слабые). Часто формы рисуют и на C++ и на VB — на последнем это проще, зато первый позволяет создавать монолитное приложение с обработкой GUI и высокопроизводительными вычилсениями в одном флаконе. Но крайне редко C++ или VB применяют там, где применяется Perl или TCL.
А иногда появляются новые языки, которые начинают вытеснять существующие из их областей применения (как это происходит с C#).
То есть язык имеет смысл рассматривать вместе с областью, где его можно эффективно использовать. Вот этого как раз и не делается. При этом упоминается применения функциональных языков в достаточно специфичной области — в телекоммуникациях. (Кстати ещё вопрос — какая часть системы там написана с их использованием).

AF>> В общем сам факт того, что статья написана 6 лет назад в 1998 году, а с тех пор воз и ныне там, если не хуже — показательно и свидетельсвтует само за себя...
G>Если не хуже, говоришь? Откуда такие опасения? Откуда ты знаешь, где воз был и где он сейчас? У тебя есть статистика по количеству применений ФЯ по годам за последние 6 лет? Или ты просто смотришь, стоит-ли соответствующий SDK на твоем компе и у соседа, который на днях его удалил?
А ты стало быть знаешь? Или это только у меня с соседом эти языки ещё не установлены?

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

G>P.S.: Небольшой комментарий к теме "делается вид — будто ещё чуть-чуть и функционаьные языки сравнятся с императивными".

G>Фрагменты моей переписки с Eric Newhuis из FutureSource (мои вопросы — его ответы):
G>

>> Btw, recently noticed that you're looking for an Erlang developer.
>> You using Erlang for feed parsers there in FutureSource, right?
G>Yes we're using Erlang for some feed parsing and also for other things as
G>well. Most of the legacy code is C++, however, and so there is still a
G>majority of parsing in C++.

G>But Erlang looks better to us every day.

>> Interesting, how your management get convinced to use Erlang?
G>I am management. It takes a while. Start out with small project. Look
G>for the failures with C++. Solve them with Erlang.

Этот фрагмент ничего не доказывает. Кто то использует язык там где он эффективен. И что это доказывает?

Раньше мы писали Web-сайты на C++ и половина проектов проваливалась. Теперь нам кто то показал HTML и мы с восторгом пишем на нём...

Значит ли это что HTML лучше чем C++ для написания расчётов?

G>Вот так. Вы все еще кипятите? А мы уже рубим!
А мы вообще то давно стиральной машинкой пользуемся.

PS. Я за новые (или старые) функциональные языки. Но я против того, что бы делать из них очередную "панацею". Я за то, что бы дополнить ими традиционные языки, а не пытаться их заменить.

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

А нельзя ли темному человеку раскинуть, че такое функциональые языки, потому что ранее похоже я заблуждался относительно этого термина. Желательно поподробнее и с примерами.

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

AF> Намёк понятен Чего и Вам желаю... Я прочёл именно эту статью — и прочёл очень внимательно, так как сам интересуюсь функциональными языками. В этой статье хорошо описаны причины того, почему функциональные языки не распространены. Беда в том, что акценты ставятся совершенно иначе, чем их расставил бы человек не заинтересованный. Как обычно и бывает в рекламе.
AF> Все описанные "причины" — показаны мелкими, незначительными и легко преодолимыми. Вот пример:
AF>

AF> Задача обучения не является трудноразрешимой. В Software AG нашли, что они могут обучать программистов использованию Natural Expert на однонедельном курсе, который включал ленивые вычисления, полиморфные типы и функции высшего порядка. Как правило, студенты раздражались, когда компилятор неоднократно отвергал программы из за ошибок типизации, но были приятно удивлены, когда их программы наконец проходили контроль типов и работали правильно с первой попытки [8].

AF> Из этого абзаца следует, что типичному функциональному языку (а именно в таком качестве, по тексту приводится Natural Expert) можно научить за неделю. Вы действительно считаете, что за неделю можно сделать готового разрзаботчика, который сможет эффективно выполнять реальную работу на каком либо языке? Однако этот факт спокойно умалчивается.

Нет конечно, я так не считаю. За неделю можно обучить языку, а не умелому применению этого языка, которое вырабатывается только практикой. Думаете, доктор Вадлер этого не знает? С другой стороны, вы способны за месяц научить кого-нибудь правильному применению С++? Haskell и Elrang будут попроще в изучении. Особенно Erlang, — практика применения языка показывает, что уже через неделю человек (незнакомый с ФЯ) может выполнять полезную работу (под присмотром, естественно), а через месяц способен эффективно выполнять работу в одиночку.

AF> Кроме того, вот здесь говорится следующее:
AF>

AF>Более важно то, что как показывает опыт, хотя эффективность помогает конкурировать с С, она вовсе не требуется для успеха. Tcl/Tk, Perl, и Visual Basic заняли видное положение с интерпретирующими реализациями. Java стал чрезвычайно популярным, имея эффективность гораздо ниже С. В функциональном мире Erlang достиг первых успехов как интерпретируемый язык.

AF> Далее софистика на тему применимости языков и их эффективности.
Поаккуратнее, плз. Не надо Вадлера голословно обвинять в софистике. У вас с ним немного разные весовые категории.

AF> Но почему то в статье нет нигде упоминания очевидного факта — что у каждого из приведённых языков — своя область применения. Иногда она пересекается с областью применения других языков — иногда нет. Там где области применения пересекаются — у каждого языка обычно есть свои сильные стороны (как и слабые). Часто формы рисуют и на C++ и на VB — на последнем это проще, зато первый позволяет создавать монолитное приложение с обработкой GUI и высокопроизводительными вычилсениями в одном флаконе. Но крайне редко C++ или VB применяют там, где применяется Perl или TCL.
AF> А иногда появляются новые языки, которые начинают вытеснять существующие из их областей применения (как это происходит с C#).
AF> То есть язык имеет смысл рассматривать вместе с областью, где его можно эффективно использовать. Вот этого как раз и не делается. При этом упоминается применения функциональных языков в достаточно специфичной области — в телекоммуникациях. (Кстати ещё вопрос — какая часть системы там написана с их использованием).
Очевидные факты на то и очевидны, чтобы их не разжевывать в каждой статье. Тем не менее...

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

...там этот факт освещен.

AF>>> В общем сам факт того, что статья написана 6 лет назад в 1998 году, а с тех пор воз и ныне там, если не хуже — показательно и свидетельсвтует само за себя...
G>>Если не хуже, говоришь? Откуда такие опасения? Откуда ты знаешь, где воз был и где он сейчас? У тебя есть статистика по количеству применений ФЯ по годам за последние 6 лет? Или ты просто смотришь, стоит-ли соответствующий SDK на твоем компе и у соседа, который на днях его удалил?
AF> А ты стало быть знаешь? Или это только у меня с соседом эти языки ещё не установлены?
Я не знаю, поэтому и не фантазирую на тему положения воза, и тем более не делаю из этого никаких выводов.

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

G>>Наивно думать, что ситуация может измениться так стремительно — сегодня "никто", завтра — "все".
AF> Не знал, что Вы так наивны.
Но-но, я попрошу!
AF> Вот именно об этом и речь. Прогресс в функциональных языках есть — но он пока на том уровне, какой соответствует научным исследованиям, а не промышленному применению.
Вот это — неправда. Факты — упрямая штука. За эти 6 лет достигнут заметный прогресс именно в области промышленного применения ФЯ. Erlang — зрелая промышленная платформа. Есть куда расти, да. Но уже. Clean тоже весьма неплох с этой точки зрения — там есть все необходимое. И по скорости выполнения программ он рвет Яву. У них есть IDE. Убогий пока, но есть.

AF> Этот фрагмент ничего не доказывает. Кто то использует язык там где он эффективен. И что это доказывает?
Очевидно, он доказывает не то, что бы вы хотели. По моему, я ясно выразился:
G>P.S.: Небольшой комментарий к теме "делается вид — будто ещё чуть-чуть и функционаьные языки сравнятся с императивными".

Yes we're using Erlang for some feed parsing and also for other things as well. Most of the legacy code is C++, however, and so there is still a majority of parsing in C++. But Erlang looks better to us every day... Look for the failures with C++. Solve them with Erlang.

AF>

AF>Раньше мы писали Web-сайты на C++ и половина проектов проваливалась. Теперь нам кто то показал HTML и мы с восторгом пишем на нём...

AF> Значит ли это что HTML лучше чем C++ для написания расчётов?
Не надо мне приписывать такой чепухи. Что за привычка считать собеседника идиотом? Где я такое говорил. Цитату.

G>>Вот так. Вы все еще кипятите? А мы уже рубим!
AF> А мы вообще то давно стиральной машинкой пользуемся.
Хе-хе! Тогда мы идем к вам!!!

AF>PS. Я за новые (или старые) функциональные языки. Но я против того, что бы делать из них очередную "панацею". Я за то, что бы дополнить ими традиционные языки, а не пытаться их заменить.
Отличный лозунг. А я по вашему, за что? За то чтобы сделать из них панацею, и все традиционные языки заменить функциональными? Попробуйте доказать этот бред цитатами из моих писем.

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

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

G>>Вот так. Вы все еще кипятите? А мы уже рубим!

WF>Не посоветуешь ли, с чего стоит начать ознакомление с функциональными языками, какой язык стоит посмотреть в первую очередь?

Haskell. Поймешь его — поймешь все функциональные языки.
www.haskell.org

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

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

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

G>>>Вот так. Вы все еще кипятите? А мы уже рубим!

WF>>Не посоветуешь ли, с чего стоит начать ознакомление с функциональными языками, какой язык стоит посмотреть в первую очередь?

G>Haskell. Поймешь его — поймешь все функциональные языки.
G>www.haskell.org

А нет ли у Вас такого же, но только с .RU?

Здравствуйте, Цунцуяби, Вы писали:

G>>Вот так. Вы все еще кипятите? А мы уже рубим!

Ц>Dear Gaperton.

Ц>Дай порубить ! ( Где,что,почем ( i love halyavah ) )
www.erlang.org
Полная халява. Начни с FAQ, чтобы понять, что это и подойдет ли для твоих задач. Язык довольно специален, например, десктопные приложения на нем писать глупо, ИМХО. Хотя это технически возможно, да и не все со мной согласны .

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

G>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>Почему никто не использует функциональные языки

Кстати я читал, МС собирается задействовать Haskell в DirectX.

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

WF>>Не посоветуешь ли, с чего стоит начать ознакомление с функциональными языками, какой язык стоит посмотреть в первую очередь?

G>Haskell. Поймешь его — поймешь все функциональные языки.
G>www.haskell.org

Haskell имху слишком уж функционален Но действительно, это самый "классический" ФЯ.
А для понимания практических возможностей ФЯ лучше посмотреть OCaml. Он удачно сочетает и функциональные, и императивные элементы. Вот на нем, в отличие от Haskell, уже можно писать практически что угодно.

Не советую начинать изучение с Erlang и Clean, т.к. они более заточены под определенные практические задачи и вследствии этого перегружены несвойственными ФЯ "фичами". Erlang, например, ближе к скриптовым языкам.

Здравствуйте, Павел Леонов, Вы писали:

ПЛ>Здравствуйте, Gaperton, Вы писали:

G>>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>>Почему никто не использует функциональные языки

ПЛ>Кстати я читал, МС собирается задействовать Haskell в DirectX.

Можно линк, если он, конечно, есть

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

G>Нет конечно, я так не считаю. За неделю можно обучить языку, а не умелому применению этого языка, которое вырабатывается только практикой. Думаете, доктор Вадлер этого не знает? С другой стороны, вы способны за месяц научить кого-нибудь правильному применению С++? Haskell и Elrang будут попроще в изучении. Особенно Erlang, — практика применения языка показывает, что уже через неделю человек (незнакомый с ФЯ) может выполнять полезную работу (под присмотром, естественно), а через месяц способен эффективно выполнять работу в одиночку.
Это верно. Но в статье это приподносится так, как будто подготовка готового специалиста займёт неделю, когда это совсем не так. Ведь там же рассматривается проблема обучения для использования функциональных языков в реальных проектах. Посморти на это глазами менеджера, у которого нет твоего опыта проектирования и программирования.
А в общем то согласен — очень многие языки проще чем C++ и в обучении и в использовании.

AF>> Кроме того, вот здесь говорится следующее:
AF>>

AF>>Более важно то, что как показывает опыт, хотя эффективность помогает конкурировать с С, она вовсе не требуется для успеха. Tcl/Tk, Perl, и Visual Basic заняли видное положение с интерпретирующими реализациями. Java стал чрезвычайно популярным, имея эффективность гораздо ниже С. В функциональном мире Erlang достиг первых успехов как интерпретируемый язык.

AF>> Далее софистика на тему применимости языков и их эффективности.
G>Поаккуратнее, плз. Не надо Вадлера голословно обвинять в софистике. У вас с ним немного разные весовые категории.
При чём здесь весовые категории? По сути можете что-либо сказать или только про весовые категории?
Кроме игры словами в абзаце, из которого приведена цитата, более ничего нет. Это называется софистика.

AF>> То есть язык имеет смысл рассматривать вместе с областью, где его можно эффективно использовать. Вот этого как раз и не делается. При этом упоминается применения функциональных языков в достаточно специфичной области — в телекоммуникациях. (Кстати ещё вопрос — какая часть системы там написана с их использованием).
G>Очевидные факты на то и очевидны, чтобы их не разжевывать в каждой статье. Тем не менее...
G>

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

G>...там этот факт освещен.
Ну это рассуждения в общем и целом и ни о чём конкретно. Причём обясняются самоочевидные факты. И так понятно, что если бы какой то язык, метод или технология — были бы в 100 раз эффективнее, чем то, чем вы пользуетесь сейчас, то вы бы бросив всё постарались как можно быстрее перейти на них. Это самоочевидно и большого ума не требует. А вот что требует большого ума — так это показать — где, что и как следует применить, что бы это оказалось в N раз эффективнее, чем то, что применяется там сейчас. Вот это действительно не тривиально.
Вот если бы он показал — как применяются функцональные языки в том же телекоме — и обяснил — почему они там оказываются гораздо эффективнее — вот это было бы гораздо интереснее.

G>Я не знаю, поэтому и не фантазирую на тему положения воза, и тем более не делаю из этого никаких выводов.
Зато есть интернет и поисковики — поищите, посмотрите. Нейронные сети и те применяются гораздо шире...

G>Но если Вы настаиваете... Во многих европейских вузах ФЯ сейчас применяются в процессе обучения, в некоторых — как первый язык. Подождите, когда эти выпускники пойдут работать, и займут руководящие позиции. Будет как с UNIX. Динамика, на мой взгляд, положительная, хотя и слабая. Но это все косвенные признаки, статистики у меня нет.
Угу. Ещё 30 лет назад в вузах многих учили основам нейроных сетей. А некоторых даже — как основному методу построения ИИ. Ну и где же засилие нейронных сетей?

AF>> Вот именно об этом и речь. Прогресс в функциональных языках есть — но он пока на том уровне, какой соответствует научным исследованиям, а не промышленному применению.
G>Вот это — неправда. Факты — упрямая штука. За эти 6 лет достигнут заметный прогресс именно в области промышленного применения ФЯ. Erlang — зрелая промышленная платформа. Есть куда расти, да. Но уже. Clean тоже весьма неплох с этой точки зрения — там есть все необходимое. И по скорости выполнения программ он рвет Яву. У них есть IDE. Убогий пока, но есть.
Вот именно! Факты упрямая вещь! Прогресс всегда определяется в сравнении. Например какую долю в том же телекоме стали занимать функциональные языки — большую или меньшую?
Я как то наткнулся на статью, где приводился забавный факт: Оказывается, что сейчас арбалетов у нас (Европа, США, Россия) больше, чем их было в 13-14 веках, когда они были основным оружием. Но значит ли это, что арбалеты стали более распространены?

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

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

WF>>>Не посоветуешь ли, с чего стоит начать ознакомление с функциональными языками, какой язык стоит посмотреть в первую очередь?

G>>Haskell. Поймешь его — поймешь все функциональные языки.
G>>www.haskell.org

INT>Haskell имху слишком уж функционален Но действительно, это самый "классический" ФЯ.
INT>А для понимания практических возможностей ФЯ лучше посмотреть OCaml. Он удачно сочетает и функциональные, и императивные элементы. Вот на нем, в отличие от Haskell, уже можно писать практически что угодно.
Это так, но! ИМХО, для целей изучения ФЯ наличие императивных возможностей в языке (как в OCaml) не очень хорошо, так как человека ничего не заставит писать в функциональном стиле. Здесь ведь надо, чтобы "торкнуло". А в OCaml он всегда сможет обойтись императивным стилем.

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

Так что высока вероятность, что ознакомившись с OCaml, человек так и не поймет в чем же прелесть ФЯ. Язык как язык.

Я бы советовал такую последовательность. Haskell -> OCaml, Erlang, Clean (на выбор или все). После хаскеля у вас уйдет максимум по 2 дня на каждый из этих языков, и вы будете в состоянии оценить их прелести.

Одно из важнейших достоинств Хаскеля — наличие великолепного Gentle Introduction to Haskell. Таким введением мог бы гордится любой язык.

INT>Не советую начинать изучение с Erlang и Clean, т.к. они более заточены под определенные практические задачи и вследствии этого перегружены несвойственными ФЯ "фичами". Erlang, например, ближе к скриптовым языкам.

Тоже не советую, но по другим причинам. По Clean просто-напросто нет нормальной документации. Учить его не зная Haskell — мазохизм. Clean очень похож на Хаскель, самое серьезное отличие — наличие Uniqueness Typing (это серьезно упрощает ввод-вывод — не надо знать что такое Монады).

Erlang так же как OCaml язык без ленивых вычислений, в добавок там нет "карринга", и нет системы типов (Хиндли/Милнера/Майкрофта) благодаря динамической типизации (хотя благодаря этому он на порядок проще Haskell; если сдадут нервы — смотрите его).

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

G>Вот так. Вы все еще кипятите? А мы уже рубим!

Не знаю честно говоря че вы там рубите...но вот статистика ясно говорит почсему никто не использует функциональные языки. Пробежался тут для интересу по сайтилам с работой и вот некоторый срез вакансий по ключевым словам

C++ Erlang
Sun 166 0
Oracle 150 0
MS 715 0

Я думаю если взять ibm и так далее то тенденция будет примерно такая же — начиная от какого-нить эриксона и заканчивая боингом
О каких ваще возах и о том где они может быть речь — возов нету. Киты капитализма пользуют традиционные императивные языки. Очевидно что за ними будущее. Все остальное — поделки (пардон за резкость изложения ) .

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

К>Здравствуйте, Павел Леонов, Вы писали:

ПЛ>>Здравствуйте, Gaperton, Вы писали:

G>>>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>>>Почему никто не использует функциональные языки

ПЛ>>Кстати я читал, МС собирается задействовать Haskell в DirectX.

К>Можно линк, если он, конечно, есть

Здесь есть упоминание, линк на сайт МС похоже устарел, надо копать.

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

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

G>>Вот так. Вы все еще кипятите? А мы уже рубим!

G>Не знаю честно говоря че вы там рубите...но вот статистика ясно говорит почсему никто не использует функциональные языки. Пробежался тут для интересу по сайтилам с работой и вот некоторый срез вакансий по ключевым словам

Как срез вакансий отвечает на вопрос "почему"?

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

G>О каких ваще возах и о том где они может быть речь — возов нету. Киты капитализма пользуют традиционные императивные языки. Очевидно что за ними будущее. Все остальное — поделки (пардон за резкость изложения ) .

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

Ну и, разумеется, ФЯ еще недостаточно развиты как языки для профессионального использования. Не хватает нормальных IDE, средств отладки, и самое главное, возможности управления императивной реализации функционального кода. Ибо машины у нас все равно императивные и код в конечном счете тоже генерируется императивный. И программируя на императивном языке мы лучше понимаеми контролируем то, как будет работать конечный код.

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

INT>Здравствуйте, Glоbus, Вы писали:

G>>О каких ваще возах и о том где они может быть речь — возов нету. Киты капитализма пользуют традиционные императивные языки. Очевидно что за ними будущее. Все остальное — поделки (пардон за резкость изложения ) .

INT>Подумалось, что основная проблема функциональных языков — то, что они слишком мощные

Что значит "слишком мощные"?
Вычислительная мощь у всех нормальных языков в общем-то одинакова.

Мыслить просто надо иначе с функциональными языками.
Есть у меня подозрение, что оба стиля (назовем их декларативный и императивный)
в одном месте почти не уживаются.

Здравствуйте, Павел Леонов, Вы писали:

ПЛ>Здравствуйте, Курилка, Вы писали:

К>>Здравствуйте, Павел Леонов, Вы писали:

ПЛ>>>Здравствуйте, Gaperton, Вы писали:

G>>>>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>>>>Почему никто не использует функциональные языки

ПЛ>>>Кстати я читал, МС собирается задействовать Haskell в DirectX.

К>>Можно линк, если он, конечно, есть

ПЛ>Здесь есть упоминание, линк на сайт МС похоже устарел, надо копать.

здесь есть описание, но уж больно древнее это дело и по ходу мёртвое...

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

INT>Здравствуйте, Glоbus, Вы писали:

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

INT>Ну и, разумеется, ФЯ еще недостаточно развиты как языки для профессионального использования. Не хватает нормальных IDE, средств отладки, и самое главное, возможности управления императивной реализации функционального кода. Ибо машины у нас все равно императивные и код в конечном счете тоже генерируется императивный. И программируя на императивном языке мы лучше понимаеми контролируем то, как будет работать конечный код.

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

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

AF>>> Кроме того, вот здесь говорится следующее:
AF>>>

AF>>>Более важно то, что как показывает опыт, хотя эффективность помогает конкурировать с С, она вовсе не требуется для успеха. Tcl/Tk, Perl, и Visual Basic заняли видное положение с интерпретирующими реализациями. Java стал чрезвычайно популярным, имея эффективность гораздо ниже С. В функциональном мире Erlang достиг первых успехов как интерпретируемый язык.

AF>>> Далее софистика на тему применимости языков и их эффективности.
G>>Поаккуратнее, плз. Не надо Вадлера голословно обвинять в софистике. У вас с ним немного разные весовые категории.
AF> При чём здесь весовые категории? По сути можете что-либо сказать или только про весовые категории?
AF> Кроме игры словами в абзаце, из которого приведена цитата, более ничего нет. Это называется софистика.
Сложно по сути возразить на голословное утверждение "Далее софистика на тему применимости языков и их эффективности.". Разве что опять привести цитату из статьи? А флейм мне разводить лень.

Вадлер готовил доклад на конференции по ФЯ. Там людям не надо ничего разжевывать, они и так знают, где софистика, а где нет.

AF>>> То есть язык имеет смысл рассматривать вместе с областью, где его можно эффективно использовать. Вот этого как раз и не делается. При этом упоминается применения функциональных языков в достаточно специфичной области — в телекоммуникациях. (Кстати ещё вопрос — какая часть системы там написана с их использованием).
G>>Очевидные факты на то и очевидны, чтобы их не разжевывать в каждой статье. Тем не менее...
G>>

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

G>>...там этот факт освещен.
AF> Ну это рассуждения в общем и целом и ни о чём конкретно. Причём обясняются самоочевидные факты. И так понятно, что если бы какой то язык, метод или технология — были бы в 100 раз эффективнее, чем то, чем вы пользуетесь сейчас, то вы бы бросив всё постарались как можно быстрее перейти на них. Это самоочевидно и большого ума не требует. А вот что требует большого ума — так это показать — где, что и как следует применить, что бы это оказалось в N раз эффективнее, чем то, что применяется там сейчас. Вот это действительно не тривиально.
У доклада ИМХО четко обозначена тема — "причины, почему никто не использует функциональные языки". Заметь, причины, а не "пути решения".
AF> Вот если бы он показал — как применяются функцональные языки в том же телекоме — и обяснил — почему они там оказываются гораздо эффективнее — вот это было бы гораздо интереснее.
Для этого г-н Вадлер привел список литературы в конце. Скопировать сюда, как обычно? Вообще, он предполагает, что читатель немного в курсе последних событий в мире ФП. Это доклад для специалистов, а не рекламная статья. Вы же хотите все и сразу. Нивапрос. Для вас постарался г-н Ульф Вигер http://www.erlang.se/publications/Ulf_Wiger.pdf

А также
A Comparison between Erlang and C++ for Implementation of Telecom Applications.
Tomas Aronsson and Johan Grafström.
LiTH/IDA, 1995.
http://www.erlang.se/publications/xjobb/c++-vs-erlang.ps.gz

И еще
http://www.erlang.org/cslab/publications/bjarnelic.pdf

G>>Я не знаю, поэтому и не фантазирую на тему положения воза, и тем более не делаю из этого никаких выводов.
AF> Зато есть интернет и поисковики — поищите, посмотрите. Нейронные сети и те применяются гораздо шире...
Искал и смотрел. И рекомендую сделать это вам — в противном случае это вы приводили бы мне ссылки, а не наоборот А что до нейросетей, то эту тему мы уже плотно обсудили в "алгоритмах". Никто так и не привел вменяемого примера промышленного применения, с четким объяснением почему это выгодно, ни удовлетворительного математического обоснования. А AXD swith это где-то 12-17% рынка, если мне не изменяет память. Так что ровнять не надо.

G>>Но если Вы настаиваете... Во многих европейских вузах ФЯ сейчас применяются в процессе обучения, в некоторых — как первый язык. Подождите, когда эти выпускники пойдут работать, и займут руководящие позиции. Будет как с UNIX. Динамика, на мой взгляд, положительная, хотя и слабая. Но это все косвенные признаки, статистики у меня нет.
AF> Угу. Ещё 30 лет назад в вузах многих учили основам нейроных сетей. А некоторых даже — как основному методу построения ИИ. Ну и где же засилие нейронных сетей?
Не надо ровнять. Ничего общего с нейросетями.

AF>>> Вот именно об этом и речь. Прогресс в функциональных языках есть — но он пока на том уровне, какой соответствует научным исследованиям, а не промышленному применению.
G>>Вот это — неправда. Факты — упрямая штука. За эти 6 лет достигнут заметный прогресс именно в области промышленного применения ФЯ. Erlang — зрелая промышленная платформа. Есть куда расти, да. Но уже. Clean тоже весьма неплох с этой точки зрения — там есть все необходимое. И по скорости выполнения программ он рвет Яву. У них есть IDE. Убогий пока, но есть.
AF> Вот именно! Факты упрямая вещь! Прогресс всегда определяется в сравнении. Например какую долю в том же телекоме стали занимать функциональные языки — большую или меньшую?
AF> Я как то наткнулся на статью, где приводился забавный факт: Оказывается, что сейчас арбалетов у нас (Европа, США, Россия) больше, чем их было в 13-14 веках, когда они были основным оружием. Но значит ли это, что арбалеты стали более распространены?

Спокойно, Андрей. Речь не о распространенности языка. Не стану я такую чепуху утверждать. А вот доля рынка продуктов на Erlang весьма заметна (например GPRS solution — почти 50 процентов). К сожалению не смог найти документ, где была сводная таблица, но эта инфа должна быть в приведенных мной ссылках. Но ничего, найду — пришлю. Не подменяй тему. Вот она:
AF>>Прогресс в функциональных языках есть — но он пока на том уровне, какой соответствует научным исследованиям, а не промышленному применению.
G>Вот это — неправда.

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

G>>Вот так. Вы все еще кипятите? А мы уже рубим!

G>Не знаю честно говоря че вы там рубите...но вот статистика ясно говорит почсему никто не использует функциональные языки. Пробежался тут для интересу по сайтилам с работой и вот некоторый срез вакансий по ключевым словам

G> C++ Erlang
G>Sun 166 0
G>Oracle 150 0
G>MS 715 0

А нам пофиг на вашу статистику, нам главное чтобы работало хорошо, и стоило дешевле.

G>Я думаю если взять ibm и так далее то тенденция будет примерно такая же — начиная от какого-нить эриксона и заканчивая боингом
Эриксон ты зря помянул, у них начиная с 1998 большинство приоритетных продуктов на Erlange делалось .

G>О каких ваще возах и о том где они может быть речь — возов нету. Киты капитализма пользуют традиционные императивные языки. Очевидно что за ними будущее. Все остальное — поделки (пардон за резкость изложения ) .

Будущее не за теми вещами, которые сейчас выпускает МS, IBM, или SUN. Это, позволю себе заметить, настоящее. Вспомни — 1981 год. IBM выпускает IBM PC, не озаботясь даже защитой авторских прав — киты капитализма используют мэйнфреймы. Очевидно что за ними будущее. Все остальное (например, компьютеры Apple) — гаражные поделки Даже заказ на разработку ДОСа дают по знакомству мальчику Биллу — все равно фигня, какая разница-то? А паренек заработает себе на пиццу.

Ох как мне понравилась фраза uw. "Не знаю, нужно-ли тебе входить в мир ФП, но смотри, как бы мир ФП не вошел в тебя" .

Здравствуйте, Павел Леонов, Вы писали:

ПЛ>Здравствуйте, INTP_mihoshi, Вы писали:

INT>>Здравствуйте, Glоbus, Вы писали:

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

INT>>Ну и, разумеется, ФЯ еще недостаточно развиты как языки для профессионального использования. Не хватает нормальных IDE, средств отладки, и самое главное, возможности управления императивной реализации функционального кода. Ибо машины у нас все равно императивные и код в конечном счете тоже генерируется императивный. И программируя на императивном языке мы лучше понимаеми контролируем то, как будет работать конечный код.

ПЛ>Посему мне видится (покрайней мере сейчас) подход, когда можно писать программу на декларативном языке или приближающемуся к этому, а его код трансформировать в обычный императивный исходник. От первого мы имеем качество и скорость разработки, от второго лучшую эксплуатацию (в том числе и мелкую поддержку/переделку). Я думаю, что резкой переходной границы между ними быть не должно, люди не рискнут, тут ведь не только изучение синтаксиса, тут библиотеки и совместимость, вакансии и т.д. и т.п.

OCaml — то, что ты хочешь. Код трансформировать не надо — есть настроение/желание — пиши императивно, хочешь функционально, а хочешь — в перемешку. То, что доктор прописал.

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

G>Кажется, ты прочел какую-то другую статью. Ничего из перечисленного там нет.
Я ее сразу проглядел, и вчера не стал даже постить. Скучно.
Возьми лисп — функциональный? Обработай на нем список без рекурсии пожалуйста... и после этого можно будет говорить о какой-либо эффективности. Приведенный мною примерчик — это вывод который делают практически все студенты реализовав одно и то же задание на "3" строчки на си и на лиспе При чем на лиспе это все выглядит гораздо неуклюже.
И потом я вообще не вижу разницы... я под подобным языком вижу исполняющее нутро которое по сути является императивным, но так устроено, что на нем нельзя писать императивным спсобом Короче сплошные ограничения Я конечно понимаю... закостенелось мышления, но все таки...

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

G>OCaml — то, что ты хочешь. Код трансформировать не надо — есть настроение/желание — пиши императивно, хочешь функционально, а хочешь — в перемешку. То, что доктор прописал.

Тут нужен хитгрый доктор Великий на мой взгляд товарищь Гегель сказал "Мысль без пути ведущего к ней — есть труп", это относиться ко многим аспектам ИТ. В данном случае, сразу выставить даже Ocaml, не говоря о Haskell не получиться, люди не примут. Посмотри, много из тех, кто подсел на С, перейдя на С++ принял идею шаблонов? Нужен последовательный, эволюционный переход, чтоб каждая косточка ФЯ выглядела смачнее прежнего императивного подхода.

Согласен, это долго и муторно, но иначе никак. Ситуацию осложняет еще и тот стереотип, что от императива к декларативу нет перехода и что они не могут дружить.

PS. Да что там ФЯ, помнишь как народ картошку боялся кушать

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

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

G>>Кажется, ты прочел какую-то другую статью. Ничего из перечисленного там нет.
F> Я ее сразу проглядел, и вчера не стал даже постить. Скучно.
F> Возьми лисп — функциональный? Обработай на нем список без рекурсии пожалуйста... и после этого можно будет говорить о какой-либо эффективности. Приведенный мною примерчик — это вывод который делают практически все студенты реализовав одно и то же задание на "3" строчки на си и на лиспе При чем на лиспе это все выглядит гораздо неуклюже.

Рекурсия в современных ФЯ не проигрывает в эффективности итерации. Весь фокус в оптимизации tail recursion (пример на Erlang — считаем кол-во элементов списка).

count( L ) -> count( L, 0 ).

count( [ _ | T ], N ) -> count( T, N + 1 );
count( [], N ) -> N.

вторая функция не будет выделять память на стеке, потому что на выходе из рекурсии не делается никакой работы. Рекурсия будет преобразована в итерацию.

Это теория, а вот в этом документе содержатся результаты performance-тестов Apach против Yaws (написан целиком на Erlang). Сюрприз!
http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf

Что до вопроса "нафик это надо, цыклы гораздо круче" — то это совсем отдельная тема. Есть ряд соображений, найду ссылки — пришлю.

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

G>Не знаю честно говоря че вы там рубите...но вот статистика ясно говорит почсему никто не использует функциональные языки. Пробежался тут для интересу по сайтилам с работой и вот некоторый срез вакансий по ключевым словам

G> C++ Erlang
G>Sun 166 0
G>Oracle 150 0
G>MS 715 0

Т. е. что, Вы средства разработки для своих проектов выбираете исключительно исходя из количества вакансий? Ну-ну...

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

G>вторая функция не будет выделять память на стеке, потому что на выходе из рекурсии не делается никакой работы. Рекурсия будет преобразована в итерацию.
Мммммм... вышеприведенным согласен, такое возможно.

Хотя не совсем пока понимаю механику... этоти два листинга (на лиспе) ну если допустим он был бы написан на Erlang — тоже смогу быть свернуты (или развернуты) в итерационный цикл? (просто любопытно — я не знаю).

    ;; cos(pi*x/4)-sin(pi*x/4)
(defun c0(x)
    (* 3 x)
)

(defun next_c
    (lambda (n cn)
        (* cn (/ (- 1 (* 2 n)) (+ 1 (* 2 n))))
    )
)

(defun next_y(yn cnp1)
    (* yn (+ 1 cnp1))
)

(defun body_cospx4_sinpx4(n yn cnp1 eps)
    (if (< (abs (- (next_y yn cnp1) yn)) eps)
        (next_y yn cnp1)
        (body_cospx4_sinpx4 (+ n 1) (next_y yn cnp1) (next_c (+ n 1) cnp1) eps)
    )
)

(defun cospx4_sinpx4(x eps)
    (body_cospx4_sinpx4 0 1 (next_c 1 (c0 x)) eps)
)

(defun _delete_even(x)
    (if (null x)
        nil
        (cons (car x) (_delete_even (cddr x)))
    )
)

(defun delete_odd(x)
    (if (null x)
        nil
        (if (cdr x)
            (_delete_even (cdr x))
            '(nil)
        )
    )
)

?

G>Это теория, а вот в этом документе содержатся результаты performance-тестов Apach против Yaws (написан целиком на Erlang). Сюрприз!
G>http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf
Забавно. Хотя подробно не рассматривал...
Тогда вопрос другого характера.
Подходит ли Erlang для написания десктопных приложений и описания бизнеслогики?

G>Что до вопроса "нафик это надо, цыклы гораздо круче" — то это совсем отдельная тема. Есть ряд соображений, найду ссылки — пришлю.
Ну насчет "нафик это надо, цыклы гораздо круче" я не столь категоричен, возможно есть вещи которые и удобно (кому-то ) делать в таком стиле... но видимо не мне... А ссылку если найдешь давай — интересно

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

G>Вадлер готовил доклад на конференции по ФЯ. Там людям не надо ничего разжевывать, они и так знают, где софистика, а где нет.
Тогда тем более смешно говорить людям с ТАКОЙ квалификацией, что используется не только C++ но и TCL и что бывают медленные языки, которые распространены больше, чем более быстрые...

AF>> Вот если бы он показал — как применяются функцональные языки в том же телекоме — и обяснил — почему они там оказываются гораздо эффективнее — вот это было бы гораздо интереснее.
G>Для этого г-н Вадлер привел список литературы в конце. Скопировать сюда, как обычно? Вообще, он предполагает, что читатель немного в курсе последних событий в мире ФП. Это доклад для специалистов, а не рекламная статья. Вы же хотите все и сразу. Нивапрос. Для вас постарался г-н Ульф Вигер http://www.erlang.se/publications/Ulf_Wiger.pdf
Спасибо за ссылки. Но сути дела это не меняет.

G>А также
G>A Comparison between Erlang and C++ for Implementation of Telecom Applications.
G>Tomas Aronsson and Johan Grafström.
G>LiTH/IDA, 1995.
G>http://www.erlang.se/publications/xjobb/c++-vs-erlang.ps.gz

G>И еще
G>http://www.erlang.org/cslab/publications/bjarnelic.pdf

G>>>Я не знаю, поэтому и не фантазирую на тему положения воза, и тем более не делаю из этого никаких выводов.
AF>> Зато есть интернет и поисковики — поищите, посмотрите. Нейронные сети и те применяются гораздо шире...
G>Искал и смотрел. И рекомендую сделать это вам — в противном случае это вы приводили бы мне ссылки, а не наоборот А что до нейросетей, то эту тему мы уже плотно обсудили в "алгоритмах". Никто так и не привел вменяемого примера промышленного применения, с четким объяснением почему это выгодно, ни удовлетворительного математического обоснования. А AXD swith это где-то 12-17% рынка, если мне не изменяет память. Так что ровнять не надо.
Про нейросети — вы слегка приврали. Практически любая комерческая программа распознавания текста испольует нейросетевые алгоритмы. А это и есть промышленное применение. Другое дело — что она использует не только НС, но ведь и софт коммуникационное оборудование не на 100% состоит из программ на функциональных языках.

G>>>Но если Вы настаиваете... Во многих европейских вузах ФЯ сейчас применяются в процессе обучения, в некоторых — как первый язык. Подождите, когда эти выпускники пойдут работать, и займут руководящие позиции. Будет как с UNIX. Динамика, на мой взгляд, положительная, хотя и слабая. Но это все косвенные признаки, статистики у меня нет.
AF>> Угу. Ещё 30 лет назад в вузах многих учили основам нейроных сетей. А некоторых даже — как основному методу построения ИИ. Ну и где же засилие нейронных сетей?
G>Не надо ровнять. Ничего общего с нейросетями.
Это всего лишь Ваша точка зрения. А я как раз вижу очень много общего. Хотя бы то, что ФЯ, ИЯ и НС начали развиваться примерно в одно и тоже время — только вот ИЯ ушли очень далеко вперёд — а ФЯ и НС — применяются весьма ограниченно, хотя в некоторых областях и очень полезны.

G>Спокойно, Андрей. Речь не о распространенности языка. Не стану я такую чепуху утверждать. А вот доля рынка продуктов на Erlang весьма заметна (например GPRS solution — почти 50 процентов). К сожалению не смог найти документ, где была сводная таблица, но эта инфа должна быть в приведенных мной ссылках. Но ничего, найду — пришлю. Не подменяй тему. Вот она:
AF>>>Прогресс в функциональных языках есть — но он пока на том уровне, какой соответствует научным исследованиям, а не промышленному применению.
G>>Вот это — неправда.

Вы кажется меня не поняли. Так же как и с арбалетами. Да, ФЯ стали гораздо лучше по сравнению с 60-ми да и думаю по сравнению с 1998 (как современные арбалеты лучше, чем те что были в 14 веке). И я прекрасно знаю, что есть области, где они промышленно применялсь и в 1998. А вот чего не вижу — так это куда они распростарнились с этого времени. Или что бы они распространились значительно в этих областях (по сравнению с тем, что было в 1998 году). Или — что бы позволили достичь чего то нового (чего без них не было). А без этого — говорить о прогрессе в языках — ошибочно.
Кроме того, факт, что что-либо применяется промышленно — ещё не говорит об этом как о промышленной технологии. Можно говорить лишь о успешных или неуспешных попытках использования новой технологии в промышленности. Часто бывало, когда, несмотря на вроде бы успешное применение технологии, от неё тем не менее отказывались. Вот потому я и говорю — что применение этих языков пока лабораторное. В том же смысле, в каком г-н Вадлер говорил о том что "никто" не испольует ФЯ.

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

F> Хотя не совсем пока понимаю механику... этоти два листинга (на лиспе) ну если допустим он был бы написан на Erlang — тоже смогу быть свернуты (или развернуты) в итерационный цикл? (просто любопытно — я не знаю).

Не уверен, я не очень хорошо знаком с лиспом, но...
F>

F>    ;; cos(pi*x/4)-sin(pi*x/4)
F>(defun c0(x)
F>    (* 3 x)
F>)

F>(defun next_c
F>    (lambda (n cn)
F>        (* cn (/ (- 1 (* 2 n)) (+ 1 (* 2 n))))
F>    )
F>)

F>(defun next_y(yn cnp1)
F>    (* yn (+ 1 cnp1))
F>)

F>(defun body_cospx4_sinpx4(n yn cnp1 eps)
F>    (if (< (abs (- (next_y yn cnp1) yn)) eps)
F>        (next_y yn cnp1)
F>        (body_cospx4_sinpx4 (+ n 1) (next_y yn cnp1) (next_c (+ n 1) cnp1) eps)
F>    )
F>)
Это tail-recursive функция

F>(defun cospx4_sinpx4(x eps)
F>    (body_cospx4_sinpx4 0 1 (next_c 1 (c0 x)) eps)
F>)
Это тоже tail-recursive функцияF>

F>

F>(defun _delete_even(x)
F>    (if (null x)
F>        nil
F>        (cons (car x) (_delete_even (cddr x)))
F>    )
F>)
А это нет. Здесь на возврате из рекурсии объединяются списки (выполняется cons)

F>(defun delete_odd(x)
F>    (if (null x)
F>        nil
F>        (if (cdr x)
F>            (_delete_even (cdr x))
F>            '(nil)
F>        )
F>    )
F>)
F>

F> ?
Вообще, tail-recursion не всегда может быть простым образом преобразована в цикл. Это чаще реализуется как специальный тип вызова, который обычно поддерживаться системой выполнения. Допустим у нас две функции, которые вызывают друг друга и сами себя (!) рекурсивно, в зависимости от условий. При этом одна из них tail-recursive, а другая нет. Не так просто преобразовать в цикл, правда? Но наверно можно, если подумать (использовать goto для локального вызова, удалить фрейм стека перед внешним вызовом, поправить адрес возврата).

F> Тогда вопрос другого характера.
F> Подходит ли Erlang для написания десктопных приложений и описания бизнеслогики?
Десктопные приложения — технически можно, но я бы предпочел какой-нибудь .net или Java. Бизнес-логика — все зависит от характера этой логики. Не знаю.

Он отлично подходит для написания отказоустойчивых распределенных приложений, где требуется время отклика реального времени, это доказано практикой. Он великолепно подходит для задач телекома. Сейчас народ в экспериментальном порядке пробует его воткнуть повсюду, с переменным успехом. Вот, взгляни например на Wings3D — вроде как, Erlang для таких задач совсем не подходит, ИМХО. Но парни считают иначе, и видать не спроста. Вобщем, будем дожидаться анализа результатов.

G>>Что до вопроса "нафик это надо, цыклы гораздо круче" — то это совсем отдельная тема. Есть ряд соображений, найду ссылки — пришлю.
F> Ну насчет "нафик это надо, цыклы гораздо круче" я не столь категоричен, возможно есть вещи которые и удобно (кому-то ) делать в таком стиле... но видимо не мне... А ссылку если найдешь давай — интересно
Вот!
http://www.md.chalmers.se/~rjmh/Papers/whyfp.pdf

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

G>Почему никто не использует функциональные языки

Со всем согласен. Вот только автор видмо решил, что все описанные проблемы должен решать кто-то другой, а он будет излагать правильные мысли.

Мне кажется, что единственный реальный шанс выйти в массы для компонентных языков — это быть встроенными в какой-нибудь императивный язык. Например, в R#.

Здравствуйте, Павел Леонов, Вы писали:

ПЛ>Посему мне видится (покрайней мере сейчас) подход, когда можно писать программу на декларативном языке или приближающемуся к этому, а его код трансформировать в обычный императивный исходник. От первого мы имеем качество и скорость разработки, от второго лучшую эксплуатацию (в том числе и мелкую поддержку/переделку). Я думаю, что резкой переходной границы между ними быть не должно, люди не рискнут, тут ведь не только изучение синтаксиса, тут библиотеки и совместимость, вакансии и т.д. и т.п.

ПральнА! А что это значит? Значит все дружно доводим R# до рабочего состояния.

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

А нельзя цитировать только то на что отвечашь?

G>OCaml — то, что ты хочешь. Код трансформировать не надо — есть настроение/желание — пиши императивно, хочешь функционально, а хочешь — в перемешку. То, что доктор прописал.

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

И если выделить идею декларативного описания, то станет понятно, что средства которыми етого можно достичь не сводятся к функциональным языкам.

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

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

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

G>>OCaml — то, что ты хочешь. Код трансформировать не надо — есть настроение/желание — пиши императивно, хочешь функционально, а хочешь — в перемешку. То, что доктор прописал.
VD>Тут ты не прав. Функциональные языки не дают сами по себе приемуществ. Просто они ближе к идеи декларативности. Причем качественной декларативности в них добиться не удается. Причем именно из-за того, что ни заточены на функциональную запись.
Да я уже привык, что как только ты пишешь — то я сразу не прав . Правда, как и всегда, сложно понять, в чем? В том, что OCaml — это не то, что хочет Павел? Это, пардон, ему решать, а не тебе и не мне.

VD>И если выделить идею декларативного описания, то станет понятно, что средства которыми етого можно достичь не сводятся к функциональным языкам.
Да ради бога, я не против.

VD>Возьми к примеру BNF/EBNF натацию и сравни ее с описанием парсера на функциональном языке. BNF/EBNF намного чище и понятнее.
Тут ты не прав. Про комбинаторные монадные парсеры слыхал? Почитай про них. Код парсера будет выглядеть если не один в один как BNF/EBNF, то очень близко .

Кстати, отчего ты не предлагаешь посмотреть код автомата, который генерится для С#?

VD>Посему более практично использовать генераторы парсеров которые читают BNF/EBNF и выдают эффективный императивный код, нежели пытаться создать программу на функциональном языке. А ведь рекурсивный разбор — это как раз та область где ФЯ чувствуют себя как рыба в воде.
Да ради бога. Или так. Или генерировать эффективный парсер на функциональном языке, например на OCaml или Clean. Или императивную на OCaml — как душе угодно. Хочешь померятся скоростью с OCaml? А что практичнее — каждый решает для себя сам. Ты я вижу — решил.

VD>Имея удобный и простой в использовании механизм трансформации можно создать даже генератор преобразующий функциональные конструкции в императивные. Таким образом язык основанный на трансформации позволяет превратить себя в фукнционльный язык. Причем мы не будем завязаны исключительно на функциональный подход, а сможем выбирать наиболее удбный подход для конкретного случая.

Попытка не пытка — зачем дело встало? Попробуй реализовать функции высокого порядка, карринг, lazy evaluation, lazy data structures, и list comprehensions. Очень интересна также будет реализация алгебраических типов. Обеспечь нам прозрачность по ссылкам. Все то, к чему мы привыкли в функциональных языках. И вот тогда мы дружно все перейдем на твой R#.

А вообще, кое-кто уже давно наслаждаются parse transform, встроеным в Erlang .

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

G>Попытка не пытка — зачем дело встало? Попробуй реализовать функции высокого порядка, карринг, lazy evaluation, lazy data structures, и list comprehensions. Очень интересна также будет реализация алгебраических типов. Обеспечь нам прозрачность по ссылкам. Все то, к чему мы привыкли в функциональных языках.

Это похоже на завывания плюсовиков по поводу того, что в шарпе нельзя делать некоторые гадости, к которым они привыкли . Давайте отталкиваться от задачи, а не от конкретного решения, ладно? Просто те же задачи решаются другими средствами. Без всяких там lazy evaluations и прочих. Подход другой.

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

_>Т. е. что, Вы средства разработки для своих проектов выбираете исключительно исходя из количества вакансий? Ну-ну...

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

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

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

L>Это похоже на завывания плюсовиков по поводу того, что в шарпе нельзя делать некоторые гадости, к которым они привыкли .
Что за быдляцкие манеры.

L>Давайте отталкиваться от задачи, а не от конкретного решения, ладно? Просто те же задачи решаются другими средствами. Без всяких там lazy evaluations и прочих. Подход другой.

Решай свои задачи как хочешь. Только давай ты не будешь, не зная что такое lazy evaluation и прочее, указывать мне, что я должен без этого обойтись, и что так будет гораздо круче, ладно? Ваш R# никто не использует не потому, что люди глупы, а по ряду серьезных причин.

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

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

_>>Т. е. что, Вы средства разработки для своих проектов выбираете исключительно исходя из количества вакансий? Ну-ну...

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

Правильнее (и честнее) сказать, что ты их не знаешь.
Ты их не знаешь, [а так как ты видимо думаешь, что знаешь все,] следовательно их нет .

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

Здравствуйте, Павел Леонов, Вы писали:


ПЛ>Как срез вакансий отвечает на вопрос "почему"?

Я думаю на данном временном интервале связь следующая: по каким-то, не зависящим от нас с вами, товарищ, историческим причинам ФЯ на прижились, ну или опять же — "случайно" получилось, что в своей масса ИТ-индустрия соринтировалась на императивные языки. Теперь же, когда встает вопрос — чем пользоваться начинающие товарищи смотрят на то, чем пользуется киты буржуализма и видят что там фя нет. Единственный вопрос, который остается — почему сложилось так изначально что фя не прижились у владельцкев заводов газет пароходов. Очевидно есть какой-то изъян.

Что-то Gapertona сильно бьют
в этой ветке

Вроде используют ФЯ :
SQL, например, чем не ФЯ. Специализированный малость.

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

G> Ваш R# никто не использует не потому, что люди глупы, а по ряду серьезных причин.
Его ни кто не использует по тому что его еще не реализовали

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

G>Я думаю на данном временном интервале связь следующая: по каким-то, не зависящим от нас с вами, товарищ, историческим причинам ФЯ на прижились, ну или опять же — "случайно" получилось, что в своей масса ИТ-индустрия соринтировалась на императивные языки. Теперь же, когда встает вопрос — чем пользоваться начинающие товарищи смотрят на то, чем пользуется киты буржуализма и видят что там фя нет. Единственный вопрос, который остается — почему сложилось так изначально что фя не прижились у владельцкев заводов газет пароходов. Очевидно есть какой-то изъян.
Скорее масса изянов. Например то, как реализуются простейшие операции вроде перебора параметров в списке. И один из самых очевидных — в императивном языке видно — что, как и в какой последовательности делается. А вот в функциональном языке — это совершенно не очевидно. Есть конечно применения — когда это плюс — но гораздо чаще это большой минус.

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

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

L>Это похоже на завывания плюсовиков по поводу того, что в шарпе нельзя делать некоторые гадости, к которым они привыкли . Давайте отталкиваться от задачи, а не от конкретного решения, ладно? Просто те же задачи решаются другими средствами. Без всяких там lazy evaluations и прочих. Подход другой.

На самом деле, любую задачу можно решить разными средствами, разными подходами и т. д.
Вопрос в том, какой подход/средство является наиболее эффективным (для конкретной задачи).

У нас же получается, что программист, однажды раз и навсегда выбрав язык, начинает применять его во всех своих проектах. Даже не пытаясь узнать, что, возможно, для данного конкретного проекта более эффективным является другой подход/язык/средство разработки.

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

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

_>>Т. е. что, Вы средства разработки для своих проектов выбираете исключительно исходя из количества вакансий? Ну-ну...

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

Ты прав с практической точки зрения, если брать "типичный" проект, "типичного" менеджера и "типичного" кандидата. Но жизнь тем и прекрасна, что разнообразна. Есть места (и области программирования), где ФЯ применяются и весьма успешно даже у нас в стране. Другое дело, что мест, где применяют обычные языки — гораздо больше...

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

_>У нас же получается, что программист, однажды раз и навсегда выбрав язык, начинает применять его во всех своих проектах. Даже не пытаясь узнать, что, возможно, для данного конкретного проекта более эффективным является другой подход/язык/средство разработки.

Верно. Только для полноты картины вспомни о затратах ресурсов на переключение контекста.

Здравствуйте, AndreyFedotov, Вы писали:
AF> Скорее масса изянов. Например то, как реализуются простейшие операции вроде перебора параметров в списке. И один из самых очевидных — в императивном языке видно — что, как и в какой последовательности делается. А вот в функциональном языке — это совершенно не очевидно. Есть конечно применения — когда это плюс — но гораздо чаще это большой минус.
А я так думаю, что в начале все было до ужаса императивно. Потом из переключения проводов на консоли переехали-таки к программам, хранимым в памяти.
Еще немного, и удалось научить машину парсить мнемоники команд.
Имея в запасе ассемблер, люди придумали процедурное программирование. Язык С был достаточно тонкой оберткой над все теми же инструкциями процессора.
Реализация ФЯ была с самого начала сопряжена с большими затратами. К моменту, когда они попытались попасть в прикладное программирование, сложилось как минимум поколение (а то и не одно) людей, уверенных, что язык общего назначения должен быть императивным. В итоге приживались только те технологии, которые не слишком нарушали эту догму. При этом, что характерно, в узких нишах ФЯ таки сумели прорваться — SQL применяется повсеместно. Как ни странно, оказалось, что императивная обработка данных не устраивает даже ярых противников ФЯ. Кроме того, тут речь идет не о мелких шажках типа порядка вычисления аргументов, а о глобальных оптимизациях. И вот тут-то отсутствие императивности начало рулить со страшной силой, не давая программисту навязать умному серверу свои убогие представления о наилучшем способе получения результата.

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

S>А я так думаю, что в начале все было до ужаса императивно. Потом из переключения проводов на консоли переехали-таки к программам, хранимым в памяти.
S>Еще немного, и удалось научить машину парсить мнемоники команд.
S>Имея в запасе ассемблер, люди придумали процедурное программирование. Язык С был достаточно тонкой оберткой над все теми же инструкциями процессора.
S>Реализация ФЯ была с самого начала сопряжена с большими затратами. К моменту, когда они попытались попасть в прикладное программирование, сложилось как минимум поколение (а то и не одно) людей, уверенных, что язык общего назначения должен быть императивным. В итоге приживались только те технологии, которые не слишком нарушали эту догму. При этом, что характерно, в узких нишах ФЯ таки сумели прорваться — SQL применяется повсеместно. Как ни странно, оказалось, что императивная обработка данных не устраивает даже ярых противников ФЯ. Кроме того, тут речь идет не о мелких шажках типа порядка вычисления аргументов, а о глобальных оптимизациях. И вот тут-то отсутствие императивности начало рулить со страшной силой, не давая программисту навязать умному серверу свои убогие представления о наилучшем способе получения результата.
Согласен — всё это безусловно так. Правда отсутствие императивности интересно при взаимодействии со внешеней системой. Например когда делается запрос к БД — совсем не интересно (как правило), что он там делает, что бы его выполнить. А вот при реализации оконного интерфейса — предсказуемость (императивность) необходима. Я это собственно к тому — что эти подходы объединять и дополнять ими друг-друга, а не противопоставлять.
Беда с ФЯ в том, что их апологеты часто пытаются противопоставлять их императивным языкам. В то же время факты показывают, что наиболее успешны или ФЯ с императивными элементами или императивные языки с функиональными элементами (типичный пример связка С++/C# с запросами SQL).

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

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

G>>Вадлер готовил доклад на конференции по ФЯ. Там людям не надо ничего разжевывать, они и так знают, где софистика, а где нет.
AF> Тогда тем более смешно говорить людям с ТАКОЙ квалификацией, что используется не только C++ но и TCL и что бывают медленные языки, которые распространены больше, чем более быстрые...

Еще смешнее указывать ТАКОМУ специалисту, как Вадлер, о что говорить и о чем молчать, выдергивая его фразы из контекста.

AF>>> Вот если бы он показал — как применяются функцональные языки в том же телекоме — и обяснил — почему они там оказываются гораздо эффективнее — вот это было бы гораздо интереснее.
G>>Для этого г-н Вадлер привел список литературы в конце. Скопировать сюда, как обычно? Вообще, он предполагает, что читатель немного в курсе последних событий в мире ФП. Это доклад для специалистов, а не рекламная статья. Вы же хотите все и сразу. Нивапрос. Для вас постарался г-н Ульф Вигер http://www.erlang.se/publications/Ulf_Wiger.pdf
AF> Спасибо за ссылки. Но сути дела это не меняет.
Если суть дела в том, что тебе интересно Вадлеру поуказывать, а не получить объяснения, то не меняет. Мне казалось, тебе интересны объяснения.

G>>Искал и смотрел. И рекомендую сделать это вам — в противном случае это вы приводили бы мне ссылки, а не наоборот А что до нейросетей, то эту тему мы уже плотно обсудили в "алгоритмах". Никто так и не привел вменяемого примера промышленного применения, с четким объяснением почему это выгодно, ни удовлетворительного математического обоснования. А AXD swith это где-то 12-17% рынка, если мне не изменяет память. Так что ровнять не надо.
AF> Про нейросети — вы слегка приврали. Практически любая комерческая программа распознавания текста испольует нейросетевые алгоритмы. А это и есть промышленное применение.
А вы приврали по-крупному. В алгоритмах одного такого, который говорил что вот-вот покажет ссылки на серьезные промышленные применения год назад дружно всем форумом порвали на сувениры. Ни одной ссылки не смог дать на прикладные продукты. Только на средства построения НС.

И вдобавок, это оффтоп. В Алгоритмы.

G>>>>Но если Вы настаиваете... Во многих европейских вузах ФЯ сейчас применяются в процессе обучения, в некоторых — как первый язык. Подождите, когда эти выпускники пойдут работать, и займут руководящие позиции. Будет как с UNIX. Динамика, на мой взгляд, положительная, хотя и слабая. Но это все косвенные признаки, статистики у меня нет.
AF>>> Угу. Ещё 30 лет назад в вузах многих учили основам нейроных сетей. А некоторых даже — как основному методу построения ИИ. Ну и где же засилие нейронных сетей?
G>>Не надо ровнять. Ничего общего с нейросетями.
AF> Это всего лишь Ваша точка зрения. А я как раз вижу очень много общего. Хотя бы то, что ФЯ, ИЯ и НС начали развиваться примерно в одно и тоже время — только вот ИЯ ушли очень далеко вперёд — а ФЯ и НС — применяются весьма ограниченно, хотя в некоторых областях и очень полезны.

Я вижу, это всего лишь моя точка зрения, а вот Вы... Ваша... Это конечно, да!
Навеяло, ничего личного. Вопрос из теста на шизофрению: что общего между наручными часами и многоэтаэным домом?

AF> Вы кажется меня не поняли. Так же как и с арбалетами. Да, ФЯ стали гораздо лучше по сравнению с 60-ми да и думаю по сравнению с 1998 (как современные арбалеты лучше, чем те что были в 14 веке). И я прекрасно знаю, что есть области, где они промышленно применялсь и в 1998. А вот чего не вижу — так это куда они распростарнились с этого времени. Или что бы они распространились значительно в этих областях (по сравнению с тем, что было в 1998 году). Или — что бы позволили достичь чего то нового (чего без них не было). А без этого — говорить о прогрессе в языках — ошибочно.

А мне кажется я прекрасно вас понял. Это вы себя не понимаете.
Говорить о прогрессе в языках можно только рассматривая этот прогресс с некоей точки зрения. Которая четко обозначена у Вадлера, а у вас плывет от письма к письму.

AF> Кроме того, факт, что что-либо применяется промышленно — ещё не говорит об этом как о промышленной технологии. Можно говорить лишь о успешных или неуспешных попытках использования новой технологии в промышленности. Часто бывало, когда, несмотря на вроде бы успешное применение технологии, от неё тем не менее отказывались. Вот потому я и говорю — что применение этих языков пока лабораторное. В том же смысле, в каком г-н Вадлер говорил о том что "никто" не испольует ФЯ.

Мне кажется, вы не поняли Вадлера, в очередной раз. На "промышленность" технологии ее распространенность напрямую не влияет. Это качественные характеристики технологии и инструментальных средств, а вот они-то и изменились за последние 6 лет. Есть профайлеры, отладчики, есть раздельная компиляция, средства соборки дистрибутивов и развертывания. Есть поддержка, в том числе и коммерческая. Т. е. есть все необходимое для нормальной разработки. Это если в том смысле, как у Вадлера. Это всего лишь я так думаю, когда выбираю технологию для промышленного применения, а вы вольны думать что угодно.

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

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

G>> Ваш R# никто не использует не потому, что люди глупы, а по ряду серьезных причин.
WH>Его ни кто не использует по тому что его еще не реализовали
Да, это самая серьезная причина из списка
А уже как на людей бросаются — "завывания плюсовиков", "единственный шанс для ФЯ", "качественной декларативности в них добиться не удается". Смешно, право слово.

А что будет, когда реализуют? Страшно подумать.

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

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

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

G>>> Ваш R# никто не использует не потому, что люди глупы, а по ряду серьезных причин.
WH>>Его ни кто не использует по тому что его еще не реализовали
G>Да, это самая серьезная причина из списка
G>А уже как на людей бросаются — "завывания плюсовиков", "единственный шанс для ФЯ", "качественной декларативности в них добиться не удается". Смешно, право слово.

G>А что будет, когда реализуют? Страшно подумать.

Предлагаю не поддаватся на провокации. Давайте жить дружно

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

AF>Здравствуйте, Glоbus, Вы писали:

G>>Я думаю на данном временном интервале связь следующая: по каким-то, не зависящим от нас с вами, товарищ, историческим причинам ФЯ на прижились, ну или опять же — "случайно" получилось, что в своей масса ИТ-индустрия соринтировалась на императивные языки. Теперь же, когда встает вопрос — чем пользоваться начинающие товарищи смотрят на то, чем пользуется киты буржуализма и видят что там фя нет. Единственный вопрос, который остается — почему сложилось так изначально что фя не прижились у владельцкев заводов газет пароходов. Очевидно есть какой-то изъян.
AF> Скорее масса изянов. Например то, как реализуются простейшие операции вроде перебора параметров в списке.

Они, не поверишь, реализуются простейшим образом. В две строки.

transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
transform( [], _ ) -> [].

Вот и все.

AF> И один из самых очевидных — в императивном языке видно — что, как и в какой последовательности делается. А вот в функциональном языке — это совершенно не очевидно. Есть конечно применения — когда это плюс — но гораздо чаще это большой минус.

В strict языках (Erlang, OCaml) последовательность очевидна всегда. В lazy языках (Haskell, Clean) очевидна только тогда, когда этого хочет программист (т. е. когда это требуется). Нет с этим никаких проблем. Учите матчасть.

Gaperton -> "Re[7]: Почему никто не использует функциональные языки" :

G> Они, не поверишь, реализуются простейшим образом. В две строки.
G>

 G> transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
 G> transform( [], _ ) -> [].
 G>

G> Вот и все.

(задумчиво) кто-то мне недавно про нечитаемость perl'a говорил

Yury Kopyl aka hrg | http://id.totem.ru | "бысто сп..ил и ушел — называется
нашел..."

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

hrg>Gaperton -> "Re[7]: Почему никто не использует функциональные языки" :

G>> Они, не поверишь, реализуются простейшим образом. В две строки.
G>>

 G>> transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
 G>> transform( [], _ ) -> [].
 G>>

G>> Вот и все.

hrg>(задумчиво) кто-то мне недавно про нечитаемость perl'a говорил

Вот как человек явно считающий перл нечитаемым скажу, что такая запись вполне читаема, если читатель имеет понятия о том, что такое функциональное программирование

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

AF> Согласен — всё это безусловно так. Правда отсутствие императивности интересно при взаимодействии со внешеней системой. Например когда делается запрос к БД — совсем не интересно (как правило), что он там делает, что бы его выполнить. А вот при реализации оконного интерфейса — предсказуемость (императивность) необходима. Я это собственно к тому — что эти подходы объединять и дополнять ими друг-друга, а не противопоставлять.
Ты опоздал со своим предложением лет на 40. Со времени появления лиспа, который допускает побочные эффекты, все ФЯ всегда содержали императивные возможности. Иначе они не смогли бы выполнять ввод-вывод и взаимодействовать с внешним миром.

Существует только два (относительно новых) чисто функциональных языка, которые в принципе способны обойтись без императивных расширений. Это Haskell (там применяются монады — спасибо, господин Вадлер!) и Clean (там применяется Uniqueness Typing). И эти языки совсем не страдают их отсутствия. При этом код с применением монад и uniqueness typing выглядит императивно, хоть и является по сути функциональным.

AF> Беда с ФЯ в том, что их апологеты часто пытаются противопоставлять их императивным языкам. В то же время факты показывают, что наиболее успешны или ФЯ с императивными элементами или императивные языки с функиональными элементами (типичный пример связка С++/C# с запросами SQL).
Так что не надо рисовать чорный образ апологета ФЯ, который раздувает пламя флейма и ненавидит все императивные проявления.

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

G>Да, это самая серьезная причина из списка
G>А уже как на людей бросаются — "завывания плюсовиков", "единственный шанс для ФЯ", "качественной декларативности в них добиться не удается". Смешно, право слово.

Смешно слушать твои фанатствующие крики временами перехдящие в открытое хамство

Автор: Gaperton
Дата: 20.08.04

. Прекрасно ведь понимашь, что в современном виде ФЯ просто не пригодны для мэйнстрима.

G>А что будет, когда реализуют? Страшно подумать.

А ты не думай. А то хамство сразу прет и зо всех щелей.

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

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

AF> Верно. Только для полноты картины вспомни о затратах ресурсов на переключение контекста.

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

А затраты ресурсов чаще всего не такие уж и большие, надо сказать. Сложно только в первый раз

Если эти языки такие могучие, что ж их фанаты не в состоянии самим себе IDE написать?
Теоретики, понимаешь, короли мысли. В падлу себе сопли утереть?

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

Еще, зачем я должен переменные таскать из функции в функции, когда можно их объявить глобальными. На мой взгляд императивные языки это и есть доведенные до ума функциональные.

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

VD>Смешно слушать твои фанатствующие крики временами перехдящие в открытое хамство

Автор: Gaperton
Дата: 20.08.04

.
Это где ты там "открытое хамство" заметил? И вообще, кто бы говорил, а ты молчал Тебе подборку твоих высказываний дать? Искать долго не придется — хамишь ты постоянно и всем. Да ты и в этом письме успел отличился, что искать.

G>>А что будет, когда реализуют? Страшно подумать.
VD>А ты не думай. А то хамство сразу прет и зо всех щелей.
Да я вижу, что прет. Если бы я так реагировал на многочисленные провокации по поводу ФЯ, как ты на единственную подколку по поводу твоего R#, меня бы давно забанили, или я бы удавился от расстройства. Спокойнее, Влад, без истерик. Ведь ваш R# и вправду ведь еще... гхм... не закончен? Ну так что ты шумишь?

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

VD>>Смешно слушать твои фанатствующие крики временами перехдящие в открытое хамство

Автор: Gaperton
Дата: 20.08.04

.
G>Это где ты там "открытое хамство" заметил?

Что за быдляцкие манеры.

G> И вообще, кто бы говорил, а ты молчал

Хочешь в бан на недельку?

G> Тебе подборку твоих высказываний дать? Искать долго не придется — хамишь ты постоянно и всем.

Давай.

G> Да ты и в этом письме успел отличился, что искать.

Ты видимо не умешь отличать хамства и оскорблений от не лестных слов. Это твои проблемы. Но знай, что подобная "агитация" резко отталкивает разумных людей от того чтобы заниматься тем за что агитируют.

G> Если бы я так реагировал на многочисленные провокации по поводу ФЯ

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

G>, как ты на единственную подколку по поводу твоего R#, меня бы давно забанили,

Плевать мне на твои потколки. Но слышать подобное процетированному не охота даже не всвой адрес.

G> или я бы удавился от расстройства. Спокойнее, Влад, без истерик. Ведь ваш R# и вправду ведь еще... гхм... не закончен? Ну так что ты шумишь?

А я не шублю. Я тебе сказал свое мнение. ФЯ ужербны и недоработаны. В них есть рациональное зерно, но оно отнюдь не в ругательствах вроде "lazy evaluation, lazy data structures" (это скорее затычки проблем чем достоинства). Достоинства в декларативности и в ином взгляде на код (под другим углом). Но они же порождают и недостатки. Как минимум используя ФЯ я не могу добиться построения такого исполнимого кода который я хочу получить. Отсюда и все споры о производительности. Когад ФЯ оказывается заточен на решение конкретной задачи, то производительность у него приемлемая. Но как только задача не стыкуется с концепцией, то код плучается медленным и мало пригодным. Именно по этому мне интересен подход с преобразованием декларативного стиля в имперетивный. Это позволяет контролировать результат. А так же добиваться большей выразительности.

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

VD>>Тут ты не прав. Функциональные языки не дают сами по себе приемуществ. Просто они ближе к идеи декларативности. Причем качественной декларативности в них добиться не удается. Причем именно из-за того, что ни заточены на функциональную запись.
G>Да я уже привык, что как только ты пишешь — то я сразу не прав . Правда, как и всегда, сложно понять, в чем? В том, что OCaml — это не то, что хочет Павел? Это, пардон, ему решать, а не тебе и не мне.

Да сказал бы проще. Возразить нечего но хочется остаться правым. А то целый абзац и никакого смысла.

VD>>И если выделить идею декларативного описания, то станет понятно, что средства которыми етого можно достичь не сводятся к функциональным языкам.
G>Да ради бога, я не против.

Судя по твоим возражениям и безграничной агитации — против.

VD>>Возьми к примеру BNF/EBNF натацию и сравни ее с описанием парсера на функциональном языке. BNF/EBNF намного чище и понятнее.
G>Тут ты не прав. Про комбинаторные монадные парсеры слыхал?

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

G> Почитай про них. Код парсера будет выглядеть если не один в один как BNF/EBNF, то очень близко .

А мне не нужно "очень близко". Мне нужно EBNF. Попробуй на досуге переиписать кусок парсера того же шарпа. Сравним результат.

G>Кстати, отчего ты не предлагаешь посмотреть код автомата, который генерится для С#?

Посмотри. Парсер доступен публично. Првда там банальный рекусивный спуск с некоторыми проверками. Но все же.

G>Да ради бога. Или так. Или генерировать эффективный парсер на функциональном языке, например на OCaml или Clean.

Этов все языком. А кода люди берутся за дело, то применяют генераторы и С/С++/C#.

G> Или императивную на OCaml — как душе угодно. Хочешь померятся скоростью с OCaml?

А что мне мериться? Мой парсер готов и летает. Пиши свой помериемся. Но не верится даже то, что он будет написан. А уж то что он окажется сильно шустрее просто выглядит нереально.

G> А что практичнее — каждый решает для себя сам. Ты я вижу — решил.

И, что любопытно, решили все кто делает парсеры. Причем тех кто выбрал ФЯ оказались еденицы и делают они обычно парсеры для те хе ФЯ.

VD>>Имея удобный и простой в использовании механизм трансформации можно создать даже генератор преобразующий функциональные конструкции в императивные. Таким образом язык основанный на трансформации позволяет превратить себя в фукнционльный язык. Причем мы не будем завязаны исключительно на функциональный подход, а сможем выбирать наиболее удбный подход для конкретного случая.

G>Попытка не пытка — зачем дело встало?

Низачем. Делаем. И не только мы.

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

Думаю, с этим проблем не будет.

G>, карринг, lazy evaluation, lazy data structures, и list comprehensions.

Блин. А по русски все это нельзя? Ну, lazy evaluation и т.п. я конечно могу в уме обратно перевести "ленивое выполнение кода". Но все эти "карринги" и т.п...

Что касается отложенных вычислений. То это затыкание дыр функционального подхода. В императивном коде в них нужны нет. От функционального подхода мне интереснее другое. Повторне исползование частей алгоритмов и декларативность. Вот это со временем мы постараемся привнести в R#. Остальное от лишнее.

G> Очень интересна также будет реализация алгебраических типов.

Кому? Мне они не нужны. Кому будут нужны реализует. Моя задача не создать узкоспециализированные решения для конкретных проблем (чтобы прозибать как современные ФЯ). А создать средство позволяющее максимально просто создавать такие прикладные решения путем создания прокрамм преобразующих декларативную или смешанную запись в императивный код на популярном и общепризнанном языке.

G> Обеспечь нам прозрачность по ссылкам.

Зачем? Меня полностью удовлетворяет ситуация со сылками в C#.

G> Все то, к чему мы привыкли в функциональных языках.

Твоя фамилия случаем не Макидонский? А что ты тогда о себе во множественном числе? Или ты не заметил, что в основном тут все с тобой не согласны?

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

К примеру, напиши программу на любом ФЯ которая сравниться по простоте и понятности с XPath- или SQL-запросом. Ну, например, вот такой запрос:

//class[@Name='AstNodeCollectionBase']

возвращает классы с именем AstNodeCollectionBase.

G> И вот тогда мы дружно все перейдем на твой R#.

Дык. Работаем... Ищем...

G>А вообще, кое-кто уже давно наслаждаются parse transform, встроеным в Erlang .

Рад за них. Прадва можно посочувствовать тому, что тех кто вообще наслаждается Erlang очень мало. Я по крайней мере в живую не видел.

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

G>Эта тема несколько раз поднималась на форуме, но ни до чего серьезного не договорились. Вот, нашел перевод статьи господина Вадлера на эту тему. Хорошо дядька пишет, правильно.

G>Почему никто не использует функциональные языки


хм.. простите, может я не в кассу...

но был у меня один предмет в ВУЗе — там триггеры изучали... так вот, что-то спор между императивным подходом и функциональным уж очень мне напоминает спор между описанием модели работы автомата (триггера) конечный он или бесконечный, Милли или Мура, не важно.. НО тем не менее двумя вариантами — статической формулой (что соответствует концепции ФЯ) или системой динамических формул (что соответствует концепции ИЯ) Как говорилось профемморами — последнее намного прощще, так как представляет собой как раз ту модель мира, в которой мы живем, т.е. учитывает чудодейтвенное присутствие времени а над первой моделью какой-нить попавшейся сложной системы из этих автоматов можно биться и биться до изнеможения, но добиться умопомрачительной компактности её представления на все века вперед — а вот в результате всё зависит от того, случится ли менять систему когда-нить... ведь всё течет, всё меняется.
Поправьте меня, если мои догадки не совсем в правильном русле данного философского течения

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

G>...г-н Ульф Вигер http://www.erlang.se/publications/Ulf_Wiger.pdf

G>... http://www.erlang.se/publications/xjobb/c++-vs-erlang.ps.gz
G>И еще
G>http://www.erlang.org/cslab/publications/bjarnelic.pdf

И что забавно, все в ужасных пдф-ах. Почему чем хуже дела с раскруткой тем больше ПДФ-ов? Такое ощущение, что ПДФ — это такое символ консерваторства.

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

G>>> Они, не поверишь, реализуются простейшим образом. В две строки.
G>>>

 G>>> transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
 G>>> transform( [], _ ) -> [].
 G>>>

G>>> Вот и все.

hrg>>(задумчиво) кто-то мне недавно про нечитаемость perl'a говорил

К>Вот как человек явно считающий перл нечитаемым скажу, что такая запись вполне читаема, если читатель имеет понятия о том, что такое функциональное программирование

Вот только почему даже в примитивных случаях нужно мыслить рекурскией? И почему мне вот такая запись:

foreach (X x in xs)
 xxx(x);

кажется понятнее и проще?

Здравствуйте, Цунцуяби, Вы писали:

Ц>Что-то Gapertona сильно бьют
Ц>в этой ветке

Дык кусается, вот и бьют.

Ц>Вроде используют ФЯ :
Ц>SQL, например, чем не ФЯ. Специализированный малость.

Это скорее декларативный язык. ФЯ все же это отдельный класс прикладных языков. Собственно Gapertona пытается доказать, что ФЯ круче паравоза, а ему в ответ отчечают, что не вдили пока ФЯ в рельной жизни. И что основное приемущество ФЯ в декларотивности, но ее можно достичь из без ФЯ. Так что SQL и XPath — это хорошие примеры декларативных языков не являющхся ФЯ и их наличие как раз говорит, о том что н все впорядке в стане ФЯ.

Согласись, что SQL и XPath учатся очень быстро. А за ФЯ люди берутся, обламываются и начинают спрашивать зачем они нужны.

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

ON>Теоретики, понимаешь, короли мысли. В падлу себе сопли утереть?

Хамить то зачем?

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

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

AF>> Согласен — всё это безусловно так. Правда отсутствие императивности интересно при взаимодействии со внешеней системой. Например когда делается запрос к БД — совсем не интересно (как правило), что он там делает, что бы его выполнить. А вот при реализации оконного интерфейса — предсказуемость (императивность) необходима. Я это собственно к тому — что эти подходы объединять и дополнять ими друг-друга, а не противопоставлять.
G>Ты опоздал со своим предложением лет на 40. Со времени появления лиспа, который допускает побочные эффекты, все ФЯ всегда содержали императивные возможности. Иначе они не смогли бы выполнять ввод-вывод и взаимодействовать с внешним миром.
И в очередной раз колумб открыл америку... Я же как раз писал, что успехи в "промышленном применении" у тех языков, AZ которые имеют императивные возможности.

AF>> Беда с ФЯ в том, что их апологеты часто пытаются противопоставлять их императивным языкам. В то же время факты показывают, что наиболее успешны или ФЯ с императивными элементами или императивные языки с функиональными элементами (типичный пример связка С++/C# с запросами SQL).
G>Так что не надо рисовать чорный образ апологета ФЯ, который раздувает пламя флейма и ненавидит все императивные проявления.
Естественно не надо. Реальность гораздо страшнее любых литературных образов
А если серьёзно — то не в приведённой ли статье приводилось описание причин, почему не используются ФЯ там — где успешно и эффективно применяются C++ и Visual Basic? Что это как не попытка захвата территории и анализ причин её провала? Зачем ФЯ к примеру для рисования интерфейса?
И опять таки — я за ФЯ, но я против того, что бы заявлять, что язык "XXX лучше всех" или "подход XXX лучше всех" (в том числе и императивый)
За ФЯ действительно может оказаться будущее — но не сейчас, а позднее — с появлением квантовых вычислений или многослойных (а возможно и многомерных) кристаллов. Т.к. там ленивые вычисления — естественное состояние работы такой структуры, т.е. ФЯ гораздо для них ближе, чем для современных нам процессоров — возможно это сделает их более востребованными.
Ну а сейчас есть некоторые задачи и области — где эти языки успешно применяются и скорее всего постепенно сфера применения ФЯ будет расти, хотя в ближайшие 15-20 лет править будут языки императивные.

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

VD>И что забавно, все в ужасных пдф-ах. Почему чем хуже дела с раскруткой тем больше ПДФ-ов? Такое ощущение, что ПДФ — это такое символ консерваторства.
Это не впечатление — это факт!

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

VD>Здравствуйте, Курилка, Вы писали:

G>>>> Они, не поверишь, реализуются простейшим образом. В две строки.
G>>>>

 G>>>> transform( [ H | T ], F ) -> [ F( H ) | transform( T, F ) ];
 G>>>> transform( [], _ ) -> [].
 G>>>>

G>>>> Вот и все.

hrg>>>(задумчиво) кто-то мне недавно про нечитаемость perl'a говорил

К>>Вот как человек явно считающий перл нечитаемым скажу, что такая запись вполне читаема, если читатель имеет понятия о том, что такое функциональное программирование

VD>Вот только почему даже в примитивных случаях нужно мыслить рекурскией? И почему мне вот такая запись:
VD>

VD>foreach (X x in xs)
VD> xxx(x);
VD>

VD>кажется понятнее и проще?

И понятнее и проще. Но не функционально-языкасто. А потому есмь ересь и должно Mustdie (следуя логике проповедников ФЯ).
А потом они удивляются, почему "никто" не хочет пользоваться ФЯ.
Было бы интереснее добавить возможности ФЯ в языки обычные. Что то а-ля:

 __functional 
 {
 ...
 };

Или хотя бы так, как обычно задаются запросы к SQL серверу. Это было бы весьма полезно.

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

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

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

AF>> Верно. Только для полноты картины вспомни о затратах ресурсов на переключение контекста.

_>Ну, вообще-то самосовершенствование в любом аспекте (и не только в профессиональной области) требует усилий. Тем не менее, это же не повод почивать на лаврах, начав писать на С++ в институте и до гробовой доски, не замечая ничего вокруг.

А это другая крайность. Крайности, как известно, вредны
Как вредно писать только на C/C++/C# или Haskell, так я думаю ещё вреднее — изучать каждыя язык — просто времени на написание кода не отсанется.

_>А затраты ресурсов чаще всего не такие уж и большие, надо сказать. Сложно только в первый раз
Это слова увлечённого программста (и совершенно прекрасные как для специалиста), а не менеджера или инвестора, который реально реализует промышленные проекты. Посмотри на всякие переходы туда — сюда ИХ глазами. Представь — что ты бы платил за подобные развлечения свои деньги, а не какого то дяди.
Причём таки переходят же. Иначе никаких ФЯ в телекоме не было бы. Просто на практике всё чуть сложнее, чем прочитать описание языка и написать пару программ.

>Хамить то зачем?

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

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

VD>Мне кажется, что единственный реальный шанс выйти в массы для компонентных языков — это быть встроенными в какой-нибудь императивный язык. Например, в R#.

Какое-то странное утверждение. Почти на любом более-менее развитом императивном языке можно программировть, используя приёмы функционального программирования. Только всегда ли это нужно?

ON>Волки санитары леса
Осторожно! Модераторы — санитары форума!

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

G>Правильнее (и честнее) сказать, что ты их не знаешь.
G>Ты их не знаешь, [а так как ты видимо думаешь, что знаешь все,] следовательно их нет .

Не надо только снова про мобильную связь! Это узкая ниша — там этих проектов всего пара будет, остальное это их поддержка и небольшие расширения со временем. Широко, вне этой ниши, они не применяются. Десктоп приложения на них не пишут.

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

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

G>>...г-н Ульф Вигер http://www.erlang.se/publications/Ulf_Wiger.pdf

G>>... http://www.erlang.se/publications/xjobb/c++-vs-erlang.ps.gz
G>>И еще
G>>http://www.erlang.org/cslab/publications/bjarnelic.pdf

V> И что забавно, все в ужасных пдф-ах. Почему чем хуже дела с
V> раскруткой тем больше ПДФ-ов? Такое ощущение, что ПДФ — это такое
V> символ консерваторства.

Да, с пдф-ами засада, если еще читать на LCD мониторе, который при маштабировании портит шрифты.... HTML надоб для этих дел.

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

V> Согласись, что SQL и XPath учатся очень быстро. А за ФЯ люди берутся,
V> обламываются и начинают спрашивать зачем они нужны.

Влад, SQL — декларативный, подкласс функциональный

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

VD>Вот только почему даже в примитивных случаях нужно мыслить рекурскией? И почему мне вот такая запись:
VD>

VD>foreach (X x in xs)
VD> xxx(x);
VD>

VD>кажется понятнее и проще?

В Haskell то, что ты написал, выглядит так.

 map xxx x

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

Кстати, если ты хочешь получить не функционального варианта — в OCaml есть метод List.iter fun list, которая работает с функциями, имеющим побочный эффект.

В ФЯ ты сам выбираешь, как выглядит твой код.

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

AD>Какое-то странное утверждение. Почти на любом более-менее развитом императивном языке можно программировть, используя приёмы функционального программирования. Только всегда ли это нужно?

Нет, нельзя. Алескандреску и Boost это доказали.

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

AF> И понятнее и проще. Но не функционально-языкасто. А потому есмь ересь и должно Mustdie (следуя логике проповедников ФЯ).
AF>А потом они удивляются, почему "никто" не хочет пользоваться ФЯ.

AF> Или хотя бы так, как обычно задаются запросы к SQL серверу. Это было бы весьма полезно.

Мы с Павлом Леоновым в самом начале работы над R# обсуждали подобное расширение. И пришли к мнению, что это вполне возможно даже без серьезного расширения синтаксиса.

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

AD>Какое-то странное утверждение. Почти на любом более-менее развитом императивном языке можно программировть, используя приёмы функционального программирования.

Да ничего странного. То что можно современных ИЯ — это жалкое подобие того что было бы можно в принципе. Все же факторы и делегаты инструмент довльно ограниченный. В итоге приходится эмулировать. А любая эмуляция хуже чистой реализации.

AD>Только всегда ли это нужно?

Дык где не нужно можно не использовать.

ЗЫ

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

Я часто ловлю себя на мысле, что могу в черне описать довольно сложный алгоритм за какие-то 5-10 минут. А потом мучиться над его реализацие неделями. Декларативность позволила бы упростить процесс реализации и процесс восприятия сути программы.

Изходя из этого я и обращаю внимание на ФЯ как на представителей декларатинвой школы. Так же мне интересны SQL, XPath, XSLT, HTML и т.п. Даже атрибуты в Шарпе интересны для меня, так как позволяют упростить разработку.

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

ON>Волки санитары леса

Согласен. Но можно сказать все тоже самое и не так прямолинейно. Беседа и так временами доходит до грани фола.

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

VD>И что забавно, все в ужасных пдф-ах. Почему чем хуже дела с раскруткой тем больше ПДФ-ов? Такое ощущение, что ПДФ — это такое символ консерваторства.

Пдф — это признак печатных работ. HTML как-то для формул не предназначен, и для печати тоже. Поэтому пищут обчно на TeX, потом конвертят в ps и pdf.

Так что, для тебя научные работы — признак консерватизма. Не скажу, что это совсем уж не так

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

INT>В Haskell то, что ты написал, выглядит так.

INT>

INT> map xxx x
INT>

Рад за них. Но это совсем не понятно. Краткость не есть качество.

INT>В других ФЯ примерно так же. При чем map — это не встроенная функция, а часть стандартной библиотеки. А то, что написал Гапертон — это как раз код аналога этой самой "map", работающий для любых функций и списков. Или других котейнеров.

INT>Кстати, если ты хочешь получить не функционального варианта — в OCaml есть метод List.iter fun list, которая работает с функциями, имеющим побочный эффект.

INT>В ФЯ ты сам выбираешь, как выглядит твой код.

К сожалению, все же за меня уже сделан выбор. Я могу выбрать только вариации, но все они связаны с рекусрисей и как следствие с перестройкой мозга на рекурсивный лад. А мне хотелось бы получить возможности декларатиного задания алгоритмов без подобных жертв. И с простым и понятный синтаксисом. Ведь даже то что ты привел из OCaml довольно некрасиво выглядит.

Здравствуйте, Павел Леонов, Вы писали:

ПЛ>Влад, SQL — декларативный, подкласс функциональный

Все же он не фунциональный. Он специализированный. Хотя временами похож.

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

INT>Пдф — это признак печатных работ. HTML как-то для формул не предназначен, и для печати тоже.

У нас почти все статьи на сайте печатаются в журнале. Вот только мы находим смелость превратить их в HTML.

INT>Поэтому пищут обчно на TeX, потом конвертят в ps и pdf.

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

INT>Так что, для тебя научные работы — признак консерватизма. Не скажу, что это совсем уж не так

Ну, в каждой шутке есть...

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

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

ON>Еще, зачем я должен переменные таскать из функции в функции, когда можно их объявить глобальными.
А также зачем области видимости и инкапсуляция. Напридумали, понимаешь.

Кстати, все, кто считает, что функциональное программирование не нужно, могут перестать использоваться STL и забыть слова инкапсуляция и полиморфизм. Ибо все это как раз и есть элементы ФЯ, привнесеный в С++.

ON>На мой взгляд императивные языки это и есть доведенные до ума функциональные.
Ну что делать, не хватает у нас умишка-то на императивных кодить. Сопли-та еще подтирать и то не умеем. Вот и ковыряемся в ФЯ потихоньку...



P.S. Народ, чо это мы, а? Почему вдруг на личности стали скатываться? Включая Влада, который, как админ, вообще должен личный пример, аки пионер, подавать?

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

ON>Еще, зачем я должен переменные таскать из функции в функции, когда можно их объявить глобальными.
INT>А также зачем области видимости и инкапсуляция. Напридумали, понимаешь.

INT>Кстати, все, кто считает, что функциональное программирование не нужно, могут перестать использоваться STL и забыть слова инкапсуляция и полиморфизм. Ибо все это как раз и есть элементы ФЯ, привнесеный в С++.

Классно. То инкапсуляция не нужна и не юзайте ее — отродие С++. То детище ФЯ. Но тоже не юзайте ее

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

INT>Кстати, все, кто считает, что функциональное программирование не нужно, могут перестать использоваться STL и забыть слова инкапсуляция и полиморфизм. Ибо все это как раз и есть элементы ФЯ, привнесеный в С++.

С каких это пор инкапсуляция и полиморфизм стали элементами ФП?

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

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

INT>>Кстати, все, кто считает, что функциональное программирование не нужно, могут перестать использоваться STL и забыть слова инкапсуляция и полиморфизм. Ибо все это как раз и есть элементы ФЯ, привнесеный в С++.

AD>С каких это пор инкапсуляция и полиморфизм стали элементами ФП?

А что такое по-твоему, к примеру,
полиморфизм и почему это не может быть в функциональных языках?

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

AD>>С каких это пор инкапсуляция и полиморфизм стали элементами ФП?
B>А что такое по-твоему, к примеру,
B>полиморфизм и почему это не может быть в функциональных языках?

Да, беру свои слова насчёт полиморфизма обратно. Сделал поиск и, с удивлением для себя обнаружил, что в полиморфизм является одним из принципов ФП.

Где можно посмотреть исходники интерпретатора? Лучше что-нибудь по-проще, джентлементский набор.
Для lisp'а у меня есть by Marc Adler, 735 строк, всего лишь.

Для императивного языка мат.частью является процессор, если знаешь как он работает, как-то сразу и программы на ум приходят. Аналогично с Windows API. Хотелось бы узнать что за чудо понимает код ФЯ.

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

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

INT>>Кстати, все, кто считает, что функциональное программирование не нужно, могут перестать использоваться STL и забыть слова инкапсуляция и полиморфизм. Ибо все это как раз и есть элементы ФЯ, привнесеный в С++.

AD>С каких это пор инкапсуляция и полиморфизм стали элементами ФП?

А они ими и не были... Эти понятия возникли в середине 60-х, применительно к обычным императивным языкам. Это потом — когда эти элементы показали и доказали свою эффективность — их стали включать или находить там, где их ранее не было...

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

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

VD>>>Смешно слушать твои фанатствующие крики временами перехдящие в открытое хамство

Автор: Gaperton
Дата: 20.08.04

.
G>>Это где ты там "открытое хамство" заметил?
VD>

Что за быдляцкие манеры.

G>> И вообще, кто бы говорил, а ты молчал
VD>Хочешь в бан на недельку?
G>> Тебе подборку твоих высказываний дать? Искать долго не придется — хамишь ты постоянно и всем.
VD>Давай.
G>> Да ты и в этом письме успел отличился, что искать.
VD>Ты видимо не умешь отличать хамства и оскорблений от не лестных слов. Это твои проблемы. Но знай, что подобная "агитация" резко отталкивает разумных людей от того чтобы заниматься тем за что агитируют.

Значит так, Влад. Твои "нелестные слова" являются на самом деле бестактностью, хамством, и оскорблениями. Мне все равно, как именно ты предпочитаешь называешь свои и чужие плохие манеры. Ясное дело, это становится не твоей проблемой, а проблемой окружающих. Мне надоело их слышать в свой адрес, и в чужой тоже. Не хочешь слышать, что твои манеры называют "быдляцкими"? Неприятно? (Замечу, что если бы я хотел тебя оскорбить, я бы назвал тебя "быдлом") Есть отличный способ — держи свои "нелестные слова" при себе. Любой воспитанный человек (каких, к счастью, на форуме много) не испытывает никаких трудностей удержатся от их употребления в адрес собеседника, им не требуется делять над собой усилий. Если у тебя с этим проблемы (я слышал, есть такая болезнь, но надеюсь, это не твой случай), то отправляй меня в бан. Или можешь сразу аккаунт удалить.

G>> Если бы я так реагировал на многочисленные провокации по поводу ФЯ
VD>Да нет никаких провокаций. Люди тебе говорят что думают. А ты все провокациями считаешь. Плевать всем на эти ФЯ.
Во-первых, говори за себя, а не за всех. Во-вторых, твоя и чужая бестактность провоцирует резкие ответы и флейм.

Давай я в порядке иллюстрации тоже скажу, что думаю, чтобы ты понял, что надо фильтровать поток сознания? Плевать всем на твой R#, ты даже объяснить зачем он нужен толком не смог, когда тебя попросили. Дай бог, если им будет пользоваться столько же людей, сколько захудалым языком Hope. Это не провокация, чего ты злишься! Я просто говорю, что думаю. Ты теперь должен конструктивно отвечать, по делу, а не хамить.

VD>Людям нужен удобный инструмент простой в изучении и использовании. А то что есть сейчас даже запустить тяжело. Не то что изучить и использовать на практике. Статья об этом собственно и говорит.
Статья, собственно, датирована 1998 годом. 6 лет прошло. Сейчас для того, чтобы запустить, надо для этого сначала скачать, потом запустить программу "сетуп", а потом ткнуть в появившуюся иконку в меню "Старт". Ты продолжишь настаивать, что это представляет для тебя сложность?

G>>, как ты на единственную подколку по поводу твоего R#, меня бы давно забанили,
VD>Плевать мне на твои потколки. Но слышать подобное процетированному не охота даже не всвой адрес.
У тебя все в порядке с причинно-следственными связями? Не понимаешь, в каких случаях я указываю на "быдляцкие манеры"? Держи свои "нелестные слова" при себе, и никогда не услышишь процетированное в свой адрес.

G>> или я бы удавился от расстройства. Спокойнее, Влад, без истерик. Ведь ваш R# и вправду ведь еще... гхм... не закончен? Ну так что ты шумишь?
VD>А я не шублю. Я тебе сказал свое мнение.
Первой фразой в своем письме выше по ветке ты мне сообщил самую важную часть твоего мнения. "Здесь ты не прав". Бестактно так начинать письма, и к тому же невыгодно тебе же, так как если ты ошибся, ты выставляешь себя дураком. Плюс, ты провоцируешь собеседника "упереться". Ну и естественно, ни в коем случае не уступишь сам — мосты сожжены.

VD>ФЯ ужербны и недоработаны. В них есть рациональное зерно, но оно отнюдь не в ругательствах вроде "lazy evaluation, lazy data structures" (это скорее затычки проблем чем достоинства).
VD>Достоинства в декларативности и в ином взгляде на код (под другим углом).
Функции высокого порядка и "ленивые вычисления" — это, основные и самые мощные механизмы ФЯ. Убери их — и от ФЯ почти ничего не останется. Просто, чтоб ты знал. Вообще, мне несколько странно, что ты, не зная ни одного ФЯ и не написав на нем ни одной программы (поправь меня, если это не так, назови язык, и мы поговорим предметно), берешься рассуждать, где там рациональное зерно, а где затычки проблем, и вдобавок говорить кому-то, что он не прав. У тебя самого этот факт не вызывает никакого беспокойства? Я бы на твоем месте постеснялся.

VD>Но они же порождают и недостатки. Как минимум используя ФЯ я не могу добиться построения такого исполнимого кода который я хочу получить. Отсюда и все споры о производительности.

Все споры о производительности исключительно от стереотипов. Кстати, я не заметил, чтобы кто-нибудь кроме тебя поднимал этот вопрос.

Есть такая программа на OCaml — Fastet Fourier Transform in the West (быстрое преобразование Фурье). Численные методы — что лучше для тестирования голой производительности? Она не зря называется Fastest. Попробуй ее обогнать на С#. А потом поговорим о производительности.

VD>Когад ФЯ оказывается заточен на решение конкретной задачи, то производительность у него приемлемая. Но как только задача не стыкуется с концепцией, то код плучается медленным и мало пригодным.
Медленный и малопригодный код можно написать на любом языке, для этого ума много не нужно. Надо использовать сильные стороны технологии, а не слабые, и все будет в порядке. Да, известны задачи, решение которых на императивных языках сильно проще и быстрее. Для этого в ФЯ есть императивные расширения, и средства межязыкового взаимодействия. Например, OCaml, кроме всего прочего — полноценный OO императивный язык.

VD>Именно по этому мне интересен подход с преобразованием декларативного стиля в имперетивный. Это позволяет контролировать результат. А так же добиваться большей выразительности.

Вообще-то этим преобразованием занимаются компиляторы. А твой подход может и хорош, у меня нет предубеждений. Но для начала тебе надо (я не указываю тебе что делать, просто напоминаю о том, что тебе сделать придется):
1) Полностью довести R# до рабочего состояния.
2) Убедительно показать, что этот подход будет давать реальные преимущества. Меня интересуют следующие измеримые преимущества:
— Заметное (в разы) сокращение объема программы в сравнении с аналогичной С++.
— Аналогичный рост продуктивности труда программиста.
— Заметное (в разы) увеличение качества ПО при тех же затратах, что и на разработку с С++.
3) Обеспечить качественную поддержку коммерческого уровня, и серьезные гарантии, что она не прекратится. Видишь-ли, когда кто-то выбирает средство разработки для проекта с бюджетом от миллиона и выше, он автоматически связывает себя с этим средством лет эдак на 5-10. И было-бы очень обидно, если через пару лет, когда в разработку вбухана куча бабла, выяснится, что спецификации R# изменились без уведомления, команда разработки R# считает, что критичные для моего продукта дефекты исправлять не надо, "потому что это фигня", и уже год как перестали выходить bug-fix релизы, по причине того, что команда занята реализацией очередной гениальной идеи. Предупреждая ответ — твои слова в форуме, какие бы нелестные они не были — это не гарантии, Влад. Это слова. А нужны гарантии. И пока никаких гарантий ты дать не можешь.

Замечу, что, например, с Erlang таких проблем нет и не будет, а применение Erlang по накопленой статистике промышленных применений за последние 10 лет дает измеряемый выигрыш по затратам минимум вчетверо при написании отказоустойчивых распределенных приложений. А это далеко не самый гибкий из ФЯ. Я уж не говорю об отказоустойчивости. Этот ненадежный динамически типизированный язык позволяет при разумных затратах писать софт объемем 1.7 миллионов строк кода с измеряемым временем отказов 99.9999999% (это 30 наносекунд в год. пример — AXD switch). Он позволяет доказывать корректность реализации (благодаря тому, что это ФЯ), что регулярно делали спецы Эрикссон в промышленной разработке — методики опубликованы, и теперь этот фокус может повторить каждый.

Люди начинают применять ФЯ не из фанатизма, как тебе наверно кажется, а потому, что они дают измеримое преимущество. Вовин применят Смолток не из фанатизма, а потому что он видит, что смолток позволяет ему (рискну предположить — вдвое) быстрее и качественнее делать софт.

Вот когда твой подход даст измеряемый выигрыш по затратам хотя-бы на одном классе приложений хотя-бы вдвое (а лучше в четверо). Когда тебе удастся сделать императивный язык, который позволит писать хотя-бы в половину такие надежные программы, как на ФЯ (с возможностью доказательств корректности). Вот тогда я с интересом послушаю, и постараюсь разобраться, чем твой подход лучше ФЯ. Да и не только я — все тебе в рот заглядывать будут и всем будет интересна твоя точка зрения.

А пока — извини. Все, что ты говоришь — это просто сказ о шкуре неубитого медведя.

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

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

PS. ФЯ я интересуюсь, ссылок на статьи и обсуждения Хаскеля и Ерланга у меня в броузере больше чем на МСДН, sourceforge и прочее, однако, имхо не все так просто и очевидно. Наибольшее впечатление пока от Смолтолка и его способностей к evolution design.

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

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

G>>Правильнее (и честнее) сказать, что ты их не знаешь.
G>>Ты их не знаешь, [а так как ты видимо думаешь, что знаешь все,] следовательно их нет .

L>Не надо только снова про мобильную связь! Это узкая ниша — там этих проектов всего пара будет, остальное это их поддержка и небольшие расширения со временем. Широко, вне этой ниши, они не применяются. Десктоп приложения на них не пишут.

А почему, собственно, не надо? Телеком — это не только мобильная связь. Это сетевые маршрутизаторы, и еще много чего — посмотри в моих ссылках. Вообще — да, ты прав, вне этой ниши серьезного опыта промышленных применений ФЯ на данный момент нет, есть эпизодические. Тем не менее, это факты успешного применения. Таким образом...
L>Факты реального успешного применения нужны. Их нет.
...ты должен признать, что они есть. И весьма положительные — отчеты публично доступны. И если ты заинтересуешься — ты найдешь еще больше примеров.

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

VD>Здравствуйте, Цунцуяби, Вы писали:

Ц>>Что-то Gapertona сильно бьют
Ц>>в этой ветке

VD>Дык кусается, вот и бьют.
Бьют, вот и кусаюсь.

Ц>>Вроде используют ФЯ :
Ц>>SQL, например, чем не ФЯ. Специализированный малость.
VD>Это скорее декларативный язык. ФЯ все же это отдельный класс прикладных языков. Собственно Gapertona пытается доказать, что ФЯ круче паравоза, а ему в ответ отчечают, что не вдили пока ФЯ в рельной жизни.
Собственно, Гапертон ничего такого доказать не пытается. Он не кричит — "императивные языки изжили себя". Это ему все пытаются доказать, что ФП — полный ацтой. А он препятствует опусканию ниже плинтуса.

Ты вот, например, начал свое первое письмо мне с первой фразой "ты здесь неправ", когда я мирно беседовал о смешении императивного и декларативного стиля в языке OCaml. В духе "сам с собой веду беседу". Твой ответ никак не не согласован с темой моего письма. На, перечитай. http://www.rsdn.ru/Forum/Message.aspx?mid=771466&only=1

Автор: Gaperton
Дата: 19.08.04

А потом говори, кто кусается.

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

G>Значит так, Влад. Твои "нелестные слова" являются на самом деле бестактностью, хамством, и оскорблениями.

Можно все таки увидеть оскорбления тебя лично?

G> Мне все равно, как именно ты предпочитаешь называешь свои и чужие плохие манеры.

В данном случае я вижу, твои плохие манеры. Вернее прямое оскорбление собеседника. Кстати, не меня. И не вижу причины по которой должен перехдить на обсуждение себя.

G>то отправляй меня в бан. Или можешь сразу аккаунт удалить.

Ну, матернись разок и я тебе это гарантирую.

VD>>Да нет никаких провокаций. Люди тебе говорят что думают. А ты все провокациями считаешь. Плевать всем на эти ФЯ.
G>Во-первых, говори за себя, а не за всех.

То есть ты тут говоришь за других обзывая их слова провокацией, а я за них сказать немогу? Луче мы подругому поступим. Если они со мной не согласны, то сам об этом скажут.

G> Во-вторых, твоя и чужая бестактность провоцирует резкие ответы и флейм.

Ты свои сообещения провол читать? Вот уж где безтактость. На первое возражение буря эмозий с кучей задевающих слов.

Вопрос поднял ты. В очередной раз получил тот же самый ответ. И не довольный начинашь других считать безтактными и т.п.

G>Давай я в порядке иллюстрации тоже скажу, что думаю, чтобы ты понял, что надо фильтровать поток сознания?

Ну, если без оскорблений, то почему бы и нет. А до этого ты говорил не то что думаешь?

G> Плевать всем на твой R#,

Ну, и что?

G>ты даже объяснить зачем он нужен толком не смог, когда тебя попросили.

Или ты толком поянть. Ну, да тоже не проблема.

G> Дай бог, если им будет пользоваться столько же людей, сколько захудалым языком Hope.

Да я и не притендую. Мне интересно реализовать свои мысли. Если это удастся и результат меня удовлетворит, то я уже буду рад.

G> Это не провокация, чего ты злишься!

Где? Кто тебе это сказал. Я соврешенно спокоин.

G> Я просто говорю, что думаю. Ты теперь должен конструктивно отвечать, по делу, а не хамить.

Отвечаю.

Я прекрасно понимаю твою точку зрения. Более того без оскорблений она ничуть меня не задевает. Я и сам не верю в то, что в один момент вдруг R# превратится в самый популярный язык программирования. Но буду стараться сделать чтобы это было именно так. И уж ныть о том что все вокруг меня не понимают точно не буду.

G>Статья, собственно, датирована 1998 годом. 6 лет прошло.

Теболее. Актуальности она не потеряла.

G> Сейчас для того, чтобы запустить, надо для этого сначала скачать, потом запустить программу "сетуп", а потом ткнуть в появившуюся иконку в меню "Старт". Ты продолжишь настаивать, что это представляет для тебя сложность?

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

G>У тебя все в порядке с причинно-следственными связями?

У меня да. А вто у тебя... что-то сомнительно.

G> Не понимаешь, в каких случаях я указываю на "быдляцкие манеры"?

А не в каких не нужно. За одно это слово можно в бан на месяц. Тебе говорят, что не нужно его употреблять здесь. У тебя есть место где это делать можно. Вот там и делай.

G> Держи свои "нелестные слова" при себе, и никогда не услышишь процетированное в свой адрес.

Если тебе не нравятся мои слова, то ты волен ходить на другой сайт, а не затыкать мне рот.

G>Первой фразой в своем письме выше по ветке ты мне сообщил самую важную часть твоего мнения. "Здесь ты не прав".

И что? Это тебя оскорбило?

G> Бестактно так начинать письма,

Ну, уж извини. Я буду начинать свои писма так и впредь если я не согласен с мнением собеседника.

G> и к тому же невыгодно тебе же, так как если ты ошибся, ты выставляешь себя дураком.

Толко дурак боится ошибок (если конечо ошибки не могут привести к жертвам). Я высказываю свое мнение. Если я полчу сведения противоречащие моему мнению, я изменю свою позицию.

G> Плюс, ты провоцируешь собеседника "упереться".

Серьезно? То есть я виноват в твоей упертости? Или это ты о других?

G> Ну и естественно, ни в коем случае не уступишь сам — мосты сожжены.

Чему я должен уступить? Напору? Да не уступлю. Крикам? Тоже не уступлю. Я уступаю только логически верным утверждениям и фактам. От тебя идут одни эмоции. Ты почему-то пытаешся кому-то что-то доказать, но получается не очень. И начинается злость. Ну, и злость выплескивается в первую очередь на тех кто тебе открыто говорит, что по его мнению ты не прав.

G>Функции высокого порядка и "ленивые вычисления" — это, основные и самые мощные механизмы ФЯ.

Функции высокого порядка несомненно интереская концепция. Концпция повтоного использования алгоритмов. Но одной ею щаслив не будешь. А линивые вычисления лично на меня вообще не оказывают никакого впечатления. Я и без ФЯ могу их делать. Вот только не часто нужно. Они нужны именно, чтобы избежать проблем полного просмотра информации в ФЯ. Для ИЯ — это не проблема.

G> Убери их — и от ФЯ почти ничего не останется.

Если это так, то привлекательность ФЯ становится просто сомнительной. Однако это все же не так. В ФЯ есть много других приемуществ.

G> Просто, чтоб ты знал.

А это ты говоришь, чтобы твои слова казались более весомыми? Или просто задеть охота?

G> Вообще, мне несколько странно, что ты, не зная ни одного ФЯ и не написав на нем ни одной программы (поправь меня, если это не так, назови язык, и мы поговорим предметно),

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

G> берешься рассуждать, где там рациональное зерно, а где затычки проблем,

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

G> и вдобавок говорить кому-то, что он не прав.

А... Понял. Тебе нельзя говорить, что ты не прав. Для этого нужно ученую степень иметь. Хотя нет вообще нельзя. Это же прямое оскорбление. Доказывать свои утверждения у тебя не очень получается, так что можно вместо этого выместить злость.

G> У тебя самого этот факт не вызывает никакого беспокойства? Я бы на твоем месте постеснялся.

Ты бы постеснялся на своем. Пользы было бы больше.

G>Все споры о производительности исключительно от стереотипов.

А ну, да у ФЯ искоственный интелект. Они во всех случаях знают самый лучший алгоритм.

G>Кстати, я не заметил, чтобы кто-нибудь кроме тебя поднимал этот вопрос.

Я в этом не виноват.

G>Есть такая программа на OCaml — Fastet Fourier Transform in the West (быстрое преобразование Фурье). Численные методы — что лучше для тестирования голой производительности?

Лучше что-то более близкое к жизни простых смертных. Про тесты у нас на сайте я тебе вроде уже говорил. Попрбуй возсоздай.

G> Она не зря называется Fastest. Попробуй ее обогнать на С#. А потом поговорим о производительности.

Это вопрос алгоритма. Можно и на ВБСкрипте сделать быстро. Затачили язык на это или нашли лучший алгоритм и добились хороших результатов. А вот не будет заточена реализация под конкретные пробелмы и приплыли.

G>Медленный и малопригодный код можно написать на любом языке, для этого ума много не нужно. Надо использовать сильные стороны технологии, а не слабые, и все будет в порядке.

Кто бы спорил. Только вот хотелось бы управлять процессом генерации рельного исполнимого кода, а не изворачиваться пытаясь сделать хорошо на том что есть.

G> Да, известны задачи, решение которых на императивных языках сильно проще и быстрее. Для этого в ФЯ есть императивные расширения,

Неудобные они, эти расширения. Мне было бы удобне иметь функциональный механизм в ИЯ.

G> и средства межязыкового взаимодействия.

Опять же слишком сложно. Тут как с встренным ассемблером. Нет проблем написать пару строче если надо. Но подключать еще один компилятор, ликовать и т.п. это утомительно.

G>Вообще-то этим преобразованием занимаются компиляторы.

Вот и плохо.

G> А твой подход может и хорош, у меня нет предубеждений. Но для начала тебе надо (я не указываю тебе что делать, просто напоминаю о том, что тебе сделать придется):
G>1) Полностью довести R# до рабочего состояния.

Ёжику понятно.

G>2) Убедительно показать, что этот подход будет давать реальные преимущества.

Тоже понятно. Работаем и над тем, и над тем.

G> Меня интересуют следующие измеримые преимущества:
G>- Заметное (в разы) сокращение объема программы в сравнении с аналогичной С++.

Это само собой. Это уже в принципе есть.

G>- Аналогичный рост продуктивности труда программиста.

Тоже само собой. Правда при определенных условиях. "Здарова, мир!" точно проще не станет. А вот многие сложные задачи упростятся. Первым делом перепишим сам R# на нем же. Первая ласточка уже есть. R# генерирует код сам для себя. Пока не много, но все же.

G>- Заметное (в разы) увеличение качества ПО при тех же затратах, что и на разработку с С++.

Я бы не стал сравнивать с С++. Качество ПО увеличивается просто при переходе на Шарп. Но в общем по сравнению с обычным императивным подходом качество конечно повысится. Генерируемый код резко упрощает реализацию многих объемных задач. Это то самый аспектный подход о котором многие сегодня так часто говорят.

G>3) Обеспечить качественную поддержку коммерческого уровня, и серьезные гарантии, что она не прекратится.

Это я прекрасно понимаю. И прекрасно понимаю, что это очень сложная и важная задача. Не уверен, что у нас это удастся, но будем пытаться. Если бы еще помошников было больше...

G> Видишь-ли, когда кто-то выбирает средство разработки для проекта с бюджетом от миллиона и выше, он автоматически связывает себя с этим средством лет эдак на 5-10.

Меня миллионы не интересуют. По крайней мере пока. Если кто-то возмется за миллионные проеткы на R# я конечно буду рад. Но если и нет, то не растроюсь.

G> И было-бы очень обидно, если через пару лет, когда в разработку вбухана куча бабла, выяснится, что спецификации R# изменились

Дык мы генерируем код на C# и надеюсь эта возможность не исчезнет. Так что как максимум заставит "жить как все".

G> без уведомления, команда разработки R# считает, что критичные для моего продукта дефекты исправлять не надо, "потому что это фигня", и уже год как перестали выходить bug-fix релизы, по причине того, что команда занята реализацией очередной гениальной идеи.

Возмет исходники и поправит сам.

G> Предупреждая ответ — твои слова в форуме, какие бы нелестные они не были — это не гарантии, Влад. Это слова. А нужны гарантии. И пока никаких гарантий ты дать не можешь.

А кто может? Гарантия одна, конечный код — это код на C# (хотя можно сделать на любом дотнетном языке). Мы надстраиваем возможности над уже популярным языком, а не делаем все снуля. Думаю — это позволит избежать пробелм что есть у ФЯ.

G>Замечу, что, например, с Erlang таких проблем нет и не будет, а применение Erlang по накопленой статистике промышленных применений за последние 10 лет дает измеряемый выигрыш по затратам минимум вчетверо при написании отказоустойчивых распределенных приложений.

Это все слва сказанные теми кто неравнодушен к Erlang. Реальная статистика говорит о том, что количество его применений не сапоставима с популярными языками. Многие программисты не знают что значит слово Erlang не то что сам язык. Честно говоря эта тема уже надоела. Статистика твоя не убедительна. Читать код на ФЯ откровнно тяжело. Учить ФЯ очень тяжело. Мэйнстрим ими интересуется из любомытсва. И я не вижу рельного решения этих проблем. А без этого они так и останутся невостребованными гениальными идеями.

G> А это далеко не самый гибкий из ФЯ. Я уж не говорю об отказоустойчивости. Этот ненадежный динамически типизированный язык

Надежный и динамически-типизированный для меня лично понятия не совместимые.

G>позволяет при разумных затратах писать софт объемем 1.7 миллионов строк кода с измеряемым временем отказов 99.9999999% (это 30 наносекунд в год. пример — AXD switch).

Чистой воды рекламщина. Вот именно такие заявления приводят к тому, что на остальные слова никто даже не взглянет.

G> Он позволяет доказывать корректность реализации (благодаря тому, что это ФЯ),

А доказывать доказательства им же? Верификация есть не только у ФЯ. Но от ошибок это еще никого не застраховала.

G> что регулярно делали спецы Эрикссон в промышленной разработке — методики опубликованы, и теперь этот фокус может повторить каждый.

А нужно это кому-то? Ну, если реактор или самолоет обсчитывать, то возможно. Но 99% пишут бизнес софт. Где не то что доказать что-то а просто разобраться в законодательстве невозможно. Так что это все опят же грасивые громкие слова. Толку он них нет. Тебе уже не раз говорили, что если бы все было так изумительно как ты пытаешься представить, то никто уже давно бы не программировал бы на ИЯ.

G>Люди начинают применять ФЯ не из фанатизма, как тебе наверно кажется, а потому, что они дают измеримое преимущество.

Скорее всего так и будет... если это когда нибудь случится.

G> Вовин применят Смолток не из фанатизма, а потому что он видит, что смолток позволяет ему (рискну предположить — вдвое) быстрее и качественнее делать софт.

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

G>Вот когда твой подход даст измеряемый выигрыш по затратам хотя-бы на одном классе приложений хотя-бы вдвое (а лучше в четверо).

Похоже ты волнуешся за судьбу R# больше чем я. Мы постораемся. А что получится загадвать не буду. По моим рассчетам на некоторых задачах можно будет резко повысить и качетво кода, и его скорость, и скорость разработки, и простоту соправождения. Более того генерация кода на базе метаинформации из сборок уже неимоверно упростили реализацию и поддержку самого R#.

G> Когда тебе удастся сделать императивный язык, который позволит писать хотя-бы в половину такие надежные программы, как на ФЯ (с возможностью доказательств корректности).

А мне не нужны доказательства. Это тебе нужно ты с ним и мучайся. Меня удовлетворит мнение что продукты на R# получаются более устойчивыми чем на C# или C++.

G>Вот тогда я с интересом послушаю, и постараюсь разобраться, чем твой подход лучше ФЯ.

То есть чужие аргументы тебя не интересуют? Ну, а что ты тогда раздражаешся когда тебе говрят, что мы посмотрим на твоим хваленые ФЯ когда на них будет программировать хотя бы 10% программистов?

G> Да и не только я — все тебе в рот заглядывать будут и всем будет интересна твоя точка зрения.

В рот? Не это лишнее.

G>А пока — извини. Все, что ты говоришь — это просто сказ о шкуре неубитого медведя.

То что я говорю — это мои мысли. Я заранее говорю, что это всего лишь мои мысли. Так что чьи слова больше смахивают на сказку нужно еще разобраться.

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

INT>Попробуй все-таки написать на ФЯ хоть что-нибудь. Возможно, ощущение сходства с ассемблером исчезнет.

В чем-то он прав. Написать конечно не сложно. А вот понять потом... Читая код на ФЯ ощущаю себя дешифровщиком. Почему-то все время вспоминается Перл.

INT>А насчет насилования мозгов — ФП, вобщем, не сложнее матанализа университетского уровня



INT>Кстати, все, кто считает, что функциональное программирование не нужно, могут перестать использоваться STL и забыть слова инкапсуляция и полиморфизм. Ибо все это как раз и есть элементы ФЯ, привнесеный в С++.

Самое забавное, что тех кому оно совсем не интересно тут нет. Что обсуждать то что не интересно? Но есть многие которым интересно, но они не готовы переступить через себя, или не будут заниматься ими потому, что на них нельзя заработать деньги.

INT>P.S. Народ, чо это мы, а? Почему вдруг на личности стали скатываться? Включая Влада, который, как админ, вообще должен личный пример, аки пионер, подавать?

А где я на личности перехожу? Да и не модер я в этом форуме.
А вообще, поддерживаю! Лучше какой-нибудь конструктив обсудить.

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

B>А что такое по-твоему, к примеру,
B>полиморфизм и почему это не может быть в функциональных языках?

Что-то не пойму. Полиморфизм, что только в них есть? Или он в ООП привнесен из ФЯ?

Ну, есть он и там, и там. Что плохого то?

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

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

AD>>>С каких это пор инкапсуляция и полиморфизм стали элементами ФП?
B>>А что такое по-твоему, к примеру,
B>>полиморфизм и почему это не может быть в функциональных языках?

AD>Да, беру свои слова насчёт полиморфизма обратно. Сделал поиск и, с удивлением для себя обнаружил, что в полиморфизм является одним из принципов ФП.

А с инкапсуляцией в чем проблема?
Тоже в общем, если приглядеться, она там есть.

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

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

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

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

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

B>>А что такое по-твоему, к примеру,
B>>полиморфизм и почему это не может быть в функциональных языках?

VD>Что-то не пойму. Полиморфизм, что только в них есть? Или он в ООП привнесен из ФЯ?

VD>Ну, есть он и там, и там. Что плохого то?

Я не объектных языках и не о том, кто у кого какие идеи перенял.
Речь идет только о функциональных языках.
Оригинальный вопрос был

С каких это пор инкапсуляция и полиморфизм стали элементами ФП?

На него и отвечаю

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

INT>>Попробуй все-таки написать на ФЯ хоть что-нибудь. Возможно, ощущение сходства с ассемблером исчезнет.
VD>В чем-то он прав. Написать конечно не сложно. А вот понять потом... Читая код на ФЯ ощущаю себя дешифровщиком.

Тут ты не прав. Всё зависит от опыта. Когда я сдавал лабораторные на лиспе, преподаваьтель толко мельком взглянув на листинг, сразу заметил: вот сдесь ошибка..., вот здесь можно упростить так..., вот сдесь сделано неоптимально... и т.д.
Надо ещё учесть, что если бы он спросил меня, что делает какая-либо строчка в коде, то мне пришлось бы очень сильно поднапрячься, чтобы вспомнить, что же я имел ввиду, когда её писал

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

VD>>В чем-то он прав. Написать конечно не сложно. А вот понять потом... Читая код на ФЯ ощущаю себя дешифровщиком.

AD>Тут ты не прав. Всё зависит от опыта. Когда я сдавал лабораторные на лиспе, преподаваьтель толко мельком взглянув на листинг, сразу заметил: вот сдесь ошибка..., вот здесь можно упростить так..., вот сдесь сделано неоптимально... и т.д.

То есть тебе самому смешно?
Если язык требует серьезного опыта для чтения чужого кода, то это делает его практически непригодным для использования в команде.

AD>Надо ещё учесть, что если бы он спросил меня, что делает какая-либо строчка в коде, то мне пришлось бы очень сильно поднапрячься, чтобы вспомнить, что же я имел ввиду, когда её писал

Вот именно. Так что в чем-то он прав.

>Вот именно. Так что в чем-то он прав.

Когда INTP_mihoshi предложил написать что-нибудь, я сразу запустил OCaml, написал

let rec a = function x -> x + 2;;
a 4;;

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

Вообще-то бывало и хуже.
Самая первая команда которую я набрал на компьютере была "color". Так как в Бейсике переменные инициализировись нулем, получил черные буквы на чемном экране. Позже в Турбо Паскале попал в clipboard. Что такое меню я тогда не знал. Тоже пришлось машину перезапускать.

А вот Windows-форма на F#. Ассемблер еще напоминает потому что писать приходиться в Far'e. Ходя довольно любопытно выходит управлять Excel'ем практически из командной строки.

open System
open System.Windows.Forms

let form = new Form()

let _ = form.Text <- "1st F# App"
let menu = form.Menu <- new MainMenu()
let mnuFile = form.Menu.MenuItems.Add("&File")
let mnuiSayHelloI = new MenuItem("&Say Hello",
new EventHandler(fun sender e -> form.Text <- "Hello"),
Shortcut.CtrlH)
let mnuiSayHello = mnuFile.MenuItems.Add(mnuiSayHelloI)

let _ = Application.Run(form)

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

Короче скачал я тут OCaml... Блин... У недоделаного R# тулзов больше и пользоваться ими удобней не смотря на то что все тулзы делались на коленке и в основном для тестов. Причем эти тулзы уже можно применять вреальных проектах для автоматизированного поиска возможных логических ошибок в программах на C#.
Ну что сложно было сделать табконтрол и на один таб поместить нормальный редактор, а на другой консоль? И сделать несколько шорткатов. До этого сложно додуматься? Или сложно реализовать?
Короче это не смотря на всю супурпуперность о которой ты говоришь использовать нельзя.
Итого: Судя по OCaml воз и ныне там.

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

VD>То есть тебе самому смешно?
VD>Если язык требует серьезного опыта для чтения чужого кода, то это делает его практически непригодным для использования в команде.

А тебе не смешно? Было сказано, что опытный программист легко понимает чужой код на ФЯ. Ты можешь сказать то же самое про ИЯ? Ты всегда легко понимашь чужой код? Включая код, написанные неопытными программистами?

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

WH>Короче скачал я тут OCaml... Блин... У недоделаного R# тулзов больше и пользоваться ими удобней не смотря на то что все тулзы делались на коленке и в основном для тестов. Причем эти тулзы уже можно применять вреальных проектах для автоматизированного поиска возможных логических ошибок в программах на C#.

Конкретно, чего именно тебе не хватает в Caml, чтое есть в R#?

Прежде чем отвечать, взгляни на Camlp4
здесь

Camlp4 is a preprocessor for OCaml. As a preprocessor, you can do syntax extensions to your OCaml programs. But Camlp4 also provides some other features:

    * A system of grammars
    * A kind of macros called quotations
    * A revised syntax for OCaml
    * A pretty printing system of OCaml programs
    * and other: extensible functions, functional streams, .

У меня сордается ощущение, что по возможностям эта штука покрывает R# как бык овцу. Возможно, обманчивое У него же нет кнопочек...

WH>Ну что сложно было сделать табконтрол и на один таб поместить нормальный редактор, а на другой консоль? И сделать несколько шорткатов. До этого сложно додуматься? Или сложно реализовать?

Просто. Имху достаточно часа от силы и знания lablTk.

WH>Короче это не смотря на всю супурпуперность о которой ты говоришь использовать нельзя.
WH>Итого: Судя по OCaml воз и ныне там.

здесь

>   Q3. What kind of development framework are available in spirit of
>       Delphi/Kylix/Glade?

Emacs! You need something else??

И вообще лучше потри ocamlwin.exe. Он там от лукавого и действительно крив. Запускай ocaml.exe — честное консольное приложение. Дебаггеры и полноценное IDE есть, но почему-то только под никсами...
здесь
Конечно, если ты хочешь действительно разобраться в вопросе.

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

Вдогонку — кому лень искать может взглянуть на интерфейс дебаггера здесь

А это собственно сайт Cameleon

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

S>Реализация ФЯ была с самого начала сопряжена с большими затратами. К моменту, когда они попытались попасть в прикладное программирование, сложилось как минимум поколение (а то и не одно) людей, уверенных, что язык общего назначения должен быть императивным. В итоге приживались только те технологии, которые не слишком нарушали эту догму. При этом, что характерно, в узких нишах ФЯ таки сумели прорваться — SQL применяется повсеместно. Как ни странно, оказалось, что императивная обработка данных не устраивает даже ярых противников ФЯ. Кроме того, тут речь идет не о мелких шажках типа порядка вычисления аргументов, а о глобальных оптимизациях. И вот тут-то отсутствие императивности начало рулить со страшной силой, не давая программисту навязать умному серверу свои убогие представления о наилучшем способе получения результата.

Антон, а не кажется тебе что ты слишком широко трактуешь термин ФЯ? Если принять за ФЯ sql то очень большое количество языков попадут под это определение. Причем часть из них не воспринимается как средство программирования (например язык запросов любого поисковика) или не позиционируется как язык программирования (как к примеру тот же xslt).
А в вышеупомянутой статье имхо трактовка куда уже. И это понятно почему — если обсуждать огромное количество декларативных и полудекларативных миниязыков то нет оттенка сенсационности.

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

AVK>Антон, а не кажется тебе что ты слишком широко трактуешь термин ФЯ? Если принять за ФЯ sql то очень большое количество языков попадут под это определение. Причем часть из них не воспринимается как средство программирования (например язык запросов любого поисковика) или не позиционируется как язык программирования (как к примеру тот же xslt).

AVK>А в вышеупомянутой статье имхо трактовка куда уже. И это понятно почему — если обсуждать огромное количество декларативных и полудекларативных миниязыков то нет оттенка сенсационности.
Его (оттенка сенсационности) там и так нет.
А трактовка действительно поуже, ты прав. Примерно, как здесь: FAQ по функциональным языкам.