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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В форумах "C/C++" и "C/C++. Прикладные вопросы" любимым волшебным словом является boost (ну прям лекарство от всех болезней ). А в "Философии программирования" волшебным словом, видимо, является "паттерн"

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

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

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

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

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


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

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

Автор: Sshur
Дата: 28.06.05

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

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

AF> Это фантазии на ту же тему, что была здесь

Автор: Sshur
Дата: 28.06.05

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


AF>> Это фантазии на ту же тему, что была здесь

Автор: Sshur
Дата: 28.06.05

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

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

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

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

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

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

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

и функция:

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

Какой из них выбрать? Какой лучше? А перед проектировщиком всегда будет стоять задача: как лучше выразить абстракцию?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знаю. Но именно, что местами. И вот эти места мне особенно интересны.

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

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

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

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

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

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

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

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

Или на среду исполнения.

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

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

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

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

А лично у меня, после работы в Borland-овской BGI библиотекой в Turbo C 2.0, паттерн -- это стиль штриховки заливок и линий.

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

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

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