Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  05:39[Войти] | [Зарегистрироваться]
Обсуждение темы:
Функциональное программирование

Функциональное программирование всегда привлекало меня в противопоставлении к императивному.
Я очень часто обсуждаю различные аспекты функционального программирования на различных ветках на Базарной площади.
Но хотелось бы собрать всех заинтересованный этой темой в одной ветке.
Я думаю что настало время открыть такую тему. И вот почему.

Исторически функциональное программирование появилось практически вместе с императивным.
Вторым языком после фортрана был лисп.
Но увы, функциональное программирование надолго было уделом исследовательских институтов или специализированных приложений (Искусственный Интеллект)
Конечно не надо считать весь мир дураками из за того что развитие пошло по пути языков Алгол семейства.
Для этого были вполне обьективные причины. Функциональные языки слишком близки к человеку и слишком далеки от машины.
Они сьедают в десятки раз больше рессурсов чем императивные языки.
Вспомните претензии, предявляемые к java - первому императивному языку с виртуальной машиной и сборщиком мусора, толкаемому большими корпорациями в mainstream.
Жутко тормозит, и жрет всю память какая есть. А ведь функциональные языки (далее ФЯ) все без иключения имеют сборщик мусора, виртуальную машину.
Многие из них (семейство лисп) еще и динамические, что только усугубляет положение.
Вполне естественно что появившись более полусотни лет назад они надолго опередилли свое время.

Для широкого распространения ФЯ нужны гигабайты дешевой памяти и гигагерцы дешевых процессоров.
Прошло более 50 лет, прежде чем такие требования к железу стали реальностью.
Это время наступило. СЕЙЧАС.
Добро пожаловать в новую эру программирования.

 Jack Of Shadows

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 5502 сообщения

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Средства разработки. Языки программирования.
  • Delphi 4 or Delphi 5
  • Что приобрести в качестве средства разработки?
  • Delphi6
  • Delphi vs PowerBuilder
  • Сравнение компиляторов
  • Вот и вышла Delphi 7... Вы рады?

  • <<<... | 1402—1393 | 1392—1383 | 1382—1373 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 412


    № 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

    Если вы ее пройдете, я думаю получите ответы на вопросы о том как отлаживаются большие программы на хаскеле.


    <<<... | 1402—1393 | 1392—1383 | 1382—1373 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 412


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования