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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 1522—1513 | 1512—1503 | 1502—1493 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 400


    № 1512   10-11-2006 02:53 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1510« (Jack Of Shadows)
    ___________________________
    зато есть eval


    № 1511   10-11-2006 02:47 Ответить на это сообщение Ответить на это сообщение с цитированием
    По моему тут кто то интересовался средствами отладки для хаскеля.
    Есть такие: http://haskell.org/hat/#intro
    Полноценный пошаговый дебаггер. Причем в отличии от императивных языков может шагать и НАЗАД! :))




    № 1510   10-11-2006 02:46 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1508« (Lisp Hobbyist)
    ___________________________
    Особенно хорошо на этапе компиляции ловится зацикливание вычисляемых ссылок, типа Excel'ного OFFSET...
    OFFSET это работа с относительной адресацией ячеек, это к си а не к лиспу :))
    лисп с адресами памяти не работает :)) По моему в нем даже указателей в сишном понимании этого слова, нет.




    № 1509   10-11-2006 02:43 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1507« (Lisp Hobbyist)
    ___________________________
    Вы правы я именно defsetf имел в виду. Хороший вопрос.
    Я попробую задать его Тилтону. Посмотрим что он думает по этому поводу.
    В любом случае как я уже говорил, полезность сеlls для простых типов (не обьектов) мне кажется сомнительной, и данный вопрос имеет чисто теоретическое а не практическое значение, в отличие от cells, который очень практичен в его нынешней реализации.


    № 1508   10-11-2006 02:08 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1504« (Jack Of Shadows)
    ___________________________

    Ну не совсем так. Не забывайте что лисп компилируемый язык, в отличие от Экселя :))
    Так что зацикливание ссылок легко ловится на этапе компиляции.


    Особенно хорошо на этапе компиляции ловится зацикливание вычисляемых ссылок, типа Excel'ного OFFSET...


    № 1507   10-11-2006 01:57 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1503« (Jack Of Shadows)
    ___________________________

    Переопределение setf это конечно не для новичков. Однако и невероятно трудного в этом ничего нет.
    Я встречал довольно много исповых библиотек в которых setf переопределяется.
    Более того при создании практически любого DSL вам скорее всего придется и setf для него переписывать.
    Так что ничего необычного или редко используемого. Однако техника конечно для тех кто значет что он делает. :))


    Расширение setf при помощи defsetf и переопределение его встроенных вариантов вообще-то две большие разницы. Я вообще сомневаюсь, что такое переопределение безопасно --- setf это все-таки макрос (со всеми вытекающими последствиями), хоть явного запрета в CLHS я пока не нашел (хоть и не особо искал).

    Зато там есть вот это:

    The effect of

    (defsetf symbol-value set)

    is built into the Common Lisp system. This causes the form (setf (symbol-value foo) fu) to expand into (set foo fu).

    Таким образом, если я ничего не напутал, перехватить присваивания вида (setf (symbol-value 'foo) 15) точно не получится. А без этого заявления о возможности надежного и прозрачного расширения подхода cells на произвольные переменные выглядят, мягко говоря, неубедительно.


    № 1506   10-11-2006 00:03 Ответить на это сообщение Ответить на это сообщение с цитированием
    Кстати, о реальных проектах на ФЯ.
    На Erlang написан Ejabberd - копроративный Jabber-сервер. Лицензия - GPL, так что можно спокойно изучать и дорабатывать.


    № 1505   09-11-2006 23:38 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1504« (Jack Of Shadows)
    ___________________________

    Вы это должны прекрасно знать по дельфишному VCL фреймворку. Там в принципе та же самая идея, только сделанная топорно, насколько возможности языка позволяли.
    Э... какие еще возможности языка? В Delphi вместо

    property Enabled: Boolean

    легко можно сказать

    TBooleanMethod = function(Sender: TObject): Boolean of object;
    //...
    property Boolean: TBooleanMethod;


    Язык позволяет реализовать такую библиотеку.


    № 1504   09-11-2006 17:41 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1500« (Сергей Перовский)
    ___________________________

    Кстати, идеология ( и название ) cells очень напоминает электронные таблицы.
    И проблемы те же - зацикливание ссылок, большие накладные расходы и т.д.

    Ну не совсем так. Не забывайте что лисп компилируемый язык, в отличие от Экселя :))
    Так что зацикливание ссылок легко ловится на этапе компиляции.
    А большие накладные расходы, слово большие здесь понятие относительное.
    Для оркестрации GUI-шных элементов не так уж и много накладных расходов.
    Вы это должны прекрасно знать по дельфишному VCL фреймворку. Там в принципе та же самая идея, только сделанная топорно, насколько возможности языка позволяли.
    И ниче, никто особенно на накладные расходы не жалуется :))


    № 1503   09-11-2006 15:48 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 1495« (Lisp Hobbyist)
    ___________________________
    Еще одна возможность сделать такой перехват --- переопределить макрос setf, но такого рода штуки крайне не рекомендуются стандартом и могут иметь трудноуловимые и далеко идущие последствия.


    Переопределение setf это конечно не для новичков. Однако и невероятно трудного в этом ничего нет.
    Я встречал довольно много исповых библиотек в которых setf переопределяется.
    Более того при создании практически любого DSL вам скорее всего придется и setf для него переписывать.
    Так что ничего необычного или редко используемого. Однако техника конечно для тех кто значет что он делает. :))



    <<<... | 1522—1513 | 1512—1503 | 1502—1493 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 400


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

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

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

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

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

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