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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

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


    № 2232   25-03-2007 12:37 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2229« (Илья Ермаков)
    ___________________________
    Когда мы не может сразу выразить вычисления в виде одного выражения, почему бы не расписать их пошагово? 
    Действительно почему бы ?
    Где вы видели функциональныя код в одну длинную строчку ?
    Мы тоже разбиваем сложные выражения на более простые, написанные на отдельных строчках.
    Только если вы для этого используете опреатор присваивания, мы используем декоарацию выражений.
    Но и в том и в другом случае это таже самая декомпозиция выражений на более простые и понятные для чтения.
    И присваивания для этого не обязательны.


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

    Не надо делать над собой никаких усилий. Раскручивайте подробности на бумаге.
    Никто не застваляет вас писать


    qsort (x:xs) = (qsort (filter (<x) xs)) ++ [x] ++ (qsort (filter (>x) xs))


    Пишите


    qsort (x:xs) = lesser ++ middle ++ greater
      where lesser = qsort (filter (<x) xs)
            greater = qsort (filter (<x) xs)
            middle = (filter (==x) xs)



    Я лучше проделаю ту же декомпозицию явно в программе.
    Правильно. Мы все проделываем декомпозицию в программе.
    Зачем на функциональщиков волну гнать ?
    И почему декомпозицию обязательно делать присваиваниями ?


    № 2231   25-03-2007 12:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2230« (info21)
    ___________________________

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

    пожалуйста иллюстрируйте иначе это читается как hype и ничего больше.

    См. Блэкбокс.


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


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

    пожалуйста иллюстрируйте иначе это читается как hype и ничего больше.

    См. Блэкбокс.

    точно так же, как если я скажу что хаскелл - сверх-высокоуровневый язык и не покажу никаких примеров. вы поверите? ;)

    Я-то не поверю... 8)))
    Потому как и математику знаю, и как работается на ФЯ -- тоже...



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

    Ответ на »сообщение 2224« (Илья Ермаков)
    ___________________________
    Это не "мусор", это избыточность, требующаяся для читабельности и большей надежности. В технике избыточность, дублирование является одним из средств повышения надежности.
    Это дейстительно избыточность. Однако к читабельности, и уж тем более к большее надежности (чаго ?!!!) она вообще никакого отношения не имеет.
    Эта избыточность требовалась 30-40 лет назад, для обеспечения экономии жутко дорогих железных ресурсов.

    Всё это многократные повторения одного и того же...
    Info21 вставил не так давно верное замечание о мифе относительно большей абстрактности и математичности ФП и задал риторический вопрос "Почему нужно считать функцию более математической концепцией, нежели концепцию оператора, если имеются матетические формализмы Дейскстры для операторной нотации".
    А по поводу "избыточности"... При чем тут, в конечном счете, экономия ресурсов?
    Лично для меня это один из видов декомпозиции задачи. Когда мы не можем что-то сделать в уме, мы явно выписываем промежуточные результаты на листке бумаги, разве не так?
    Когда мы не может сразу выразить вычисления в виде одного выражения, почему бы не расписать их пошагово? Любая математическая теорема представляет собой такое же пошаговое преобразование, с запоминанием промежуточных результатов, с выполнением действий по преобразованию. Можно, конечно, отказаться от этой пошаговости - и записать все преобразования в одну строку, но для чего?
    У меня, например, не математический склад ума, мне сложно воспринимать математический вывод, громоздкие формулы - приходится делать над собой усилие, раскручивать с подробностями на бумажке и т.п.
    И точно так же мне сложно воспринимать функциональную программу. Да, это очень изящно и красиво! Но я не представляю, как можно заворачивать единые выражения большой сложности и вложенности без предварительного их вывода по кусочкам "на бумажке". И зачем мне это надо? Выкинуть бумажку, записать красивый и лаконичный результат, а через полгода вспоминать, как он был получен? Я лучше проделаю ту же декомпозицию явно в программе.


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

    Ответ на »сообщение 2224« (Илья Ермаков)
    Вот современные императивные программисты и напоминают таких вот обезьян, которые уже давно не испытывают никаких недостатков в компьютерных рессурсах, но по прежнему рьяно эти рессурсы берегут.
    При этом даже изначальную причину позабыли и заменили ее на новую молитву, про читабельность и большую (хаха) надежность.

    Что-то Вы, Джек, забываете, что море задач по прежнему находятся на пределе возможностей машин... Если брать из прикладной сферы - то те же задачи машинной графики. Кстати, некоторые задачи ИИ - в чем и грустное противоречие - идеально подходят одни языки, в лабораториях используют их, а в условиях требований к промышленной реализации приходится опять вспоминать про ресурсы...
    Ну да это прикладные задачи, шут с ними - тут действительно выгоднее иногда написать быстрее на более медленных языках, добавить в кластер в сети лишнюю пару-тройку ПК и обсчитать за то же время...

    А вот в системном ПО это далеко не все равно. Вам ведь не все равно, сожрет ОС у вас 64-128 мб памяти или все 512? Системное ПО - это не раз, не на один запуск, не на один расчет... Это то, что работает все время резидентно, и от того, насколько быстро оно работает, зависит, сколько процентов системных ресурсов достанется вашему интерпретатору Хаскелла для обсчета прикладной задачи.
    Не говоря о встроенных системах, где есть большая разница - поставить один процессор, или десять... А если оборонка, то есть еще разница - поставить свой процессор, который на порядок помедленней ,и выиграть на быстром и компактном софте, или ставить забугорный с закладками :-)


    № 2227   25-03-2007 10:59 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2224« (Илья Ермаков)
    ___________________________
    Это не "мусор", это избыточность, требующаяся для читабельности и большей надежности. В технике избыточность, дублирование является одним из средств повышения надежности.
    Это дейстительно избыточность. Однако к читабельности, и уж тем более к большее надежности (чаго ?!!!) она вообще никакого отношения не имеет.
    Эта избыточность требовалась 30-40 лет назад, для обеспечения экономии жутко дорогих железных ресурсов.
    Сегодня такой необходимости нет. Но жертвопрношения мертвому богу по прежнему приносятся.

    Мне это напоминает эксперимент с обезьянами.
    В клетке 5 обезьян. Опускают банан. Как только кто нибудь из обезьян пытается схватить банан - всех бьет током. В результате очень скоро они смирненько сидят и банан не трогают.
    Затем одну из обезьян меняют на новенькую. А как только опускают в клетку банан она конечно пытается схватить, и тут же остальные 4 обезьяны накидываются на нее и начинают бить.
    Естественно новая обезьяна тоже теперь "научена".
    Постепенно заменяют всех обезьян и отключают ток.

    Ни одна из новых обезьян НИКОГДА не испытывала электрического шока. Ни одна не знает, почему нельзя трогать банан. Но все исправно бьют любого кто попытается к банану притронуться.

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



    № 2226   25-03-2007 10:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2216« (AVC)
    ___________________________
    Deep-версии популярных шахматных программ давали на 2-ядерном процессоре прирост быстродействия 80%.

    Ну это смотря в какую сторону роценты считать. :)) .Я посчитал не убыстрение а уменьшение времени исполнения.
    То есть заявленные 40% уменьшения времени выполнения это и есть 80% убыстрения. Все сходится.

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


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


    № 2225   25-03-2007 08:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2221« (info21)
    ___________________________

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


    во-первых, синт. мусор и объявление типов - разные вещи :) в данном случае мусор - это procedure, begin, end, if, then, else. запись без них гораздо лаконичней и что главное - поощряет разбиение алгоритма программы на крошечные, в несколько строчек процедуры, делая её логику более очевидной

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

    вывод типов - свойство всех языков-наследников ML (т.е. практически всех используемых нынче ФП языков со статистической типизацией - sml,ocaml,f#,haskell,clean,mercury) и в последнее время он стал заимствоваться императивными языками - C# 3.0 поддерживает его на локальном уровне. вывод типов однако несовместим (или плохо совместим) с наследованием в стиле ООП, неограниченной перегрузкой имён, автоматическими преобразованиями типов - вместо них в хаскеле используются type classes, а все преобразования типов (скажем, Int->Double) делаются только вручную: нельзя написать i+d, только (fromIntegral i)+d

    ml-derived языки поддерживают объявления типов - можно описать тип функции, можно вообще "заказать" тип любого выражения :)  при отсутствии же этих объявлений будет выведен наиболее общий тип, соответсвующий использованным операциям. к примеру, мы можем определить тип fac явно:

    fac :: Integer -> Integer

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

    double (x::Int) = 2*x

    компилятор сообразит, что тип результата тоже x, и выведет объявление double как

    double :: Int -> Int

    если же типов не задавать, то в обоих случаях компилятор автоматом определит, что тип результата совпадае с типом аргумента, и что аргумент должен принадлежать классу чисел Num (то есть быть Int, Integer, Double, Int64 или что-то ещё из этой серии). если автоматом выведенный тип записать явно, то он будет выглядеть как

    fac :: Num a =>  a -> a

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

    qsort :: Ord a =>  [a] -> [a]
    qsort [] = []
    qsort (x:xs) = qsort lesser ++ [x] ++ qsort greater
      where (lesser, greater) = partition (<x) xs

    типы внутренних величин lesser, greater и анонимной функции (<x) при этом не указываются. опять же подчеркну, что этот явно запсианный тип в точности соответсвует тому, что был бы выведен автоматически. хотя при желании можно сделать фукнцию менее generic, задав явный тип элментов списка:

    qsort :: [String] -> [String]



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

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

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


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


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

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

    Это не "мусор", это избыточность, требующаяся для читабельности и большей надежности. В технике избыточность, дублирование является одним из средств повышения надежности.
    Да, язык должен заставлять программиста явно дублировать информацию, например, о типе, т.к. это оберегает во многих случаях от трудноуловимых ошибок. Про нестрогую типизацию с неявными преобразованиями вообще молчу, но даже автовывод типов - не особо нужное, но опасное "умничанье" компилятора. Автоконтроль лучше автовывода...
    И еще - большую часть времени программист "серьезных" областей проводит за чтением кода - своего и чужого (в отличие от массового программиста, который, перефразируя студенческую присказку, на "три З": "з"делал,"з"дал",забыл), поэтому избыточность просто необходима.
    Она, межлду прочим, именно что позволяет не комментировать каждую строку кода.
    Мне пришлось и приходится очень много копаться в чужом коде на Обероне ("нутро" Блэкбокса) - швейцарцы комментировали код очень-очень скупо. Однако при этом, из-за однозначности и простоты языка и наглядности синтаксиса, я ни на каком другом языке не читал код так легко..
    Даже на других паскалеподобных. В той же Дельфе язык более "размазанный" и нет единого стандарта на запись/оформление кода. В Обероне код оформляется унифицированно, т.е. индивидуальным "закидонам" программиста там просто негде развернуться, индивидуальный стиль оформления практически отсутствует как явление...


    № 2223   25-03-2007 06:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2222« (info21)
    ___________________________

    Ответ на »сообщение 2200« (Сергей Перовский)
    ___________________________

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

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


    пожалуйста иллюстрируйте, иначе это читается как hype и ничего больше. точно так же, как если я скажу что хаскелл - сверх-высокоуровневый язык и не покажу никаких примеров. вы поверите? ;)


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


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

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

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

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

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

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