Ответ на »сообщение 101« (Jack Of Shadows)
___________________________
Все это не говорит ни о простоте использования для неподготовленного человека, ни о возможности заниматься предметом, не отвлекаясь на то, чтобы сделать программу более удобной для компьютера.

P.S. А написать программу, которая покажет, сколько байт отводится под каждую переменную -- это вообще раз плюнуть.

Ответ на »сообщение 98« (Geo)
___________________________
Определить, что именно вот эта функция будет выполняться долго, и требуется ее вычислять параллельно -- это, по-моему, намного сложнее, чем решить, сколько байт отвести под строку.
Вы никогда не пользовались профайлером ?
Вы никогда не пользовались Query Analyzer, чтобы посмотреть план выполнения sql запроса и определить какой индекс нужно создать чтобы запрос выполнялся мгновенно ?

Уважаемый вам не надо ничего определять. Вы просто не думаете об этом.
Просто после написания программы, когда вы ее тестируете, если вас не устраивает скорость выполнения, и вы хотите понять где задержка, прогонятете свою программу через профайлер. Они существуют практически для всех языков, например для дельфи есть аж несколько. Вот один из них http://www.automatedqa.com/products/aqtime/

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

Ответ на »сообщение 99« (Mirage)
___________________________
Quick Sort на хаскеле:

qsort []    = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

Quick Sort на Си:

qsort( a, lo, hi ) int a[], hi, lo;
{
  int h, l, p, t;

  if (lo < hi) {
    l = lo;
    h = hi;
    p = a[hi];

    do {
      while ((l < h) && (a[l] <= p))
          l = l+1;
      while ((h > l) && (a[h] >= p))
          h = h-1;
      if (l < h) {
          t = a[l];
          a[l] = a[h];
          a[h] = t;
      }
    } while (l < h);

    t = a[l];
    a[l] = a[hi];
    a[hi] = t;

    qsort( a, lo, l-1 );
    qsort( a, l+1, hi );
  }
}

Почувствуйте разницу :)))

Понять что делает функция на хаскеле можно занесколько секунд (если знаешь хаскель)
Понять что делает функция на Си уйдет несколько минут, как бы хорошо ты не знал Си.

Интересная тема. Раньше с ФП почти не сталкивался. Посмотрел по ссылкам - не так уж все и страшно. Наоборот - многие (все?) задачи по вычислению чего-либо (да и не только), решаются очень красиво.
Думаю, будет весьма полезно ознакомиться с ФП даже людям, применять его не планирующим.
Эти идеи вполне можно применить и в императивном языке.

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

Ответ на »сообщение 93« (Jack Of Shadows)
___________________________
>>> Машина <...> распараллеливает код. А человек указывает машине какие участки кода необходимо распараллелить, а какие не трогать
Где-то на ранних стадиях обсуждения звучало, что одно из преимуществ функционального программирования состоит в том, что человек пишет на языке, понятном ему самому, а не компьютеру. И может не заморачиваться над тем, сколько байт выделить под число, а сколько под строку. Может быть, я по натуре -- императивный программист, но про представление данных в Паскале я узнал значительно раньше, чем о "тяжести" той или иной функции. Определить, что именно вот эта функция будет выполняться долго, и требуется ее вычислять параллельно -- это, по-моему, намного сложнее, чем решить, сколько байт отвести под строку.

Ответ на »сообщение 95« (Руслан Богатырев)
___________________________
приведите пример чистого языка функционального программирования. Есть ли где территория, свободная от происков других парадигм?

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

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

Кстати вот вам пример императивного кода на хаскеле, чтобы развеять все опасения что это что то жутко нечитабельное:

do
  putStrLn "Hello, what is your name?"
  name <- getLine
  putStrLn ("Hello, " ++ name ++ "!")

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

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

Ответ на »сообщение 94« (Комбриг)
___________________________

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

Попробуйте на нем решить хотя бы пару задач и сделать один пробный проект. Быть может, тогда будет проще рассуждать. Если это тяжело, то почитайте что-нибудь из того, что здесь предлагалось. Задайте по ним вопросы. А то это все больше начинает напоминать Жванецкого:

В наше время, когда уничтожают вредных насекомых, стерилизуя самцов, мы должны поднять уровень спора до абстрактной высоты. Давайте рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма. Давайте сталкивать философов, не читая их работ. Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто ел их, до хрипоты, до драки, воспринимая вкус еды на слух, цвет на зуб, вонь на глаз, представляя себе фильм по названию, живопись по фамилии, страну по 'Клубу кинопутешествий', остроту мнений по хрестоматии.

Ответ на »сообщение 92« (Jack Of Shadows)
___________________________

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

Понятно. У Вас другая точка зрения на императивность ООП. Что касается Лиспа и его "всеядности", то приведите пример чистого языка функционального программирования. Есть ли где территория, свободная от происков других парадигм?

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

И чем «полуручное» распараллеливание в parallel haskel эффективнее такового же в Делфи мне осталось непонятным.

Единственное что остается – компактность описания «функциями». Но что удобнее для работы – компактное описание или развернутое – вопрос более чем дискуссионный. Я лично, кстати, всякими средствами «сворачивания кода» в VS и BDS обычно не пользуюсь – мне неудобно, когда я не вижу каких-то частей подпрограммы. А против «листингов на десятки листов» есть элементарное, известное много лет средство – модульность...

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

Ответ на »сообщение 81« (Комбриг)
___________________________
Это что, кто-то написал такую волшебную реализацию этих языков, которая сама знает, как ей распараллеливаться??? Хотелось бы поглядеть... :)


Ссылки я приводил. Все уже сделано и прекрасно работает.
Кстати сложность написания такого вот компилятора заключается вовсе не в том что автоматически распараллеливать невозможно. Задача трудная но абсолютно по силам. Многие это уже сделали, и в этом направлении и будет развиваться индустрия программирования и дальше (железо к этому толкает).

Сложность в другом. Компилятор прекрасно распараллелит вам любой ЧИСТЫЙ функиональный код. Но вот принять решение в каких случаях это стоит делать а в каких нет - не может. Слишком сложно научить компьютер принимать такие решения.

Проиллюстрирую это на примере.

x = sqrt(a) + sqrt(b)

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

Поэтому например в расширении parallel haskel пошли по такому пути. Распределение обязанностей между человеком и машиной. Машина заанимается тем что у нее получается гораздо лучше чем у человека - распараллеливает код. А человек указывает машине какие участки кода необходимо распараллелить, а какие не трогать. Parallel haskel добавляет всего два оператора par и seq. Которыми маркируются участки кода, где программист хочет чтобы код был распараллелен. Естественно помечаться будут лишь функции занимающие достаточно большое времы для выполненияю Например больше секунды - уже хороший кандидат на распараллеливание.

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

Что же касается вопроса почему нельзя то же самое делать в императивных языках.
Видимо дело в том что чистые функциональные языки ГАРАНТИРУЮТ что часть кода является чисто функциональной (т.е. без побочных эффектов). В императивных языках компилятор такой гарантии дать не может.

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

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