| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 4182 25-02-2008 14:51 |   |
Ответ на »сообщение 4181« (Jack Of Shadows)
___________________________
Самым эффективным способом улучшения качества и скорости обучения оказались не типы (статическая типизация/ динамическая типизация), не парадигма программирования (императивное/функциональное), а значимые отступы!!!
На заметку всем проталкивающим программирование в школы.
Ерунда какая-то. Ну отступы и отступы. Сама собой разумеющаяся вещь. За которую бьют линейкой по рукам умные преподаватели всегда. (А в некоторых учебных средах советских их вообще среда принудительно ставила, т.к. конструкции вводились целиком, как единый каркас).
Если это даёт "самое эффективное улучшение качества и скорости...", то вопрос в том, чему учат. Непохоже, что самым главным вещам. Т.к. понимание самых главных вещей отдельно взятым формальным аспектом не привьёшь.
Например, те же самые отступы должны быть не просто автоматом вдолблены, а отрефлексированы как следствие более важных принципов, которых следует придерживаться в работе. И вот как именно учить этим принципам - пока большой и большой вопрос, к которому только подбираются лучшие педагоги... (Нужно ещё учитывать, что отрефлексировать учащиеся могут только отталкиваясь от конкретного опыта).
| № 4181 25-02-2008 14:11 | |
http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html
Интересная статья от профессора Окасаки (автор великолепной книги Purely functional data types).
Он преподает программирование в университете. И делится интересными наблюдением.
Самым эффективным способом улучшения качества и скорости обучения оказались не типы (статическая типизация/ динамическая типизация), не парадигма программирования (императивное/функциональное), а значимые отступы!!!
"My experience with this aspect of the language has been so overwhelmingly positive that I will never again voluntarily use a language without mandatory indentation for teaching novice programmers"
На заметку всем проталкивающим программирование в школы.
| № 4180 Удалено модератором | |
| № 4179 23-02-2008 13:35 | |
Когда императивщики говорят что функциональные языки плохо подходят для написания динамичных графических программ с большим количеством состояния, я обычно привожу в пример компанию Naughty dogs, которая делала классные игры для Sony Playstation на лиспе. Игры были настолько хороши что их потом купила сама Sony.
Так вот после скупки, мужики лисп не забросили. Их последняя игра Uncharted: Drake's Fortune тоже написана на лиспе (вернее scheme). Причем для нового PS3 они пустились во все тяжкие и написали scheme сами.
Так что подходит или не подходит ФЯ для какого то типа программ наверное зависит от того как вас научили мыслить.
| № 4178 22-02-2008 17:16 | |
http://www.theregister.co.uk/2007/08/21/sun_transactional_memory_rock/
Sun встраивает Transactional Memory в свой новый многоядерный процессор.
Делается это понятное дело для того чтобы написание многопоточного кода (и следовательно и задействование всех этих ядер) стало легким для программистов.
Думаю что Intel с ответом тоже не задержится.
Индустрия то двигается в одном направлении. Ядра множатся как грибы после дождя, а спроса на них особого нет, поскольку задействовать эту мощь могут в лучшем случае один программист из тысячи.
Вот господа и засуетились :))
Понятное дело что и язык должен поддерживать STM чтобы воспользоваться новыми аппаратными возможностями.
Ну в ФЯ с этим как раз таки все в порядке.
| № 4177 18-02-2008 14:01 | |
Ответ на »сообщение 4176« (Lisp Hobbyist)
___________________________
Я согласен. Сам до сих пор не использую измененные reader, хотя библиотеки, в которых есть такие рюшки, использую (clsql).
Но вот для curly собираюсь сделать исключение.
Работаю на лиспе я в одиночку. Набор библиотек у меня уже устоялся, так что проблем думаю у меня не будет.
| № 4176 18-02-2008 09:50 | |
Ответ на »сообщение 4174« (Jack Of Shadows)
___________________________
Программистам одиночкам как то еще все равно.
Им тоже важно, какие библиотеки они могут задействовать для решения своих задач без "доработки напильником".
С другой стороны все эти библиотеки имеют функции включения-выключения синтаксиса.
То есть enable-curly-syntax в одном файле, и enable-sql-syntax в другом.
Да. Но это "костыли". Во-первых, не так уж и редко, что функциональность двух библиотек может понадобиться в одном файле (особенно таких, которые реализуют разные взаимно дополняющие ФП-инструменты). А во-вторых, разве управление reader'ом на уровне файла не затрудняет интерактивность? Тот же Emacs умеет переключать активный пакет при переопределении функций из редактора, а вот есть ли в нем автоматическая активизация нужного синтаксиса?
IMHO, выходит, что надежнее не гнаться за "рюшечками", а следовать традиционному синтаксису, с именованными макросами и унифицированным представлением всего кода S-выражениями. К сожалению, даже в ANSI CL это не так (loop). Почему --- не знаю.
| № 4175 18-02-2008 06:08 | |
Небольшое лирическое отступление.
Избавляя разум от всей ненужной работы, хорошая нотация позволяет сосредоточиться на более сложных проблемах и в конечном счете повышает интеллект человечества. До появления арабской нотации умножение было
весьма сложным, а деление даже целых чисел требовало усилий ведущих математиков. Возможно, ничто в современном мире не смогло бы удивить греческого математика сильнее, чем то, что большинство европейцев умеют делить крупные числа. Это показалось бы ему абсолютно невозможным... Легкость выполнения операций над десятичными дробями — почти сверхъестественный результат постепенного обнаружения отличной нотации.
Альфред Норт Уайтхед (Alfred North Wbitehead)
| № 4174 18-02-2008 03:35 | |
Ответ на »сообщение 4173« (Lisp Hobbyist)
___________________________
подерутся за соответствующий reader macro.
Да, с переопределением reader надо быть поосторожнее. Программистам одиночкам как то еще все равно. А вот в командах могут выйти недоразумения.
Да и квадратные скобки использует еще ка минимум одна библиотека - clsql. Для записи sql select statements.
С другой стороны все эти библиотеки имеют функции включения-выключения синтаксиса.
То есть enable-curly-syntax в одном файле, и enable-sql-syntax в другом.
| № 4173 18-02-2008 03:10 | |
Ответ на »сообщение 4172« (Jack Of Shadows)
___________________________
Вот она сила лиспа! Все что угодно можно играючи реализовать, не ожидая годами когда комитет сподобится что то добавить в язык.
Никто не спорит, что "Lisp is a programmable programming language", но и у комитетов есть свои положительные стороны. IMHO, как раз наличие объемистого комитетского стандарта ANSI CL сыграло важную роль в его промышленном применении. Написать свое расширение Лиспа куда легче, чем обеспечить его интеграцию с другими такими же расширениями. Собственно, Curly и служит отличным примером, что может произойти. Если мне не изменяет память, в этой ветке когда-то упоминалась другая библиотека, реализующая list comprehensions, которая тоже переопределяет символы [...]. Скорее всего, попытка использовать две эти разработки в рамках одного файла приведет к тому, что они подерутся за соответствующий reader macro. Эта проблема решается, причем не слишком сложно, но все же может доставить определенные неудобства. А задача комитета и состоит в том, чтобы взять достаточно широкий спектр таких частных решений, собрать из них что-то целостное и зафиксировать спецификации результата со всеми нюансами. Не будь комитета по стандартизации CL, его бы скорее всего ждала судьба Scheme --- языка скорее исследовательского и учебного. Спору нет, написать свой собственный ОО-каркас интереснее, чем изучать глубины CLOS. Но интегрировать между собой компоненты, реализованные каждый на собственной ОО-прослойке... "Академикам" --- тоже интересно, а вот "производственникам" как-то не очень.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
