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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

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


    № 2602   04-04-2007 06:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2597« (Рэйлвэй Каген)
    ___________________________
    >>>"написать компилятор, используя только конструкции соответствующего языка, без ассемблерных вставок и т.п."

    А зачем компилятору ассемблерные вставки?


    № 2601   04-04-2007 06:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2590« (Jack Of Shadows)
    ___________________________

    Ответ на »сообщение 2588« (RBV)
    ___________________________
    Дежурная задачка: реализуйте на Хаскеле загрузчик модулей Оберона в память для Линукса
    А программу для бразильской АЭС вам не написать ? :)) Ну и запросы у народа. Ща все все бросют и кинутся для RBV загрузчик модулей Оберона в память для Линукса писать. Я плакаль :))


    А почему бы и нет?

    Спокойно, Джек. Я предложил оценить вполне реальную системную задачу.

    Кстати, программа для АЭС - это тоже интересно. :)


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

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

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

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


    А конструкции языка в ходы выполнения ведь чем-то поддерживаются, не так ли? Ран-таймом. Поэтому чистота языка для реализации будет мнимой. К тому же не стоит забывать про метод раскрутки (bootstrapping): вы берете сокращенную версию языка с активным участием чужеродных кодов, а потом итеративно наращиваете компилятор, внедряя новые конструкции (заливая их "эпоксидкой"). С формальной точки зрения -- чистота сохранена (в расширенном языке). А в действительности -- плавает на чужом.

    Думаю, Trurl, справедливо заметил относительно эффективности. Я разделяю эту точку зрения. Именно эффективности, а не потенциальной возможности.


    № 2599   04-04-2007 04:55 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2580« (Trurl)
    ___________________________

    Если интересно, язык называется SETL. Можно ли его назвать существующим - не знаю. Может быть правильнее - вымершим. Создан он был на рубеже 60-70-х и в свое время имел некоторую известность (в немалой степени благодаря тому, что на нем был написана первая "полноценная" реализация Ады). В СССР даже книга издана была "Язык сверхвысокого уровня СЕТЛ и его реализация".

    Ну не совсем вымершим. Он еще теплится в своей альма-матер -- Курантовском институте в Нью-Йорке, только в виде SETL2.

    Помнится, Дейкстра с некоторым скепсисом говорил о том, что русские непонятно зачем носятся с этим детищем профессора Шварца едва ли не как с писаной торбой. Насколько знаю, SETL (базирующий на работе со множествами) пришел с подачи А.П.Ершова (точнее даже, инициатором был А.А.Ляпунов -- учитель Ершова). Ершов разузнал про SETL (и пообщался со Шварцем) в ходе одного из своих визитов в Штаты. В отношении SETL Ершов и Дейкстра стояли на полярных позициях. Потом СЕТЛом занялась группа А.С.Нариньяни, точнее Д.Я.Левин с коллегами. Они реализовали ее сначала в ВЦ СО АН СССР в Новосибирске (на БЭСМ-6), а потом уже сменили дислокацию и в Российском НИИ искусственного интеллекта (который возглавляет А.С.Нариньяни, соратник А.П.Ершова и В.Е.Котова) создали несколько трансляторов для SETL (на базе проработанной ими абстрактной SETL-машины). Вполне вероятно, что в ряде проектов на уровне прототипирования/макетирования он в РосНИИ ИИ используется и поныне. Хотя внешних следов я там не встречал.

    Стоит отметить, что разработка системы программирования и компилятора для языка Little на БЭСМ-6 была выполнена Л.В.Городней (1976) -- самым известным в Союзе специалистом по ФП. Этот язык системного программирования, похожий на Fortran, но обрабатывающий произвольные коды и приспособленный к крупноблочной организации программ и данных, был предложен Дж. Шварцем как средство реализации эффективной системы программирования для языка SETL.

    SETL получил новый импульс развития у нас в ходе проекта МАРС (СТАРТ), в середине 1980-х годов (я о нем в свете Кроноса, транспьютеров и Модулы-2 здесь как-то рассказывал). И.В.Поттосин в конце 1990-х выделял наши реализации SETL и РЕФАЛ как хороший предмет для экспорта знаний-продуктов-технологий. Подробнее об истории SETL в нашей стране можно посмотреть в статье Давида Левина в музее Эдуарда Михайловича Пройдакова: http://www.computer-museum.ru/books/n_mozaika/setl.htm Она взята вот из этого сборника: http://www.iis.nsk.su/pottosin/40/win/title.htm

    P.S. Кстати, раз уж речь зашла о РосНИИ ИИ. В отчете американцев о поездке в Советский Союз в конце 1950-х годов был признан приоритет СССР в направлении автоматического перевода с естественного языка на другой (у нас были даже машинные словари и технологии для китайского и японского). Американцы до этого тогда не додумались (или руки не дошли).


    № 2598   04-04-2007 04:01 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2587« (Geniepro)
    ___________________________

    Haskell мало подходит для написания рантаймов.
    В принципе, написать можно. Например, сделать интерпретатор байт-кода. Но эффективность будет...
    К тому же реально рантайм все равно будет на си.


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


    Есть два отнюдь не праздных вопроса:
    1.можно ли написать компилятор Оберона на Хаскеле?
    2.можно ли написать компилятор Хаскела на Обероне?


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

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

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


    № 2596   04-04-2007 03:55 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2595« (Lisp Hobbyist)
    ___________________________

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

    Чтобы не было болтовни, нельзя ли ссылочку на сообщение, когда этот клуб ставил перед собой такую задачу?


    № 2595   04-04-2007 03:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2583« (AVC)
    ___________________________

    А здесь нам с непонятной гордостью предъявляют такую большую простыню. :)

    А чем не повод для гордости? Я, любитель, который никогда не занимался целенаправленной оптимизацией скорости своих Лисп-программ, имея бесплатную версию не самой лучшей Лисп-системы, потратил полчаса на чтение документации (CLHS + документация к LW) и еще примерно столько же на эксперименты, и в итоге смог ИМХО добиться заметного эффекта по крайней мере, в "визуальном качестве" сгенерированного кода. А клуб пикейных жилетов на страницах этого форума за полгода не удосужился разобраться в реальном соотношении "программа/рантайм" в современных Лисп-системах, предпочитая просто генерировать информационный шум.


    № 2594   04-04-2007 03:19 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2579« (Рэйлвэй Каген)
    ___________________________

    Есть два отнюдь не праздных вопроса:
    1.можно ли написать компилятор Оберона на Хаскеле?
    2.можно ли написать компилятор Хаскела на Обероне?


    Разумеется, можно. А с чем связаны сомнения? Реализация Хаскеля (как и любого другого языка) несет в себе "чистую", самостийную часть и "грязную", чужеродную часть. Эта чужеродная часть (ее фрагменты) может быть реализована на чем угодно (хоть в кодах процессора). Методом раскрутки можно получить псевдочистую вещь (где "грязь" осядет на самом донышке реализации).


    № 2593   04-04-2007 03:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2572« (Lisp Hobbyist)
    ___________________________

    А сейчас --- раскроем страшную тайну. :-)

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

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

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

    ИМХО, любые тесты производительности, кроме профилирования реальных программ в реальных условиях их эксплуатации --- это самообман.

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


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


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

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

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

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

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

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