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

Как мне кажется, Вы упускаете из виду способность ума к обобщению и переносу опыта на новые ситуации.
У Вас же получается, что каждая ситуация абсолютно уникальна, перенос опыта невозможен.


Я не упускаю. Это вы чересчур обобщаете.
Да, существуют ситуации где раз за разом надо делать одно и тоже.
Замерил, сшил костюм.
Замерил, сшил еще костюм.
После тысячи костюмов, процесс настолько набит, что вариации уже не имеют никакого значения.

Но программирование, это не профессия в которой вы делаете одно и тоже. Иначе грош нам цена.
Да, мы кажый раз пользуемся одними и теми же инструментами, да мы каждый раз используем одни и те же технические приемы, и в данном случае речь не идет ни об ИЯ, ни об ФЯ.
Но каждый раз используя одни и те же приемы и инстрмеунты мы не шьем один и тот же костюм, мы не играем одну и ту же партию, с одним и тем же человеком, мы каждый раз решаем новую задачу.
Вы выиграли партию в шахматы у новичка.
Вместо новичка сел игрок поопытнее. И все, весь ваш маленький опыт и знания уже не годны. Надо опять учиться.
Одолели его, приходится играть с соперником посильнее.
И только сыграв десятки тысяч партий, каждый раз играя с соперником посильнее, то есть решая НОВЫЕ задачи,  вы выбиваетесь на вершину.

Давайте возьмем другой пример - пианист.
Он может пройти прекрасную школу, иметь более десяти лет опыта.
Но он не может основываясь на все свои знания и весь свой опыт, просто взять новую незнакомую партитуру, выйти на сцену и сходу ее забацать.
Ему требуется тренировка.
Да, он сможет разобрать эту партитуру за неделю. В тысячи раз быстрее чем любой неподготовленный человек.
Именно из за своих знаний и опыта по переносу этих знаний на новые ситуации.
Но никакие знания и никакой опыт не освобождают от необходимости каждую ситуацию изучать заново.
И у шахматистов то же самое.
Каким бы чемпионом вы не были, вы не будете выходить на турнир с новым противником полагаясь на "способность ума к обобщению и переносу опыта на новые ситуации."
Вы соберете все партии этого соперника, будете их изучать, искать его любимые приемы и его слабые места, сотни раз проигрывать партии в том направлении которое обычно он выбирает.
То есть вы будете ТРЕНИРОВАТЬСЯ, изучать новую ситуацию.
Да, может быть в тысячи раз быстрее и эффективнее нешахматиста.
Но тем не менее, изучать новую ситуацию вам придется. Чтобы потом по настоящему сыграть всего один лишь раз.

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

Вот только ООП ставит программистов в идиотскую ситуацию, когда от них требуется решить новую задачу без тренировки вообще, полагаясь только на "способность ума к обобщению и переносу опыта на новые ситуации."

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

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

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

>>>Неужели бильярд труднее реализовать, чем игру типа Квейка?

Будем считать, что одинаково трудно (в принципе, это задачи примерно одного класса). :)
Вместо того, чтобы отсылать спрашивающего к 345KB очередного чуда криптографии, вполне можно, IMHO, объяснить принцип на словах.
Например (это, конечно, мои глупые фантазии) так: основной цикл программы моделирования реализован в виде хвостовой рекурсии, а (измененное) состояние передается между итерациями в качестве аргумента этой рекурсивной функции основного цикла.
Или, что вероятнее, используется какой-то другой способ.
Главное, что это вполне можно выразить обычным языком.

Ответ на »сообщение 2845« (Jack Of Shadows)
___________________________

Чемпионы мира это те кто прошел один и тот же путь десятки тысяч раз.
<...>
Невозможно грамотно проектировать на незнакомой местности.

Где-то здесь у нас расхождение.
Как мне кажется, Вы упускаете из виду способность ума к обобщению и переносу опыта на новые ситуации.
У Вас же получается, что каждая ситуация абсолютно уникальна, перенос опыта невозможен.
Но Вы же не станете утверждать, что чемпион мира стал таковым, потому что заранее выучил наизусть все возможные шахматные позиции? (Ведь иначе, по вашей логике, он должен был бы играть не сильнее, чем новичок; ведь каждая ситуация уникальна.)

