Ответ на »сообщение 2998« (Geniepro)
___________________________
Раз уж речь зашла о проникновении ФП в mainstream языки.
Анонимные функции в java 5

new FunctionIII()
{
    public int invoke(int x,int y)
    {
        return x+y;
    }
}

Анонимные функции в java 7

{int x,int y => x+y}

Прогресс однако. Вопрос только уложатся ли в пятилетку ? :))

Ответ на »сообщение 3000« (Илья Ермаков)
___________________________
Свойство ФП, позволяющее легко и даже автоматически распараллеливать алгоритм, это чистота функции.
Да но как же писать программы при помощи только чистых функций ? Ведь как то же состоянием надо оперировать ?
Задумавшись над необходимым для этого механизмом, вы рано или поздно приходите к идее higher order functions (HOF). То есть создавать на лету функции, передавая их как параметры в другие функции, возвращая их как результат, чтобы передать дальше итд, создавая таким образом цепочку действий, цепочку превращений данных.
Для того чтобы этот механиз был удобным и практичным, очень важно иметь легкий синтаксис создания функций на лету, то есть анонимных функций. Ведь если HOF (higher order functions) это единственный фундаментальный механизм на который вы будете опираться, то есть использовать его практически в каждой строчке программы, то наверное важно чтобы это по крайней мере было легко делать.

Сравните синтаксис анонимных функций лиспа (scheme), haskell и java:

Scheme: (lambda (x y) (+ x y))

Haskell: \x y -> x+y

Java 5:
new FunctionIII()
{
    public int invoke(int x,int y)
    {
        return x+y;
    }
}

Сразу видно какой язык приспособлен для такой методики, а какой нет.

Идем дальше. Ну хорошо, получили вы свой механизм "нанизывания бусинок" то есть HOF, начинаете строить программу.
И тут очень быстро выясняется что подавляющее большинство операций укладывается в три станлартных действия.
map - прогон одной функции по списку значений с возвращением списка результатов.
fold - прогон одной функции по списку значений с возвращением конечного (одного) результата
filter - прогон одной функции по списку значений с возвращением другого, отфильтрованного списка результатов.

Все остальное это различные комбинации этих трех кирпичиков.

То есть к "функционально-математическим абстракциям" вы приходите сами. Их вам никто не навязывает.
Это естественное и логическое развитие практики ФП.

А вот если подумать...

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

Исследования в области ФП всё больше и больше проникают в мейнстримные языки!

Вот, например, в Майкрософте три группы исследователей и разработчиков (из Microsoft Research, команды CLR и команды платформы параллельных вычислений) разработали библиотеку распараллеливания заданий TPL для C# и прочих языков платформы .NET. Эта библиотека, главный компонент библиотеки Parallel FX, позволяет с очень небольшими модификациями кода хорошо распараллеливать циклы и заметно ускорять работу программ на многоядерных системах.

Очень показательный пример - трассировка лучей (Ray Tracing). Путём небольшой модификации одного цикла:

void Render(Scene scene, Color[,] rgb)
{
  for (int y = 0; y < screenHeight; y++)
  {
    for (int x = 0; x < screenWidth; x++) {
      rgb[x,y] = TraceRay(new Ray(scene,x,y));
    }
  }
}

заменяя этот цикл на вызов процедуры с передачей ей тела цикла в качестве делегата:

void Render(Scene scene, Color[,] rgb)
{ 
  Parallel.For(0, screenHeight, delegate(int y)
  {
    for (int x = 0; x < screenWidth; x++) {
      rgb[x,y] = TraceRay(new Ray(scene,x,y));
    }
  });
}

удалось добиться семикратного роста скорости трассировки лучей на восьмиядерном компьютере!
Это отличный результат для такого мизерного изменения кода!

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

Подробнее об этой библиотеке можно прочесть в статье известного хаскеллера Даана Лейжена (Daan Leijen) из Microsoft Research и Джада Холла (Judd Hall) из Microsoft:
Параллельная производительность: Оптимизация управляемого кода для многоядерных компьютеров

Группа энтузиастов (пока из двух человек: IvanVeselov aka dying_sphynx и я, и вроде ещё двое желающих есть) решили открыть свой вики-сайтик, посвящённый решению задачек из культового учебника по программированию "Структура и интерпретация компьютерных программ" (SICP).
Решения задач будут на языках Scheme, Haskell, Oberon/Component Pascal (на их общем подмножестве), возможно ещё на каких-нибудь...

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

Ответ на »сообщение 2994« (Marduk)
___________________________
Господин хороший. Хаскель и лисп это для очень и очень немногих. Для большинства это delphi или vb. Ну или java csharp в лучшем случае.
Вас никто на этот поезд не зовет. Здесь мест очень мало, и они все заняты.
Идите на другой перон.

Потрясающее сообщение от администратора тестов Great Language Shootout.
http://www.haskell.org//pipermail/haskell/2006-June/018127.html
Он сообщает что хаскель, появившись в линейке тестируемых языков, из за свое ленивой природы настолько стал обгонять все остальные языки по скорости в тестах, что ему пришлось многие тесты переделать, чтобы обмануть черезчур умный компилятор хаскеля. Но даже переделки тестов, НАМЕРЕННО ставящие хаскель в невыгодное по отношению к обычным языкам положение, отбросили хаскель ненадолго. Последние изменения в компиляторе (версия 6.6) а также в библиотеках (ByteString) опять вывели хаскель на лидирующие позиции во многих тестах.

Подумать только, на какие ухищрения приходится идти для поддержания слабеющего реноме императивных языков :))

Ну дак я сейчас тоже скажу потрясающее сообщение:
Оказывается в результате моих тестов VisualBasic  настолько стал обгонять все остальные языки по скорости в тестах, что мне пришлось  многие тесты переделать, чтобы обмануть череcчур умный интерпетатор VB.
А теперь докажите обратное :)))

Я конечно извиняюсь, но интересно- это что за железнодорожный вокзал у нас? Постоянно какие-то поезда уходят.
То на .NET, то все едут на Visual Studio, теперь вот Haskell надо срочно учить, а то поезд опять отправляется. Ну что за бред. Может хватит уже пропаганды?