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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1262—1253 | 1252—1243 | 1242—1233 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 426


    № 1252   Удалено модератором


    № 1251   Удалено модератором


    № 1250   18-09-2006 16:28 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1249« (Jack Of Shadows)
    ___________________________
    Вагиф, в начале этой ветки вы пели дифирамбы Лиспу, говорили, что это идеальный язык, а теперь сфокусировались на Хаскеле. Что, приятнее все-таки работать с более человеческим по синтаксису языком? Или вам еще обилие глупых скобок не надоело? :)


    № 1249   18-09-2006 15:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1248« (bb)
    ___________________________
    Нет языка программирования в котором не было бы возможности менять состояние (императивная составляющая)
    В это плане чистые ФЯ не отличаются от любых других.
    Императивная составляющая существует везде и является неотемлимой частью программирования.
    Но вот гарантия того что некая часть программы (Не вся программа а лишь НЕКОТОРАЯ ЕЕ ЧАСТЬ), некие ее модули, некие функции - чистые, без побочных эффектов. Такая гарантия и делает язык чистым ФЯ.
    Наскель эту гарантию дает тем что вы не можете смешивать чистый и императивный код.
    Функции, меняющие состояние системы (Out), или чей результат зависит от состояния системы (In) помечаются как тип IO.

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

    Вы не сможете использовать эту функцию нигде в коде в правой части выражения (x = myFunction y)
    Вам придется все применения этой функции обертывать в монад do
    Что влечет за собой дальнейшее "отравление" кода типом IO.

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

    Вот вам и гарантия того что функция НЕ ПОМЕЧЕННАЯ как IO будет возвращать всегда ОДИН И ТОТ ЖЕ результат на одни и те же параметры, и вас не ждет скрытая подстава.

    Попробуйте сами. Есть великолепные книги по хаскелю. Порешайте задачи. Время проведете с удовольствием.
    Заодно и на своем опыте убедитесь как просто невозможно переть против насаждаемой хаскелем дисциплины программирования.




    № 1248   18-09-2006 14:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1245« (Jack Of Shadows)
    ___________________________

    Почему именно пять ? Три не устроит ? Haskell, Erlang, Clean

    Значит, Haskell - это чистый ФЯ (в понимании purely functional language), т.е. язык, чистота которого заключается в обязательной поддержке функционального программирования и гарантии отсутствия у функций побочных эффектов (side-effect)?

    Как Вы прокомментируете тогда следующее высказывание, принадлежащее Jan-Willem Maessen из MIT Laboratory for Computer Science? http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04244.html

    В частности, фразу применительно к Haskell You have a choice: write
    programs in the beautiful, purely-functional part of the language (in
    which case you have to use unstable but widely-known hacks to hide
    certain sorts of side effects), or write programs in the much clunkier
    monadic sublanguage, where you need to name all your subexpressions,
    the order of evaluation is fixed, and you can use as many side effects
    as you like.


    № 1247   18-09-2006 14:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1246« (bb)
    ___________________________

    Ссылка не битая. Просто wikipedia лежит :)) Попробуйте через некоторое время.

    Не поленюсь повторить вопрос, оставшийся без ответа.
    Не поленюсь указать вам еще раз на то что все это уже обсуждалось.
    И как рещается взаимодействие чистых ФЯ с внешней средой, и изменение состояния (монады в хаскеле, uniqueness types в Clean)
    Повторяться мне не интересно.

    А вот дать что то новенькое - это можно.
    К вопросу о смешивании парадигм а также о том как на ФЯ выражать то что на ФЯ "не выражается" :))

    http://web.engr.oregonstate.edu/~erwig/papers/Zurg_JFP04.pdf

    Интересная статья о том как на хаскеле эмулируется логическое программирование.
    Дана чисто логическая задача (search problem? домейн являющийся родным для Пролога).
    Реализованная на Прологе (исходный код приведен)
    А затем дано решение этой же задачи на хаскеле.

    Как я уже говорил, я сейчас штудирую книжку по хаскелю. С огромным удовольствием. В сто раз приятнее чем гонять NeverWinter Nights :))

    Так вот разобрал пример приведенный в статье, получил массу положительных эмоций. :))
    Сейчас я как раз на type classes. Поразительно мощная вешь.
    Позволяет полностью эмулировать как ОО так и ЛП



    № 1246   18-09-2006 14:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1245« (Jack Of Shadows)
    ___________________________

    Ну а пока: http://en.wikipedia.org/wiki/Pure_functional_language
    Ссылка битая.


    Не поленюсь повторить вопрос, оставшийся без ответа.

    Есть ли в чистых ФЯ вещи, не выражаемые на самом ФЯ (встроенные, предопределенные средства)? Если имеются, то на чем они реализуются и как это сообразуется с чистотой ФЯ?


    № 1245   18-09-2006 14:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1244« (bb)
    ___________________________

    При этом сколько вы там насчитаете парадигм и как вы их назовете - меня совершенно не волнует.
    Тоже подход. Технологическим нигилизмом называется.

    Почему нигилизм ? Нигилизм это отрицание. Я же ничего не отрицаю. Меня просто это не интересует.
    Найдите того кого интересует классификация и обсуждайте с ним.

    Если нетрудно - приведите список из пяти "чистых" ФЯ.
    Почему "Ы" ? : ))
    Почему именно пять ? Три не устроит ? Haskell, Erlang, Clean

    И поясните, что Вы понимаете под чистотой ФЯ (т.е. какие языки и диалекты, причисляемые к ФП относятся по Вашей классификации к "нечистым").

    Обсуждалось уже много кратно. Опоздали к банкету - придется вам отматывать тему назад.
    Ну а пока: http://en.wikipedia.org/wiki/Pure_functional_language

    Кстати я собираюсь поднять еще один интересный вопрос bottom-top approach (FP) vs top-bottom approach (OOP)
    Но это когда у меня время появится написать. Там поболее материала будет чем в статье про дисциплину программирования :))


    № 1244   18-09-2006 13:48 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1243« (Jack Of Shadows)
    ___________________________

    При этом сколько вы там насчитаете парадигм и как вы их назовете - меня совершенно не волнует.
    Тоже подход. Технологическим нигилизмом называется.

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

    Если нетрудно - приведите список из пяти "чистых" ФЯ. И поясните, что Вы понимаете под чистотой ФЯ (т.е. какие языки и диалекты, причисляемые к ФП относятся по Вашей классификации к "нечистым").

    Есть ли в чистых ФЯ вещи, не выражаемые на самом ФЯ (встроенные, предопределенные средства)? Если имеются, то на чем они реализуются и как это сообразуется с чистотой ФЯ?


    № 1243   18-09-2006 13:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1241« (bb)
    ___________________________
    Как вы это собираетесь обеспечивать ?


    Задавая этот вопрос я имел в виду конечно взаимодействие разных программистов (в команде или просто используя разные библиотеки от других программистов)

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

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

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

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

    В отличие от ОО языков - чистый ФЯ не дает такой возможности.
    Нет оператора присваивания. Это значит невозможно повторно использовать локальные переменные.
    Нет цикла. Это означает что любую циклическую обработку данных приходится оформлять в виде отдельной рекурсивной функции.
    Поскольку функции рекурсивые, чистые, и не могут изменять значения локальных переменных, это значит любое взаимодействие между ними должно происходить ТОЛЬКО путем передачи параметров и возвращения результата.
    То есть ГАРАНТИРУЕТСЯ соблюдение контракта, соблюдение интерфейса.
    То что в мире ОО держится только на честном пионэрском слове программиста.
    Гарантируется упрятывание локальных, промежуточных результатов на соответствующем им уровне абстакции, вместо того чтобы захламлять код программы повсеместно. То есть гарантируется инкапсуляция.

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


    <<<... | 1262—1253 | 1252—1243 | 1242—1233 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 426


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

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

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

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

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

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