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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 672—663 | 662—653 | 652—643 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 485


    № 662   12-08-2006 04:05 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 660« (hugi)
    ___________________________
    Я вижу вам нравится Smalltalk.
    Обратите внимание в таком случае на его молодого и удачливого потомка - Ruby.

    Smalltalk прекрасный язык. Язык опередивший свое время также как и лисп.
    К сожалению язык, павший жертвой неудачного выбора его создателя.
    Алан Кей, также как и позже Гослинг с java, сделали колоссальную ошибку.
    Оба купились на популярную в то время религию ООП, и замуровали этот ООП в самое сердце своих языков.
    Можно даже сказать сделали ООП скелет для своих языков.
    При этом ведь за ООП ничего не стояло. Никаких теоретических работ, никакого опыта, никаких статистических данных. Просто идеи, захватившие умы тогдашних гуру. Симула всех с толку сбила.

    Увы время показало что ООП это гипотеза, не подтвердившаяся фактами.
    В Лиспе или скажем OCAML в этом плане поступили гораздо лучше. В них есть полноценный и очень мощный механизм ООП. Но он при этом не диктует ничего. Можно его полностью игнорировать.

    В java и Smalltalk этого сделать не удастся. Там ООП это как вера. Либо ты верующий, либо тебя сожгут на костре :))

    В хаскеле вот ООП вообще нет. Не нужен. type classes вкупе с модулями полностью его заменяют.
    При этом органично вписываются в парадигму функционального программирования (в отличие от ООП)

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

    Вообще то ругать ООП на сайте дельфи - это ересь.
    Думаю щас мне не поздоровится :))


    № 661   12-08-2006 03:44 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 659« (Артем)
    ___________________________
    - И давно вы мучаетесь извращениями ?
    - Что вы доктор, я ими наслаждаюсь :))

    Ну, вот вы наконец и признались, что Лисп - это бзик :)))
    А я этого никогда и не скрывал :))

    Но, к сожалению, его реализации пока похожи на интеллектуальные игрушки и в промышленном программировании он практически не используется.

    Glasgow Haskell Complier ну никак игрушкой назвать нельзя.
    Хотя мясом конечно еще не оброс. Нет IDE, нет многих практических библиотек.
    Ну у него еще все впереди. Все это сейчас весьма активно наращивается.

    Я в принципе не тороплюсь. Лиспа мне за глаза хватает.
    Придет время и хаскель поспеет.

    Хотя кое какие практические вещи на нем уже делают.
    Я уже говорил что Перл 6 делают на хаскеле.
    Есть еще darcs - весьма популярная система контроля версий. Тоже на хаскеле.



    № 660   12-08-2006 03:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 559« (Jack Of Shadows)
    ___________________________
    Видите ли, семантически разницы между этими двумя примерами нет никакой.
    Согласен.
    Даже в количестве символов они гораздо более близки чем наш с вами пример с closures и локальными функциями.
    Не согласен (по крайней мере с closures VS. delegates).
    Таким образом, согласно вашей логике, они идентичны и следовательно между языками в которых есть case и нет case - никакой разницы нет.
    Семантически никакой разницы нет, есть разница в синтаксисе, но, как я уже говорил, для меня синтаксис не так важен, как семантика. Одного того факта, что в каком-то языке есть case, недостаточно, чтобы заставить меня на него перейти, при условии, что в языке, которым я пользуюсь в настоящий момент, есть совершенно идентичная по семантике конструкция. Тем более, что синтаксические различия преодолеваются в большинстве случаев гораздо легче, чем семантические. В том же Squeak, насколько я знаю, возможно использовать различные синтаксисы для одного и того же языка -- Smalltalk. Но если в языке нет оператора условного перехода, вам придётся напрячься, чтобы его сделать (исключение, пожалуй, составляет всё тот же Smalltalk, в котором условный оператор реализуется с помощью двух ключевых понятий языка: объектов, сообщений, а также возможности передачи блока кода, -- да-да, всё тех же closures). Так что речь идёт скорее о полноте, замкнутости и гибкости системы понятий на которых строится этот язык, а также продуманности его дизайна, а не компактности формы записи и куче наворотов, включённых в язык (о пагубности несоблюдения меры в этом вопросе наглядно свидетельствует "замечательный" язык Perl). И, кстати, механизмам того же Smalltalk я отдаю гораздо большее предпочтение, чем макросам.
    Все до единого корифеи программирования, включая Вирта, Гослинга, Андерса Хейлберга, Алана Кея, и конечно же моего обожаемого Маккарти - с вами в этом не согласны. У них у всех есть case вместе с if.
    Вы снова ошиблись. По крайней мере, насчёт Кея. В Smalltalk нет case, равно как и if, но их можно "построить" стандартными средствами, не прибегая к метапрограммированию. Насчёт Вирта, думаю, Вы тоже ошибаетесь. Не он ли хотел выкинуть из Оберона цикл for? Или ошибаюсь я? А Гослинг и Хейлсберг? Может, они в этом вопросе ориентировались на "посредственностей"?
    Тем не менее, я думаю, лучше закончить дискуссию на эту тему, тем более, что факторы, влияющие на выбор того или иного языка программирования, ни семантикой, ни синтаксисом не исчерпываются.
     hugi


    № 659   12-08-2006 03:28 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 657« (Jack Of Shadows)
    ___________________________
    А лисп я использую потому что у меня бзик на него :))
    Хаскель я обязательно буду использовать.
    Я пока хожу вокруг него, рассматриваю. И чем больше смотрю тем больше он мне нравится.
    Но пока нет практической задачи, на которой я бы его проверил.
    А играться у меня времени нет.


    Ну, вот вы наконец и признались, что Лисп - это бзик :)))
    Признаю, Хаскель красив. Я сам не него смотрю. Но, к сожалению, его реализации пока похожи на интеллектуальные игрушки и в промышленном программировании он практически не используется.


    № 658   12-08-2006 02:51 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 655« (Сварог)
    ___________________________


    И никто не мешает программисту на Делфи, С и С++ автоматически создавать в программе потоки в любом количестве.


    Автоматически нет. Вручную да.
    Вам вообще то Артем и Антон Григорьев уже ответили.
    Это как сравнение сборщика мусора с ручным убиванием обьектов.
    Сборщик мусора ГАРАНТИРУЕТ корректное управление памятью, в то время как ручное управление памятью всегда оставляет шанс для ошибки.

    Также и с потоками. Ручное управление потоками - работа чрезвычайно трудная, и 100% гарантирует ошибку.
    Такую работу лучше отдать на откуп компилятору.
    А сделать это в ИЯ невозможно. Никакой, даже самый навороченный компилятор не сможет корректно определить как распараллеливать код с побочными эффектами.

    Чистые ФЯ дают компилятору такую возможность, поскольку гарантируют что некоторые части кода (функции) являются чистыми.



    № 657   12-08-2006 02:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 656« (Артем)
    ___________________________
    Другое дело, что чистые ФЯ довольно убоги в смысле возможностей. Видите, и сам Jack of Shadows пользуется смешанным языком.

    Не согласен с вами. Чистые ФЯ очень богаты по своим возможностям.
    А лисп я использую потому что у меня бзик на него :))
    Хаскель я обязательно буду использовать.
    Я пока хожу вокруг него, рассматриваю. И чем больше смотрю тем больше он мне нравится.
    Но пока нет практической задачи, на которой я бы его проверил.
    А играться у меня времени нет.


    № 656   12-08-2006 01:29 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 655« (Сварог)
    ___________________________
    И никто не мешает программисту на Делфи, С и С++ автоматически создавать в программе потоки в любом количестве.
    Да, но в ИЯ нам приходится делать это вручную, а в ФЯ по идее это может делаться автоматически. Правда, пока только в экспериментальных непромышленных (ну,может за исключением Эрланга) языках.

    [Qoute]И самое главное - остается совершенно непонятным именно то утверждение, о котором я писал ранее: "Реализация многопоточности с помощью библиотек ИЯ не может гарантировать корректное исполнение кода". Поскольку реализация этой многопоточности "на уровне языка" в ФЯ никак не может быть иной, чем на основе библиотек ИЯ, гарантии корректности исполнения у них в точности совпадают. Иначе означенный ФЯ должен был бы быть сам по себе ОС, что не имеет места.

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

    Другое дело, что чистые ФЯ довольно убоги в смысле возможностей. Видите, и сам Jack of Shadows пользуется смешанным языком.


    № 655   12-08-2006 00:17 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 654« (Антон Григорьев)
    ___________________________

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

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

    И никто не мешает программисту на Делфи, С и С++ автоматически создавать в программе потоки в любом количестве.

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

    И самое главное - остается совершенно непонятным именно то утверждение, о котором я писал ранее: "Реализация многопоточности с помощью библиотек ИЯ не может гарантировать корректное исполнение кода". Поскольку реализация этой многопоточности "на уровне языка" в ФЯ никак не может быть иной, чем на основе библиотек ИЯ, гарантии корректности исполнения у них в точности совпадают. Иначе означенный ФЯ должен был бы быть сам по себе ОС, что не имеет места.


    № 654   11-08-2006 23:42 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 651« (Сварог)
    ___________________________

    Ответ на »сообщение 646« (Jack Of Shadows)
    ___________________________

    Не будете ли любезны объяснить, что это означает - "многопоточность реализуется на уровне языка"? А то я до сих пор полагал, что многопоточность реализуется на уровне ОС её библиотеками. А Ерланг и parallell haskell - это, вроде бы, не ОС.


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


    № 653   11-08-2006 22:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Сегодня пришлось выполнять срочную задачу.
    Крупный клиент потребовал переделать по другому Table of Contents в нескольких тысячах своих файлов (pdf)
    Сами файлы хранятся на различных серверах. Пути к ним в базе данных.
    На лиспе решение задачи заняло у меня меньше часа.

    На дельфи я даже не уверен что справился бы за 1 день.


    <<<... | 672—663 | 662—653 | 652—643 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 485


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

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

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

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

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

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