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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 262—253 | 252—243 | 242—233 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 526


    № 252   19-06-2006 14:21 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 249« (hugi)
    ___________________________
    Этот вариант тоже не является по-настоящему функциональным.

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


    № 251   19-06-2006 14:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 249« (hugi)
    ___________________________
    То есть перебрать элементы списка один за другим, не производя его декомпозицию с помощью операций первый_элемент, остальные_элементы, у Вас называется "работать не напрямую"?

    Насчет декомпозиции списка в ФЯ только что говорил: »сообщение 248« :)) Как будто предвидел ваш вопрос. :))






    № 250   19-06-2006 14:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 247« (Как слышно? Приём!)
    ___________________________

    В визуальных-то языках скелет проекта приложения строится
    по описаной выше ... ещё выше ... схеме легко.


    Это не имеет отношения к дискуссии ФЯ\ИЯ. Это к проектированию, т.е. к проблемам которые решаются (или проваливаются) одинаковыми методами как в ФЯ так и в ИЯ.
    Я помню на базарной площади была ветка посвященная методам и проблемам проектирования.
    Думаю ваш вопрос уместен там.


    № 249   19-06-2006 14:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 243« (Jack Of Shadows)
    ___________________________
    Результат да, но не логику. Логика все также прямолинейна. Т.е. с точки зрения человека, описывающего процесс, разницы нет.
    Я человек, и с моей точки зрения разница есть, причём ощутимая.
    (Насыпать-в-чай список-ложек)
    (Сыпем (первая список-ложек)
    (Насыпать-в-чай (остальные список-ложек))

    Этот вариант тоже не является по-настоящему функциональным. Т.к. Вы последовательно изменяете состояние кружки с чаем:(Сыпем (...)). Хотя, если последовательность


    (operation1 (a)
        (operation2 (b)))


    автоматически создаёт и возвращает список, то всё ОК (по части примера, но не модели).
    К тому же в этом случае нужно предварительно сформировать список (в реальности этого не происходит, и даже в ФП это необязательно, а в ИП и подавно не нужно).
    Просто в ИЯ это делать настолько громоздко, что даже когда у вас есть список данных, вы все равно предпочитаете работать почему то не напрямую с ним, а опосредствованно, через число итераций, типа
    i = 0 то list.Count - 1

    То есть перебрать элементы списка один за другим, не производя его декомпозицию с помощью операций первый_элемент, остальные_элементы, у Вас называется "работать не напрямую"?
     hugi


    № 248   19-06-2006 13:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Я думаю пришла пора обьяснить чем же отличается список в ФЯ от списка в ИЯ.
    Заметьте я с казал в ФЯ а не в лиспе.
    Дело в том что во всех ФЯ внутреннее предсталение спика одинаково, неважно, работаете вы с лиспом или с хаскелем.

    Возьмем список (1 2 3 4)
    Казалось бы простенький плоский список. Не совем так!
    На самом деле это такая вложенная конструкция (как матрешки).
    Выглядит она вот так: (1 (2 (3 (4 ())))
    Т.е (1 a) где a это тоже спикок (2 b) где б это тоже спикок (3 с) где с это тоже список (4 d) где d это тоже список () т.е пустой список.

    Даже список с одним элементом на самом деле имеет два элемента.
    Т.е. (1) на самом деле это (1 ()) т.е. первый элемент 1 и второй элемент пустой список.

    ОК скажете вы, ну и плевать, мне то что ? Я же записываю плоско (1 2 3 4)
    Какая разница, как список предствален внутренне.

    Огромная разница, уважаемые. Огромная!!

    Благодаря тому что список предствален вложенными парами (tuples или cons в лиспе) их можно обрабатывать 2 функциями
    (first spisok) дает вам первый элемент списка.
    (rest spisok) дает вам ОСТАЛЬНЫЕ элементы списка. На самом деле он просто дает вам второй элемент из пары.
    Но поскольку тот является списком то вы получаете то что хотели.

    first и rest (первый и остальные) или в лисповом синтаксисе car и cdr используется во всех без исключения рекурсиях. Именно наличие этого механизма делает возможным, естественным и легким рекурсию.

    ОК, но почему бы не работать с first и rest в ИЯ ? Разве нельзя вернуть список в которм убран первый элемент ?
    Физически можно. Практически нереально.
    Функцию first реализовать в ИЯ легко. А вот rest (остальные) - трудно. Для этого придется каждый раз создавать новый список без первого элемента и передавать его дальше.
    Представьет себе обработку списка из миллиона записей. Любой компьютер сдохнет! Никакой памяти не хватит!

    А в ФЯ все гораздо легче, ведь rest не создает новый список, просто возвращает указатель на уже готовый.
    Поэтому в ФЯ рекурсивная обработка списков практически возможна и по эффективности не уступает итерации.

    Когда научишься работать со списками в рекурсивном режиме, это такое удовольствие! Это так естественно для человека, это так легко!! (не нужно помнить обо всех этих временных переменных, о счетчике цикла итд итп)

    К сожалению, когда переходишь обратно на ИЯ (работать надо) то приходится возвращаться к циклам.

    Циклы (for, while) превращают программирование в скучную и трудную работу.
    Рекурсия (там где она практически возможна конечно, т.е. в ФЯ) возвращает вам обратно радость программирования.

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



    № 247   19-06-2006 13:48 Ответить на это сообщение Ответить на это сообщение с цитированием
    >>> Вот где настоящий расход памяти.
    Приказ же был: "Патронов не жалеть!" Наступило изобилие памяти
    и тактовой частоты, ядра раздвояются и прочие чудеса.
    Поэтому сравнивать надо скорее ФЯ не с Си подобным императивом,
    а с визуальным программированием или конструированием.
    Собирать приёмник из транзисторов и прочей рассыпухи это
    в прошлом. Микросхемы в ходу.

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

    А вот о разработке общей структуры проекта в мануале не вычитаешь.
    По мне, общий принцип разработки приложения примерно таков.
    1) Выясняем постановку задачи, выясняем то, что хотим получить.
    В этом смысле декларации важны, созвучны и органичны, если
    ты не кодер - машинистка, а задачу понимаешь широко.
    2) Разбиваем большую задачу на относительно независимые куски
    до уровня прожевываемости куска за раз. (Может здесь кроется тяга
    к модулям) . Устанавливаем связи между ними. Модель готова.
    3) Ну и делее.

    Так вот, вопрос. Разбиение на куски и построение системы, здесь,
    в ФЯ, - это установление набора функций и связи по их аргументам?
    Или как? Скелет проекта смутно представляю как может строиться.
    Или к мизинцу на ноге пририсовываем пятку, потом коленку, потом ...,
    потом спину и так до макушки.
    В визуальных-то языках скелет проекта приложения строится
    по описаной выше ... ещё выше ... схеме легко.

    Нашёл описалово НА РУССКОМ по лиспу (жаль-pdf) двухтомник 15 и 13 Мб:
    http://www.dvo.ru/tech/lisp/index.html
    Ссылку проверил - работает.


    № 246   19-06-2006 13:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 245« (Jack Of Shadows)
    ___________________________
    А во избежание подобных недоразумений можно было бы сопровождать код комментариями, а не просто говорить: "Вот код. Хотите понять? Лезьте в интернет." Мне кажется, это в Ваших же интересах, если Вы действительно хотите привлечь людей к ФП. Тем более Вас никто не принуждает делать подробный обзор Лиспа, достаточно ограничиться краткими пояснениями.
     hugi


    № 245   19-06-2006 13:16 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 242« (hugi)
    ___________________________
    Человеку хочется прежде получить общее представление о предмете, оценить, хотя бы приближённо, все плюсы и минусы, а уже потом с головой погружаться (или не погружаться) в углубленное изучение.

    Вы меня извините, но там речь не шла об "общем представлении". Господин Qwerty задавал вопросы о синтаксисе.

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

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

    Работа должна быть обоюдной.



    № 244   19-06-2006 13:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 242« (hugi)
    ___________________________
    Кстати, для желающих взять быстрый старт и понять, что же такое ФП, и что лежит в его основе (структуры данных и т.п.), настоятельно рекомендую ознакомиться: http://www.roman-dushkin.narod.ru/fp.html
    Написано простым понятным языком, примеры... нет, не на Лиспе, на абстрактном ФЯ, похожем  на Хаскель. Трёх первых лекций (очень небольших, кстати) вполне хватит, чтобы войти в курс дела.
     hugi


    № 243   19-06-2006 13:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 240« (hugi)
    ___________________________
    Напомню, что в чистых ФЯ, где нет понятия состояние, результат рекурсивных вызовов мы будем получать только про т.н. "обратном раскручивании".

    Результат да, но не логику. Логика все также прямолинейна. Т.е. с точки зрения человека, описывающего процесс, разницы нет.

    (Насыпать-в-чай число-ложек)
    (если число-ложек больше нуля)
        (Сыпем-одну-ложку)
        (Насыпать-в-чай (на-одну-меньше число-ложек))

    Однако такой подход не является по настоящему функциональным.
    На самом деле правильнее было бы работать не с числом итераций, а с данными, то есть со списком.

    (Насыпать-в-чай список-ложек)
    (Сыпем (первая список-ложек)
    (Насыпать-в-чай (остальные список-ложек))

    Просто в ИЯ это делать настолько громоздко, что даже когда у вас есть список данных, вы все равно предпочитаете работать почему то не напрямую с ним, а опосредствованно, через число итераций, типа
    i = 0 то list.Count - 1



    <<<... | 262—253 | 252—243 | 242—233 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 526


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

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

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

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

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

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