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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1552—1543 | 1542—1533 | 1532—1523 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 397


    № 1542   14-11-2006 02:34 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1540« (Geniepro)
    ___________________________
    Да забыл ответить на вопрос :)
    Для ручной мемоизации можно воспользоваться функцией memo из модуля memo
    То есть

    import Memo

    fdec n = memo dec n

    После чего вместо dec используете fdec.


    № 1541   14-11-2006 02:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1540« (Geniepro)
    ___________________________
    Прошу прощения, я ошибся.
    В хаскеле нет автоматической мемоизации вызовов функций. Это можно сделать только вручную.
    Меня сбила с толку автоматическая мемоизация выражений (memoization of expressions).
    То есть напишите для первого вызова let x = dec 1000000000
    dec не выполнится сразу же а только когда понадобится то есть когда print x
    А вот на второй раз print x не будет выполнять dec, а возьмет запомненное значение.



    № 1540   14-11-2006 00:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1539« (Jack Of Shadows)
    ___________________________

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

    кстати, а как заставить GHC запоминать это значение? Вот пример:

    main = do t1 <- getClockTime
              print t1
              print (dec 1000000000)
              t1 <- getClockTime
              print t1
              print (dec 1000000000)
              print (dec 1000000000)
              t1 <- getClockTime
              print t1

    dec :: Int -> Int
    dec n = f n 0 0
      where
        f x y z  = if x==1 then 0 else f2 x y z
          where
            f2 x y z = if (y+1)==x then z else f2 x (y+1) (z+1)


    dec 1000000000 вычисляется КАЖДЫЙ раз перед распечаткой, причём одинаковое время.
    То есть в данном случае мемоизации нет?
    Я замечал это кеширование только со списками - результаты работы функций обработки списков как-будто действительно запоминаются.


    № 1539   13-11-2006 18:34 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1538« (Сергей Перовский)
    ___________________________
    Как насчет общения с другими программами?
    С другими модулями?

    Вы им параметры - они вам результат :))

    Как вы общаетесь скажем с математической библиотекой ? Разве функциям sin, cos нужно от вас что либо кроме передаваемого им параметра ? Разве они должны делать что то еще помимо вычисления и ВОЗВРАТА результата ?
    Разве они ответственны за то куда этот результат сохранить ?

    В принципе любую работу можно представить как выборку из базы данных разных заранее записанных туда значений, например заменить функцию sin на функцию которая будет по параметру искать из таблицы и возвращать значение результата. Это императивность, когда вы не знаете, не можете выразить взаимосвязь между параметром и возвращаемым значением и потому вам эту взаимосвязь приходится вычислять и временно ХРАНИТЬ где то, до того момента когда понадобится. Однако если вы знаеете формулу, зачем ее вычислять и где то хранить ?
    Это же низкоуровневая оптимизация. Пусть ею компьютер занимается (мемоизация).
    Так в хаскеле функция отработавшая один раз по какому то параметру не будет вычисляться заново по тому же параметру, а просто вернет запомненное с первого раза значение.
    Точно также как вы бы запомнили это значение для последующего применения, только здесь это за вас сделает компилятор.
    Как видите императивность все равно существует, состояние существует, но от микроменеджмента ФЯ вас избавляет.
    Вместо ручного управления состоянием - автоматическое, как вместо ручного управления освобождением памяти - автоматическая сборка мусора. Только вот сборка мусора по сравнению с автоматическим управлением состоянием - это такая мелочь, которая даже не стоит упоминания.
    Это по ее уровню воздействия и важности для повышения качества программ, упрощения алгоритма, и контроля сложности систем.
    При этом сборка мусора не отменила ручное управление рессурсами.
    Так например открытый файл все равно надо закрывать вручную, открытый connection к базе данных все равно надо закрывать вручную. Никакой сборщик мусора за вас это не сделает. То есть ручное управление рессурсами осталось, просто его стало гораздо меньше. Ту часть с которой может справиться машина - отдали машине.
    Также и с состоянием. Он никуда не исчезнет, и нам все равно придется в ручную управлять им, изменять его.
    Но не повсеместно в программе, а только на небольших ее участках.



    № 1538   13-11-2006 17:13 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1534« (Jack Of Shadows)
    ___________________________
    >>>ФЯ не может отменить ИЯ (по крайней мере на машинах существующей архитектуры), просто потому что ИЯ - это единственный способ общения программы с внешним миром.
    >>>Давайте в конце концов перестанем обвинять друг друга в попытках взаимного уничтожения :))
    А кто обвиняет? Да ни разу :)
    Мне только подозрительно утверждение
    >>>ИЯ - это единственный способ общения программы с внешним миром.
    Только ли с внешним миром?
    Как насчет общения с другими программами?
    С другими модулями?
    Как часто удастся свести общение к вызову функций?

    >>>Однако убрать состояние оттуда где оно не нужно (описание процессов и взаимосвязей системы) - вот это ФЯ должно и будет делать.
    Например технологический процесс с точки зрения оборудования - последовательность операций, а с точки зрения объекта обработки - последовательность изменения его состояния. Взаимосвязи элементов системы типа  сообщение-реакция вряд ли можно описать не опираясь на понятие состояния.
    Похоже тут у нас тоже терминологические разночтения. Сами понятия процессов и взаимосвязей видимо отличаются :(


    № 1537   13-11-2006 16:59 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1533« (Владимир Лось)
    ___________________________
    Представьте себе, что астроном заявит, что по его расчетам Земля столкнется с крупным астероидом, и на Ваш резонный вопрос "Когда?" скажет: 
    <<<"это произойдёт, когда выполнятся условия ...(перечисление условий)". 

    Мы имеем дело с разными моделями и по разному интерпретируем термины.
    Если мы, всего навсего, пытаемся произвести некоторые вычисления, например расчитываем напряженное состояние конструкции, то время появляется только из за последовательности шагов алгоритма и от него можно абстрагироваться - ура функциональному программированию.
    Если мы моделируем работу аэропорта в критической ситуации, для нас важно время, идущее в нашей модели.
    Я не могу позволить себе сказать: "при условии перегрузки таких то ресурсов аэропорт будет закрыт", мне необходимо явно указать, что "это произойдёт в АА часов ББ минут ВВ секунд".
    Имитационное моделирование представляет собой эксперимент, проводимый над моделью системы. И модельное время, с точки зрения экспериментатора - объективная реальность. И состояния всех элементов в интересующий нас момент времени - объективная реальность. И как тут приложить функциональный подход?

    Повторюсь - ООП недаром было придумано специалистами по имитационному моделированию задолго до того, как вошло в языки общего назначения.


    № 1536   13-11-2006 11:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1535« (Lisp Hobbyist)
    ___________________________
    Сам жду. Пока Тилтон ничего на CVS не выложил.
    Дам ему еще пару дней, потом спрошу опять.
    Там из кода видно будет что он имел в виду под тем что любой символ уже обьект с нескольким слотами.


    № 1535   13-11-2006 11:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1525« (Jack Of Shadows)
    ___________________________

    Я написал Кени Тилтону об идее макроса def-cells-var с symbol macros внутри.
    Он ответил что идея ему понравилась и он уже добавил два новых макроса def-с-var и def-с-parameter в cells.
    Причем что самое интересное, оказалось даже не нужно создавать обьект с один слотом. Любой символ в лиспе - уже обьект с несколькими слотами, только один из которых хранит его значение.


    CL-USER 1 > (class-of 'foo)
    #<BUILT-IN-CLASS SYMBOL 20731A6C>

    CL-USER 2 > (class-effective-slots (class-of 'foo))
    NIL



    Где слот со значением? (symbol-value 'foo) за слот не считается, так как не управляется через MOP.


    Вот вам и cells с поддержкой простых типов а не только обьектов.
    Я думаю он скоро выложит код на CVS.


    Насколько я могу видеть,

    (setf (symbol-value '*xxx*) 'foo)



    игнорирует setter function, что, собственно, и зафиксировано в CLHS. Без этого, ИМХО, решение неполное --- пусть сам программист так и не напишет, а вот какой-нибудь макрос из сторонней библиотеки --- запросто.


    № 1534   13-11-2006 11:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Господа вопрошающие. Вы опять скатываетесь к двум утверждениям, которые многокоратно здесь опровергались.

    Так надо ли в 21 веке делать революцию и во имя торжества определенной парадигмы (ФЯ) полностью отказываться от другой (ИЯ)?

    ФЯ не может отменить ИЯ (по крайней мере на машинах существующей архитектуры), просто потому что ИЯ - это единственный способ общения программы с внешним миром.
    Давайте в конце концов перестанем обвинять друг друга в попытках взаимного уничтожения :))

    Функциональный подход, отвергая понятие состояния, тем самым отвергает понятие модельного времени. 

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

    По поводу моделей как отображения и прочей лабуды, будет время напишу свои мысли. Вам они не понравятся :))



    № 1533   13-11-2006 10:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1532« (Владимир Лось)
    ___________________________
    Что бы было понятно. Для меня не имеют смысл слова "это произойдёт в АА часов ББ минут ВВ секунд", скорее я пойму, когда скажут "это произойдёт, когда выполнятся условия ... (перечисление условий)".


    <<<... | 1552—1543 | 1542—1533 | 1532—1523 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 397


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

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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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