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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 432—423 | 422—413 | 412—403 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 509


    № 422   17-07-2006 02:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    To Jack Of Shadows.

    Ув. Jack Of Shadows! Скажите, пожалуйста, а что Вы думаете по поводу Prolog и Prolog-подобных языков и об их преимуществах (недостатках), по сравнению с функциональными языками (в частности, с горячо любимым Вами Lisp).
    Дело в том, что я сейчас начинаю использовать Prolog в связке с .Net приложением и очень доволен его возможностями. На нем, действительно, очень легко решается определенный класс задач, которые довольно трудно решить с помощью императивных языков.
    Что касается функциональных языков. Мне показалось (я изучал OCAML), что по своим возможностям они стоят между императивными языками и логическим программированием. Да, на них можно легко и наглядно реализовать рекурсивные алгоритмы. Но все эти алгоритмы я без проблем могу реализовать и на императивном языке. Учитывая развитость библиотек и интегрированных сред для императивных языков, не факт, что эта реализация будет сложнее, чем на функциональном языке.  А что касается языка Prolog? Не буду рассусоливаться. Приведу пример всем известного теста Эйнштейна на сообразительность.

    Условие:

    Есть 5 домов каждый разного цвета.
    В каждом доме живет по одному человеку отличной друг от друга национальности.
    Каждый жилец пьет только один определенный напиток, курит определенную марку сигарет и держит определенное животное:
    Никто из 5 человек не пьет одинаковые с другими напитки, не курит одинаковые сигареты и не держит одинаковое животное.

    Дополнительные условия:
    Англичанин живет в красном доме.
    Швед держит собаку
    Датчанин пьет чай
    Зеленый дом стоит слева от белого и они стоят рядом.
    Жилец зеленого дома пьет кофе
    Человек, который курит Pall Mall, держит птицу
    Жилец из среднего дома пьет молоко
    Жилец из желтого дома курит Dunhill
    Норвежец живет в первом доме
    Курильщик Marlboro живет около того, кто держит кошку
    Человек, который содержит лошадь, живет около того, кто курит Dunhill
    Курильщик сигарет Winfield пьет пиво
    Норвежец живет около голубого дома
    Немец курит Rothmans
    Курильщик Marlboro живет по соседству с человеком, который пьет воду

    Вопрос: кому принадлежит рыба?

    Задача на Prolog решается елементарно:
    next_to(X, Y, List) :- iright(X, Y, List).
    next_to(X, Y, List) :- iright(Y, X, List).

    iright(L, R, [L | [R | _]]).
    iright(L, R, [_ | Rest]) :- iright(L, R, Rest).

    einstein(Houses, Fish_Owner) :-
      =(Houses, [[house, norwegian, _, _, _, _], _, [house, _, _, _, milk, _], _, _]),
      member([house, brit, _, _, _, red], Houses),
      member([house, swede, dog, _, _, _], Houses),
      member([house, dane, _, _, tea, _], Houses),
      iright([house, _, _, _, _, green], [house, _, _, _, _, white], Houses),
      member([house, _, _, _, coffee, green], Houses),
      member([house, _, bird, pallmall, _, _], Houses),
      member([house, _, _, dunhill, _, yellow], Houses),
      next_to([house, _, _, dunhill, _, _], [house, _, horse, _, _, _], Houses),
      member([house, _, _, _, milk, _], Houses),
      next_to([house, _, _, marlboro, _, _], [house, _, cat, _, _, _], Houses),
      next_to([house, _, _, marlboro, _, _], [house, _, _, _, water, _], Houses),
      member([house, _, _, winfield, beer, _], Houses),
      member([house, german, _, rothmans, _, _], Houses),
      next_to([house, norwegian, _, _, _, _], [house, _, _, _, _, blue], Houses),
      member([house, Fish_Owner, fish, _, _, _], Houses).

    А теперь попробуйте написать это же на функциональном языке.


    № 421   16-07-2006 22:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 420« (Jack Of Shadows)
    ___________________________

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


    № 420   15-07-2006 23:42 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 419« (Комбриг)
    ___________________________
    И мы получим "процедурно генерированный" отстой цветов детской неожиданности 

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

    Так что вам беспокоиться не о чем. Если ничего лучше тетриса новое поколение игр не принесет, по крайней мере останетесь с тетрисом : ))



    № 419   15-07-2006 23:28 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 418« (Jack Of Shadows)
    ___________________________

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


    № 418   15-07-2006 12:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 417« (Как слышно? Приём!)
    ___________________________
    Процедурная генерация это всего лишь техника, набор алгоритмов, типа фракталов.
    Они конечно могут реализоваваться на любом языке.
    Однако писать генерацию на функциональном языке дает много преимуществ по сравнению с императивным.
    Во первых такие функции не несут в себе никакого состояния (state) а потому могут быть чистыми.
    Во вторых функции генерации невероятно прожорливы (процессор), поэтому чтобы добиться приемлимой производительности их приходится распараллеливать. О том насколько это легче делать в ФЯ здесь уже много говорилось.

    Я привел в пример процедурную генерацию как одну из областей программирования в которой применение ФЯ дает отчетливое преимущество программистам.

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

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

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

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




    № 417   15-07-2006 06:43 Ответить на это сообщение Ответить на это сообщение с цитированием
    Цитата из readme.txt файла KKRIEGER:
    >>> "Like the vast majority of game projects being developed today,
    >>> .kkrieger was mostly written in C++, with some tiny bits
    >>> of assembler where it is actually advantageous

    "Как прикажешь понимать тебя, Саид?"  (С) к/ф "Белое солнце пустыни".

    Но идея компрессии и генерации графики восхищает!


    № 416   15-07-2006 01:25 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 415« (Комбриг)
    ___________________________
    kkrieger не игра, а программа, чья основная задача уместиться в 96 килобайт.
    Создатели игр конечно таких задач себе не ставят и потому kkrieger здесь не показатель а лишь концепт, доказывающий возможности.
    Как я уже говорил, Spore тоже вовсю использует procedural generation.

    А системные требования к компьютере - повыше чем в Дум-3. 
    Совершенно верно. Подобную технику можно использовать только на очень мощной технике.
    Но ведь такая техника уже реальность. Современные приставки (PS2, PS3, Xbox360), а также последние графические карты вкупе с двухядерными процессорами уже легко и быстро справляются с такой нагрузкой.

    Так что новое поколение игр, вам еще предстоит увидеть.


    № 415   15-07-2006 00:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 414« (Jack Of Shadows)
    ___________________________

    Похоже, что вы совсем не геймер :)

    Видел я этот kkrieger. Графика качества первой Кваки, те же сотни мегабайт на диске (которые генерируются при первом запуске игры) и невероятный геморрой дизайнеров и художников, которым надо простые и понятные 2D и 3D концепты реализовывать в процедурном виде...

    А системные требования к компьютере - повыше чем в Дум-3.

    ИМХО - 100% тупиковое направление. Интересно только для фанатиков "оптимизации размеров исполняемых файлов" - есть такие...


    № 414   14-07-2006 18:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Еще один интересный аспект функционального программирования.
    Называется Procedural Generation.
    Это техника создания контента для программы, скажем для игры, на лету.
    В обычных видео играх контент изготавливается заранее. Карты, графика, звук.
    Современные игры занимают гигабайты места на диске. 99% все это контент, то есть графика и звук.

    Использую технику procedural generation можно игру скажем уровня doom 3 уместить вместо пары гигабайт в...96 КИЛОБАЙТАХ !!!!
    То есть вы декларируете графику и звук при помощи функций.
    Конечно поскольку никакого действия не происходит, функциональный подход идеально подходит для такой техники. А тут еще и практически обязательная для настолько требовательных вычислений распараллеливаемость.

    Вот например такая игра: http://produkkt.abraxas-medien.de/kkrieger

    Всего 96 килобайт. Можте скачать и попробовать, или просто посмотреть картинки на сайте. Впечатляет!!

    Вот тут статья на английском про procedural generation:
    http://en.wikipedia.org/wiki/Procedural_generation

    Кстати новая игра Spore, о которой шумит весь интернет как о прорыве в области видеоигр, использует именно procedural generation для создания графики и звука на лету.

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


    № 413   03-07-2006 19:07 Ответить на это сообщение Ответить на это сообщение с цитированием
    Открывается регистрация на чемпионат по программированию ICFP http://icfpcontest.org/
    Участие бесплатное. Разрешается использовать любой язык программирования, любую ОС, любые библиотеки, любое железо. Не надо никуда ехать. Можете учавствовать из дома, или с работы (если на работе договоритесь) или с института (если вы студент.)

    Чемпионат будет проходить July 21-24

    В прошлом году учавствовало 360 программистов (161 команда) из 26 стран.
    Не смотря на то что ограничений на используемый язык нет, из года в год первые места занимают хаскель, ocaml, и различные диалекты лиспа.


    <<<... | 432—423 | 422—413 | 412—403 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 509


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

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

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

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

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

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