UML-модели и чертёжи дома - неправильная аналогия
От: Кодёнок  
Дата: 05.07.05 05:53
Оценка:
Вот подумалось. Есть такая профессия — архитектор ПО, который в конечном счёте выдает множество схем и диаграмм, описывающих архитектуру систему. И эти схемы сравнивают с чертежами дома, а написание программы без (детального) проектирования сравнивают с построением дома в лоб, без чертежей.

Таким образом,

проектирование = рисование чертежей
кодирование = строительство
тестирование,
внедрение.

Но это неверная аналогия, и вот почему. Исходный код, который получается в результате, не есть сама программа. По построенному дому уже можно говорить, хорошо получилось или плохо, а написанный код надо ещё собрать. По чертежам дома можно построить только один вариант дома, а по UML-схемам можно написать кучу вариантов кода, в том числе очень плохого. Если в строительстве дома между проектированием, строительством и заселением ничего нет, то в разработке ПО пропущен этап компиляции (сборки). Она даже называется Build

Правильная аналогия такая:

проектирование = рисование эскиза (архитектура, выраженная UML-схемами = ПРИМЕРНЫЙ образ готовой системы)
кодирование = рисование чертежа (исходный код = чертёж)
сборка = строительство
тестирование,
внедрение.

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

Таким образом, сравнение написания программы без проектирование со строительством без чертежей (проекта) неверное. Если вы когда-нибудь строили, то знаете, что без проектирования можно построить только собачью будку, и то вряд-ли — мерять и сверять придётся не раз А вот небольшие и даже средние программы миллионы программистов успешно создают в одиночку.

Архитектура системы строится так, что менять её потом нельзя. (По крайне мере, в одной фирме, где главной частью процесса было проектирование, мне несколько раз сказали именно так). Если обнаруживается, что какая-то иерархия классов ненужная и её можно значительно упростить, то это ошибка архитекторов, за которую их бьют Если сравнивать проект системы с эскизом, то всё понятно — никакой рефакторинг, ни изменение набора фич, не превратят дворец в стадион — это принципиально разные продукты. А если сравнивать проект с чертежом? Мне почему-то трудно представить систему, которую нельзя рефакторить вообще. Имеется ввиду, существенно рефакторить — изменить архитектуру классов, удалять и вводить сущности.
Re: UML-модели и чертёжи дома - неправильная аналогия
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.07.05 06:13
Оценка: 8 (1)
Здравствуйте, Кодёнок

Кё>Правильная аналогия такая:


Кё>проектирование = рисование эскиза (архитектура, выраженная UML-схемами = ПРИМЕРНЫЙ образ готовой системы)

Кё>кодирование = рисование чертежа (исходный код = чертёж)
Кё>сборка = строительство
Кё>тестирование,
Кё>внедрение.

По-моему, вот здесь: Джек Ривз. Как проектировать ПО?
Автор: Зверёк Харьковский
Дата: 21.05.05
на эту темы Зверек Харьковский попробовал разговор завести. По крайней мере, в статье, на которую указал Зверек, автор пытался говорить об этом:

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

... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: UML-модели и чертёжи дома - неправильная аналогия
От: Кодёнок  
Дата: 05.07.05 06:26
Оценка:
E>По-моему, вот здесь: Джек Ривз. Как проектировать ПО?
Автор: Зверёк Харьковский
Дата: 21.05.05
на эту темы Зверек Харьковский попробовал разговор завести. По крайней мере, в статье, на которую указал Зверек, автор пытался говорить об этом:


+
Да, это именно то, о чём я думаю.
Re[3]: UML-модели и чертёжи дома - неправильная аналогия
От: Кодёнок  
Дата: 05.07.05 06:59
Оценка: +1
Кё>+
Кё>Да, это именно то, о чём я думаю.

Ещё я думаю, что люди не принимают идеи XP и вообще идею "код = проект", потому что императивные языки, на которых все пишут, в своей сути слишком тупы для выражения идей. Возрастающая сложность ПО неизбежно приведет к использованию декларативного программирования, и вот тогда всё встанет на свои места.
Re[4]: UML-модели и чертёжи дома - неправильная аналогия
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.07.05 07:09
Оценка: +3
Здравствуйте, Кодёнок, Вы писали:


Кё>>+

Кё>>Да, это именно то, о чём я думаю.

Кё>Ещё я думаю, что люди не принимают идеи XP и вообще идею "код = проект", потому что императивные языки, на которых все пишут, в своей сути слишком тупы для выражения идей. Возрастающая сложность ПО неизбежно приведет к использованию декларативного программирования, и вот тогда всё встанет на свои места.


Боюсь, что это место будет называться нецензурным именем какого-нибудь человеческого органа.

Я это говорю просто исходя из того, что "серебрянной пули" не сущесвует. Не нужно ожидать, что придет какая-то технология или подход к программированию (проектированию) и все станет на порядок проще и легче.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: UML-модели и чертёжи дома - неправильная аналогия
От: Кодёнок  
Дата: 05.07.05 07:43
Оценка: 21 (3)
E>Я это говорю просто исходя из того, что "серебрянной пули" не сущесвует. Ну нужно ожидать, что придет какая-то технология или подход к программированию (проектированию) и все станет на порядок проще и легче.

Зачем так сразу называть это серебрянной пулей.

С созданием высокоуровневых языков многое стало на порядок проще и легче. С вводом шаблонов в С++ язык преобразился, и многое стало куда проще и легче. Согласен? Только для того и создаются новые технологии, методики, инструменты, для чего же ещё? Растёт сложность — изменяются средства выражения наших требований, становятся более абстрактными.

Сейчас уже наверное все понимают, что наиболее читабельный вариант для определения функции сортировки массива, это

"Из всех элементов массива A составить массив R так, чтобы каждый элемент был меньше последующего"
"Переупорядочить элементы массива A так, чтобы каждый элемент был меньше последующего"

чем

"определить переменную a, присвоить ей ноль, определить пер. b, присвоить ей длину массива A, определить переменную x, ... лень писать дальше — я думаю, все понятно "

или

цикл для переменной i от нуля до длины A-1:
  определить переменную minIndex = i
  цикл для переменной j от i+1 до длины A:
    если minIndex-й элемент A > j-го элемента A, то присвоить minIndex j
  если minIndex не равен i, поменять местами элементы i-й и minIndex-й


На пути к такому счастью есть несколько нетривиальных практических проблем но они будут решены.

На императивном языке неочевидно, что программа — это проект, потому что инструкции компонуются как шестерёнки, а их смысл остаётся в комментариях, названиях методов или в голове у программиста. На декларативном это очевидно. Даже если синтаксис у него не такой сладкий, как у меня, а такой, как у современных Прологи и Хаскели

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

Популярный сейчас Design by contract тоже говорит в пользу декларативного программирования. Когда в начале и в конце функции сортировки ты пишешь assert/require/ensure, ты пишешь свои требования к данным и результату явно. Т.о. внутри функции могут быть нагромождения алгоритмов, но в конце явно прописан ensure, из которого ясно, что мы просто хотим получить отсортированный массив.

В общем, декларативное программирование придёт, оно будет не серебрянной пулей, но переворотом совершенно точно. Современные средства выражения замысла программиста просто не справляются со своей задачей, для того и придумали злосчастный UML и другие нотации Для того и рекомендуется использовать boost::noncopyable вместо скрытия конструктора копирования и оператора =. Про ассерты уже сказал. Сюда же атрибуты. И так далее. Всё это для лучшего выражения, чтобы код прямо отражал замысел, т.е. был в буквально смысле чертежом, проектом. Это первые ласточки.
Re[2]: UML-модели и чертёжи дома - неправильная аналогия
От: Кодёнок  
Дата: 05.07.05 07:52
Оценка:
Здравствуйте, eao197, Вы писали:

E>По-моему, вот здесь: Джек Ривз. Как проектировать ПО?
Автор: Зверёк Харьковский
Дата: 21.05.05
на эту темы Зверек Харьковский попробовал разговор завести. По крайней мере, в статье, на которую указал Зверек, автор пытался говорить об этом:


Кстати, во второй статье Дмитрий Завалишин с первого абзаца показал, что не понял, о чем вообще Джек Ривз пишет

