Здравствуйте, Кодёнок, Вы писали:

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

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

Ну как тебе сказать... очень детальные требования по объёму запросто превысят сам код + примерное описание постановки задачи. Кроме того, они болжны быть непротиворечивыми, верифицированными и т.п... Ну, и заказчик, разумеется, должен уметь работать с компилятором требований.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?
IT>>Ты неверно понимаешь значение слова паттерн. К сожалению прочтение широкоизвестной книжки часто оставляет неизгладимый отпечаток на правильном понимании слова паттерн у программистов. Паттерн — это не только то. что описано в книжке банды четырёх. Паттерн — это просто типовое решение и таких решений в твоём коде масса. Следовательно ты и есть их автор.

ГВ>Отлично! А как это относится к заданным вопросам?

Включаем логику.

1. Паттерны мы придумываем сами.
2. Столько сколько необходимо для решения каждой конкретной задачи.
3. Не переведутся.

Здравствуйте, IT, Вы писали:

ГВ>>>>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?
IT>>>Ты неверно понимаешь значение слова паттерн. К сожалению прочтение широкоизвестной книжки часто оставляет неизгладимый отпечаток на правильном понимании слова паттерн у программистов. Паттерн — это не только то. что описано в книжке банды четырёх. Паттерн — это просто типовое решение и таких решений в твоём коде масса. Следовательно ты и есть их автор.

ГВ>>Отлично! А как это относится к заданным вопросам?

IT>Включаем логику.

IT>1. Паттерны мы придумываем сами.
IT>2. Столько сколько необходимо для решения каждой конкретной задачи.
IT>3. Не переведутся.
4. Как следствие п.1 — передерутся.

Ergo, имеем тот же самый процесс программирования, но спроецированный на "немного другую" деятельность — формулирование паттернов. Что и требовалось доказать. Спасибо, IT.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ergo, имеем тот же самый процесс программирования, но спроецированный на "немного другую" деятельность — формулирование паттернов. Что и требовалось доказать. Спасибо, IT.

Именно. Пишем правила и их применяем. По моему скромному опыту такой подход даёт существенное упрощение прикладного кода.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndreyFedotov, Вы писали:

AF>> Да, знакомая идея. У неё видно два крупных недостатка:
AF>> Шаблоны придётся описывать. А работы там ох как много!
AF>> Но её главный недостаток в том, что для того, что бы шаблоны были гибкими (руку то робот может двигать по-разному!) — придётся настраивать эти шаблоны, указывать кучу параметров. В резальтате читаемость кода будет падать — она будет обратно пропорциональна его гибкости. И деться от этого куда-либо не возможно — законы сохранения не позволяют.

IT>Это не совсем так. Чем более универсален алгоритм, тем таки да, действительно, требуется всё большее количество параметров его настройки. Но чем более по типовому мы его используем, тем больше параметров у нас начинают принимать одни и теже значения. В результате список параметров может очень сильно укоротиться или совсем выродиться. Если надо могу привести вполне рабочий показательный пример.

Полностью согласен.
Я это прекрасно понимаю, да и пример привести довольно легко.
Можно прекрасно упаковать шаблоны, со множнством параметров, в некие шаблоны более высокого уровня, с меньшим числом настроек — в общем обычная декомпозиция. Но в том то и суть — что это уже будет не так выразительно, как простенький пример с декларацией. Кроме того, это опять-таки будет зависеть от мастерства разработчика — как и сейчас. И опять всё вернётся на круги своя... То есть вместо красивой теории начнутся суровые будни.

Здравствуйте, IT, Вы писали:

IT>В принципе, Кодёнок прав, хотя пока у него не очень получается с аналогиями

IT>Дело в том, что на сегодняшний день императивные языки хорошо решают проблему повторного использования кода посредством процедур. Но есть такие вещи как паттерны, которые по сути являются типовыми повторно используемыми решениями. Алгоритм решения для паттернов известен, но в отличии от процедур их нельзя реализовать в одном и том же машинном коде раз и навсегда. Программист или компилятор (в случае использования шаблонов или дженериков) должен писать/генерировать такой типовой код каждый раз заново. Вышеупомянутые шаблоны, представляя собой фактически типизированные макроподстановки, позволяют закодировать часть паттернов. Но существует масса более сложных случаев, с которыми шаблоны не справляются и не могут справиться в принципе. Обычно в таких случаях используется величайшая технология всех времён и народов — Copy/Paste.

IT>Декларативное программирование позволяет в какой-то степени решить проблему повторного использования паттернов, а следовательно упростить написание бизнес кода. Т.е. фактически отделить мух от котлет и максимально "отжать" бизнес код.

В том, что декларативный стиль более переспективен (если не везде, то во многих областях) — то я с этим полностью согласен, о чём и писал здесь

Автор: AndreyFedotov
Дата: 05.07.05

. Кодёнок однако понял идею весьма поверхностно, потому и с примерами так получилось. Что же до остального, Игорь, то тут я полностью согласен — ты всё очень просто, хорошо и доходчиво объяснил.

Здравствуйте, AndreyFedotov, Вы писали:

AF>Что же до остального, Игорь, то тут я полностью согласен — ты всё очень просто, хорошо и доходчиво объяснил.

Ой, правда! Тебе понравилось?!?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndreyFedotov, Вы писали:

AF>>Что же до остального, Игорь, то тут я полностью согласен — ты всё очень просто, хорошо и доходчиво объяснил.

IT>Ой, правда! Тебе понравилось?!?

Хуже того — сам понял, что такое декларативное программирование...

Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>Ну как тебе сказать... очень детальные требования по объёму запросто превысят сам код + примерное описание постановки задачи. Кроме того, они болжны быть непротиворечивыми, верифицированными и т.п... Ну, и заказчик, разумеется, должен уметь работать с компилятором требований.

Этого не может быть по определению. Код — это и есть одно из представлений требований. Работающий код = достаточная детализация. Превысить по объему могут только требования с избыточной детализацией.

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

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Возвращаясь к первоначальной статье, можно так сказать: программа собирается прямо из UML-схем. Минуя стадию кодирования. Вряд ли UML способен настолько детализовано описать систему, но теоретически принцип именно такой.

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

Здравствуйте, eao197, Вы писали:


E>...И вот эти места мне особенно интересны.

Если инетресно, можно для начала посмотреть: здесь, здесь, здесь и здесь

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>>Ну как тебе сказать... очень детальные требования по объёму запросто превысят сам код + примерное описание постановки задачи. Кроме того, они болжны быть непротиворечивыми, верифицированными и т.п... Ну, и заказчик, разумеется, должен уметь работать с компилятором требований.

Кё>Этого не может быть по определению. Код — это и есть одно из представлений требований. Работающий код = достаточная детализация. Превысить по объему могут только требования с избыточной детализацией.

А вот и нет. Простой пример: твой же. Подача инструкций:

1. Включить сигнал 1 на 100 мс с частотой 10000 гц
2. Включить сигнал 3 на 50 мс с частотой 15000 гц
3. Повторять 1-2 в течение 2 секунд

Может оказаться гораздо компактнее, чем:

 Робот должен наклонится вперёд, легко покачивая корпусом (с амлитудой колебаний копруса 5-10%), руки робота должны плавно отклоняться в стороны (левая в бок, правая - вперёд) со скоростью 2-5 градусов в секунду, ноги робота...

Так ведь ещё необходимо будет реализовавать переход от деклараций к конкретным командам.

Декларативный стиль может быть гораздо выразительнее, чем императивный, но далеко не факт, что он окажется компактнее...

В общем стоит различать компактность и выразительность — далеко не всегда одно сопутствует другому.

Кё>Но глядя на код, который сам пишу каждый день, понимаю, что там много лишнего и достаточно куда меньшей детализации. Т.е. С++ например, позволяет делать очень много вещей, но часто кривыми и неочевидными путями.

Кё>Вообще, если ты реализуешь в проекте, скажем, паттерны проектирования банды четырёх, то это уже означает, что твои описания избыточны.

Это так, но эти вещи являются следствием более фундаментальных причин — чем стиль описания.

Здравствуйте, AndreyFedotov, Вы писали:

Кё>>Этого не может быть по определению. Код — это и есть одно из представлений требований. Работающий код = достаточная детализация. Превысить по объему могут только требования с избыточной детализацией.

AF> А вот и нет. Простой пример: твой же. Подача инструкций:
AF> Может оказаться гораздо компактнее, чем:

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

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

// подавая +1, мы увеличиваем угол до максимума (1)
// подавая 0, угол не меняется
// подавая -1, угол уменьшается до минимума (0)
// прим. нельзя долго держать мотор включенным, если шлагбаум не движется
Команда "поднять":
  если угол != 1, подать +1
  пока угол != 1, ничего не делать
  подать 0

