Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  13:12[Войти] | [Зарегистрироваться]
Обсуждение темы:
Функциональное программирование

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

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

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

 Jack Of Shadows

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5502 сообщения

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 112—103 | 102—93 | 92—83 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 541


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

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


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

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

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


    № 100   12-06-2006 11:39 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 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 );
      }
    }



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

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


    № 99   12-06-2006 08:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Интересная тема. Раньше с ФП почти не сталкивался. Посмотрел по ссылкам - не так уж все и страшно. Наоборот - многие (все?) задачи по вычислению чего-либо (да и не только), решаются очень красиво.
    Думаю, будет весьма полезно ознакомиться с ФП даже людям, применять его не планирующим.
    Эти идеи вполне можно применить и в императивном языке.

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


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


    № 97   12-06-2006 02:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 95« (Руслан Богатырев)
    ___________________________
    приведите пример чистого языка функционального программирования. Есть ли где территория, свободная от происков других парадигм?

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

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

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


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



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

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



    № 96   12-06-2006 02:03 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 94« (Комбриг)
    ___________________________

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

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

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


    № 95   12-06-2006 01:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 92« (Jack Of Shadows)
    ___________________________

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

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


    № 94   11-06-2006 23:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Если я правильно понял то, что тут писалось про декларативную и исполняемую часть программы, то получается, что декларативной частью является сама структура любой императивной программы. Когда я проектирую систему и принимаю решения по поводу структуры модулей, классов, интерфейсов и пр., то я и создаю декларативное описание системы. Никаких конкретных данных у меня на этом этапе нет (ну кроме глобальных констант, может быть). И порядок создания и вычисления я тоже, большей частью, возлагаю на компьютер, поскольку у меня может быть куча forvard объявлений классов, которые реально инициализируются и производят действия по событиям в программе, т.е. по мере надобности.

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

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

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


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


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

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

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

    x = sqrt(a) + sqrt(b)

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

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

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

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

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

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




    <<<... | 112—103 | 102—93 | 92—83 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 541


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

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

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования