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

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

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

Не так уж сложно это сделать.

/// на подобии лиспа

sequence(list-of-code) =
  if(empty(list-of-code),
    nil,
    if(empty(tail(list-of-code)),
      eval(head(list-of-code)),
      tail(cons(eval(head(list-of-code)), sequence(tail(list-of-code)))
  ) )

repeat(n,code) =
  if((n=0),
    nil,
    if((n=1),
      eval(code),
      tail(eval(code), repeat(n-1,code))
  ) )

for(i,j,code) =
  if((i>j),
    nil,
    if((i=j),
      eval(code i),
      tail(eval(code), for(i+1,j,code))
  ) )

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


К>Ну не грустно, не грустно. AutoCAD юзает в качестве скриптового языка диалект AutoLISP
К>Тоже небось, неспроста.

Но неспроста и то, что уже пару лет, как AutoCAD отказалась от AutoList в пользу VBA. Делаем выводы...

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

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

B>Если знаешь основы обычного программирования,
B>то в Прологе постоянно не хватает обычных переменных,
B>циклов и прочих обычных для процедургого программирования вещей.
B>С функциональными языками будет примерно то же самое.
А вот это не совсем. Если принять во внимание, что мыслить надо иначе, то надо просто учится мыслить иначе, и все будет в порядке. Сложность чего в общественном сознании сильно преувеличена, ИМХО. Стоить упомянуть функциональный язык, и все приходят в трепет, — о-о-о, там даже переменных нет! Мы на зачет пришли (один раз открыв до этого книгу по языку) — а там валят, гады — квиксорт писать заставляют!!! Меж тем, речь идет не более чем о нескольких месяцах (сравните с С++ — еще не понятно в чью пользу разница).

Вот, к примеру, и авторы erlang считают так же:

How long does it take to learn Erlang?
It depends. (did you expect anything else?)

With a C background (or Java, C++, Pascal, etc.), it takes most people about a week before they can write nontrivial programs, about a month to feel really comfortable and a few months before feeling ready to take on something big by themselves. It helps a lot to have someone who knows how to use Erlang around for some hand-holding.

With a background which includes another declarative language (Lisp, Prolog, Haskell, Scheme), you'll be able to hack Erlang code straight away, though learning to take advantage of the fault tolerance and concurrency takes a while.

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

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

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

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

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

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

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

Мне кажется Кодт хотел сказать немного другое: выразительные способности FL не уже, чем выразительные способности IL и привёл ряд конструкций, характерных для IL и их реализацию на FL.

Так ведь? Кодт, признавайся!

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

LVV>У Адаменко Анатолия (он из издательства Питер) вышла книжку в издательстве БХВ "Логическое программирование и Visual Prolog". Система — современная, визуальная. Самое интересное, что к книжке прилагается ЛИЦЕНЗИОННЫЙ Visual Prolog от автора — фирмы PDS Prolog.

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

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

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

А ссылку можно?

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

B>Думаю, здесь найдутся знающие люди, потому спрошу.
B>Есть у меня идея залезть в функциональное программирование поглубже. Потому встает вопрос, какой язык выбрать для изучения (благо, выбор есть).
B>Я в свое время довольно неплохо изучил Лисп (в его Common варианте). Но это было во время учебы, и цели были чисто академические. Сейчас интерес несколько другой: применение в реальных проектах на практике.
B>Поэтому интересует современный и активно развивающийся функциональный язык. Кто что может посоветовать?
B>Еще поделитесь своими соображениями относительно перспектив функционального программирования. Или будущего нет?

Для изучения, я думаю, лучше выбрать чисто функциональный язык, чобы лучше почувствовать стиль мышления. К примеру Haskell (www.haskell.org). Среди его приемуществ — наличие стандарта (Haskell 98), однако, существует много быстро развивающихся расширений и разновидностей.
Для реальных же проектов обычно легче бывает использовать языки с побочными эффектами. Можно порекомендовать ML. Пожалуй есть 2 наиболее популярные ветви — Standard ML (среди реализаций Moscow ML и SMLNJ) и Caml. На мой взгляд, Standard ML наиболее разумный компромисс. Caml грязен до отвращения хотя, говорят, порождает весьма эффективный код.
Само собой, scheme. Тут уже упоминался. Вот и книга: http://mitpress.mit.edu/sicp/sicp.html
Ну и напоследок, — Clean (http://www.cs.kun.nl/~clean/index.html) Очень интересный чисто функциональный язык. Для некоммерческих целей доступна бесплатная реализация. Шустрый, активно развивается. Там же на сайте доступна куча научных статей по теории и реализации ФЯ и даже книга AWL по редукции графов.
Остальные ссылки легко найти через гугль.

Будущее, определенно, есть, хотя чтобы его приблизить, теоретикам программирования придется постараться. Основной недостаток ФЯ — низкая скорость — сейчас перестает быть актуальным. С распространением таких вещей как .NET все языки будут тормозить одинаково Зато ФЯ с их строгой математичесой базой открывают возмоности (по крайней мере, теоретически ) для таких вещей, как доказательство корректности программ, что для обычных языков крайне затруднительно. Возможно, это способ справиться с растущим мастабом ПО.

Из функциональных языков отмечу Visual Lisp — очень удобная вещь для программирования под AutoCAD. Активно продвигается Autodesk.

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

C>На мой взгляд, Standard ML наиболее разумный компромисс. Caml грязен до отвращения хотя, говорят, порождает весьма эффективный код.

Знаешь, у меня Ocaml при первом (и втором) взгляде вызвал похожую реакцию. И он валялся у меня на винте без дела почти год. Взялся я за него толком только из-за отсутствия альтернатив. И только после интенсивного использования я понял, что на самом деле вся его "некрасивость" оправдана и это очень стройный и гибкий язык. Просто надо стараться писать как можно более тупой код и использовать, скажем, модули или объекты, только когда они действительно необходимы.