| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 3032 02-10-2007 15:48 |   |
Ответ на »сообщение 3030« (Илья Ермаков)
___________________________
Простите но именно "кукольный театр" вы и получаете. В реальном мире у самолета нет метода "гравитация". Гравитация есть сила внешная по отношению к обьекту самолет. Сила глобальная. Функция, преобразующая данные. Весь мир состоит из громадного количества таких вот ВНЕШНИХ и ВЗАИМОПРОНИКАЮЩИХ связей, а не обьектов у которых все методы обработки акуратно так "пришпилены" к данным.
Парадигма на которой построена ООП - это игрушечная и неработающая "модель" в которую несчастные программисты вынуждены впихивать реальный мир. Да еще и без права на ошибку. Ведь даже поиграться с несколькими построенными моделями нельзя. На одну (самую первую и по определению неверную) уходит слишком много усилий и времени.
Короче мы уже об этом говорили.
Вы господа топчетесь на одном месте. Оттачиваете до блеска дедовский самурайский меч.
А ФП этот тот самый прогресс, автоматизация, который и выжил на пенсию всех этих самураев, могикан и ОО программистов :))
| № 3031 02-10-2007 15:35 | |
Ответ на »сообщение 3030« (Илья Ермаков)
___________________________
Т.е. вместо "кукольного театра", являющегося моделью задачи, хотят получить полную аналогию задачи, чтобы "всё так же и само..."
Продолжая аналогию: вместо кукольного театра (марионетки) сначала игрушечная железная дорога (локомотивы с автоматикой управления движением), а потом и свой настоящий театр, с живыми актерами, моделирующими сон и явь. :)
| № 3030 02-10-2007 15:27 | |
Ответ на »сообщение 3028« (Jack Of Shadows)
___________________________
Ответ на »сообщение 3027« (Руслан Богатырев)
___________________________
АТД - это декларация типов данных и операций над ними (что есть хорошо). ООП - это упаковка типов данных, методов их обработки, и хранилища состояния в единый обьект (что есть плохо).
Я для себя это "плохо" понимаю обычно так: вместо явного различения программы (технической системы) и данных (информации, обрабатываемой этой системой и перемещающейся по её каналам), в ООП стремятся получить "самодвижущуюся" информацию, которая полностью воспроизводит реальные объекты проблемной области. Т.е. вместо "кукольного театра", являющегося моделью задачи, хотят получить полную аналогию задачи, чтобы "всё так же и само..."
| № 3029 02-10-2007 15:19 | |
Ответ на »сообщение 3027« (Руслан Богатырев)
___________________________
>>> При всей верности критики излишнего восхваления ООП во имя извлечения прибыли (маркетинговая сторона медали) трудно согласиться с технологическими оценками Армстронга.
Как будто все дело именно в ООП (маркетинговая сторона)... Можно ООП заменить на ФП - статья совершенно не про это. Так как всегда были, есть и будут люди, готовые создать трудности, чтобы потом героически их решить (за определенное вознаграждение)... И проблема эта общесоциальная, а не только ИТ...
| № 3028 02-10-2007 14:51 | |
Ответ на »сообщение 3027« (Руслан Богатырев)
___________________________
Инкапсуляция суть идея абстрактных типов данных (АТД). До сего дня не утихают споры, что считать типом данных: только набор (однородных) сущностей или еще и набор операций над ними. АТД не стоит путать с ООП.
А он и не путает.
АТД - это декларация типов данных и операций над ними (что есть хорошо). ООП - это упаковка типов данных, методов их обработки, и хранилища состояния в единый обьект (что есть плохо). Уберите из этого контейнера состояние - и получите нормальный хаскелевский type classes или эрланговский process.
О том и речь Руслан. ФП пытается автоматизровать работу с состоянием в то время как ООП считает что достаточно состояние инкапсулировать в обьекты, и программирование станет легче. Практика показывает - не стало легче. Ручная работа она и есть ручная работа, в какую оболочку ее не упаковывай.
| № 3027 02-10-2007 14:26 | |
Ответ на »сообщение 3026« (Jack Of Shadows)
___________________________
Наверное надо именно так нелюбить ОО чтобы создать такой язык как Erlang :))
При всей верности критики излишнего восхваления ООП во имя извлечения прибыли (маркетинговая сторона медали) трудно согласиться с технологическими оценками Армстронга.
Особенно занятна фраза: Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.
Вообще говоря, это и есть инкапсуляция (которую многие смешивают с информационным сокрытием). Инкапсуляция суть идея абстрактных типов данных (АТД). До сего дня не утихают споры, что считать типом данных: только набор (однородных) сущностей или еще и набор операций над ними. АТД не стоит путать с ООП.
Логика утверждения Армстронга ведет к тому, что объединять можно только представителей одного муравейника. Что является средством объединения сущностей в языках программирования? Структуры (записи), процедуры (функции), классы, модули (кластеры)... В общем-то вся их ценность в том и состоит, что они объединяют именно неоднородные вещи.
Что касается децентрализации структур данных и структур управления в ООП -- то это и есть его природа. Говорить о том, что децентрализация плоха, столь же неразумно, как и то, что плоха централизация. Все зависит от задачи и условий ее решения. Это два полюса, и в задачах требуется находить аккуратный баланс, а не впадать в крайности.
Хорошо, что появляются статьи, критикующие рыночные перекосы ИТ-индустрии. Но плохо, что при этом оценка технологическая (со стороны специалистов именно в технологиях) делается как бы походя и при том весьма поверхностна.
| № 3026 02-10-2007 11:46 | |
| № 3025 01-10-2007 18:29 | |
Ответ на »сообщение 3024« (Сергей Осколков)
___________________________
Это было к тому, что свои собственные предметные области (или область) есть и у программистов, а не только в сферах, внешних по отношению к программированию. Списки м.б. пример неудачный, но взамен могу назвать сетевое программирование, работу с БД, и т.д. и т.д.
Работа с БД - отличный пример. Никак не могу найти СУБД, строго реализующую реляционное исчисление. Такое впечатление, что разработчики теорию не изучали. Нет, нормальные формы они, конечно, проходили. А вот к чему может привести разрешение незаполненного поля никто не разбирался. Стараясь перещеголять друг друга, вводят все новые механизмы, способные разрушить целостность реляционной модели. И перекладывают ответственность на разработчиков конкретных баз данных и конкретных запросов.
То же самое с сетями - почитайте вопросы на круглом столе: "никогда раньше с сетями не работал, посоветуйте компоненты...". А советовать нужно книжки по сетям :(
Имеет предметная область отношение к программированию или не имеет - ее нужно знать.
Дилетантизм собственно в программировании менее опасен, чем дилетантизм в понимании решаемой задачи.
Можно сделать коряво, неэффективно, но нельзя сделать НЕ ТО.
Что касается системного анализа, мне кажется, что здесь важно скорей умение, чем формальные знания, причем умение может быть без наличия формальных знаний о системном анализе.
Конечно, системный анализ не только наука но и исскуство. В любом исскустве можно найти примеры высоких достижений у самородков. Но в любом исскустве больше возможностей добится хороших результатов у тех, кто изучил соответствующие науки. В Академии Художеств не только пишут картины, вырабатывая навык, но и изучают перспективу, анатомию, свойства красок и т.д. Очень способствует...
| № 3024 01-10-2007 11:19 | |
Ответ на »сообщение 3022« (Сергей Перовский)
___________________________
А это тоже предметные области :)
Только специфические.
Это было к тому, что свои собственные предметные области (или область) есть и у программистов, а не только в сферах, внешних по отношению к программированию. Списки м.б. пример неудачный, но взамен могу назвать сетевое программирование, работу с БД, и т.д. и т.д. Не думаю, что нужно перечислять, при желании это можно сделать.
Технология программирования не так важна, как знание предметной области и системного анализа.
Т.к. есть собственно программистская предметная область, и знание ее входит в технологию программирования, то все-таки технология важна, я так считаю, и думаю, что множество программистов тоже. Что касается системного анализа, мне кажется, что здесь важно скорей умение, чем формальные знания, причем умение может быть без наличия формальных знаний о системном анализе.
| № 3023 01-10-2007 10:43 | |
Ответ на »сообщение 3021« (torvic)
___________________________
утверждён новый стандарт Scheme R6RS
http://www.r6rs.org/
Что-то многие разработчики трансляторов Scheme недовольны новым стандартом - считают его слишком сложным... Некоторые даже предложили альтернативный стандарт ERR5RS
Основная страница SchemePunks - Панки Схемы... :о))
Говорят, поддержка R6RS будет у PLT (DrScheme/MzScheme), Scheme 48 и Chez.
А вот отказались поддерживать: Bigloo, Gambit, Chicken, Stalin, SCM. Stalin, Bigloo, Gambit-C вроде как самые оптимизирующие трансляторы Схемы, MzScheme уступает им...
Но наверное, пройдёт какое-то время, и им придётся тоже обеспечить совместимость с R6RS?..
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
