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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2622—2613 | 2612—2603 | 2602—2593 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 290


    № 2612   04-04-2007 08:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2593« (Руслан Богатырев)
    ___________________________

    Чтобы не затерялась в дискуссии важная вещь, хочу на нее обратить особое внимание оппонентов.

    Для ФП, IMHO, интенсивная работа с динамическими структурами -- достоинство. Но они же являются и его недостатком (узким местом). Следовательно, для выбора приемлемости ФЯ к решению конкретной задачи, где подразумевается активная работа с динамическими структурами, необходимо иметь инструмент анализа (оценки/прогноза) "прожорливости" ресурсов. Было бы интересно узнать, какими возможностями располагает программист, приподнятый ФП над реальностью железа, для адекватной оценки и прогноза "просадки" -- возможностей масштабирования задачи. Нет ничего хуже, чем получив быстро красивый результат и пустив его в дело через некоторое время выяснить, что при м асштабировании просадка станет таковой, что потребует кардинальной переработки. "Автопилот" ФП в этом плане не может не настораживать. Или мои опасения напрасны?

    Когда грамотный программист работает на ИП (Delphi, Оберон, КП), он в состоянии понять, во что превратится его текст после трансляции (как будет отображен на железо и где появяться точки "просадки"). Для ФП (из-за оторванности от императива и конкретики железа) этот момент затруднителен. Понимаю, что можно заниматься дизассемблированием и анализировать схему работы транслятора, но сомневаюсь, что этим озадачиваются даже грамотные ФП-программисты.

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



    № 2611   04-04-2007 08:36 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2610« (Geniepro)
    ___________________________


    Вам обязательно нужен строгий квалифицирующий импорт? Пожалуйста

    Он не мне нужен, а Вам нужен, если предполагаете использование строго стиля программирования, а также отчуждать свое творение (пресловутое readability и clearity). Без qualified-импорта нельзя локализовать точки импорта сущностей (надо знать, что было в импортируемом модуле -- иметь к нему доступ или документацию, которая имеет тенденцию рассинхронизироваться с действительностью). Хочу обратить Ваше внимание, что неквалифицирующий импорт в Хаскеле сделан не как в Модуле-2 -- в Модуле-2 явно прямо в списке импорта (т.е. у нас перед глазами) перечисляются импортируемые идентификаторы, а в Хаскеле -- только имя импортируемого модуля. Это худший вариант. То, что он в этом языке сосуществует с лучшим вариантом -- квалифицирующим импортом -- дает возможность выбора (чего давать нельзя). И Вы, разумеется, выбрали худший, поскольку руководствовались "Бейсик-критерием" вместо надежности и сопровождаемости. Экономия на использовании лишних "буковок" -- IMHO, Бейсик-мания. Об уроках Оберона я не зря говорил. Делайте выводы, учитесь на чужом опыте тех, кто на этом не одну собаку съел, а не отмахивайтесь, как от назойливой мухи. Уж слава Богу, в сфере нюансов модульного программирования Вирт и его коллеги дадут 100 очков вперед Хаскель-сообществу.

    Как видите, это вполне возможно в Хаскелле.

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

    Впрочем, вопрос вкусов и приоритетов...

    Не уверен, что строгость программирования -- дело вкуса. Это больше напоминает принцип "и так сойдет".


    № 2610   04-04-2007 08:02 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2604« (Руслан Богатырев)
    ___________________________

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

    Вам обязательно нужен строгий квалифицирующий импорт? Пожалуйста:

    module ACM_2007_A where

    import qualified IO
    import qualified List

    {-------------------------------------------------------------------------------
    --                    Гр.кр.  Гр.кр.  Гр.кр.
    --                    родит.  родит.  ребёнка
    -}

    type TestCaseStr    = (String, String, String)
    type TestCaseResult = (SetABO, SetABO, SetABO)

    type SetABO        = [String]

    --------------------------------------------------------------------------------

    main = do
        fileIn          <- IO.openFile "blood.in" IO.ReadMode
        contents        <- IO.hGetContents fileIn
        putTestCases $ process $ parse $ lines contents
        IO.hClose fileIn
    ...
    ...
    ...                               


    Как видите, это вполне возможно в Хаскелле.

    Вот только это создаёт лишнюю писанину и код может выглядеть весьма неестественно и некрасиво. Например:

    module Complex_Test where

    import qualified Array
    import qualified Complex

    main = do let n = 1.0 Complex.:+ 2.0
                  m = 5.0 Complex.:+ (-12.3)
              print (m / n)
              print (fib 1000)

    fib n = fa Array.! n
      where
        fa = Array.array (1,n) ([(1, 1), (2, 1)] ++
                                [(i, fa Array.! (i-2) + fa Array.! (i-1)) | i <- [3..n]])

    вместо аналогичного

    module Complex_Test where

    import Array
    import Complex

    main = do let n = 1.0 :+ 2.0
                  m = 5.0 :+ (-12.3)
              print (m / n)
              print (fib 1000)

    fib n = fa ! n
      where
        fa = array (1,n) ([(1, 1), (2, 1)] ++
                          [(i, fa ! (i-2) + fa ! (i-1)) | i <- [3..n]])


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

    Впрочем, вопрос вкусов и приоритетов...


    № 2609   04-04-2007 08:00 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2602« (Trurl)
    Ответ на »сообщение 2603« (Trurl)
    Ответ на »сообщение 2606« (Geniepro)

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

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


    № 2608   04-04-2007 07:40 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2606« (Geniepro)
    ___________________________

    ЗЫ. А если сделать Оберон-систему целиком в машинных кодах, то она будет гораздо эффективнее, чем на Обероне. И почему большинству людей такая идея кажется бредом?

    Простите за нескромный вопрос, а Вы в этом плане себя причисляете к большинству или к меньшинству?


    № 2607   04-04-2007 07:34 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2605« (Geniepro)
    ___________________________

    Вот Руслан Богатырёв уже несколько лет предлагает российскому сообществу блэкбоксёров вставить в Блэкбокс компилятор первого Оберона. Но почему-то эта идея никого, кроме него, так и не заинтересовала, хотя казалось бы - чего уж сложного взять несколько модулей из ETH-Oberon, чуть-чуть их подшаманить - и вуаля! Ан нет...

    Здесь возникают определенные проблемы. Сам по себе компилятор классического Оберона там есть (или уже был?), поэтому, строго говоря, нужно его лишь обустроить: дать удобный доступ и решить задачу сосуществования двух языков Оберона и КП в рамках одной среды BlackBox (она не только инструментальная, но и одновременно расширяемо-исполняющая). Нжна унификация общения по базовым типам данных (они рассинхронизированы), стандартная библиотека. Сама по себе задача не сверхсложная, но нет мотивации. Нет практической задачи (где востребовалась бы связка Оберон-КП), которая бы инициировала такую работу. Если бы она была (равно как и мотивированные исполнители -- было бы замечательно, Вирт время от времени интересуется, есть ли подвижки в направлении стандартной библиотеки...).

    В КП можно работать на уровне классического Оберона, при этом опускаться на бесклассово-шинный уровень или подниматься на уровень модификаторов ООП (для придания большей жесткости ОО-конструкциям). На мой взгляд, гораздо акутальнее сейчас задача легко отчуждаемых практических программ/систем-примеров (совсем даже не компонент), которые полезны потребителям как с точки зрения функционала, так и использования для "клепания" собственных вещей (и изучения Оберон-технологий). Подача этого с подробным разъяснением (почти как Вы Geniepro делали, разжевывая свое решение на Хаскеле). В этом большая ценность -- открытый продуманный код, открытая документация, возможность расширять или преобразовывать путем "клепания" расширенных клонов.


    № 2606   04-04-2007 07:26 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2597« (Рэйлвэй Каген)
    ___________________________

    Прошу прощения за overload, но я имел ввиду

    "написать компилятор, используя только конструкции соответствующего языка, без ассемблерных вставок и т.п."

    Иначе теряется чистота эксперимента.

    А скажите пожалуйста, считается ли экспериментально чистым вставка машинных команд (даже не ассемблерных вставок, а именно машинных кодов!) в исходники компиляторов таких Оберон-систем, как ETH-Oberon и BlackBox?

    ЗЫ. А если сделать Оберон-систему целиком в машинных кодах, то она будет гораздо эффективнее, чем на Обероне. И почему большинству людей такая идея кажется бредом?


    № 2605   04-04-2007 07:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2588« (RBV)
    ___________________________

    Дежурная задачка: реализуйте на Хаскеле загрузчик модулей Оберона в память для Линукса.

    Большое спасибо за интересную идею. Только ответьте, пожалуйста, на один вопрос.

    Вот Руслан Богатырёв уже несколько лет предлагает российскому сообществу блэкбоксёров вставить в Блэкбокс компилятор первого Оберона. Но почему-то эта идея никого, кроме него, так и не заинтересовала, хотя казалось бы - чего уж сложного взять несколько модулей из ETH-Oberon, чуть-чуть их подшаманить - и вуаля! Ан нет...

    Так вот, вопрос: Почему Вы думаете, что создание транслятора Оберона или хотя бы загрузчика его модулей может заинтересовать необеронщиков, если это неинтересно даже оберонщикам?


    № 2604   04-04-2007 07:05 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2559« (Jack Of Shadows)
    ___________________________

    Совсем нетяжело обьяснить. Правда видимо тяжело на это обращать внимание: »сообщение 2512« »сообщение 2514« Это только последние. До этого тоже самое говорил GeniePro и я.

    Раз некоторые сторонники ФП ограничиваются общими словами вместо анализа-сравнения, то предпочту сильно не углубляться в детали. Напомню, две с лишним недели назад я предложил взяться за сравнение подходов-языков на примере пробного камня (задач из набора финала последнего чемпионата мира ACM по программированию) -- http://www.delphikingdom.com/asp/talktopic.asp?ID=368&ref=msg&msg=3271#msg3271

    Была выбрана первая задача (кстати, одна из самых простых).

    Итак, Евгений (Geniepro) представил решение на Хаскеле с подробным описанием: http://geniepro.livejournal.com/1174.html
    Илья Ермаков вслед за этим дал свой вариант на Компонентном Паскале: http://forum.oberoncore.ru/viewtopic.php?t=409
    VPrin представил вариант на Delphi (отобразив готовое решение на Хаскеле): »сообщение 2243«
    Trurl предложил два собственных варианта: на SETL  -- »сообщение 2539« и на J? -- »сообщение 2309«

    Последние два, как я понимаю, для иллюстрации того, что есть решение крайне компактное по записи и даже на императивном языке (SETL).

    Напомню, что предлагал провести качественное сравнение (подсчет строк и быстродействие оставить за скобками):
    A. Выделить алгоритмическую часть кода, отвечающего за функционал решения (без UI-ввода-вывода и инфраструктурной обвязки)
    B. Выделить UI (ввод-вывод)
    C. Выделить инфраструктурную обвязку (если есть, как-то: спецификации модуля, экспорт-импорт и т.д. и т.п., что поддерживает существование алгоритма в пространстве ОС).

    Пойду с конца.

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

    В отношении части B: на примере Хаскеля хорошо видно, что импорт IO не показывает точки использования импортируемых сущностей внутри исходного текста (типичная ситуация в случае т.н. неквалифицирующего импорта). В Обероне от неквалифицирующего импорта Вирт после Модулы-2 отказался (в том числе по этой причине). Локализовать области использования ввода-вывода (интерфейс с внешним миром) в Хаскеле для меня было затруднительно (возможно, излишне субъективно). В КП они легко локализуются поиском модульных префиксов (In. и Out.). При этом, правда, в частном решении происходит смешение работы со строками с вводом-выводом (что может, правда, вполне оправдываться на понятийном уровне).  Справедливости ради следует сказать, что в Хаскеле поддерживается дуальность квалифицирующего и неквалифицирующего импорта (по образу и подобию Модулы-2), но то, что средством qualified не воспользовался Geniepro, лишний раз говорит о недооценке такой возможности (ложный стереотип относительно того, что это всего лишь косметическое средство борьбы с конфликтом имен). Уроки и опыт Оберона стоит извлекать. Ахиллесовой пятой в отношении части B для КП является работа со строками, что, кстати, Илья сразу отметил (она занимает больше половины исходного текста). Напрашивается вывод: либо выносить это за скобки (в отдельный модуль, дабы не нарушать целостности восприятия решения), либо даже иметь часть этих средств в штатной библиотеке.

    В отношении алгоритмической части (A): задача по своей сути -- задача на преобразование (а не на конструирование/моделирование), поэтому "лобовой" подход через функции/отображения/проекции работает практически без проблем. Как показывает решение на Delphi ("калька" с решения на Хаскеле), идущее от использования функционального подхода, за небольшими моментами нет технических сложностей для Delphi (а, значит, и для КП). В варианте с КП был выбран самостоятельный путь (тоже через отображения), но он оказался в невыгодном свете ("придавлен" работой со строками и детализацией циклической обработки). Компонентный Паскаль практически работал на уровне классического Оберона (разве что кроме конкатенации строк). А точнее даже, в невыгодных для себя условиях -- на уровне едва ли не классического Паскаля образца 1972 г.  Что для задачи на преобразование да еще такого масштаба -- ожидаемая вещь.

    Если говорить не о языке, а о сопоставлении подходов в рамках конкретных языков реализации, то следует обратить внимание, что в Хаскеле использовались императивные вещи (do и монады). По словам Р.В.Душкина, "монада является наиболее сложным концептом для понимания, который только есть в языке Haskell". Они в ФП служат окном в императивный мир. Это типы-контейнеры, "которые связывают внутри себя определенные объекты заданных типов для выполнения над ними операций, в которых могут содержаться побочные эффекты, недетерминизм и прочие неприятные для функционального стиля аспекты программирования".

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

    P.S. На мой взгляд, задача достаточно хорошо ложится на конечные автоматы (со всеми вытекающими последствиями по компактности, в ущерб определенной наглядности). Но это детали.


    № 2603   04-04-2007 07:04 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2598« (Trurl)
    ___________________________
    >>>К тому же реально рантайм все равно будет на си.
    Можно предложить и чистую реализацию.

    runtime=[0x55,0x8B,0xEC...]


    или такой вариант

    newBlock = asmdo
      push  EBP
      mov  EBP ESP
      sub  ESP 12
      ...




    <<<... | 2622—2613 | 2612—2603 | 2602—2593 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 290


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

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

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

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

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

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