Рассуждения автора сводятся к простой мысли: кодирование — это не черная и тупая работа.

Кодирование — это принятие решений, и кодер — такой же участник процесса проектирования, как и архитектор проекта.


И дальше по тексту опять сравнивает построение программы со строительством дома.

Утверждение «Исходный код является последней стадией проектирования» имеет такое же право на жизнь, как и утверждение «Дом является последней стадией проектирования». Нравится? Правда, нравится? Давайте я проиллюстрирую построение дома по технологии экстремального программирования.

  • Вы (будущий житель) приходите на стройку к рытью котлована и сидите за спиной у тракториста. Воняет? Купите одеколону. Сидеть придется до готовности дома.


  • Вообщем, не в плюс редактору, что он это вообще пропустил.

    Даже если сравнивать с набившим оскомину строительством, что неверно, то должно быть:

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

    Строительство (сборка программы) происходит автоматически без участия людей. Это делает робот-компилятор Благодаря волшебному компьютеру вы можете за один день построить дом, пожить в нём, затем сломать и затем ещё много раз строить заново, пока не получите приемлемый результат.
    Re[6]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 07:58
    Оценка: 3 (2)
    Здравствуйте, Кодёнок, Вы писали:

    E>>Я это говорю просто исходя из того, что "серебрянной пули" не сущесвует. Ну нужно ожидать, что придет какая-то технология или подход к программированию (проектированию) и все станет на порядок проще и легче.


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


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

    Ну научимся мы декларативно описывать сортировки, поиск максимального или минимального элементов массива, проверки наличия файла с нужным именем и т.д. Но тогда встанет вопрос о том, как все эти декларации объединить для решения реальной задачи. Скажем обеспечения безопасности on-line платежей в Интернете.

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

    Собственно, у меня проблемы чаще с тем, что я не знаю, что именно нужно сделать. Затем я не знаю как именно это сделать. А когда у меня такие знания появляются, записать их в том или ином виде уже не проблема.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[3]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 07:59
    Оценка:
    Кё>Кстати, во второй статье Дмитрий Завалишин с первого абзаца показал, что не понял, о чем вообще Джек Ривз пишет

    В каждом абзаце, кроме этого, непонимание главной идеи:

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


    А вот тут Дмитрий прямо в точку попал. Надо поднимать уровень кода. Но автор мыслит о "коде" как исключительно о примитивных командах, поэтому видит только один путь — отказаться от его написания.
    Re[5]: UML-модели и чертёжи дома - неправильная аналогия
    От: Дарней Россия  
    Дата: 05.07.05 08:18
    Оценка:
    Здравствуйте, eao197, Вы писали:

    E>Я это говорю просто исходя из того, что "серебрянной пули" не сущесвует. Не нужно ожидать, что придет какая-то технология или подход к программированию (проектированию) и все станет на порядок проще и легче.


    Я так подозреваю, что сам Брукса ты не читал.
    Когда он писал "серебряной пули не существует", то имел в виду, что нельзя упростить на порядок весь процесс разработки ПО. По той простой причине, что основная сложность в разработке — это анализ и проектирование. Но упростить на порядок процесс реализации ПО можно.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[6]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 08:32
    Оценка:
    Здравствуйте, Дарней, Вы писали:

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


    E>>Я это говорю просто исходя из того, что "серебрянной пули" не сущесвует. Не нужно ожидать, что придет какая-то технология или подход к программированию (проектированию) и все станет на порядок проще и легче.


    Д>Я так подозреваю, что сам Брукса ты не читал.


    Читал, но давно.

    Д>Когда он писал "серебряной пули не существует", то имел в виду, что нельзя упростить на порядок весь процесс разработки ПО. По той простой причине, что основная сложность в разработке — это анализ и проектирование. Но упростить на порядок процесс реализации ПО можно.


    Основная сложность в разработке ПО -- это получить работающий продукт. Вообще. Еще сложнее получить его вовремя и в рамках бюджета.

    Естественно, что новые инструменты позволяю решать стоящие сегодня задачи проще, быстрее. Но освободившееся время будет сразу же занято либо увеличением количества кода на одного разработчика, либо переходом на задачи, для которых новые инструменты не так хорошо приспособлены. Это, имхо, замкнутый круг.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[7]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 09:20
    Оценка:
    E>Имхо, более глобальная проблема не в выборе конкретной нотации (имперической или декларативной), а в том, что с помощью этих нотаций нужно записывать -- в идеях. Которые почему-то просто так не приходят или приходят всегда слишком поздно. И почему-то мутные, не четкие, какие-то. И ошибочные чаще всего.

    Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

    E>Собственно, у меня проблемы чаще с тем, что я не знаю, что именно нужно сделать. Затем я не знаю как именно это сделать. А когда у меня такие знания появляются, записать их в том или ином виде уже не проблема.


    Если бы ты писал на ассемблере, то ты бы до сих пор возможно решал какую-нибудь частную задачу из разряда "как это сделать". Если бы писал на Си, справился бы быстрее. На "паскале с объектами" ещё быстрее. Суть в том, что когда идея пришла и тебе уже ясно, что нужно получить, то всё остальное — черновая, тривиальная работа. Если её переложить на компилятор и другие тулсы, ты один сможешь гораздо больше, реализовать более сложный проект. За счёт этого высокоуровневые инструменты и давали прирост производительности, и будут давать в будущем.
    Re[7]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 09:30
    Оценка:
    E>Основная сложность в разработке ПО -- это получить работающий продукт. Вообще. Еще сложнее получить его вовремя и в рамках бюджета.

    Я не раз слышал высказывание, "зачем нужны новые языки, когда есть С++, который всё может". Ассемблер тоже всё может. А хекс-едитор может больше всех. Но это всё неправильно, потому что вопрос надо ставить не так, "что может язык", потому что он не живой и сам вообще ничего не может. Вопрос надо ставить, что может один и тот же программист с помощью разных инструментов. Ты же не станешь отрицать, что с помощью С++ за то же время сделаешь больше, чем на ANSI C. Так что новые (в смысле, качественно новые) инструменты и призваны эту основную сложность устранять.

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

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


    Вот в выделеном и кроется разногласие. Количество кода на разработчика должно сокращаться! Новые языки, библиотеки как раз сокращают количество кода на разработчика. В идеале, кодом должны быть требования к программе. Конечно, я имею виду очень детальные требования, а не то, что говорит заказчик
    Re[8]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 09:37
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

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


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


    Боюсь, мне нужно пояснить этот момент. Представь, что у нас есть разработчик, который делает задачу X. На языке Y с инструментом Z эта задача у него занимает 2 часа. Затем, ему в руки дают инструмент S и эта же задача будет решена за 1 час. Как ты думаешь, что будет делать разработчик с одним освободившимся часом? Имхо, он получит задачу X2, на которую он этот час и потратит. Т.е. как пахал он full-time, так и будет пахать. Если платят ему за это одинаково, то все это смена шила на мыло. И мне кажется, что с переходом на инструмент S стоимость его труда не увеличится, т.к. стоимость работ X и X2 просто сократится в два раза и все.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[9]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 09:51
    Оценка:
    E>Боюсь, мне нужно пояснить этот момент. Представь, что у нас есть разработчик, который делает задачу X. На языке Y с инструментом Z эта задача у него занимает 2 часа. Затем, ему в руки дают инструмент S и эта же задача будет решена за 1 час. Как ты думаешь, что будет делать разработчик с одним освободившимся часом? Имхо, он получит задачу X2, на которую он этот час и потратит. Т.е. как пахал он full-time, так и будет пахать. Если платят ему за это одинаково, то все это смена шила на мыло. И мне кажется, что с переходом на инструмент S стоимость его труда не увеличится, т.к. стоимость работ X и X2 просто сократится в два раза и все.

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

    Ты уж тогда не лукавь, а скажи честно: хочу получать $100'000 в месяц не работая вообще
    Re[8]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 10:00
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:


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


    Кё>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.


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

    Проблема в том, что компьютер -- это черезвычайно и покладистый и тупой исполнитель -- он делает в точности то, что ты ему говоришь. И если он делает что-то не то, значит твои слова не согласовываются с твоими идеями. Значит твоя идея не настолько кристально ясна, чтобы однозначно ее задекларировать.




    А приведенный тобой пример "направить электрические..." уже давно в эмпирических языках решается библиотеками и декомпозицией приложения на разные уровни абстракции.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 10:17
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    E>>Боюсь, мне нужно пояснить этот момент. Представь, что у нас есть разработчик, который делает задачу X. На языке Y с инструментом Z эта задача у него занимает 2 часа. Затем, ему в руки дают инструмент S и эта же задача будет решена за 1 час. Как ты думаешь, что будет делать разработчик с одним освободившимся часом? Имхо, он получит задачу X2, на которую он этот час и потратит. Т.е. как пахал он full-time, так и будет пахать. Если платят ему за это одинаково, то все это смена шила на мыло. И мне кажется, что с переходом на инструмент S стоимость его труда не увеличится, т.к. стоимость работ X и X2 просто сократится в два раза и все.


    Кё>Так к этому же и стремимся.


    Как в анекдоте, почти:

    Октябрь 17-го. По улицам Петрограда бегают вооруженные люди, что-то происходит, какой-то шум, гам...
    Внучка декабриста спрашивает у своей служанки:
    -- Что это там происходит?
    -- Это революция барышня.
    -- Революция! Ведь мой дед так же мечтал о революции! А чего хотят революционеры?
    -- Хотят, чтобы не было богатых.
    -- ?! Странно... А мой дед хотел, чтобы не было бедных.


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


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

    Кё>Ты уж тогда не лукавь, а скажи честно: хочу получать $100'000 в месяц не работая вообще


    Нет, 100'000 не хочу. Тем более, если ничего не делать. Тут уж речь нужно вести о миллионах

    Если же говорить серьезно, то, поскольку программирование для меня не только работа но и пагубное увлечение с неискореннимым креном в велосипедостроение, то мое желание формулируется очень просто: иметь возможность выпускать собственные велосипеды и чтобы эти велосипеды были востребованны. Даже если ради этого придется пахать, как папа Карло.

    Как говорил Линус Торвальдс: когда вопрос о выживании не стоит, то все делается just for fun.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[9]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 10:18
    Оценка:
    Кё>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

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


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

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

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

    E>А приведенный тобой пример "направить электрические..." уже давно в эмпирических языках решается библиотеками и декомпозицией приложения на разные уровни абстракции.


    Плохо решается. Можно лучше.
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 10:32
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    Кё>>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.


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


    Кё>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.


    Так, имхо, именно этим программисты сейчас и занимаются.

    А постановка экспериментов подстановка чисел в алгоритм -- это ты о чем?

    E>>А приведенный тобой пример "направить электрические..." уже давно в эмпирических языках решается библиотеками и декомпозицией приложения на разные уровни абстракции.


    Кё>Плохо решается. Можно лучше.


    Извини, но здесь мне хочется вспомнить: "Ба! Вы не любите кошек? Вы просто не умеете их готовить!" ((C) народный фольклер).
    Конечно же все улучшается. Но гораздо медленнее, чем нам хотелось бы. И принципиальных прорывов здесь, имхо, не будет. Разве что заменят программирование чем-то другим.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[11]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 10:40
    Оценка:
    E>Если же говорить серьезно, то, поскольку программирование для меня не только работа но и пагубное увлечение с неискореннимым креном в велосипедостроение, то мое желание формулируется очень просто: иметь возможность выпускать собственные велосипеды и чтобы эти велосипеды были востребованны. Даже если ради этого придется пахать, как папа Карло.

    E>Как говорил Линус Торвальдс: когда вопрос о выживании не стоит, то все делается just for fun.


    А велосипеды у тебя никто не отнимет. Как не отнимали ассебмлер у хакеров. Просто появились другие альтернативы, и ассемблер помер сам. Он не исчез, у него всё еще есть применение. Кто хочет — пишите Но с появлением альтернатив уже не стоит труда доказать, что целесообразнее выбрать в качестве основного языка для своего продукта.

    Вот и я предлагаю — сделаем альтернативу, а там посмотрим. Быть С++ или не быть С++. А за свой хлеб не волнуйся, умный не пропадёт, а дуракам ничто не поможет

    P.S. Я часто пишу программу сначала в комментариях:

    // read directory
    ;
    // for each file name
    ;
    //// if directory
    ;
    //// if file
    ;


    И потом вписываю инструкции. Когда я полностью придумал, что надо сделать, писать код уже неинтересно — это черновая работа. Редко попадается какая-нибудь чисто практическая задача (фактически, по обману компилятора или синтаксиса С++), которую интересно решить.

    И эти комментарии в идеале должны быть программой. Мне куда интереснее, чтобы компьютер что-нибудь делал, рисовал там, или дудел, чем тупо писать одну старую идиому за другой. Уже давно надоело объяснять ему на пальцах, какой байт куда положить. Самый тупой раб на его месте уже бы давно научился, и стал понимать комментарии Настала пора обучить компьютер не просто развёртывать for (;) в инструкции, образующие цикл, а применять те же шаблоны и выученные алгоритмы, которые я применяю. А нетривиальные задачи я возьму себе, какого уровня — низкого или высокого — они не были.
    Re[7]: UML-модели и чертёжи дома - неправильная аналогия
    От: Дарней Россия  
    Дата: 05.07.05 10:43
    Оценка: +1
    Здравствуйте, eao197, Вы писали:

    E>Основная сложность в разработке ПО -- это получить работающий продукт. Вообще. Еще сложнее получить его вовремя и в рамках бюджета.


    Ну это и ежу понятно. Но задачу надо все-таки деструктурировать.

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


    То же самое можно про процессоры сказать. Хоть их быстродействие и повысилось на порядки, аналогичного прироста в скорости работы ПК не наблюдается, скорее даже наоборот. Даже на кассетном спектруме среда разработки грузилась быстрее, чем сейчас на моем компе
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
    Re[11]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 10:50
    Оценка:
    Кё>>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.

    E>Так, имхо, именно этим программисты сейчас и занимаются.


    Нет, они по большей части эти требования реализуют — пишут код.

    E>А постановка экспериментов подстановка чисел в алгоритм -- это ты о чем?


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

    Кё>>Плохо решается. Можно лучше.


    E>Извини, но здесь мне хочется вспомнить: "Ба! Вы не любите кошек? Вы просто не умеете их готовить!" ((C) народный фольклер).

    E>Конечно же все улучшается. Но гораздо медленнее, чем нам хотелось бы. И принципиальных прорывов здесь, имхо, не будет. Разве что заменят программирование чем-то другим.

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

    А по поводу "принципиальных улучшений не будет" — президент IBM когда-то не верил, что компьютеры станут покупать, поищи в хуморе этот старый баян
    Re[8]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 10:51
    Оценка: +2
    Здравствуйте, Кодёнок, Вы писали:


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


    Кё>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.


    И кто мешает написать функцию:

    ПоднятьРуку( Правую )

    или вызвать метод:

    Человек.Конечности.Рука.Поднять( ... )


    Дело в том, что инструкции вида:

    "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц".

    — всё равно придётся выполнять. Законы природы не обманешь. Если тебе нужно, что бы поднялась правая рука и на 15 градусов в бок — это всё равно придётся описывать или — расплатой будет то, что операции будут слабоуправляемы (если большинство параметров зашиты внутри).
    Поскольку компьютер сам не в состоянии придумать, что нужно делать, то абсолютно всё равно в каком виде ему отдавать команды — в императивном ли, в декларативном ли — всё равно где то придётся их описывать. Кто, где и как за тебя опишет в любой программе — что конкретно должно означать "Поднять руку"?
    Вот потому декларативное программирование — как и функциональное — хорошо работает, пока речь идёт о известных (т.е. реализованных в библиотеке) вещах — вроде сортировки или foreach. А как только начинается практическая работа — как то отдача чётких инструкций оборудованию — всякая красота или пропадает (у неумелого разработчика) — или определяется тем, какую архитектуру для описания своих задач придумает разработчик.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 10:55
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    E>>Если же говорить серьезно, то, поскольку программирование для меня не только работа но и пагубное увлечение с неискореннимым креном в велосипедостроение, то мое желание формулируется очень просто: иметь возможность выпускать собственные велосипеды и чтобы эти велосипеды были востребованны. Даже если ради этого придется пахать, как папа Карло.


    E>>Как говорил Линус Торвальдс: когда вопрос о выживании не стоит, то все делается just for fun.


    Кё>А велосипеды у тебя никто не отнимет.


    Не скажи. Ведь есть же где-то благословенные места, где программистам говорят -- мы должны что-то изобрести! Чтобы не как у других!
    Но на эту тему я уже распостранялся: Re[4]: Джек Ривз. Как проектировать ПО?
    Автор: eao197
    Дата: 22.05.05
    .
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[8]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 10:55
    Оценка:
    Здравствуйте, Дарней, Вы писали:

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


    Д>То же самое можно про процессоры сказать. Хоть их быстродействие и повысилось на порядки, аналогичного прироста в скорости работы ПК не наблюдается, скорее даже наоборот. Даже на кассетном спектруме среда разработки грузилась быстрее, чем сейчас на моем компе


    Так и будем бегать по замкнутому кругу
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 11:00
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    Кё>>>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.


    E>>Так, имхо, именно этим программисты сейчас и занимаются.


    Кё>Нет, они по большей части эти требования реализуют — пишут код.


    Так ведь это и есть самое детальное изложение собственных (ну или чужих) идей.

    E>>А постановка экспериментов подстановка чисел в алгоритм -- это ты о чем?


    Кё>А том, что ты заранее не знаешь, сколько секунд и какой силы импульсы надо отправлять, и должен их сам просчитать и затем полученные числа использовать. Хотя компьютер это в состоянии сделать сам. Проблема лишь в том, как ему дать такое задание? Сейчас такое задание дается как последовательность команд императивного языка. Фактически, как калькулятор с отложенным вычислением. А можно по-другому.


    Мне кажется, что ты передергиваешь. Для многих задач уже все величины известны. Нужно только правильно огранизовать их использование.

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


    Ну что же, если такое произойдет, то будем приспосабливаться.

    Кё>А по поводу "принципиальных улучшений не будет" — президент IBM когда-то не верил, что компьютеры станут покупать, поищи в хуморе этот старый баян


    Ну я не обижусь, если по такому поводу мои слова затем в хуморе окажутся. В таких вещах гораздо приятнее ошибаться, чем убеждаться в собственной правоте.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re: UML-модели и чертёжи дома - неправильная аналогия
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 05.07.05 11:01
    Оценка:
    Здравствуйте, Кодёнок,

    Естественно. Компиляция программы — вот он самый настоящий аналог строительства дома. Это описано у классиков, но точно не помню где, кажется: Брукс "Мифический человекомесяц".
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 11:05
    Оценка:
    Кё>>А велосипеды у тебя никто не отнимет.

    E>Не скажи. Ведь есть же где-то благословенные места, где программистам говорят -- мы должны что-то изобрести! Чтобы не как у других!

    E>Но на эту тему я уже распостранялся: Re[4]: Джек Ривз. Как проектировать ПО?
    Автор: eao197
    Дата: 22.05.05
    .


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

    Это проблема наемной работы в любой области, зачем новые идеи из-за этого останавливать-то?
    Re[9]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 11:16
    Оценка:
    Кё>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.

    AF>И кто мешает написать функцию:

    AF> ПоднятьРуку( Правую )
    AF>или вызвать метод:
    AF> Человек.Конечности.Рука.Поднять( ... )

    Это у тебя получилось, потому что "поднять руку" по своей сути императивная инструкция, я слишком всё упростил.

    "Через 10 секунд у робота правая рука должна быть поднята вертикально вверх" — вот так примерно выглядит декларативное описание. Сравни это с императивной реализацией:

    робот.начать_поднимание_руки(правая, (тут полярные координаты нужного положения ) )
    пока (прошедшее_время < 10 сек)
    ничего не делать;
    робот.получить_состояние_правой_руки
    ...тут генерировать исключение, если не успел...


    Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком

    Сейчас управление компьютером сводится к выдаче команд, но скорости мысли обычных людей не хватает, чтобы писать большие системы. Качественный скачок может быть, только если свести управление компьютером к выдаче требований.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 11:27
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    Кё>>>А велосипеды у тебя никто не отнимет.


    E>>Не скажи. Ведь есть же где-то благословенные места, где программистам говорят -- мы должны что-то изобрести! Чтобы не как у других!

    E>>Но на эту тему я уже распостранялся: Re[4]: Джек Ривз. Как проектировать ПО?
    Автор: eao197
    Дата: 22.05.05
    .


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


    Для создания компании и обеспечения ее жизнеспособности нужны некоторые специфические качества.
    Кроме того, есть и третий путь -- убедить руководство твоей компании вложится в твою идею. Google, имхо, такой подход практикует.

    Кё> А наёмная работа по определению предполагает реализацию идей начальника, каков бы его уровень понимания не был.


    А в научно-исследовательских центрах крупных корпораций по-твоему не наемные рабочие работают?
    Или ты думаешь, что Грослинг Java придумывал дома для удовольствия?

    Кё> В чем твоя проблема-то? Не нравится, что индустрия разработки ПО работает не в твою пользу, даёт не те задания, которые тебе интересны?


    Индустрия вообще не дает знаний, имхо, она их потребляет.
    Кроме того, публичный форум совсем не место для осуждения личных проблем.

    Кё>Это проблема наемной работы в любой области, зачем новые идеи из-за этого останавливать-то?


    Новые идеи должны доказывать свое право на жизнь. Вот сейчас ты и пытаешься доказать жизнеспособность своей идеи (четкость которой, имхо, не мешало бы повысить).
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re: UML-модели и чертёжи дома - неправильная аналогия
    От: Ranger_XL  
    Дата: 05.07.05 11:37
    Оценка: +1
    ИМХО, в принципе неправильно проводить параллели между строительством (или чем-нибудь еще) и разработкой программ. Понятно, что многие процессы разработки ПО были заимстовваны из традиционных отраслей. Но это только усугубляет. Потому что существует принципиальная разница между software и hardware engeneering! (не буду перечислять, об этом столько раз уже писали классики.)
    Пока эта разница не будет до конца осознана, успешная разработка средних и крупных проектов по-прежнему будет оставаться героическим делом!
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 11:40
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    Кё>>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.


    Кё>"Через 10 секунд у робота правая рука должна быть поднята вертикально вверх" — вот так примерно выглядит декларативное описание. Сравни это с императивной реализацией:

    Кё>

    Кё>робот.начать_поднимание_руки(правая, (тут полярные координаты нужного положения ) )
    Кё>пока (прошедшее_время < 10 сек)
    Кё> ничего не делать;
    Кё>робот.получить_состояние_правой_руки
    Кё>...тут генерировать исключение, если не успел...


    Кё>Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком


    Скорее это твоя попытка сделать неудачное решение императивным подходом. Что тебе мешало записать так:
    робот.начать_понятие_руки( правая, координаты, ограничение_по_времени( 10мин ) )
    /* никаких проверок не делаем, если в заданное время не уложились,
        то исключение будет сгенерированно автоматически */
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 11:46
    Оценка: +2
    Здравствуйте, Кодёнок, Вы писали:

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


    Каких требований? В какой парадигме будут формулироваться требования? В объектной? В логической? В императивной? В ...?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 11:46
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    Кё>>>Всё это и будет являться работой программиста — сделать требования чёткими. А не просчитывать заранее и не ставить эксперименты с силой импульсов, чтобы потом полученные числа подставить в алгоритм.

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

    Процитирую перевод с Programmer's Stone:

    Мы инженеры-программисты. Почему? Для чего служит программная инженерия? Что делают инженеры-программисты? Мы получаем самые курьезные ответы на этот вопрос. Один чудак сказал: "Они следуют процедурам Стандартов Программной Инженерии!" Другой добавил: "Они переформулируют (transliterate) требования!"

    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[15]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 11:46
    Оценка:
    E>Для создания компании и обеспечения ее жизнеспособности нужны некоторые специфические качества.
    E>Кроме того, есть и третий путь -- убедить руководство твоей компании вложится в твою идею. Google, имхо, такой подход практикует.

    С третьим путём далеко не уедешь. Для компании всегда на первом месте будет прибыль, а зарплата и благополучие работников по минимуму, чтобы продолжали работать. Хочешь свободы — летай один закон жизни.

    E>А в научно-исследовательских центрах крупных корпораций по-твоему не наемные рабочие работают?

    E>Или ты думаешь, что Грослинг Java придумывал дома для удовольствия?

    А я не говорил, что начальство принципиально не будет брать твои идеи. Но брать строго каждую и вообще работать ради твоего блага тоже не будет.

    Собственно, сейчас, если ты хочешь повысить свою квалификацию, или попробовать применить Лисп в проекте, или попробовать редизайнить программу с применением какой-нибудь интересной методологии, тебя скорее попросят делать это не на работе и не с основной веткой Если это удастся, идею возьмут с охотой, и поощрить могут, но суть останется одна: исследованием, созданием нового, творчеством ты занимаешься сам, по своей инициативе. Не надо мечтать о "правильном начальнике", которые тебе все условия создаст.

    Кё>>Это проблема наемной работы в любой области, зачем новые идеи из-за этого останавливать-то?


    E>Новые идеи должны доказывать свое право на жизнь. Вот сейчас ты и пытаешься доказать жизнеспособность своей идеи (четкость которой, имхо, не мешало бы повысить).


    Идея ничего никому доказать не может. Если ты сам её продвинешь, вложишь достаточное количество усилий и времени, этим ТЫ докажешь её право на жизнь. Сколько примеров, когда не лучшее живёт, а лучшее помирает, просто потому, что в нелучшее случайно вложили больше усилий. Проблем с наличием идей и их продвижением никогда не было, главная проблема в наличии людей, которые за это возьмутся. Все или ждут волшебника, который даст $10M и все условия для исследований, либо согласны только на обычную работу без гарантии результата. Ни то, ни другое не является приклекательным для инвестиций.
    Re[16]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 12:00
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    E>>Для создания компании и обеспечения ее жизнеспособности нужны некоторые специфические качества.

    E>>Кроме того, есть и третий путь -- убедить руководство твоей компании вложится в твою идею. Google, имхо, такой подход практикует.

    Кё>С третьим путём далеко не уедешь.


    Мне кажется, что эта твоя фраза как раз противоречит твоему же примеру с IBM.

    Кё>Собственно, сейчас, если ты хочешь повысить свою квалификацию, или попробовать применить Лисп в проекте, или попробовать редизайнить программу с применением какой-нибудь интересной методологии, тебя скорее попросят делать это не на работе и не с основной веткой Если это удастся, идею возьмут с охотой, и поощрить могут, но суть останется одна: исследованием, созданием нового, творчеством ты занимаешься сам, по своей инициативе.


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

    E>>Новые идеи должны доказывать свое право на жизнь. Вот сейчас ты и пытаешься доказать жизнеспособность своей идеи (четкость которой, имхо, не мешало бы повысить).


    Кё>Идея ничего никому доказать не может. Если ты сам её продвинешь, вложишь достаточное количество усилий и времени, этим ТЫ докажешь её право на жизнь.


    Так ведь я же тебе и говорю: доказывай свою идею о том, что императивный подход способен изменить подход к разработке.
    Пока речь идет о фантазиях, о том, что "хорошо бы что бы". Если это фантазии, то давай к ним и относится как к фантазиям. Если же ты веришь в это, если у тебя есть идея -- озвучь ее, дай потрогать. Чтобы практикой скепсис развееть.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: Ranger_XL  
    Дата: 05.07.05 12:11
    Оценка:
    Можно сказать и так: программисты переводят (транслируют) инженерные представления в код.
    Re[11]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 12:16
    Оценка:
    Кё>>Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком

    E>Скорее это твоя попытка сделать неудачное решение императивным подходом. Что тебе мешало записать так:

    E>робот.начать_понятие_руки( правая, координаты, ограничение_по_времени( 10мин ) )
    E>/* никаких проверок не делаем, если в заданное время не уложились,
    E> то исключение будет сгенерированно автоматически */

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

    начать_поднятие_руки
    поднять_руку
    начать_поднятие_рук
    поднять_руки
    начать_поднятие_ноги
    поднять_ногу

    и т.д. Это я для понятности говорю, на самом деле кода не должно быть.

    И исключение у тебя генерируется не автоматически, а вручную, в реализации метода, и в методах "начать_" ты сам создаёшь поток. И всё это, в принципе, шаблонные действия, которые можно делать в лоб, можно предусмотреть какой-нибудь абстрактный фреймворк, но в идеале компьютер это должен делать сам.

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

    E>Так ведь я же тебе и говорю: доказывай свою идею о том, что декларативный подход способен изменить подход к разработке.

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

    Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 12:22
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:

    E>>Пока речь идет о фантазиях, о том, что "хорошо бы что бы". Если это фантазии, то давай к ним и относится как к фантазиям. Если же ты веришь в это, если у тебя есть идея -- озвучь ее, дай потрогать. Чтобы практикой скепсис развееть.


    Кё>Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.


    А, тогда понятно. Фантазии -- это и интересно, и полезно.
    Только дальше я пас. Велосипедостроение от фантазирования отличается тем, что велосипед обязательно нужно заставить ездить. И это у меня, имхо, получается. Этим я и продолжу заниматься.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 12:24
    Оценка: 10 (1) +1
    Здравствуйте, Кодёнок, Вы писали:


    Кё>>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.


    AF>>И кто мешает написать функцию:

    AF>> ПоднятьРуку( Правую )
    AF>>или вызвать метод:
    AF>> Человек.Конечности.Рука.Поднять( ... )

    Кё>Это у тебя получилось, потому что "поднять руку" по своей сути императивная инструкция, я слишком всё упростил.


    Кё>"Через 10 секунд у робота правая рука должна быть поднята вертикально вверх" — вот так примерно выглядит декларативное описание. Сравни это с императивной реализацией:

    Кё>

    Кё>робот.начать_поднимание_руки(правая, (тут полярные координаты нужного положения ) )
    Кё>пока (прошедшее_время < 10 сек)
    Кё> ничего не делать;
    Кё>робот.получить_состояние_правой_руки
    Кё>...тут генерировать исключение, если не успел...


    Это мы жулничаем — сравниваем вещи разного уровня. Ты бы ещё дезасемблировал программу. Адекватный императивный код выглядит так:
    Ждать( 10 секунд )
    Робот.правая_рука.поднять( вертикально_вверх )

    Ты ведь нигде в императивном коде не специфицировал реализацию того, как именно будет обеспечиваться поднятие руки — а ведь это должно быть где то описано. Но если это выносить за скобки — то императивная реализация выглядит столь же очевидной, что и функциональная.

    Кё>Просто современные декларативные языки ещё на примитивном уровне. Я о более высоком

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

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

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

    Через 10 секунд у робота правая рука должна быть поднята вертикально вверх


    Придётся писать:
    Через 10 секунд у робота правая рука должна быть поднята вертикально вверх. Поднятие руки нужно делать медленно (за 2 секунды), с плавным поворотом ладонью вперёд (скорость поворота 90 градусов за 2 секунды). Амплитуда случайных колебаний (используется иммитация естественного движения) должна находится в диапазоне от 3 до 5% от максимальной амплитуды движения для заданной степени свободы.....

    А потом — всё это ещё и реализовывать! Вот где песня то будет!

    О чём забывают фанаты декларативных языков — так это о том, что ДЯ появились одновременно с императивными. Но большого развития не получили. Интересно — почему это?
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 12:34
    Оценка: +2
    Здравствуйте, Ranger_XL, Вы писали:

    R_X>Можно сказать и так: программисты переводят (транслируют) инженерные представления в код.


    ИМХО, тоже чудаковатый вариант. Я как-то привык считать, что программисты воплощают свои представления о структуре той или иной предметной области. Иначе программированием просто неинтересно заниматься.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 12:37
    Оценка: 1 (1)
    Аналогия вещь опасная и пользоваться ей нужно очень осторожно. Если абсолютно всё, что можно было бы сказать о строительстве, можно было бы сказать о программировании и наоборот — то очевидно, что это были бы два названия для одного и того же. А это очень разные вещи. Если не веришь — оттащи мешок с цементом на 15-й этаж — мнение резко поменяется.
    Потому нет ничего удивительного, что ты легко можешь найти противоречия между обеими метфорами — ибо метафоры всё таки разные.
    Тем более, что никакого противоречия, которое ты усмотрел нет. Код — это чертежи программы для компилятора, UML и описание архитектуры — чертежи для разработчика — по которым он создаёт код. Описание системной архитектуры — это чертежи для архитекторов отдельных модулей, по которым они будут делать архитектуру модуля.
    Это как чертежи дома для дизайнера интерьера — который их использует для того, что бы разработать оформление интерьера и сделать списки для закупки мебели.
    Re[11]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 12:43
    Оценка:
    AF>Придётся писать:
    AF>Через 10 секунд у робота правая рука должна быть поднята вертикально вверх. Поднятие руки нужно делать медленно (за 2 секунды), с плавным поворотом ладонью вперёд (скорость поворота 90 градусов за 2 секунды). Амплитуда случайных колебаний (используется иммитация естественного движения) должна находится в диапазоне от 3 до 5% от максимальной амплитуды движения для заданной степени свободы.....

    AF>А потом — всё это ещё и реализовывать! Вот где песня то будет!


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

    А топик не в защиту декларативного стиля, это я просто предположение выдвинул. Топик про качественное изменение смысла кодирования.
    Re[15]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 12:49
    Оценка: 1 (1)
    ГВ>Здравствуйте, Ranger_XL, Вы писали:

    R_X>>Можно сказать и так: программисты переводят (транслируют) инженерные представления в код.


    ГВ>ИМХО, тоже чудаковатый вариант. Я как-то привык считать, что программисты воплощают свои представления о структуре той или иной предметной области. Иначе программированием просто неинтересно заниматься.


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

    Классической же аналогией является сравнения написания программы с построением дома из кирпичиков, что неверно. О чем я в начале написал.

    Если уж и сравнивать разработку со строительством, то заранее оговорить, что дом строится из чертежей сам, волшебным образом, максимум за полчаса. Что довольно странно, не так ли
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 12:49
    Оценка: :)
    Здравствуйте, Кодёнок, Вы писали:

    Кё>Вот реализовывать это компьютер как раз должен сам, из готовых паттернов


    В форумах "C/C++" и "C/C++. Прикладные вопросы" любимым волшебным словом является boost (ну прям лекарство от всех болезней ). А в "Философии программирования" волшебным словом, видимо, является "паттерн"
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[2]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 12:57
    Оценка:
    Здравствуйте, AndreyFedotov, Вы писали:

    AF> Аналогия вещь опасная и пользоваться ей нужно очень осторожно.

    AF> Потому нет ничего удивительного, что ты легко можешь найти противоречия между обеими метфорами — ибо метафоры всё таки разные.
    AF> Тем более, что никакого противоречия, которое ты усмотрел нет.

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

    Если архитектор ПО называется архитектором, то программиста по умолчанию отводят в строители, что аналогично, если смотреть на взаимодействие этих людей в команде, но неверно, если смотреть на получаемый результат. А мы ведь улучшаем результат, а не строим взаимоотношения в команде.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 12:58
    Оценка: 28 (2) +1
    Здравствуйте, Кодёнок, Вы писали:


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

    Кё>Пока речь идет о фантазиях, о том, что "хорошо бы что бы". Если это фантазии, то давай к ним и относится как к фантазиям. Если же ты веришь в это, если у тебя есть идея -- озвучь ее, дай потрогать. Чтобы практикой скепсис развееть.
    Любители фантазировать забывают, частенько, что далеко не от каждой фантазии бывает польза. Можно, конечно, фантазировать и так "кабы я лежал на диване, а компьютер за меня всё делал, и деньги сам приносил..." только этого не будет
    Такая же тупиковая мечта — это излагать компьютеру требования, что бы он сам их превращал в программу. Причём причина тупиковости очевидна — неоднозначность, объём описания и преобразование описаний в действия. Уж если человек часто не в состоянии понять требования, тем более однозначно — то что ты от машины хочешь?
    Ты не обратил внимания на маленькую деталь — для иллюстрации своей идеи ты использовал принипиально императивный пример — пример на уровне действий — то есть ты сам подсознательно выбрал весьма низкий логический уровень. И сделал это потому, что только на этом уровне можно более-менее понятно объяснить что ты имеешь в виду, не рискуя влезть в спор о терминах или идеологии.

    Кё>Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.

    Это фантазии на ту же тему, что была здесь
    Автор: Sshur
    Дата: 28.06.05
    . Там человек сделал ту же ошибку. На основе не верных аналогий он не правильно понял идею, заложенную в ООП в том конкретном случае он истактовал её, как "объект в программе всегда есть модель объекта реального мира" и движимый этой идеей предложил создать библиотеку классов для описания всех объектов во вселенной!
    Так вот то же самое я вижу и у тебя. Декларативное программирование вещь безусловно полезная, оно уже оказало существенное влияние на современные языки — в том числе C++ и C# — и некоторые архитектурные решения, есть не что иное, как попытка описывать программу в декларативном стиле. Но оно не имеет ничего общего с той гипретрофированной фантазией, о которой ты пишешь.

    Если когда-либо и будет достигнут тот уровень, о котором ты пишешь — это будет уже не программирование, а общение, и я не уверен, что то, с чем будет происходить общение можно будет назвать компьютером.
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 05.07.05 13:14
    Оценка: +1
    AF> Это фантазии на ту же тему, что была здесь
    Автор: Sshur
    Дата: 28.06.05
    . Там человек сделал ту же ошибку. На основе не верных аналогий он не правильно понял идею, заложенную в ООП в том конкретном случае он истактовал её, как "объект в программе всегда есть модель объекта реального мира" и движимый этой идеей предложил создать библиотеку классов для описания всех объектов во вселенной!

    AF> Так вот то же самое я вижу и у тебя. Декларативное программирование вещь безусловно полезная, оно уже оказало существенное влияние на современные языки — в том числе C++ и C# — и некоторые архитектурные решения, есть не что иное, как попытка описывать программу в декларативном стиле. Но оно не имеет ничего общего с той гипретрофированной фантазией, о которой ты пишешь.
    .
    AF> Если когда-либо и будет достигнут тот уровень, о котором ты пишешь — это будет уже не программирование, а общение, и я не уверен, что то, с чем будет происходить общение можно будет назвать компьютером

    Согласен. Меня немного занесло Вряд ли повышение уровня кода будет выглядеть именно так.

    Введение UML — не что иное, как попытка ввести высокоуровневую нотацию. Пусть она переводится в код вручную и не является 100% конкретной, чтобы её можно было дать компьютеру, но это то же самое, о чем я говорил. Какое-нибудь, но высокоуровневое описание должно быть.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 13:15
    Оценка: +2 :))
    Здравствуйте, Кодёнок, Вы писали:


    AF>>Придётся писать:

    AF>>Через 10 секунд у робота правая рука должна быть поднята вертикально вверх. Поднятие руки нужно делать медленно (за 2 секунды), с плавным поворотом ладонью вперёд (скорость поворота 90 градусов за 2 секунды). Амплитуда случайных колебаний (используется иммитация естественного движения) должна находится в диапазоне от 3 до 5% от максимальной амплитуды движения для заданной степени свободы.....

    AF>>А потом — всё это ещё и реализовывать! Вот где песня то будет!


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


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

    Кё>А топик не в защиту декларативного стиля, это я просто предположение выдвинул. Топик про качественное изменение смысла кодирования.

    Ты же в политики не собираешься? Форум то по программированию — то есть науке об эффективном достижении совершенно чётких и ясных результатов. Потому — если у тебя есть идея — так предложи её — предварительно оценив возможность её воплощения в жизнь — хотя бы с точки зрения здравого смысла.
    Ну а декларативно-процессные заявления вроде:
    "Cегодняшняя ситуация с программированием плачевна и зашла в тупик. Мы должны предпринять незамедлительные меры, да предотвращения кризиса в области разработки программного обеспечения, в частности переход на принципиально новый подход декларативного описания программ, над которым бъются наши лучшие инженеры"
    — лучше оставить для политиков.
    Re[3]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 13:25
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:

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


    AF>> Аналогия вещь опасная и пользоваться ей нужно очень осторожно.

    AF>> Потому нет ничего удивительного, что ты легко можешь найти противоречия между обеими метфорами — ибо метафоры всё таки разные.
    AF>> Тем более, что никакого противоречия, которое ты усмотрел нет.

    Кё>Противоречие нужно специально создать, чтобы обратить внимание. Потому что вот например здесь Дмитрий Завалишин критикует экстремальное программирование, пользуясь неадекватной метафорой.

    Да, есть такой приём.

    Кё>Если архитектор ПО называется архитектором, то программиста по умолчанию отводят в строители, что аналогично, если смотреть на взаимодействие этих людей в команде, но неверно, если смотреть на получаемый результат. А мы ведь улучшаем результат, а не строим взаимоотношения в команде.

    Я же предупреждал про опасность аналогий.
    А что в строительстве архитектор решает абсолютно всё? А обои какие клеить тоже он решает? А при какой температуре и влажности класть бетон и сколько давать ему сохнуть — этим тоже он занимается? А как проводить локальную сеть, электропроводку и какое телефонное оборудование закупать — это всё тоже он?
    В действительности у архитектора в строительстве так же весьма ограниченная и далеко не исчерпывающая роль — причём чем сложнее проект здания — тем лучше это видно (кстати, как и в программировании). И если распределение интеллектуальной работы в строительстве в пользу архитектора — так это потому, что средненькая программная система по набору элементов гораздо сложнее, чем типичный небоскрёб — проект которого, кстати, по времени разрабатывается примерно столько же.
    Ну а архитектора назвали архитектором по аналогии с тем что в программной инженерии он определяет контуры системы, так же, как в строительстве архитектор определяет контуры здания. А вот отделкой интерьеров — как и дизайном GUI — занимаются уже совсем другие люди.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 13:26
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:


    AF>> Это фантазии на ту же тему, что была здесь
    Автор: Sshur
    Дата: 28.06.05
    . Там человек сделал ту же ошибку. На основе не верных аналогий он не правильно понял идею, заложенную в ООП в том конкретном случае он истактовал её, как "объект в программе всегда есть модель объекта реального мира" и движимый этой идеей предложил создать библиотеку классов для описания всех объектов во вселенной!

    AF>> Так вот то же самое я вижу и у тебя. Декларативное программирование вещь безусловно полезная, оно уже оказало существенное влияние на современные языки — в том числе C++ и C# — и некоторые архитектурные решения, есть не что иное, как попытка описывать программу в декларативном стиле. Но оно не имеет ничего общего с той гипретрофированной фантазией, о которой ты пишешь.
    Кё>.
    AF>> Если когда-либо и будет достигнут тот уровень, о котором ты пишешь — это будет уже не программирование, а общение, и я не уверен, что то, с чем будет происходить общение можно будет назвать компьютером

    Кё>Согласен. Меня немного занесло Вряд ли повышение уровня кода будет выглядеть именно так.


    Кё>Введение UML — не что иное, как попытка ввести высокоуровневую нотацию. Пусть она переводится в код вручную и не является 100% конкретной, чтобы её можно было дать компьютеру, но это то же самое, о чем я говорил. Какое-нибудь, но высокоуровневое описание должно быть.

    Приятно таки придти к согласию
    Мир!
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 14:06
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:

    F>>Придётся писать:

    AF>>Через 10 секунд у робота правая рука должна быть поднята вертикально вверх. Поднятие руки нужно делать медленно (за 2 секунды), с плавным поворотом ладонью вперёд (скорость поворота 90 градусов за 2 секунды). Амплитуда случайных колебаний (используется иммитация естественного движения) должна находится в диапазоне от 3 до 5% от максимальной амплитуды движения для заданной степени свободы.....
    AF>>А потом — всё это ещё и реализовывать! Вот где песня то будет!
    Кё>Вот реализовывать это компьютер как раз должен сам, из готовых паттернов
    Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?

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

    класс Рука { поднять(угол) }


    и функция:

    поднять(рука, угол)


    Какой из них выбрать? Какой лучше? А перед проектировщиком всегда будет стоять задача: как лучше выразить абстракцию?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[9]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 14:13
    Оценка: 2 (1)
    Здравствуйте, AndreyFedotov, Вы писали:

    Кё>>Так различие декларативной и командной нотации как раз в этом — как на них записываются идеи. В декларативном стиле идея записывается явно. В командном записывается реализация. "Поднять руку" против "направить электрические сигналы по нервам №1130..5600 с частотой 10 Гц". Качественное различие, которое и обеспечит качественные изменения в процессе разработки ПО.


    AF>И кто мешает написать функцию:

    AF>

    AF> ПоднятьРуку( Правую )

    AF>или вызвать метод:
    AF>

    AF> Человек.Конечности.Рука.Поднять( ... )


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

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

    Декларативное программирование позволяет в какой-то степени решить проблему повторного использования паттернов, а следовательно упростить написание бизнес кода. Т.е. фактически отделить мух от котлет и максимально "отжать" бизнес код.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 14:24
    Оценка:
    Здравствуйте, eao197, Вы писали:

    Кё>>Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.


    E>А, тогда понятно. Фантазии -- это и интересно, и полезно.

    E>Только дальше я пас. Велосипедостроение от фантазирования отличается тем, что велосипед обязательно нужно заставить ездить. И это у меня, имхо, получается. Этим я и продолжу заниматься.

    Вы зря иронизируете, молодой человек Фантазии уже начинают воплощаться в жизнь и местами настолько. что их начинают называть велосипедами.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 14:26
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    Кё>>>Это фантазии Сам я ещё только изучаю готовое, Лисп, Пролог... То, о чем я говорю — это перспектива, если бы её не было, то и декларативного программирования бы не существовало.


    E>>А, тогда понятно. Фантазии -- это и интересно, и полезно.

    E>>Только дальше я пас. Велосипедостроение от фантазирования отличается тем, что велосипед обязательно нужно заставить ездить. И это у меня, имхо, получается. Этим я и продолжу заниматься.

    IT>Вы зря иронизируете, молодой человек Фантазии уже начинают воплощаться в жизнь и местами настолько. что их начинают называть велосипедами.


    Знаю. Но именно, что местами. И вот эти места мне особенно интересны.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 14:40
    Оценка: +1
    Здравствуйте, AndreyFedotov, Вы писали:

    AF> Да, знакомая идея. У неё видно два крупных недостатка:

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

    Это не совсем так. Чем более универсален алгоритм, тем таки да, действительно, требуется всё большее количество параметров его настройки. Но чем более по типовому мы его используем, тем больше параметров у нас начинают принимать одни и теже значения. В результате список параметров может очень сильно укоротиться или совсем выродиться. Если надо могу привести вполне рабочий показательный пример.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 14:46
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?


    Ты неверно понимаешь значение слова паттерн. К сожалению прочтение широкоизвестной книжки часто оставляет неизгладимый отпечаток на правильном понимании слова паттерн у программистов. Паттерн — это не только то. что описано в книжке банды четырёх. Паттерн — это просто типовое решение и таких решений в твоём коде масса. Следовательно ты и есть их автор.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[8]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 14:51
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

    Кё>Работают в двух направлениях: повторное использование кода и перекладывание работы на компилятор.


    Или на среду исполнения.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: eao197 Беларусь http://eao197.blogspot.com
    Дата: 05.07.05 14:59
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    ГВ>>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?


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


    А лично у меня, после работы в Borland-овской BGI библиотекой в Turbo C 2.0, паттерн -- это стиль штриховки заливок и линий.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>


    SObjectizer: <микро>Агентно-ориентированное программирование на C++.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 15:04
    Оценка:
    Здравствуйте, IT, Вы писали:

    ГВ>>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?

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

    Отлично! А как это относится к заданным вопросам?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[8]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 15:04
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

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


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


    Ну как тебе сказать... очень детальные требования по объёму запросто превысят сам код + примерное описание постановки задачи. Кроме того, они болжны быть непротиворечивыми, верифицированными и т.п... Ну, и заказчик, разумеется, должен уметь работать с компилятором требований.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[15]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 15:13
    Оценка: 18 (1)
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>>>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?

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

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


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

    1. Паттерны мы придумываем сами.
    2. Столько сколько необходимо для решения каждой конкретной задачи.
    3. Не переведутся.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[16]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 05.07.05 15:23
    Оценка:
    Здравствуйте, IT, Вы писали:

    ГВ>>>>Главный вопрос: откуда возьмутся паттерны? Сколько их нужно? Не передерутся ли разные авторы похожих паттернов?

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

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


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


    IT>1. Паттерны мы придумываем сами.

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

    Ergo, имеем тот же самый процесс программирования, но спроецированный на "немного другую" деятельность — формулирование паттернов. Что и требовалось доказать. Спасибо, IT.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[17]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 05.07.05 15:37
    Оценка: +2
    Здравствуйте, Геннадий Васильев, Вы писали:

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


    Именно. Пишем правила и их применяем. По моему скромному опыту такой подход даёт существенное упрощение прикладного кода.
    ... << RSDN@Home 1.1.4 beta 7 rev. 447>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 16:58
    Оценка: +1
    Здравствуйте, IT, Вы писали:

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


    AF>> Да, знакомая идея. У неё видно два крупных недостатка:

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

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


    Полностью согласен.
    Я это прекрасно понимаю, да и пример привести довольно легко.
    Можно прекрасно упаковать шаблоны, со множнством параметров, в некие шаблоны более высокого уровня, с меньшим числом настроек — в общем обычная декомпозиция. Но в том то и суть — что это уже будет не так выразительно, как простенький пример с декларацией. Кроме того, это опять-таки будет зависеть от мастерства разработчика — как и сейчас. И опять всё вернётся на круги своя... То есть вместо красивой теории начнутся суровые будни.
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 05.07.05 17:09
    Оценка:
    Здравствуйте, IT, Вы писали:

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


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


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


    В том, что декларативный стиль более переспективен (если не везде, то во многих областях) — то я с этим полностью согласен, о чём и писал здесь
    Автор: AndreyFedotov
    Дата: 05.07.05
    . Кодёнок однако понял идею весьма поверхностно, потому и с примерами так получилось. Что же до остального, Игорь, то тут я полностью согласен — ты всё очень просто, хорошо и доходчиво объяснил.
    Re[11]: UML-модели и чертёжи дома - неправильная аналогия
    От: IT Россия linq2db.com
    Дата: 06.07.05 03:59
    Оценка: :))
    Здравствуйте, AndreyFedotov, Вы писали:

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


    Ой, правда! Тебе понравилось?!?
    ... << RSDN@Home 1.1.4 stable rev. 510>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 06.07.05 04:50
    Оценка:
    Здравствуйте, IT, Вы писали:

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


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


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


    Хуже того — сам понял, что такое декларативное программирование...
    Re[9]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 06.07.05 05:32
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


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

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

    Вообще, если ты реализуешь в проекте, скажем, паттерны проектирования банды четырёх, то это уже означает, что твои описания избыточны.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: _Obelisk_ Россия http://www.ibm.com
    Дата: 06.07.05 06:02
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

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


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



    Душа обязана трудиться! (с) Н.Заболоцкий.
    Re[15]: UML-модели и чертёжи дома - неправильная аналогия
    От: craft-brother Россия  
    Дата: 06.07.05 06:47
    Оценка: 10 (1)
    Здравствуйте, eao197, Вы писали:


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


    Если инетресно, можно для начала посмотреть: здесь, здесь, здесь и здесь
    Re[10]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 06.07.05 09:45
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:

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


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


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


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


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

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


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

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


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

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

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

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


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


    Это так, но эти вещи являются следствием более фундаментальных причин — чем стиль описания.
    Re[11]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 06.07.05 10:45
    Оценка:
    Здравствуйте, AndreyFedotov, Вы писали:

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


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

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

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

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

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


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


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

    Требования у тебя получаются избыточными потому, что ты мыслишь об объектах реального мира, а там огромное число процессов, параметров и т.д. Но мы-то создаем ограниченную, логически завершенную систему. В ней не может быть неоднозначности.
    Re[12]: UML-модели и чертёжи дома - неправильная аналогия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 06.07.05 12:38
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:

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


    Тогда "за кадром" остаются исходные требования...
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 06.07.05 13:42
    Оценка: +1
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


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


    Вот именно — и исходная идея, "проект == код" летит ко всем чертям, превращаясь на ходу в обыденное "проект == код + описание модели/требований"
    Re[13]: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 07.07.05 05:45
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

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


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


    В идеале, архитектор пишет требования низкодетализованные, как эскиз (или диаграмма структуры системы), а программисты (как я сказал, это тоже проектировшики, только уровнем ниже) детализуют их, что-то решают вручную.
    Re[14]: UML-модели и чертёжи дома - неправильная аналогия
    От: AndreyFedotov Россия  
    Дата: 07.07.05 06:33
    Оценка: +1
    Здравствуйте, Кодёнок, Вы писали:

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


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


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


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


    Вообще то так и происходит, только получается забавная ситуация, если рассматривать поток данных:
    Заказчик (знает требования детально) => аналитик (ещё более детализирует и систематезирует требования) => архитектор (задаёт общие требования) => разрботчики (детализируют требования)
    Всё это похоже на испорченый телефон...
    Re[3]: UML-модели и чертёжи дома - неправильная аналогия
    От: cranky Украина  
    Дата: 12.07.05 13:07
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

    Кё>Если архитектор ПО называется архитектором, то программиста по умолчанию отводят в строители, что аналогично, если смотреть на взаимодействие этих людей в команде, но неверно, если смотреть на получаемый результат. А мы ведь улучшаем результат, а не строим взаимоотношения в команде.

    В строительстве зданий, кстати, у архитектора совсем не главная и, по сути, небольшая роль. Обычно они выступают в роли художников, людей с пространственным эстетическим воображением, которые способны выслушать заказчика и на основе его пожеланий нарисовать будущее здание в нескольких видах (часто только внешних). А вот после них и начинается настоящая работа — инженерам-конструкторам железобетона, металла, электросетей, сантехнического оборудования и т.п. Так что аналогия в общем виде наверное остаётся, только все эти разномастные инженеры ассоциируются с программистами. Ну а строители, конечно, — средства компиляции.
    You aren't expected to absorb this
    Re: UML-модели и чертёжи дома - неправильная аналогия
    От: Ka3a4oK  
    Дата: 16.07.05 18:46
    Оценка: 1 (1) +1
    Высокоуровневое проектирование "на UML" можно приравнять к проектированию архитектора-мастера. Он определяет вид здания, то как оно будет вписываться в окружение. Все говорят — это здание спроектировал архитектор Иванов или этот небоскреб построил архитектор Smith. А есть архитекторы "попроще", их никто не знает — они расчитывают нагрузки на несущие констукции, выбирают тип материала исходя из требований прочности, пожарной безопасности, санитарно-гигиенических норм и т.п.
    Они изготовляют море чертежей, с которыми в итоге работает прораб.

    Программисты — это и есть эти архитекторы "Попроще", которые выбирают тип контейнера, алгоритм сортировки исходя из требований производительности и др. требований. Они изготовляют чертежи для компилятора-прораба.
    Это только мое видение.
    ... << RSDN@Home 1.1.4 stable rev. 510>>
    Re: UML-модели и чертёжи дома - неправильная аналогия
    От: Кодёнок  
    Дата: 21.07.05 10:57
    Оценка:
    Вот ещё один аргумент против программиста-строителя и за программиста-инженера (архитектора). Это рефакторинг.

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

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

    Пока заказчик думает, что программирование — это строительство, то вы его не убедите в необходимости рефакторинга. А если использовать правильную аналогию, ему сразу станет всё понятно.
    Re: UML-модели и чертёжи дома - неправильная аналогия
    От: Дарней Россия  
    Дата: 21.07.05 11:57
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

    Кё>проектирование = рисование эскиза (архитектура, выраженная UML-схемами = ПРИМЕРНЫЙ образ готовой системы)

    Кё>кодирование = рисование чертежа (исходный код = чертёж)
    Кё>сборка = строительство
    Кё>тестирование,
    Кё>внедрение.

    Про это еще Брукс писал, мне кажется. Правда, про UML у него ничего не было
    Но аналогия была та же самая. Исходники — это чертеж, компиляция и сборка программы — это строительство.
    Всех излечит, исцелит
    добрый Ctrl+Alt+Delete
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.