| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 2552 03-04-2007 07:53 |   |
Ответ на »сообщение 2550« (Geniepro)
___________________________
>>>Вот только почему-то богатства друг друга противоположным сторонам кажутся исключительно синтаксическим сахаром, от которого лишь один рак точки с запятой... :о(
Разве это так?
Просто оберонщики различают "движок" и "сахарок". :)
Поэтому и спрашиваем все время, в чем заключается собственно ФП, и не удовлетворяемся ответом "см. Хаскель".
А тем временем потихоньку все-таки "грызем гранит": Илья Ермаков интересуется Хаскелем, мне легче дается Схема...
| № 2551 03-04-2007 07:47 | |
Ответ на »сообщение 2536« (Geniepro)
___________________________
Оставшимя нескольким процентам изучать Хаскелл будет ничуть не труднее, чем Оберон, а даже легче, потому что поинтереснее. Правда, ещё интереснее С++, но уже, увы, не легче... :о)
Хм... а почему C++ еще интереснее?
Как-то не вижу логики...
| № 2550 03-04-2007 07:43 | |
Ответ на »сообщение 2547« (Руслан Богатырев)
___________________________
Вот мы и пытаемся совместными усилиями разобраться в том, кто чем богат.
Вот только почему-то богатства друг друга противоположным сторонам кажутся исключительно синтаксическим сахаром, от которого лишь один рак точки с запятой... :о(
| № 2549 03-04-2007 07:35 | |
Ответ на »сообщение 2548« (Geniepro)
___________________________
ЗЫ. Неужели Вам эзотерический код на Форте кажется более понятным и читабельным, чем на строго математически выверенном рафинированном Хаскелле?
Дело даже не в коде. Форт заставляет думать о низкоурованевых сущностях - стеке, адресах и прочих устройствах виртуальной машины.
| № 2548 03-04-2007 07:22 | |
Ответ на »сообщение 2544« (Руслан Богатырев)
___________________________
И в смысле эффективности по быстродействию и памяти? Лисп в этом плане может конкурировать с Фортом? Очень сомнительно.
Насчёт памяти спорить, пожалуй не буду, хотя лично мне игры с двумя стеками не кажутся удобными для работы с памятью...
Насчёт быстродействия. Случаи, когда шитый код оказывается на специально подобранных тестах быстрее чистого машинного, конечно, есть, но они исключительно редки. В основном программы на форте работают заметно медленнее, чем на тех же Си или Фортране, и только у лучших Форт-трансляторов код приближается к Си.
Во времена PDP-11 компиляторы Лиспа показали, что по крайней мере для научных расчётных программ могут генерировать код более эффективный, чем (тогдашние) трансляторы Фортрана. Да и сейчас есть трансляторы Лиспа, генерирующие код, сравнимый по быстродействию с кодом у трансляторов Си.
Так почему же Лисп не может конкурировать по быстродействию с ничуть не менее заторможенным Фортом?
ЗЫ. Неужели Вам эзотерический код на Форте кажется более понятным и читабельным, чем на строго математически выверенном рафинированном Хаскелле?
| № 2547 03-04-2007 07:17 | |
Ответ на »сообщение 2546« (Lisp Hobbyist)
___________________________
Меня же они наводят на грустные мысли о том, как ничтожна вся эта дискуссия, full of sounds and fury, signifying nothing.
Думаю, Вы немного лукавите. Вряд ли бы решились высказать эти слова в ничтожной дискуссии. Значит, определенный смысл и польза в ней все же есть.
О вкусах не спорят, но ИМХО Lisp таки летал, причем на штуках посерьезнее пионерских авиамоделек.
Безусловно летал, но, согласитесь, если хотите быть до конца корректным, Лисп на нелисповой архитектуре (которые мы все у себя имеем) вряд ли способен конкурировать с теми средствами, которые под эту мейнстрим-архитектуру заточены. Приходится подстилку класть. Увы-увы.
Важны не инструменты, а польза, которую принесет обществу ПО, разработанное с их помощью. По этому "гамбургскому счету" мейнстрим-языки пока что вне конкуренции
Нельзя не согласиться, что польза обществу важнее, только приносят ли ее мейнстрим-языки? Тут согласиться не могу. Проблем на годы вперед создают больше, чем пользы.
"альтернативщики" всех мастей, вместо того, чтобы помочь друг другу (и мейнстриму --- почему бы и нет?) раскрыть свои лучшие стороны, наперебой соревнуются в том, кто найдет более изощренные способы высмеять недостатки оппонента, не замечая при этом, что слишком часто пытаясь унизить других, вы зачастую унижаете только себя, демонстрируя не столько остроумие, сколько невежество.
Есть такое дело. Только было бы неплохо, если бы Вы не обобщали, не чесали всех под одну гребенку, а выделяли мысли, направленные на единение "альтернативщиков", а не размежевание. Они здесь высказывались, и не одним-двумя людьми. Кстати, насчет альтернативщиков. Странная, однако, картина: Хаскель назвать языком в загоне ну никак язык не поворачивается (в отличие от тех же Оберонов). Раскручивают его по полной программе. Так что тут среди альтернативщиков неплохо бы выделять "неформалов" и "маргиналов". При этом Оберон причисляют к ИП (магистральному направлению), а Хаскель -- к ФП (периферийно-побочному, так сказать). Вот мы и пытаемся совместными усилиями разобраться в том, кто чем богат. И кто бы что ни говорил, польза от такого разговора (если смотреть не на форму, а на содержание) все же имеется.
| № 2546 03-04-2007 06:20 | |
Ответ на »сообщение 2544« (Руслан Богатырев)
___________________________
Ответ на »сообщение 2543« (ДД)
___________________________
Например, реализация Лиспа просто идеально на такую систему исполнения...
И в смысле эффективности по быстродействию и памяти? Лисп в этом плане может конкурировать с Фортом? Очень сомнительно. "Рожденный ползать, летать не может".
А еще говорят: "тише едешь --- дальше будешь".
http://groups.google.com/group/comp.lang.lisp/msg/d1f23fa9a395e84e?dmode=source&hl=en
In 1994 I used Lisp to produce a code patch for an instrument on the Galileo spacecraft in orbit around Jupiter. The instrument (a magnetometer) was programmed in Forth, and had developed a bad memory byte (out of a total 4k bytes of memory). It was estimated that to patch the Forth code (which is notoriously difficult to maintain) would take so long that it was not feasable. I wrote a customized Forth development environment in Lisp that was used to produce a code patch. The total time it took to produce the development environment and the code patch was three months. (The resulting patch is flying today. It's the only thing this development environment was ever used for.)
И далее:
From 1995 to about 1998 I was part of a team using Lisp to program an autonomous spacecraft (a project called Remote Agent which flew on a spacecraft called DS1). At one point part of the team tried to re-implement their part of the software in C++. After a year the effort was declared a failure and they went back to Lisp.
О вкусах не спорят, но ИМХО Lisp таки летал, причем на штуках посерьезнее пионерских авиамоделек.
И еще так, информация к размышлению, на чем пишут в космической промышленности (конкретно, речь шла о Mars Rover в тот самый момент, когда ему стало плоховато, и народ в c.l.l жаждал инсайдерских подробностей о причине проблем).
http://groups.google.com/group/comp.lang.lisp/msg/a630d3b87686066e?dmode=source&hl=en
The flight software is all written in C running on vxWorks.
The ground software is a mishmash of C, C++, Fortran, Perl and Java (and maybe a few other things.)
The other day in the hallway I heard a MER team member who had worked on some of the C++ ground software say, "I wish we were using Lisp." I had to leave the conversation at that point to avoid having a Howard Dean moment.
В приведенных выше отрывках каждый, скорее всего, увидит то, что он априори хочет увидеть. Кто-то в очередной раз позлорадствует, что отступники от единственно верного пути были наказаны. Кто-то порадуется, что еще один человек задумался о переходе на Lisp. Меня же они наводят на грустные мысли о том, как ничтожна вся эта дискуссия, full of sounds and fury, signifying nothing. Важны не инструменты, а польза, которую принесет обществу ПО, разработанное с их помощью. По этому "гамбургскому счету" мейнстрим-языки пока что вне конкуренции, а "альтернативщики" всех мастей, вместо того, чтобы помочь друг другу (и мейнстриму --- почему бы и нет?) раскрыть свои лучшие стороны, наперебой соревнуются в том, кто найдет более изощренные способы высмеять недостатки оппонента, не замечая при этом, что слишком часто пытаясь унизить других, вы зачастую унижаете только себя, демонстрируя не столько остроумие, сколько невежество. Изрядная часть той аргументации, которая повторяется в этой ветке снова и снова, проистекает из элементарного отсутствия достаточного опыта применения подходов противоположной стороны, а то и просто информации о том, что делается в "другом лагере".
Как говорится, "о времена, о нравы!" :-(
| № 2545 03-04-2007 04:17 | |
Ответ на »сообщение 2543« (ДД)
___________________________
Например, реализация Лиспа просто идеально на такую систему исполнения...
... вот только и LMI, и (по непроверенным данным) Symbolics, свои новые поколения Лисп-машин сделали RISC-like (LMI --- со стеком фреймов РОН наподобие SPARC, насколько я знаю эту архитектуру), уйдя от чисто стековых решений (MIT CADR, из которой "росли ноги" их предыдущих архитектур).
Хотя, если бы они знали о работах Н.П. Брусенцова, стеки могли бы получить и "второе рождение"... Но история, как известно, "если бы" не терпит.
| № 2544 03-04-2007 03:50 | |
Ответ на »сообщение 2543« (ДД)
___________________________
Например, реализация Лиспа просто идеально на такую систему исполнения...
И в смысле эффективности по быстродействию и памяти? Лисп в этом плане может конкурировать с Фортом? Очень сомнительно. "Рожденный ползать, летать не может".
| № 2543 03-04-2007 03:48 | |
Ответ на »сообщение 2540« (Руслан Богатырев)
___________________________
Форт -- вообще почти идеальный, на мой взгляд, язык для реализации всевозможных исполняющих систем (run-time), поверх которых плавают высокоуровневые универсальные и проблемно-ориентированные языки.
Например, реализация Лиспа просто идеально на такую систему исполнения...
Если бы сейчас стояла, например, задача реализовать исполняющую систему для Пролога (та же абстрактная машина Уоррена, WAM), думаю, Форт был бы едва ли не лучшим выбором в качестве языка реализации.
Скорее всего, это не совсем вы так думаете, а - Таунсенд с Фохтом... :о)))
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
