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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вернее чем shu-thing

http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/
Haskell in Space

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

Ответ на »сообщение 2835« (Geniepro)
___________________________


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

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

Ответ на »сообщение 2835« (Geniepro)
___________________________

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

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

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

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

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

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.

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

Ответ на »сообщение 2827« (Trurl)
___________________________

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

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