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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 3262—3253 | 3252—3243 | 3242—3233 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 226


    № 3252   06-10-2007 03:46 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3239« (Geniepro)
    ___________________________

    >Асинхронное ООП в моем понимании не сильно отличается от декларатива (то бишь вообще не отличается).

    Это вообще поразительное утверждение. Этак можно договориться, что Смоллток - диалект Пролога... :о))


    Утверждение про асинхронное ООП следует из »сообщение 3142«.


    № 3251   06-10-2007 03:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3249« (Geniepro)
    ___________________________

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


    № 3250   06-10-2007 03:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3246« (Jack Of Shadows)
    ___________________________

    Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?

    Это я увидел? Может быть, все же Евгений? :)

    См. »сообщение 3159«:
    >Как только вы пришпиливаете функции к данным, вы становитесь заложником этой связки. Если же данные и функции отдельно, то очень легко создавать новые типы данных, и новые функции работы с ними. Не нужно ничего ни к чему привязывать.

    А Вы не задумывались над тем, что можно иметь и то, и другое? Отдельно -- пришпиливание процедур (методов) к типам и отдельно -- функции?


    Реакция на него Евгения. См. »сообщение 3241«:
    Ну так это так и сделано в Хаскелле - классы типов, содержащие в себе методы работы со значениями разных логически схожих типов, и просто функции...

    Моя реакция. См. »сообщение 3242«:
    Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)? См. »сообщение 3154« и »сообщение 3135«.

    Реплика Евгения. См. »сообщение 3243«:
    У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...

    Ваша реплика. См. »сообщение 3246«:
    Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?

    Мой вывод: как выясняется, есть пришпиливание и пришпиливание. Одно чистое, другое -- грязное. Но я собственно о чистоте в своей реплике и не заикался... :)


    № 3249   06-10-2007 03:31 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3244« (Руслан Богатырев)
    ___________________________

    Я имел в виду O'Haskell, OOHaskell. Если делают -- значит, видимо, не хватает.

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

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

    Давайте представим, что получится, если убрать имитацию императива из Хаскелла - это do-нотация, в основном. Так как на do-нотации также основан очень популярный и удобный механизм list comprehensions, позволяющий декларативно описывать содержимое списков (которые в Хаскелле являются разновидностью монад), то убирание этого сахара (do-нотации и list comprehensions) чуть-чуть упростит компилятор и заметно понизит удобство использования Хаскелла - придётся вручую писать очень много ненаглядного (э.. в смысле, не имеющего наглядности :о) ) кода. В результате, кто-нибудь просто напишет простейший препроцессор, который реализует и do-нотацию, и list comprehensions. Сейчас этот несложный препроцессор встроен в трансляторы Хаскелла.

    Что бы избавиться раз и навсегда от квазиимператива Хаскелла, нужно убрать сами монады. Так как монады в Хаскелле - это просто два класса типов Monad и MonadPlus, то если просто убрать эти два класса, их тут же реализует вручную любой достаточно опытный функциональщик, вместе с тем же препроцессором do-нотации...

    Что бы сделать воссоздание монад таким же трудным, неудобным и корявым, как их имитируют в С#, Java и прочих языках, нужно будет избавиться от классов типов, что будет огромнейшим щагом назад, к языкам типа Миранды и ML/O'Caml. Это решение возродит давно забытые (20 лет назад) проблемы с перегрузочным полиморфизмом и статической типизацией с автовыводом типов по алгоритму Хиндли-Милнера. Почитайте статью Корделии Холл и пр. "Type Classes in Haskell" , там описаны те проблемы, которые были просто, элегантно и эффективно решены благодаря классам типов:

    - перегрузка операций сравнения на равенство и неравенство;
    - перегрузка арифметических операций + - * / и т.д.;
    - преобразование значений разных типов в строковое представление.

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

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


    № 3248   06-10-2007 03:03 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3236« (Илья Ермаков)
    ___________________________

    Т.е. циклом while вы пользоваться не умеете. Только рассуждаете о том, какой он правильный. Так и запишем.


    № 3247   06-10-2007 02:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3238« (Geniepro)
    ___________________________
    Евгений, спасибо за комментарий и ссылки. Сделал себе несколько закладок в браузере. :)


    № 3246   05-10-2007 16:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?
    Функции описанные в type classes все также принимают значения через параметры и все также возвращают новое значение, ничего ни в каком контейнере не меняя.
    писывая тип как принадлежащий к каому то классу, вы всего лишь даете знать что функции в этом классе будут принимать параметры этого типа. Естественно для вашего нового типа эти функции придется переопределить, когда вы описываете свой новый тип как instance какого то класса типов.
    Ближайшим аналогом type classes в ОО наверное будут интерфейсы.

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


    № 3245   05-10-2007 15:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3240« (Geniepro)
    ___________________________

    Ответ на »сообщение 3153« (Евгений Непомнящий)
    ___________________________
    Пролог, кстати, не имеет отношения к ФП - это язык логического программирования, которое вместе с функциональным составляет ветку декларативного программирования, противостоящую ветке императивного программирования, в которую входят процедурное и ООП...

    В императив ещё стоит, видимо, добавить автоматное.
    А в декларатив - марковское.


    № 3244   05-10-2007 15:56 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3243« (Geniepro)
    ___________________________

    >Аналогично: может ли он обойтись без ООП, если за это отвечает свой язык?

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


    Я имел в виду O'Haskell, OOHaskell. Если делают -- значит, видимо, не хватает.

    >Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)?

    У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...


    Раз сомнения -- подождем, как прокомментирует сам Вагиф, как сообразуются Ваши высказывания с его.

    >Может ли Haskell обойтись без работы с миром императива через монады? Если будет для этого специальный язык (вне Haskell'я)?

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


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


    № 3243   05-10-2007 15:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 3242« (Руслан Богатырев)
    ___________________________

    Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)?

    У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...

    Может ли Haskell обойтись без работы с миром императива через монады? Если будет для этого специальный язык (вне Haskell'я)?

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

    Аналогично: может ли он обойтись без ООП, если за это отвечает свой язык?

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


    <<<... | 3262—3253 | 3252—3243 | 3242—3233 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 226


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

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

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

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

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

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