| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 502 Удалено модератором | |
| № 501 24-07-2006 01:50 |   |
Недописал прошлый пост. Например, проверку корректности SQL при работе с конкретной базой данных.
| № 500 24-07-2006 01:48 | |
Препроцессорные макросы также можно разделить на активные и пассивные. Пассивные просто разворачиваются в неких программный текст, активные на этапе прекомпиляции могут выполнять кроме генерации текста и другие действия, например.
| № 499 24-07-2006 01:43 | |
Макросы, насколько я понимаю, могут быть 2 типов. Первые, препроцессорные, разворачиваются до этапа компиляции. Вторые – разворачиваются в run-time и далее происходит их run-time компиляция, или, если хотите интерпретация. Все-таки Jack of Shadows, если я правильно понял, говорил о препроцессорных макросах-функциях, которые могут выполнять активные действия в precompile time. То, что сделал я, конечно, не похоже на макросы Лиспа, но по классификации подпадает в эту же группу. Если я не прав – объясните, плиз.
| № 498 24-07-2006 00:47 | |
Кстати, о надоевших предложениях об "отдельных ветках".
SpeedTree - тулзовина, основанная на процедурной генерации
для построения деревьев и даже леса в автоматическом
режиме. На С++ опять:) Хотя я не фанат-геймер, но работал
с VRML для ГИС и утверждаю, что проблема с кустами и деревьями
актуальна и в бизнесе. Проработанность графики в SpeedTree вполне
современная и близкая к реалистичной - зависит, в основном,
от настроек, ну и возможностей компа.
Так вот, если эту самую генерацию использовать широко, то разница
между макросами (генерация не лету) и препроцессорами (генерация
заранее до запуска программы) не колоссальна, а даже принципиальна.
Так что не надо трогать яйца, независимо от того, какой конец Вы
предпочитаете - тупой или острый :)
| № 497 23-07-2006 22:25 | |
Разница между препроцессорами и макросами колоссальная.
Угу... и разница между разбиванием яйца с тупого конца и с острого тоже колоссальная :)
Нет, с религиозной точки зрения оно, может быть, конешно... но для меня, атеиста, как-то не видно разницы между вставкой кода одной программой (собственнон компилятором) или парой - связкой препроцессор+компилятор...
| № 496 23-07-2006 04:26 | |
Ответ на »сообщение 495« (Jack Of Shadows)
___________________________
Но если вас интересует мы попозже эту тему раскроем.
А я предлагаю вынести обсуждение макроязыков в отдельную ветку, потому что эта тема имеет весьма отдалённое отношение к ФП, как таковому.
И вообще, Jack, у меня сложилось впечатление, что Вы подменяете рассуждения о достоинствах и недостатках ФП рассуждениями о таковых в Лиспе (в котором, как мы уже поняли недостатков нет). Если есть желание продолжить разговор о Лиспе, то осмелюсь предложить делать это в отдельной ветке, а то у людей, зашедших на эту ветку может сложиться впечатление, что ФП -- это Лисп, а Лисп -- это ФП, что, в общем случае, не так.
| № 495 22-07-2006 16:01 | |
Ответ на »сообщение 494« (Артем)
___________________________
И, в конце концов, что тут такого трудного. Свой компилятор командной строки я вставлял в меню Tools,
Ну я так и знал. :)) Начинали с того что в дельфи макросы сделали, а выяснилось, что до дельфи, текст программы обрабатывает ваша программа.
Это не макросы, Артем, это препроцессор. Их полно, наиболее известные это это SQL/J и AspectJ
Разница между препроцессорами и макросами колоссальная.
У меня сейчас нет времени, надо бежать. Но если вас интересует мы попозже эту тему раскроем.
А пока что скажу вам что премия Тюринга за препроцессор вам не светит :))
| № 494 22-07-2006 15:38 | |
Ответ на »сообщение 493« (Jack Of Shadows)
___________________________
Если вы мудрились создать макросы для дельфи на самом дельфи то вам полагается премия Тьюринга :)) Этого даже создателям дельфи не удалось.
А они и не пытались. По причинам, о которых я говорил раньше. И, в конце концов, что тут такого трудного. Свой компилятор командной строки я вставлял в меню Tools, используя при этом встроенную макрокоманду $EXENAME для передачи моему макрокомпилятору имени проекта. Макрокомпиляция вызывалась мною перед компиляцией в случае добавления новых макровызовов или изменения самих макросов. Макрокомпилятор, использую стандартный компилятор Дельфи компилировал используемые макробиблиотеки в dll, после чего макрокомпилятором анализировались все pas-файлы проекта на предмет вхождения директив {$Include filename.inc funcName param1..}. Из нужных dll вызывалась нужная функция с нужными параметрами и возвращаемая строка писалась в нужный инклуд-файл. В принципе можно было автоматизировать процесс вызова прекомпилятора перед компиляцией с помощью OpenToolsAPI, но мне уже было лень это делать. Вот и все. Ничего особенного, за что надо давать премию Тьюринга я здесь не вижу. Если очень хотите, я могу выслать вам проект.
[Quoye]Скажем в CMUCL лиспе есть параметр компилятора -lazy который включает режим. А это во всех версиях Лиспа реализовано? – ведь их куча. И насчет стандарта Лиспа, как я слышал, тоже не все гладко. В Common Lisp такая возможность есть? Если уж на то пошло, если не трудно, ответьте, что все-таки лучше использовать с дотнет? L#, Scheme.net или что-то еще?
| № 493 22-07-2006 13:21 | |
Ответ на »сообщение 492« (Артем)
___________________________
Нет, она выполняется тоже precompile time. Я там не совсем полный вызов записал. Полный выглядит так:
{$Include myfile myMacroFunc param1 param2 …}
Артем, насколько я знаю макрос $Include вставляет текст из указанного файла, а не выполняет на этапе компиляции какую то функцию.
Если можно приведите полный код проекта, или выложите его куда нибудь.
Или обьясните что конкретно делает myMacroFunc и как это отражается на компиляции.
Если вы мудрились создать макросы для дельфи на самом дельфи то вам полагается премия Тьюринга :))
Этого даже создателям дельфи не удалось.
Так что я думаю мы с вами просто не понимаем друг друга. И вы говорите о чем то другом.
Не совсем похожа на нормальный SQL. Software Factories из ООП более гибки, и позволяют использовать метаязыки в любой форме.
Макросы в лиспе может писать даже новичек.
А Software Factories вешь чрезвычайно сложная в использовании, что будет ограничивать ее применение только немногими программистами.
Попробуйте, мало не покажется :))
Кстати, не из вредности, а по любопытсву. Если вам не трудно, приведите все-таки пример ленивого вычисления в Лиспе
Дык зависит от библиотеки или лиспа которую вы будете использовать.
Скажем в CMUCL лиспе есть параметр компилятора -lazy который включает режим. То есть в данном случае вы получите автоматически отложенные вычисления точно как в хаскеле.
А в других лиспах можно воспользоваться одной из библиотек.
В таком случае режим lazy включается / выключается макросами (delay ...)/(force ...)
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
