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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 402—393 | 392—383 | 382—373 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 512


    № 392   28-06-2006 02:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Разрешите еще два вопроса по идеологии ФП.
    1) Как я понял, программа на "чистом" ФЯ - это набор определений взаимосвязанных функций. Можно сказать, что программа представляет собой одно большое вычисляемое выражение. С другой стороны, любая "нормальная" программа - это все-таки какая-то определенная последовательность действий - сначала пользователь открывает какую-то форму, потом заполняет поля, потом нажимает кнопку, потом программа вычисляет что-то одно, потом что-то другое и т.д. Как при этом можно обходится без четкого указания что должно следовать за чем, т.е. без "императивности". Пока это не очень понятно.
    2) Как вообще в ФЯ, например, в том же Haskell, создавать визуальные элементы управления. В Блэкбокс все ясно - открыл меню, создал форму, на форме создал контролы, связал их с переменными и процедурами и все. А в полной версии WinHugs (~40МБ) в меню даже намека на операцию создания формы нет. Какая в функциональных языках используется "идеология" для создания элементов графического интерфейса? Человеку, испорченному визуальными и компонентными средами, этот вопрос тоже с ходу не дается :))

    P.S.
    Дошел до своей первой программы на ФЯ - что-то вроде личного варианта Hello, world на незнакомом языке. Написал программу на Хаскеле, которая формирует и выводит список из 10 чисел Фибоначчи, используя для этого рекурсивное определение функции F(N), где N - номер числа в последовательности, а F - значение числа.

    -- Последовательность чисел Фибоначчи
    module Fibonachi where
    main = t >> s
    t = putStrLn "Числа Фибоначчи"
    s = print ( map f [1..10] )
    f :: Int -> Int
    f 1 = 1
    f 2 = 1
    f n = f(n-1) + f(n-2)

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



    № 391   27-06-2006 10:03 Ответить на это сообщение Ответить на это сообщение с цитированием


    № 390   27-06-2006 06:16 Ответить на это сообщение Ответить на это сообщение с цитированием
    Спасибо за ссылку!
    Слишком рано заволновался :)).
    Поработал с модулями - там все нормально. Этот паразит в режиме командной строки кириллицу игнорирует, а когда из модуля, то пожалуйста, выводит любой литерал!
    Ну, так еще жить можно.


    № 389   27-06-2006 05:18 Ответить на это сообщение Ответить на это сообщение с цитированием


    № 388   27-06-2006 01:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    Мои отношения с Haskell 98 (Hugs) под угрозой :))).
    Выполняю код типа: putStrLn "Hello, world!"
    Получаю свой текст без проблем.
    Набираю putStrLn "Привет, мир!"
    Интерпретатор выдает что-то типа: "??????, ???!"
    Опять "проблема кириллицы" встала на пути прогресса ))).
    И почему ребята совершенно не думают, что кто-то может использовать в их замечательной системе не только латынь? Кстати, с набором кириллицы нет никаких проблем - значит это уже интерпретатор так интерпретирует? Коллеги, которые "съели собаку" на этих вещах - что можете сказать по этому поводу. Клинический случай или есть решение? Заранее, спасибо.



    № 387   26-06-2006 01:00 Ответить на это сообщение Ответить на это сообщение с цитированием
    Вот насчет практического применения...
    Подскажите пожалуйста есть ли такая возможность в ЛИСПЕ
    Это больше относится к биб-кам, чем к "языку будущего".
    Необходима правильная консольная работа. Типа curses.
    прямой доступ к символу по адресу (строка, столбец) и управление цветом
    (текст, фон) как это делается в ФАРе.
    Подскажите где копать.


    № 386   24-06-2006 07:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    как  писать в функциональном стиле на js
    http://www.remast.de/javascript.php
    http://javascript.infogami.com/Functional_Javascript


    № 385   24-06-2006 07:50 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 383« (Антон Григорьев)
    ___________________________
    >>> "если первый ряд кубиков пуст, возвращаем без изменения второй ряд, иначе откладываем из первого ряда кубик, а к тому, что осталось, применяем ту же операцию, и её результат объединяем с отложенным кубиком".

    "возвращаем" "откладываем" - императивные слова, обозначающие действия.

    Функционально думать, наверное, так:

    "соединение списков а и b это:

    • список b, если a пуст
    • список из (головы A) и (соединения (хвоста A) и B)
    "

    Мне кажется стобы понимать функциональный код надо попробовать думать не действиями а отношениями.

    Еще мне кажется что цикл проще для понимания, потому что использованы разные примитивы. Допустим у нас были было бы функция add(xs, x) - присоединение к списку xs элемента x


    append(a, b)=
      if b=nil then
          a
      else
          append(add(a, head(b)), tail(b))


    вот, допустим питоновский код:


    def append(xs, ys):
      result=xs
      for y in ys:
          result+=y
      return result


    но здесь у нас есть for .. in а теперь давайте попробуем построить его на тех же примитивах


    def append(xs, ys):
      result=xs
      rest=ys
      while rest:
          add(result, head(rest))
          rest=tail(rest)
      return result


    а теперь попробуюем написать то же в функциональном стиле, но с аналогом for .. in


    def append(a, b):
      return reduce(add, b , a)


    функция reduce:

    reduce( function, sequence[, initializer])

    Apply function of two arguments cumulatively to the items of sequence, from left to right, so as to reduce the sequence to a single value. For example, reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2)+3)+4)+5). The left argument, x, is the accumulated value and the right argument, y, is the update value from the sequence. If the optional initializer is present, it is placed before the items of the sequence in the calculation, and serves as a default when the sequence is empty. If initializer is not given and sequence contains only one item, the first item is returned.


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


    № 384   24-06-2006 02:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 383« (Антон Григорьев)
    ___________________________

    но всё равно - итерация проще.

    Приведенную вами запись я прочитал моментально. Для вас она непонятна сходу не потому что это рекурсия, а потому что это новый язык. Вы его еще по слогам читаете, так что вы не безнадежны.
    А вот чтобы провести корректное сравнение вам надо было дать еще вариант с циклом этого же append.

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

    Книга же которую вы читаете не поможет вам освоить лисп. Вам нужен что то типа htdp.org Увы может на русском его и нет. И практика. Префиксная запись слишком чужда вам чтобы безо всякой практики вы могли легко читать код и делать обьективные сравнения по легкости/сложности подходов.

    Вы бы хотя бы что нибудь попривычнее взяли - ocaml или haskell. Там хоть форма записи инфиксная.




    № 383   24-06-2006 00:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    Решил освежить свои знания Лиспа по книге http://www.delphikingdom.com/asp/book.asp?BookID=63 Там описан диалект Лиспа Scheme.

    Сначала - ликбез для тех, кто с Лиспом не знаком совсем. Основной элемент данных - атомы и списки. Атом - это идентификатор или число, список - это список из нескольких элементов, каждый из которых может быть атомом или списком. Список заключается в круглые скобки. Например, (A B C) - список из трёх элементов A, B и C, (A (B C)) - список из двух элементов - атома A и списка (B C).

    Список является не только элементом данных, но и синтаксической конструкцией языка. (A B C) интерпретируется как "применить функцию A к аргументам B и C). Если перед списком поставить одиночный апостроф, то он не вычисляется, а передаётся как есть. Например:

    (A (B C D)) - применить функцию А к результату применения функции В к аргументам С и D
    (A '(B C D)) - применить функцию А к списку (B C D)

    Основные функции работы со списком - CAR и CDR. CAR возвращает первый элемент списка, CDR возвращает хвост списка - список без первого элемента. Например:

    (CAR '(A B C)) вернёт A
    (CAR '((A B) C) вернёт (A B)
    (CDR '(A B C)) вернёт (B C)
    (CDR '((A B) C) вернёт (С)

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

    (CONS A '(B C)) восзвращает (A B C)
    (CONS '(A B) '(C D)) возвращает ((A B) C D)

    Для любых аргументов a1, lst1 верны отношения

    (CAR (CONS a1 lst1)) = a1
    (CDR (CONS a1 lst1)) = lst1

    Теперь рассмотрим, как в Лиспе определяется функция для объединения двух списков. Назовём эту функцию append. От CONS она отличается вот чем:

    (CONS '(A B) '(C D)) даёт ((A B) C D)
    (append '(A B) '(C D)) даёт (A B C D)

    Итак, вот эта функция:

    DEFINE (append lst1 lst2)
      (COND
        ((NULL? lst1) lst2)
        (ELSE (CONS (CAR lst1) (append (CDR lst1) lst2)))
    ))

    COND - это аналог case, NULL? - функция, возвращающая #T (т.е. True), если её аргумент - пустой список. Переведём на человеческий язык, что делает эта функция. Пусть у нас есть два ряда кубиков, и нам нужно объеденить их в один. Тогда функция append работает так: "если первый ряд кубиков пуст, возвращаем без изменения второй ряд, иначе откладываем из первого ряда кубик, а к тому, что осталось, применяем ту же операцию, и её результат объединяем с отложенным кубиком". Немного напрягшись, конечно, можно понять, что в результате мы получим то, что нам нужно, но сравните то же самое с чётким и ясным итеративным описанием: "пока во втором ряду есть кубики, повторять: взять первый кубик из второго ряда и перенести его в конец первого ряда".

    Одним словом, я могу поверить, что ФЯ имеют серьёзные преимущества при распараллеливании. Что Лисп имеет уникальные возможности по созданию самомодифицирующегося кода благодаря тому, что список - это и элемент данных, и команда языка. Но вот поверить в то, что рекурсия ближе к человеку, чем итерация, я, извините, не могу. Можете считать меня человеком, безнадёжно испорченным императивными языками, но всё равно - итерация проще.

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


    <<<... | 402—393 | 392—383 | 382—373 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 512


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

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

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

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

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

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