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 (;) в инструкции, образующие цикл, а применять те же шаблоны и выученные алгоритмы, которые я применяю. А нетривиальные задачи я возьму себе, какого уровня — низкого или высокого — они не были.
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.