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... Вы рады?

  • <<<... | 82—73 | 72—63 | 62—53 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 544


    № 72   09-06-2006 12:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 66« (AK)
    ___________________________
    В примере, иллюстрирующем декларативный подход, непонятно, что с этим _описанием_ делать дальше. 

    А разве в императивном примере понятно что с этим делать дальше ? :))
    "Дальше" там отсутствует, выведено за рамки примера. Конечно и в том и в другом случае это "дальше" рано или поздно упрется в изменения состояния системы, т.е. в императивную составляющюю.
    Но в функциональном коде это произойдет гораздо позже. В императивном у вас вся программа меняет состояние (покрасить небо, покрасить звезды) В функциональном примере эта часть программы описывает (декларирует) часть системы. Потому эта часть легче в написании ибо отсутствует зависимость между положением описания в коде и изменением состояния системы.
    Пример с экселем я уже приводил. Люди с легкостью компонуют сложные системы, декларируя систему взаимосвязей ячеек в экселе. При этом те же люди не могут написать небольщую ПОСЛЕДОВАТЕЛЬНОСТЬ процедур (команд) делающюю тоже самое на бейсике.


    № 71   09-06-2006 12:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 67« (Антон Григорьев)
    ___________________________
    Всё-таки, где границы этого подхода? Есть же функции, которые принципиально не могут быть реентерабельными - Random, например.
    От изменения состояния системы никуда не деться. Хош на лиспе программируй, хош на хаскеле.
    Такой задачи никто не ставит. Я уже говорил, что без императивной составляющей любой функциональный язык - это сферический конь в ваккууме :))

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

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

    Я уже приводил пример кода где я передаю функцию в другую функцию. Это повсеместная практика на лиспе.
    Т.е. для меня это самое обычное дело. Я это делаю ПОСТОЯННО.
    Однако когда я работаю на дельфи или javа я практически никогда этой техникой не пользуюсь.
    Почему ? Потому что трудно. Легче работать с обьектами.

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

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



    № 70   Удалено модератором


    № 69   09-06-2006 04:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 63« (Антон Григорьев)
    ___________________________

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

    С этим аргументом трудно не согласиться. Передача по имени (позабытый механизм Алголов) усиливает возможности "трансформации" программ.


    № 68   09-06-2006 04:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 64« (Jack Of Shadows)
    ___________________________

    Я полагаю вы использовали Пролог по назначению.

    Ровно для того чтобы использовать Пролог по назначению, и участвовал в создании связки Modula-2/Prolog/Lisp, где Modula-2 была фундаментом, но при этом поддерживалось двусторонняя связь языков.


    № 67   09-06-2006 02:21 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 65« (Jack Of Shadows)
    ___________________________

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


    Всё-таки, где границы этого подхода? Есть же функции, которые принципиально не могут быть реентерабельными - Random, например.


    № 66   09-06-2006 02:16 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 53« (Jack Of Shadows)
    ___________________________

    Я думаю Geo искал что то более практичное и приземленное нежели ваше обьяснение.
    Да у ж куда приземленней-то? И практичней.

    Кстати, вряд ли стоит вести речь о противопоставлении функционального подхода императивному. Скорее - должна идти речь о диалектическом единстве в противоположности :). Так как гипотезу об эквивалентности разных алгоритмических систем никто еще не отменял. Просто каждый подход определяет свой ракурс видения объекта разработки, т.е. информационной системы. Выбор той или иной парадигмы диктуется удобством ее применения в конкретном случае.

    Далее, Вы приводите очень интересный пример.

    Сравните например:

    Декларативный (функциональный) подход.
    1. Небо темно-синее.
    2. На Небе звезды
    3. Звезды блестят серебрянным светом.

    Императивный подход:
    1. Покрасить небо в темно синий цвет
    2. Вывесить на небо звезды.
    3. Покрасить звезды в серебрянный цвет.

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


    В примере, иллюстрирующем декларативный подход, непонятно, что с этим _описанием_ делать дальше. Где здесь объявления и композиция функций (если это функциональный подход)? А если это логический подход, то должна быть фаза вопросов к программе, типа: Небо синее? --> Да. Звезды блестят золотым цветом? --> Нет. И т.д.
    Как по мне, Вы смешиваете два подхода. Но об этом чуть позже. Так как идет речь пока о примере, илюстрирующем возможность "поломатости" системы в императивном подходе.

    Предложим свой контрпример.

    Функциональный (аппликативный):
    Предположим, есть две функции
    g(x) = x * 3
    f(x) = x + 2

    Сформируем программу:
    h(g(f(x)))
    Как видим, никаких переменных, никаких состояний, только объявления функций и их композиция.

    Указанная выше функциональная программа эквивалентна императивной программе:
    x <- x * 3
    x <- x + 2

    Например, для значения аргумента X равного 5 получим результат 21.

    Но. Вы совершенно точно указываете, что поменяв операторы местами в императивном подходе, мы получим другой результат. В случае того же начального значения аргумента 5 во втором случае получим 17. Но тот же самый результат мы получим, скомпоновав другим образом функции в первом варианте, т.е.
    h(f(g(x))).
    Как видим, функциональная система "поломалась". Относительно ожидаемого результата, конечно.

    Что касается неразличения парадигм в рамках декларативной. Вполне обосновано можно применить термин "декларативный" и к императивным языкам. Просто нужно сказать, что такие языки декларируют операции исполнителя. Хотя некоторые авторы и определяют логический и функциональный подход как разновидности декларативного все-таки я бы различал функциональный(аппликативный)(пример, язык LISP) подход и декларативный(логический)(пример, язык Prolog). В основе указанных подходов лежат разные математические модели и их не следует смешивать. Мне кажется, что в рамках данной ветки логичней употреблять термины "функциональный" и "аппликативный", а "декларативный" отнести все-таки к логической парадигме.
    ИМХО.
     AK


    № 65   09-06-2006 02:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 62« (Руслан Богатырев)
    ___________________________
    Дальше. В Обероне есть процедурные переменные, которые есть ничто иное как указатели на процедуры (с контролем сигнатуры-интерфейса допустимых процедур).

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

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


    № 64   09-06-2006 02:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 62« (Руслан Богатырев)
    ___________________________
    Те, кто писал на Прологе, наверняка знают, сколь навороченным все это общение становится.

    Я полагаю вы использовали Пролог по назначению. Писать на прологе программы, это дикое заблуждение эпохи моды на ИИ.
    Я вот сейчас кстати использую пролог, наряду с forward chaining rule engine.
    Оба написаны на лиспе. Великолепный инструмент надо сказать.
    Мы держим на нем базу знаний, и самые обычные программы на дельфи обращаются через http к серверу правил (эдакая экспертная система) чтобы она говорила этим тупым императивным программа что делать.
    Отлично работает. Каждой задаче - свой инструмент.


    № 63   09-06-2006 01:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Видимо, самым располагающим к функциональному программированию из компилируемых императивных языков был Алгол, точнее, те его версии, в которых была реализована передача параметра по имени. Поясню, что это значит. Пусть у нас есть такой код:

    var
      SomeGlobalVar:Integer;

    procedure SomeProc(name Param:Integer);
    var
      Local1,Local2:Integer;
    begin
      SomeGlobalVar:=10;
      Local1:=Param;
      SomeGlobalVar:=20;
      Local2:=Param;
      ...
    end;

    ...

    SomeProc(SomeGlobalVar+5); {*}



    Когда выполняется вызов {*}, переменная Local1 получит значение 15, а Local2 - 25, т.е. при обращении внутри функции к формальному параметру, передающемуся по имени, производится вычисление выражения, переданного в качестве фактического параметра. Реализовывалось это так: для каждого фактического параметра компилятор создавал функцию, вычисляющую соответствующее выражение, и передавал в стек её адрес, а обращение к соответствующему формальному параметру интерпретировалось как вызов функции по этому адресу.

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


    <<<... | 82—73 | 72—63 | 62—53 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 544


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

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

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

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

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

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