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

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

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


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

Архив

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


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

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

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

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

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

 
   
С Л С

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

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

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

Квинтана

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

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

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

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

 
  
АРХИВЫ

 
 

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

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

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

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

 Jack Of Shadows

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

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

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


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

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

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


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

  • <<<... | 2852—2843 | 2842—2833 | 2832—2823 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 267


    № 2842   13-04-2007 12:35 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2841« (Сергей Перовский)
    ___________________________
    Человек много к чему не приспособлен - например к научной деятельности.
    Не путайте. Не к научной деятельности, а к просчету шагов на незнакомой территории, неважно что это, охота на незнакомой местности, проектирование незнакомого проекта, или попытка слишком далеко просчитать какое нибудь физическое явление.

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

    А что предлагают апологеты "грамотного проектирования" ?
    Они предполагают что существует набор методик, которые позволят даже не пройдясь по незнакомой территории, только лишь сбором первичной информации, сразу построить весь план пути от начала до конца. И далее ему следовать.
    Посмотрите, во всех до единого книгах по ООП, говорится. что раз построив модель, иерархию классов и их взаимосвязей, переделывать ее уже невозможно (слишком дорого)

    А другого пути (строить по ходу) у ООП нет. Это считается неграмотным. Да и невозможно тоже. Почему ?

    Что из себя представляет такая вот методика построения архитектуры ?
    Бетон видели как делается ?
    В форму укладываются длиннющие и очень крепкие железные пруты, арматура.
    Затем все это заливается цементом.
    Как цемент прихватило, поздно уже что то менять. Только ломать и заново строить.

    В ООП роль этой пронизывающей все и все связывающей арматуры играет состояние, структура данных, размазанное по всей иерархии классов. И цемент (функции) жестко к этой арматуре привязан, в виде методов классов.

    Как начинаете строить, все, поздно уже дергаться.
    В ООП практически нет возможности поиграться, быстро построить и выбросить десятки разных иерархий классов, чтобы выбрать одну правильную.
    Слишком тяжело и затратно построить даже одну иерархию.
    Поэтому всегда на практике только одна архитетура и строится.
    Это равносильно попытке выиграть партию в шахматы с первого раза.

    В ФЯ нет арматуры связывающей весь проект. Чистые функции как лего-кубики. Легко строятся, легко разбираются. Легко выкидываются.
    Поэтому стоимость эксперимента в ФЯ чрезвычайно низка. Поэтому первые дни вместо того чтобы придумывать иерархию классов (и 100% ошибиться), программист играется с автономными функциями, быстро нарабатывая инструментарий, и отбрасывая неудачные решения. Это легко. Это дешево. Это быстро. И самое главное, это гарантированно выводит на правильный путь, и резко увеличивает шансы на успешное решение задачи.



    № 2841   13-04-2007 12:15 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2840« (Jack Of Shadows)
    ___________________________
    >>>Нет на самом деле такой вещи как грамотное проектирование. Не приспособлен человек для такой деятельности.
    Я бы так категорично не утверждал.
    Человек много к чему не приспособлен - например к научной деятельности.
    Однако на этом основании утверждать, что наука не существует, я бы не стал.
    Почему мне интереснее играть в "шахматы" 6х6? Потому, что я хорошо понимаю, что без изучения огромного количества "самых лучших книг по теории игры" вероятность успеха 0% при игре с мало-мальски образованным шахматистом.
    Книги по теории игры, это опыт тысяч шахматистов, наработать который самостоятельно невозможно.
    Так что теория столь же необходима, как и собственный опыт. Тут противопоставлять не нужно.
    Часто заказчик может уточнить свои требования только увидев некоторый прототип.
    Но "физик должен паять лучше лудильщика", в смысле, чтобы не попасть в 80% проектов на выброс, разработчик должен быть в теме не хуже заказчика.
    Должен уметь правильно выбрать математический аппарат, а уже к нему язык программирования. Тогда и прототип можно быстро построить и выбрасывать его не придется, а только дописывать.



    № 2840   13-04-2007 11:45 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2836« (AVC)
    ___________________________
    Конечно, (ничем) "незамутненное состояние" сознания гораздо лучше, чем "грамотное проектирование". ;)

    "Грамотное проектирование" это миф, живущий в рекламных слоганах оберонщиков.
    Нет на самом деле такой вещи как грамотное проектирование. Не приспособлен человек для такой деятельности.
    Вот для изучения обстановки на собственном опыте - прекрасно приспособлен.
    Когда люди показывают на примеры "грамотного проектирования" то на самом деле это примеры использования уже наработанного опыта на точно такой же задаче.

    Для эксперимента: Возьмите человека, прекрасного программиста, не знакомого с шахматами (шашакми, го, нардами, любой настольной игрой открытого типа). Научите его всем шаманствам "грамотного проектирования".
    Дайте ему задание сыграть в шахматы, ну хотя бы с обычным любителем, и выиграть.

    Уже сздесь он в выигрыше. Поскольку игра открытого типа, вся информация как на ладони.
    Это в отличии от обычного проекта, где программист видит лишь верхушку айсберга, все остальное от него скрыто.
    Дайте ему правила шахмат.
    Уже здесь он в выигрыше, поскольку полных спецификаций задачи для программирования он никогда не получает. В шахматах он сразу получает ВСЕ условия задачи, да еще и прекрасно сформулированные.
    Дайте ему самые лучшие книги по теории игры.
    Уже здесь он в колоссальном выигрыше, поскольку в реальном проекте никто никогда не даст ему легко усваиваемый и сконцентрированный опыт лучших из лучших, и готовые наработки большей части проекта (дебют, миттельшпиль, ендшпиль)

    Пусть он все это усвоит (ни разу не сев за доску), а потом применит свои недюжинные познания в "грамотном проектировании" игры, и выиграет свою первую в жизни партию сходу.

    Вероятность успеха ? 0% !!!
    Путь к победе ? Десятки может и сотни провальных проб. Это несмотря на весь обьем готовой инфы, ему предоставленной. Это несмотря на маленький набор взаимодействующих обьектов, с четко описанными взаимосвязями, это несмотря на очень ограниченное и полностью просматриваемое поле действий.

    В реальном проекте ? Информации как обычно кот наплакал, да и ту приходится клещами выдирать,
    Набор взаимодействующих обектов большой, количество обьектов и их взаимосвязи описанны неполно и часто неверно, поле действия невидно, и без наработки нескольких лет опыта в этой области не будет видно.

    Вы хотите сказать что в таких условиях кто то может сходу, с первого захода, успешно рещить задачу ?
    Ха ха ха!!

    Поэтому процент провальных проектов среднего и большого размера с традиционным подходом к проектированию настолько высок - 80% !!!

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

    Функциональые языки с REPL - идеальное поле для быстрых экспериментов в предметной области, нарабатывания знаний по ним, и создания слоя кода нижнего уровня, фундамента, на котором в последствии можно будет строить программу.

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

    Именно поэтому ФЯ используются для быстрого прототипирования (понимания задачи и нарабатывания опыта) и потом уже этот опыт переносится на реализацию задачи на ИЯ, поскольку на ФЯ программа не уложится в жесткие рамки ограниченных рессурсов железа.

    Но это было раньше. Сейчас с каждым днем все больше и больше задач можно оставлять на ФЯ после прототипирования, просто потому что они уже работают на доступном железе. А зачем делать одну и ту же работу два раза, если и первая реализация вполне подходит ?


    № 2839   13-04-2007 09:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    вернее чем shu-thing


    № 2838   13-04-2007 09:30 Ответить на это сообщение Ответить на это сообщение с цитированием
    http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/
    Haskell in Space

    учебный пример, существенно менее монадический, чем Haskell in Space


    № 2837   13-04-2007 09:24 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2835« (Geniepro)
    ___________________________


    Этот пример ярко демонстрирует, насколько легко изучать Хаскелл людям с незашоренным разумом и незамутнённым сознанием! :о)

    Буквально сегодня провел пед. эксперимент. Как уже "жаловался" в Оберон-ветке, занимаюсь с группой первокурсников, которые "не тянут" из-за того, что в школе не было вообще ничего, а на первом курсе вуза - только сухая конкретика языка С++. Строить алгоритмы и вообще программировать их не учит никто.
    Увы, из-за того, что нужно подготовить к сдаче конкретного экзамена, нет времени на другой язык, приходится оставаться в рамках С++, высекая существенное и отсекая мишуру.
    Так вот, изучение функций и рекурсии я поставил до изучения алгоритмов с управляющими операторами.
    Т.е. сначала показываем, как можно писать программу в чистых выражениях, без явного управления состоянием, а уже потом вводим остальную часть ИЯ - операторы.
    Люди, знающие математику, усвоили рекурсию с полнамека. Конкретно покажет следующее занятие, но понимание темы было заметно высокое.


    № 2836   13-04-2007 09:12 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2835« (Geniepro)
    ___________________________

    С огромным интересом и удовольствием почитал статью об одном занятном эксперименте по прототипированию военного ПО:

    К сожалению, так и не смог найти описания задачи. :(

    Этот пример ярко демонстрирует, насколько легко изучать Хаскелл людям с незашоренным разумом и незамутнённым сознанием! :о)

    Конечно, (ничем) "незамутненное состояние" сознания гораздо лучше, чем "грамотное проектирование". ;)
     AVC


    № 2835   13-04-2007 06:58 Ответить на это сообщение Ответить на это сообщение с цитированием
    С огромным интересом и удовольствием почитал статью об одном занятном эксперименте по прототипированию военного ПО:

    P. Hudak, M. P. Jones, "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity"

    Этот эксперимент был проведён осенью 1993 г. по заказу ВМФ США агентством US ARPA совместно с Office of Naval Research (ONR) и Naval Surface Warfare Center (NSWC).

    Эксперимент заключался в быстром прототипировании ПО для упрощённого варианта важной части системы ПВО США: geometric region server (geo-server), входящего в NSWC's AEGIS Weapons System (AWS).
    Этот гео-сервер должен был обработать набор данных о расположении военных судов и дружеских, коммерческих, а также вражеских, самолётов, и определить нарушении зон безопасности, ну и тому подобное...

    Прототипы создавались на нескольких известных языках: Haskell, Ada, Ada-9x, C++, AWK, и на нескольких экспериментальных языках, разработанных именно для прототипирования подобного ПО: Rapide, Griffin, Proteus и Relational Lisp. Затем прототипы были отданы независимым экспертам для оценки по нескольким параметрам, в том числе: понятность, компактность, расширяемость, пригодность для поддержки и развития, эффективность выполнения и т.д.

    Результаты сравнения:

          Язык            Строк    Строк    Время разра-  Общая
                          кода документации ботки (часов) оценка
    (1)  Haskell . . . . .  85 . . 465 . . . . . 10 . . . . A
    (2)  Ada . . . . . . . 767 . . 714 . . . . . 23 . . . . B
    (3)  Ada9x . . . . . . 800 . . 200 . . . . . 28
    (4)  C++ . . . . . .  1105 . . 130 . . . . . --
    (5)  Awk/Nawk  . . . . 250 . . 150 . . . . . --
    (6)  Rapide  . . . . . 157 . . . 0 . . . . . 54
    (7)  Griffin . . . . . 251 . . . 0 . . . . . 34
    (8)  Proteus . . . . . 293 . .  79 . . . . . 26 . . . . A
    (9)  Relational Lisp . 274 . .  12 . . . . .  3 . . . . A-
    (10) Haskell . . . . . 156 . . 112 . . . . .  8     


    Решение 1 (на Хаскелле), сделанное вторым автором статьи (с небольшой помощью со стороны первого), из 85 строк кода имело 20 строк входных данных, 29 строк синонимов типов и сигнатур типов (которые в принципе могут быть убраны - типы может вывести компилятор) и всего 36 строк собственно кода решения задачи. Большую часть времени авторы уделили документированию программы (видимо, старались сделать её образцово-показательной), поэтому потратили аж 10 часов.
    Тем не менее, общая оценка этой программы выглядит явно заниженной, потому что у программы на Proteus'е при той же общей оценке многие частные параметры были оценены ниже, чем аналогичные в хаскеллевской.

    Решение 10 (тоже на Хаскелле) было проделано выпускником колледжа, которому дали описание Хаскелла и 8 дней на изучение языка, затем дали спецификацию задачи и этот студент сумел всего за 8 часов написать этот прототип.
    Этот пример ярко демонстрирует, насколько легко изучать Хаскелл людям с незашоренным разумом и незамутнённым сознанием! :о)

    Решение 2 (на Аде) является референсным (контрольным), так как разработано ведущим программистом NSWC. Любопытно, что эту программу эксперты оценили хуже остальных...

    Решения 4 (на С++) и 5 (на Awk) представил один и тот же программист, причём он почему-то не указал времени работы над ними, поэтому они не были оценены.
    Для программы на С++ ему пришлось написать ещё 595 строк тестовой программы (вдобавок к 1105 уже имевшимся строкам).
    А вот неплохой результат на скриптовом языке Awk (250 строк) показал некоторую пригодность его для подобных дел.

    Решение 6 (на Rapide) выбивается из этого ряда, потому что не удовлетворяло требованиям задачи.
    К тому же, для этого языка на тот момент не было транслятора. Так же, впрочем, как не было трансляторов и для языков Ada9x (3) и Griffin (7).

    Решение 7 (на Griffin, 251 строка) потребовало от своих авторов ещё и написания дополнительных 200 строк библиотеки, похожей на стандартный модуль Prelude в Хаскелле.

    Решение 9 (на варианте Лиспа) демонстрирует поразительную "взрывную" скорость прототипирования программ на Лиспе - автор решения потратил на него всего 3 (три) часа! Правда, он уделил очень мало внимания документированию программы, что, конечно же, значительно сэкономило ему время...
    Несмотря на это (почти отсутствующую документацию), эта программа была оценена выше, чем образцовая программа на Аде, что противоречит распространнёному мнению о Лиспе как о диком и непонятном нагромождении круглых скобок... :о))

    Общий вывод статьи таков: функциональное программирование прекрасно подходит для быстрого прототипирования серьёзного и важного программного обеспечения.

    Исходники программ можно найти в отчёте:

    J.A.N.Lee, B.Blum, P.Kanellakis, H.Crisp, and J.A.Caruso. ``ProtoTech HiPer-D Joint Prototyping Demonstration Project'', February 1994. Unpublished; 400 pages.

    Подробный отчёт о решении на Хаскелле:

    W.E. Carlson, P. Hudak, and M.P. Jones. ``An experiment using Haskell to prototype "geometric region servers" for navy command and control''. Research Report 1031, Departmentof Computer Science, Yale University, November 1993.

    И вообще о прототипировании на ФП:

    P. Henderson. ``Functional programming, formal specification, and rapid prototyping''. IEEE Transactions on SW Engineering, SE-12(2):241–250, 1986.


    № 2834   13-04-2007 06:07 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2826« (Jack Of Shadows)
    ___________________________
    >>>на меня сразу набросятся с требованиями соответствия реализации каким нибуль правилам снукера.
    Насчет правил, это не ко мне, я с удовольствием играю с компьютером в шахматы на доске 6х6 :)
    Меня интересуют задачи, в которых существуют внутренние события - соударение шаров очень характерный пример. Мне кажется, что именно тут лежит граница эффективного применения функционального подхода.




    № 2833   13-04-2007 03:14 Ответить на это сообщение Ответить на это сообщение с цитированием
    Ответ на »сообщение 2827« (Trurl)
    ___________________________

    >>>Странно, все набросились на правила шахмат, и никто не обращает внимание, что это совсем не интерактивная программа. ;-)

    Началось с того, что я просто удивился мотивировке искажения правил.
    После этого для меня уже отошло на второй план, интерактивная это программа или нет.
     AVC


    <<<... | 2852—2843 | 2842—2833 | 2832—2823 | ...>>>
    Всего сообщений в теме: 5502; страниц: 551; текущая страница: 267


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

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

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

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

    Перейти на конкретную страницу по номеру
      
    Время на сайте: 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» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

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