Ответ на »сообщение 2844« (Илья Ермаков)
___________________________

Представьте себе, что вас не особо заботит, как реализовать ту или иную функцию, а вам приходится решать задачи, как обеспечить их взаимодействие, обмен сообщениями, синхронное управление и т.п. Здесь модульные ИЯ дают мощные конструкции и паттерны. Что дает ФЯ? Вместо модулей - просто пакеты. Вместо взаимодействия и явного управления состоянием технической системы - исключительно композицию функций. Тоска, господа :-)

Тоска, абсолютнейшая тоска... :о(

Ну хорошо, возьмём такую программу как игра-3D шутер Quake 3. Скажите, в этой игре есть манипуляции с состояниями? Есть взаимодействия между объектами? Есть события типа столкновений шаров друг с другом или пуль и тел? Синхронное управление?
Очевидно, что есть. Хорошо.

Неужели бильярд труднее реализовать, чем игру типа Квейка?

Теперь в который раз вспомним про игру Frag ...
Frag - это игра, очень таки походая на Quake 3, причём написана она на Хаскелле с использованием библиотеки Функционально-Реактивного Программирования Yampa .
Как Вы думаете, Хаскелл всё ещё ничего не может предложить для подобных задач?
Исходники доступны, и занимают всего 345 кБт...

Ну ладно, чёрт с ними с Квейками/Фрагами. Всем известный Тетрис, реализованный на Хаскелле

Библиотеки для генетического программирования на Хаскелле - подойдут для демонстрации изменяемого состояния?

Тоска, господа :-)

Ответ на »сообщение 2847« (Илья Ермаков)
___________________________
Класс - это всего лишь тип данных. Но ни в коем случае не несущий элемент архитектуры.
Золотые слова!!
Уже много раз об этом здесь говорилось.
Бессмысленно ориентировать программирование вокруг какого то конкретного то типа данных.

Но поднята другая тема.
Поднята тема проектирования архитектуры, и средств, необходимых для успешного проектирования.
Я уже говорил что исходя из натуры человеческой мы гарантированно ошибаемся.
Мы обязанны просто пробовать каждый шаг, вместо того чтобы планировать сделать сразу несколько.
ФЯ дает нам такую возможность. В ФЯ пробовать легко и быстро.
А вот как пробовать в ООП ?
ФЯ дает вам возможность строить кирпичик за кирпичиком снизу вверх, проверяя на прочность и практичность каждый уровень, и строя следующий только после проверки предыдущих.

ООП требует сначал полностью возвести каркас (иерархию классов, арматуру) а затем уже строить.
Но строить каркас дорого, трудно, долго. Цена ошибки высока.
Денег на столь дорогостоящие пробы ни у кого нет.
Я в программировании с 1992 года. До сих пор ни разу не видел, чтобы построенные ОО каркасы отбрасывались.

Сколько не говори о грамотном проектировании, сколько не оттачивай до совершенства императивные системы, а до тех пор пока вы господа не изыщите возможность дешевого массового экспериментирования, не видать вам улучшения той плачевной ситуации в которой находится программное строительство в императивном мире.

Ответ на »сообщение 2846« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2844« (Илья Ермаков)
___________________________
Большая беда в том, что архитектура и анализ ПрО смешиваются воедино. 
Этому способствует, да нет, даже поддталкивает к этому, парадигма ООП.

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

Ответ на »сообщение 2844« (Илья Ермаков)
___________________________

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

Проектируя систему, я строю инфраструктуру, на которой смогу
Вот так прям с ходу строите ? Без экспериментов ? Без проб и ошибок ? Да вы первый человек, который может строить сложную инфраструктуру без проб, сразу с идеи в голове, в воплощение в коде :))
Я больше таких не видал.

где ФЯ не предоставляет практически ничего... 
Говорит человек, пробовавший ФЯ в реальной задаче. Или вы повторяете то что гле то слышали ?

Здесь модульные ИЯ дают мощные конструкции и паттерны.
Я понимаю что вам дает ИЯ. Я просто не вижу, где ваша песочница в которой вы можете легко и быстро поиграться с множеством разных идей чтобы отбросить ошибочные и найту ту саму правильную.
Более того, я даже не вижу что вы ВООБЩЕ это делаете.
Я знаю что нет человека который бы не ошибался. И чем длиннее цепочка рассуждений без проб, тем дороже цена ошибки, тем больше девиация от правильно подхода.

