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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2232—2223 | 2222—2213 | 2212—2203 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 329


    № 2222   25-03-2007 06:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2200« (Сергей Перовский)
    ___________________________

    Для меня все это именно фокусы: вполне симпатичные но совершенно не обязательные возможности. ... приятные мелочи.

    Не совсем так. Потому что основаны они на очень простых фундаментальных, тщательно отобранных весчах, которых нет в других системах. А эффект этих простых фундаментальных весчей propagates сквозь всю разработку -- от уровня кода, где это выглядит как приятные мелочи, до уровня архитектуры, где это выглядит уже как life saver.


    № 2221   25-03-2007 06:44 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2217« (Булат Зиганшин)
    ___________________________

    Ответ на »сообщение 2206« (AVC)
    ___________________________

    ... нет синтакс. мусора, типы выводятся автоматически.

    А если при выводе типа программист -- а вслед за ним компилятор -- ошибется дважды?
    Мало не покажется.

    Синтаксический "мусор" -- нужный, в т.ч. для явных объявлений типов -- средство экспликации.

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

    Точно такого же? Сильно сомневаюсь. Точнее, знаю наверняка, что гораздо меньшего.

    И проблема согласованности комментариев и текста тоже никуда не уходит. А это -- реальная промблема.


    № 2220   25-03-2007 05:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2211« (Geniepro)
    ___________________________

    поэмы красивее тяжеловесных романов.

    Отнюдь не факт ... depends.
    Не все романы тяжеловесны, даже толстые.


    № 2219   25-03-2007 05:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2208« (AVC)
    ___________________________

    Т.е. по всей программе "разгуливает" структура неизвестного размера

    забыл сказать. гуляют конечно ссылки. есть и другой подход - он избавляет от явной передачи state, но в то же время не создаёт проблем для распараллеливания. это - использование монад. однако при этом замедляется работа программы, причём не удивлюсь если в несколько раз

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

    условно говоря, если есть программа

    compressData = do createArchive
                      addData
                      closeArchive

    и compressData вызывается с использованием монад UI и Error, то этот код на внутреннем языке компилятора будет выглядеть как

    compressData UI Error = do createArchive UI Error
                              addData UI Error
                              closeArchive UI Error

    и такая же трансляция будет предпринята для всех монадических операций (процедур), вызхываемых внутри этих createArchive/... подчеркну - это очень поверхностное описание, гораздо лучше это описано в http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html

    сам компилятор ghc написан именно таким образом. как результат - его удалось легко распараллелить (насколько я в курсе, для gcc о подобном и не помышляют :) правда при этом выигрыш afair составил всего 15%

    в ghc есть, например, монады, генерящие уникальные имена, запоминающие генерируемый код (это когда в процессе генерации тела одной процедуры вдруг решили создать ещё одну, вспомогательную) и многие другие


    № 2218   25-03-2007 05:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2208« (AVC)
    ___________________________

    Ответ на »сообщение 2202« (Булат Зиганшин)
    ___________________________

    >>>я ниже писал - передавать целиком состояние мира в виде структуры.

    Очень интересно.
    Т.е. по всей программе "разгуливает" структура неизвестного размера (да и неясного содержания), а учитывая строгости ФП -- скорее всего, несколько ее копий.
    Если это то, что я подумал (я мог понять неверно), то у нас с Вами разные представления о модульности (в данном контексте -- разбиении программы на части с минимизацией связей (coupling) между частями).


    не всё так трагично :)  для разных задач - разные инструменты. хаскел поддерживает императивное программирование тоже. у меня в программе есть два модуля - учёт ошибок и UI - которые являются для остальной части программы чёрными ящиками и имеют в частности свой state. и то - лучше было бы их сделать отдельными тредами, по крайней мере UI это бы точно не помешало, да нет сейчас времени переделывать

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

    вообще, мне кажется, вы судите о порблемах ФП, примеривая его на выразительные средства Оберона, а они по своременным меркам весьма узки. нет polymorphic programming, type constructors, type inheritance. к примеру, заголовк процедуры, читающей оглавление архива, у меня выглядит так:

    -- |Прочитать каталог, записанный функцией `archiveWriteDir`
    archiveReadDir arc_basedir  -- базовый каталог в архиве
                  disk_basedir  -- базовый каталог на диске
                  archive      -- файл архива
                  arcpos        -- позиция в архиве, где начинается этот каталог
                  filter_f      -- предикат фильтрации файлов
                  receiveBuf    -- "(buf,size) <- receiveBuf" получает для работы очередной буфер размером `size`

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


    № 2217   25-03-2007 04:46 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2206« (AVC)
    ___________________________

    Легче читать нормальный текст, чем криптограмму, даже короткую.


    а как ты надеялся прочитать программу на незнакомом языке, да ещё и с незнакомой паралигмой программирования? :)

    давай сравним элементарный код:

    function fac (n:integer) : integer;
    begin
      if n=0
        then Result:=1
        else Result:=n*fac(n-1)
    end

    и

    fac n = if n==0
              then 1
              else n*fac(n-1)

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


    вот другой пример - поиск в строке последнего пробела до 80-й позиции:
    last_space = last . findIndices (==' ') . take 80

    вот она уже существенно использует ФП стиль.

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

    -- Подготовить список замен к использованию в lookup
    prepareSubsts x = x
        -- Удалить пустые строки, пробелы и комментарии
        .$ map (filter (not.isSpace) . fst . split2 ';') .$ filter (not.null)
        -- Заменить каждую строку с символом # на 9 строк, где # пробегает значения от 1 до 9
        .$ concatMap (\s -> map (\d->replace '#' d s) ['1'..'9'])
        -- Преобразовать список строк вида "a=b" в список для lookup
        .$ map (split2 '=')

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


    № 2216   25-03-2007 03:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2215« (Jack Of Shadows)
    ___________________________

    >>>А вот и первые ласточки преимущества ФЯ в автоматическом распараллеливании:

    Цифры (пока!) не очень впечатляют.
    Насколько я помню (и если реклама не врет :) ), Deep-версии популярных шахматных программ давали на 2-ядерном процессоре прирост быстродействия 80%. Очень сомневаюсь, что они пишутся на ФЯ.
    Но все равно очень интересно. Спасибо!

    Вместе с тем, IMHO, не стоит особо преувеличивать трудности распараллеливания.
    Превратить "подпрограмму" в "сопрограмму" (поток) и добавить шедулер (или использовать готовый) не такая уж непосильная работа. :)
     AVC


    № 2215   25-03-2007 00:54 Ответить на это сообщение Ответить на это сообщение с цитированием
    А вот и первые ласточки преимущества ФЯ в автоматическом распараллеливании:
    http://cs.hubfs.net/blogs/tomasp/archive/2007/03/25/fsharp_parallel_ops.aspx
    F# библиотека для распараллеливания работы со списками.
    Пока в ней только 2 функции filter и map. 
    Убыстрение на 2-ядерном процессоре функции нахождения prime numbers, гле то в 40%
    Причем разница в коде только в импортируемом модуле. Вместо модуля List импортируется модуль ParallelList.
    Сравните это с изменениями которые придется делать в императивной программе для распараллеливания.
    Кстати по оценкам экспертов, через 4-5 лет большщинство продаваемых компьютеров будет иметь 16 и больше ядер.
    Так что подобные функциональные библиотеки придутся как нельзя кстати.




    № 2214   24-03-2007 17:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2213« (AVC)
    ___________________________

    Прошу прощения за отсутствие разделения между цитатой и собственным текстом. :(
    Мой ответ начинается со слова "спасибо". :)
     AVC


    № 2213   24-03-2007 17:49 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2211« (Geniepro)
    ___________________________

    Ответ на »сообщение 2206« (AVC)
    ___________________________


    Кстати, о криптограммах. :о))
    Почитайте, если найдёте время, мою статью с расписанной по пунктам программой - решением задачки с ACM ICPC 2007.
    Не знаю, почему Вы так не любите Хаскелл, но надеюсь, что Ваше мнение о нём изменится...

    Надеюсь, Илья Ермаков распишет так же подробно матричные-множественные алгоритмы из своей программы на КП и укажет, какие у них преимущества... ;о)

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

    По поводу же преимуществ Оберона/КП, они, IMHO, в основном все-таки лежат в системной сфере; не обязательно системного ПО, а программ, функционирующих как системы, с изменением состояний (так в жизни!), накоплением информации, изменением и расширением модульного состава "на лету".
     AVC


    <<<... | 2232—2223 | 2222—2213 | 2212—2203 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 329


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

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

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

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

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

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