программа:
  поднять

"шлагбаум поднят", если угол == 1 и подано 0
"угол растёт", если подано +1
"угол не меняется", если подано 0
"угол уменьшается", если подано -1

программа:
  требуется достигнуть "шлагбаум поднят"

В императивном описании вся суть (идея) остаётся где-то в документации, в комментариях, в UML-диаграммах, но не в коде.

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Требования у тебя получаются избыточными потому, что ты мыслишь об объектах реального мира, а там огромное число процессов, параметров и т.д. Но мы-то создаем ограниченную, логически завершенную систему. В ней не может быть неоднозначности.

Тогда "за кадром" остаются исходные требования...

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Кодёнок, Вы писали:

Кё>>Требования у тебя получаются избыточными потому, что ты мыслишь об объектах реального мира, а там огромное число процессов, параметров и т.д. Но мы-то создаем ограниченную, логически завершенную систему. В ней не может быть неоднозначности.

ГВ>Тогда "за кадром" остаются исходные требования...

Вот именно — и исходная идея, "проект == код" летит ко всем чертям, превращаясь на ходу в обыденное "проект == код + описание модели/требований"

Здравствуйте, Геннадий Васильев, Вы писали:

Кё>>Требования у тебя получаются избыточными потому, что ты мыслишь об объектах реального мира, а там огромное число процессов, параметров и т.д. Но мы-то создаем ограниченную, логически завершенную систему. В ней не может быть неоднозначности.

ГВ>Тогда "за кадром" остаются исходные требования...

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Геннадий Васильев, Вы писали:

Кё>>>Требования у тебя получаются избыточными потому, что ты мыслишь об объектах реального мира, а там огромное число процессов, параметров и т.д. Но мы-то создаем ограниченную, логически завершенную систему. В ней не может быть неоднозначности.

ГВ>>Тогда "за кадром" остаются исходные требования...

Кё>В идеале, архитектор пишет требования низкодетализованные, как эскиз (или диаграмма структуры системы), а программисты (как я сказал, это тоже проектировшики, только уровнем ниже) детализуют их, что-то решают вручную.

Вообще то так и происходит, только получается забавная ситуация, если рассматривать поток данных:
Заказчик (знает требования детально) => аналитик (ещё более детализирует и систематезирует требования) => архитектор (задаёт общие требования) => разрботчики (детализируют требования)
Всё это похоже на испорченый телефон...

Здравствуйте, Кодёнок, Вы писали:

Кё>Если архитектор ПО называется архитектором, то программиста по умолчанию отводят в строители, что аналогично, если смотреть на взаимодействие этих людей в команде, но неверно, если смотреть на получаемый результат. А мы ведь улучшаем результат, а не строим взаимоотношения в команде.
В строительстве зданий, кстати, у архитектора совсем не главная и, по сути, небольшая роль. Обычно они выступают в роли художников, людей с пространственным эстетическим воображением, которые способны выслушать заказчика и на основе его пожеланий нарисовать будущее здание в нескольких видах (часто только внешних). А вот после них и начинается настоящая работа — инженерам-конструкторам железобетона, металла, электросетей, сантехнического оборудования и т.п. Так что аналогия в общем виде наверное остаётся, только все эти разномастные инженеры ассоциируются с программистами. Ну а строители, конечно, — средства компиляции.

Высокоуровневое проектирование "на UML" можно приравнять к проектированию архитектора-мастера. Он определяет вид здания, то как оно будет вписываться в окружение. Все говорят — это здание спроектировал архитектор Иванов или этот небоскреб построил архитектор Smith. А есть архитекторы "попроще", их никто не знает — они расчитывают нагрузки на несущие констукции, выбирают тип материала исходя из требований прочности, пожарной безопасности, санитарно-гигиенических норм и т.п.
Они изготовляют море чертежей, с которыми в итоге работает прораб.

Программисты — это и есть эти архитекторы "Попроще", которые выбирают тип контейнера, алгоритм сортировки исходя из требований производительности и др. требований. Они изготовляют чертежи для компилятора-прораба.
Это только мое видение.

Вот ещё один аргумент против программиста-строителя и за программиста-инженера (архитектора). Это рефакторинг.

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

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

Пока заказчик думает, что программирование — это строительство, то вы его не убедите в необходимости рефакторинга. А если использовать правильную аналогию, ему сразу станет всё понятно.