| Функциональное программирование |
Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.
Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.
Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.
Jack Of Shadows
Всего в теме 5502 сообщения
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Сравнение компиляторов
- Вот и вышла Delphi 7... Вы рады?
| № 1392 02-11-2006 06:39 |   |
Ответ на »сообщение 1389« (al_mt)
___________________________
Если я хоть что-то понял относительно ФЯ, кэширование должно быть спрятано от программиста напрочь.
Это не только применительно к ФЯ...
А где,когда и какой идиот выствляет клиенту(пользователю) своей библиотеки(системы, утилиты, поделки) факт наличия кеша и необходимости им управлять? Смысл кеша как раз в "незаметности" и "создании впечатления" :о)
Для аналогии - перекликающаяся с этим тема(вопрос), например, - наличие явных процедур "команды обновления" для прорисовки содержимого контрола в некоторых графических фреймвоках. Ежели такое есть - явный признак непроработанности архитектуры фреймвока.
| № 1391 02-11-2006 06:10 | |
Ответ на »сообщение 1390« (Как слышно? Приём!)
___________________________
Теперь всё объяснили. Эта ветка - закрытый клуб пауков, которым хорошо на Юпитере.
Да. В смысле - ХОРОШО.
| № 1390 02-11-2006 04:22 | |
Теперь всё объяснили.
Эта ветка - закрытый клуб пауков, которым хорошо на Юпитере.
| № 1389 02-11-2006 02:11 | |
Сори! Просмотрел. Ключевое слово "кэширование". Если я хоть что-то понял относительно ФЯ, кэширование должно быть спрятано от программиста напрочь.
| № 1388 02-11-2006 02:09 | |
БД состоит из нескольких таблиц, по которым рассыпаны кусочки документа. В основном это две таблицы:
в одной каждая запись - заголовок документа
в другой каждая запись - это элемент документа. Таких элементов в документе много и они соеденены в дерево. Каждый элемент - это набор стандартных полей + BLOB неизвестного состава и размера.
ИМХО реализация древовидной конструкции на ФЯ ложится без проблем, но технические ограничения вынуждают управлять ресурсами "вручную".
P.S. Кстати, логика обработки документа почти целиком построена на рекурсивных циклах :)))))
| № 1387 02-11-2006 01:21 | |
Ответ на »сообщение 1386« (al_mt)
___________________________
Полтора дня читал. %) До зюк в глазах :))
Прога работает со специфическим документом, хранимым в БД. Проблема с том, что документ в принципе может быть больше гига в размере :) При реализации это не великая проблема, т.к. документ древовиден и его можно обрабатывать по кусочкам, организовав явное взятие/освобождение памяти.
Так "документ" - это и есть сама БД или "документ" – поле записи в БД?
Грядут перспективы осетенизации проекта, что автоматом влечёт за собой таскание оного гига или более через сеть. Разумеется управление этим тасканием надо делать ручками.
Если "документ древовиден и его можно обрабатывать по кусочкам", то почему бы его и не "таскать" по кусочкам? С "кэшированием" уже перетасканных кусочков у клиента и поддержанием синхронности информации с сервером... :о)
Я это к чему. ИМХО существующая техника, которая требует ЯВНОГО управления многими функциями завязанными на "железо" слишком далека от "идеального ФЯ железа".
..."Виноград ещё зелен"?
| № 1386 02-11-2006 01:03 | |
Полтора дня читал. %) До зюк в глазах :))
Попытался примерить ФЯ к моей текущей задаче. Прога работает со специфическим документом, хранимым в БД. Проблема с том, что документ в принципе может быть больше гига в размере :) При реализации это не великая проблема, т.к. документ древовиден и его можно обрабатывать по кусочкам, организовав явное взятие/освобождение памяти.
Грядут перспективы осетенизации проекта, что автоматом влечёт за собой таскание оного гига или более через сеть. Разумеется управление этим тасканием надо делать ручками.
Я это к чему. ИМХО существующая техника, которая требует ЯВНОГО управления многими функциями завязанными на "железо" слишком далека от "идеального ФЯ железа".
| № 1385 01-11-2006 23:53 | |
Ответ на »сообщение 1384« (Jack Of Shadows)
___________________________
А в ФЯ все гораздо проще. Написал функцию - можно тут же ее запустить. Заметьте - не программу запустить а одну единственную функцию, и посмотреть результат.
... Ну прям перепечатка одной из характеристик Форта от Лео Броуди... :о)
| № 1384 01-11-2006 12:00 | |
Ответ на »сообщение 1380« (Geniepro)
___________________________
хочется сразу увидеть, как работает та или иная функция, а увидеть не так просто, так как другие взаимосвязанные части ещё не готовы...
А вот это кстати то чем сильны все ФЯ. В том числе и хаскель. REPL то у вас под рукой. Нет нужды компилировать всю программу, запускать главный ехе-шник, вводить имя/пароль, добираться по менюшкам о нужного окна, вводить там нужные данные и НАКОНЕЦ нажимать ту кнопку на которую завязана функция которую вы хотели проверить (sic!!)
Это сценарий по которому "отлаживают" программы 99.99% всех императивных программистов. О unit тестах слышали (и уж тем более применяют) считанные единицы.
А в ФЯ все гораздо проще. Написал функцию - можно тут же ее запустить. Заметьте - не программу запустить а одну единственную функцию, и посмотреть результат.
| № 1383 01-11-2006 11:54 | |
Ответ на »сообщение 1380« (Geniepro)
___________________________
Вот например, как отлаживать программу на Хаскелле? Какие существуют методы отладки программ на Хаскелле?
Необходимость отладчика обуславливается размазыванием состояния по программе.
То есть в какой то момент состояние программы не совпадает с ожидаемым.
Тут уж приходится шажочками ее проходить.
Но чистую функцию запускать в отладчике нет никакого смысла. Ее достаточно протестировать, либо вручную, либо написав для нее unit тест.
Если у вас в программе манипуляция состоянием происходит лишь в нескольких обособленных островах. А весь остальной код - это чистые и уже ОТЛАЖЕННЫЕ функции, то в такой программе гораздо меньше ошибок.
Да и места в которых они могут появиться четко выделены (монады IO).
Это резко облегчает нахождение проблемы. При этом в монадах если уж вам так нужно можно преспокойно писать print для отладки.
Но это все частности - проблемы хаскеля. К другим ФЯ (ocaml, лисп ) никакого отношения не имеют.
Если же вас интересует опыт написания нетривиальных программ на хаскеле, то есть великолепная "проходилка" - рассказ о написаниии Scheme на хаскеле за пару дней.
http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/overview.html
Если вы ее пройдете, я думаю получите ответы на вопросы о том как отлаживаются большие программы на хаскеле.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