Ответ на »сообщение 2843« (AVC)
___________________________
Вы ссылаетесь на шахматы. Хорошо. Вам известно, что бывают слабые шахматисты, а бывают чемпионы мира. Несовершенны все, но в разной степени. :)


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

ФЯ позволяет вам проваливать проекты в песочнице, быстро и помногу, в считанные дни и выкатить в production сразу версию 100

В то время как в ООП, повсеместно проекты выходят в версии 1.0 и потом уже на живых пользователях "доводятся". Долго, мучительно, годами, с огромными затратами. С фантомными багами, кочующими из версии в версию.
С необходимым "полным переписыванием" каждые несколько лет. Поскольку количество и нагромождение ошибок проектирования становится уже невыносимым.
Это и есть тот самы метод проб и ошибок. Другого у нас нет.
Вопрос только в том где вы пробуете и ошибаетесь. Как быстро и легко и дешево, или наоборот медленно, трудно и дорого вы это делаете. Но и в том и в другом случае это один и тот же метод.
Грамотного проектирования не существует. Есть только нарабатывание опыта и его применение.
Как программистами так и чемпионами мира по шахматам.

Ответ на »сообщение 2842« (Jack Of Shadows)
___________________________

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

Джек, Вы немножко не правы...

Большая беда в том, что архитектура и анализ ПрО смешиваются воедино. Это две ортогональные задачи при разработке ПО. Они решаются в терминах различных конструкций, различных абстракций. Сколь бы ни была замутнена постановка задачи - можно начать выстраивать систему так, чтобы при флуктуациях ее постановки систему перестраивать было гораздо легче. Анализ/решение ПрО и проектирование системы - это связанные, но ортогональные и часто (конструктивно) противоречивые задачи.
Проектируя систему, я строю инфраструктуру, на которой смогу (или смогут другие) эффективно и быстро построить решение конкретных задач. Но я не завязываюсь на эти конкретные задачи.
Реализация функционального языка в совокупности со средой - одна из возможных инфраструктур, которую кто-то уже реализовал для вас, господа прикладники.
Императивные языки позволяют реализовывать и другие инфраструктуры...

ФЯ - это прекрасно. Если бы я писал алгоритмы и решал прикладные задачи, то я нашел бы там много интересного... Но, увы, в моих задачах мне приходится мыслить в других категориях, где ФЯ не предоставляет практически ничего... Представьте себе, что вас не особо заботит, как реализовать ту или иную функцию, а вам приходится решать задачи, как обеспечить их взаимодействие, обмен сообщениями, синхронное управление и т.п. Здесь модульные ИЯ дают мощные конструкции и паттерны. Что дает ФЯ? Вместо модулей - просто пакеты. Вместо взаимодействия и явного управления состоянием технической системы - исключительно композицию функций. Тоска, господа :-)

Однако очень часто в крупных системах встречаются отдельные части, которые занимаются интенсивными вычислениями/преобразованиями данных. И эти части было бы очень неплохо реализовать на ФЯ, внутри ИЯ-системы. Но для этого нужны хорошие механизмы межъязыкового взаимодействия... У того же Хаскелла, увы, с этим пока проблемы.

Ответ на »сообщение 2840« (Jack Of Shadows)
___________________________

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


Так все-таки грамотное проектирование есть? :)

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

Конечно, я мог бы сослаться на Капабланку, выигравшего свою самую первую партию. :)
Но речь идет не о том.
Вы беретесь доказать, что грамотного проектирования не существует, а доказываете совсем другую мысль: что этому надо учиться, что одних книг недостаточно, нужен опыт, и с первого раза может и не получиться.
А кто с этим спорит?
Существует или нет "грамотное проектирование"? Для ответа на этот вопрос надо представить какой-нибудь пример плохого дизайна и пример хорошего дизайна. Разница между ними -- как раз качество, "грамотность" проектирования.
Вы ссылаетесь на шахматы. Хорошо. Вам известно, что бывают слабые шахматисты, а бывают чемпионы мира. Несовершенны все, но в разной степени. :)