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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2812—2803 | 2802—2793 | 2792—2783 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 271


    № 2802   12-04-2007 12:22 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2801« (AVC)
    ___________________________
    В смысле мотивировки исключения рокировки и взятия на проходе.
    Для рокировки имеет значение двигались ли до этого король или ладья.
    Для взятия на проходе имеет значение с какой позиции стартовала пешка противника, и был ли после этого пропущен ход.
    Как видите обе задачи нетрудные, но нагромождают лишние детали, с точки зрения маленькой учебной программки.
    В отличии от вас, у меня нет никаких сомнений в том что автор достаточно квалифицирован, чтобы решить эти задачи, если ему придется за них браться.
    В конце концов состояние всей доски он ведь сохраняет между ходами без проблем. Разве сохранять возможность взятия на проходе для КАЖДОЙ пешки (16), и возможность рокировки для короля и обоих ладьей (6) сильно сложнее ?
    Нет. Просто работы много и заморачиваться для маленького примера неохота.


    № 2801   12-04-2007 11:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2800« (Jack Of Shadows)
    ___________________________

    >>>Бросилось в глаза...
    В смысле ? Вы ожидали чего то большего от маленькой учебной программки размером в несчастные 200 строчек ?


    В смысле мотивировки исключения рокировки и взятия на проходе.
     AVC


    № 2800   12-04-2007 11:11 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2799« (AVC)
    ___________________________
    Бросилось в глаза...
    В смысле ? Вы ожидали чего то большего от маленькой учебной программки размером в несчастные 200 строчек ?


    № 2799   12-04-2007 09:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2798« (Jack Of Shadows)
    ___________________________

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


    Бросилось в глаза...

    * the capturing en passant and castling rules are the worst things from a programmers point of view, because they make moves depending on previous moves, thats why I ignored both rules in my implementation

    * a depth of the game tree of 4 is already very, very slow
     AVC


    № 2798   12-04-2007 03:21 Ответить на это сообщение Ответить на это сообщение с цитированием
    Я помню Сергей Перовский все пытался здесь выяснить как на хаскеле написать программу, которая оперирут сложным состоянием в течении долгого времени. Например шахматной партией.
    Теперь у него такая возможность появилась:
    http://www.steffen-mazanek.de/blog/2007/02/haskell-chess.html
    Простенькие шахматы на хаскеле. Весь код - 12 kb
    За часик можно в принципе составить себе общее представление.
    Изучение кода думаю даст ответ на многие вопросы, которые постоянно возникают у императивщиков.


    № 2797   12-04-2007 03:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2793« (Max Belugin)
    ___________________________

    Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).

    Если в языке Оберон использовать модули с контролем импорта на чтение, то многие вопросы снимутся сами собой. Для этого нужно ввести понятие read-only import (точнее, импорт с ограничениями) и его контроль на уровне верификатора (который гарантирует, что импортированные сущности не превышают свои полномочия).

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


    № 2796   12-04-2007 02:43 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2795« (Jack Of Shadows)
    ___________________________

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

    Джек, я не пытаюсь других убедить, что ФП -- это плохо, а ИП -- супер. Наоборот, стараюсь, чтобы мы совместными усилиями выявили границы применимости и ограничения как ИП, так и ФП.

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

    В ФП для реализации обособленного ИП-мира используются монады. В ИП для ФП-мира можно использовать модули. "Искусственность" модулей в этом смысле ровно такая же, как и монад.


    № 2795   12-04-2007 02:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2791« (Руслан Богатырев)
    ___________________________
    Абсолютно правильно поняли, с той разницей, что прочитать может, а изменить -- нет. Но если нужно, чтобы и прочитать не мог -- это реализуется просто отказом в "визе" (она не будет включена в список импорта). Вроде бы уже объяснял, но повторю.

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

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

    И вот такая гарантия дорого стоит. Дороже любых уговоров грамотно пользоваться модулями.
    Уговорам я не верю.


    № 2794   12-04-2007 02:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2793« (Max Belugin)
    ___________________________

    Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).

    Это верно. Внутри модуля гарантий нет. Но есть средства-подходы, позволяющие такую гарантию обеспечить/реализовать.

    1. Отделенная от остального мира и "препарированная" функция-модуль (т.е. вырожденный модуль, внутри которого одна функция) гарантирует в определенной мере адекватную проверку подобного воздействия побочных эффектов. Следуя принципу No Paranoia, можно повышать гранулярность такого автономного ФП-модуля другими функциями.

    2. Язык Оберон/КП не дает гарантий, но они могут быть обеспечены внеязыковыми средствами (верификатором). Точнее, средствами языка более высокого уровня (языка контроля -- языка для верификатора), который внедряется в базовый язык на уровне маркированных комментариев (подобно прагмам компилятора). Некие идеи в отношении этого описывал пару дней назад в ветке по Оберону. Гарантии -- включая контроль однократного присваивания.

    На самом деле, глубинные отличия ФП от ИП довольно неплохо проведены в тьюринговской лекции недавно ушедшего от нас Джона Бэкуса (1977) "Можно ли освободить программирование от стиля фон Неймана? Функциональный стиль и соответствующая алгебра программ". На русском перевод у меня есть только в бумажном виде ("Лекции лауреатов премии Тьюринга. 1966-1985" -- М.: Мир, 1993). В оригинале (2,93 Мбайт) http://www.europrog.ru/paper/jb1977-01e.pdf

    Бэкус проводит классификацию моделей:
    1. Простые операционные модели (машина Тьюринга, конечные автоматы, сети Петри и т.п.)
    2. Аппликативные модели (лямбда-исчисление, система комбинаторов Карри, системы ФП)
    3. Модели фон Неймана (традиционные языки)

    Разграничительная линия двух миров (ФП и ИП) проходит по связке "мир выражений -- мир операторов". Второй важный момент -- придание одной сущности разных имен (в ИП), то бишь ссылки на оригинал (в том числе через присваивание).

    Поэтому, если в ИП имитируется мир ФП, то в этой "песочнице" надо установить повышенный контроль за упомянутыми вещами. Это возможно.

    P.S. В рассуждениях относительно Оберона/КП можете спокойно держать в голове Delphi (по ключевым вещам он не шибко отстает, просто много наносного, от которого можно абстрагироваться).



    № 2793   12-04-2007 01:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2792« (Руслан Богатырев)
    ___________________________
    Насколько я понял, монада ST грубо говоря создает полностью закрытый изолированный мир в котором можно вычислять путем явного задания последовательности состояния этого мира.

    Внутри него, например, нельзя явно или неявно изменить состояние ничего другого.

    Насколько я понял в обероне не гарантируется неизменение чего-то другого (и снаружи это не будет видно).

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

    Еще, как мне кажется, джек описался упоминая монаду IO - он имел ввиду монаду ST.


    <<<... | 2812—2803 | 2802—2793 | 2792—2783 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 271


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

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

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

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

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

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