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

Трудоемкость оценивается в человеко-часах/днях/месяцах/годах/столетиях/тысячелетиях. Методика проста: считается время потраченное людьми на выполнение работы.

Проста, говорите? Мне это нужно комментировать? Ok. Если программист в единицу времени (в месяц) пишет и отчуждает после отладки 3000 строк исходного текста, а другой -- 100, то у кого производительность выше? Языки разные, задача с требованиями одна и та же. Уровень квалификации первого (предположим) -- Beginner (начинающий), уровень квалификации второго -- Advanced. Значит, требуется фиксация по языку. Ok. Фиксируем. Опять первый пишет 3000 строк, а второй -- 100. У кого производительность выше? У первого. Кто молодец? Он, а кто же еще?

Теперь, говорите, время? Хорошо, зафиксируем задачу, язык, квалификацию  (хотя в реальных метриках до такой глубины не опускаются и получают что получают). Первый решает задачу за 1 день (8 часов). Второй -- за 3 дня (24 часа). Но первое решение качественно хуже второго. Это действующий макет, который только внешне и функционально похож на реальную компоненту. Значит, у нас появляется такое понятие, как качество. Как его оценивать? Оно же обусловлено многими факторами, из которых простота, надежность, отчуждаемость (в пространстве, во времени, в пользовании), адаптируемость (статическая и динамическая) -- лишь небольшая часть. Это не учитывают, а, значит, стимулируют применение количественных метрик оценки проиводительности, меряющих среднюю температуру по госпиталю с учетом морга. Оберон направлен на качество, надежность и контролируемость сложности. Это все противоречит производительности (точнее, принятой оценке производительности).

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

Программа имеет цельную структуру, система состоит из частей. Программа решает частную задачу, система множество задач. Достаточно?..

Недостаточно. Здесь уже обсуждали пример олимпиадной задачки с последнего чемпионата мира ACM по программированию. Она была решена (вариант на КП) в виде программы (одного модуля). Однако при этом выяснилось, что половину текста загромождает ввод-вывод и работа со строками. Я предложил вынести это со "сцены" в отдельный модуль. Простейшая декомпозиция. Перестала она после этого быть программой? Превратилась в систему? Если мы вынесем в модули еще некую специфику (передав на "аутсорсинг", на субподряд некий функционал), это станет системой?

Возьмем компилятор классического Паскаля, написанный на этом же языке. Он выполнен в виде одного куска текста (одной программы, program в понимании Паскаля). При этом в нем есть все стадии, требуемые компилятору. Несложно показать, что можно реализовать компилятор языка Оберон, реализованный на нем же самом, при этом все стадии (это разные части: синтаксический анализатор, лексический анализатор, генератор кода) могут быть в одном модуле. То есть это будет одна программа. Но стадии могут быть разбиты на отдельные части и логика обмена (а также главенство той или иной) между ними может быть реализована по-разному.

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

Не поленитесь, откройте книгу "Compiler Construction" Никлауса Вирта (заодно и познакомьтесь поглубже с раздельной компиляцией и внутренним хозяйством Оберона). Всего 131 стр. блестяще выверенного текста. Это и есть подводная часть айсберга под названием "язык Оберон" (надводная -- 16-страничное описание языка). Можно найти здесь: http://www.europrog.ru/book/ccnw2005e.pdf

Ваши комментарии?

Ответ на »сообщение 4072« (AVC)
___________________________
Я выделил жирным шрифтом рефрен "интерфейс – один".
Ну, и...

Это и побуждает меня думать, что Вы настроены критически не к "какому-то там" квалифицирующему импорту (IMHO, естественно вытекающему из модульной структуры), а именно к модульности.
Поверьте, я к модульности отношусь с большой теплотой и трепетом :)
Представьте, что Вы с ребенком играете в «железную дорогу». Берете разные вагончики и тепловозики и сцепляете их между собой... Все вагончики разные: пассажирские, грузовые, цистерны и пр., а... интерфейс у всех один. Вагончики – модули, сцепка – интерфейс. Так понятнее? Я не отрицаю модульности, но множественность интерфейсов... как правило, следствие неудачного проектирования.

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

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

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

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

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

Ответ на »сообщение 4070« (Руслан Богатырев)
___________________________
>> Построение программных систем, комплексов и пр...
> Это очень абстрактная постановка. Где кончается "несколько" и начинается "куча"? Как отличить программу от программной системы?
Программа имеет цельную структуру, система состоит из частей. Программа решает частную задачу, система множество задач. Достаточно?..

Хм... Например, высокая трудоемкость на всех стадиях...
Как оценивается трудоемкость? Какие метрики? Для каких ролей/специальностей? Если речь идет о промышленном программировании (а не о кустарном), то автоматически появляется разделение труда.
Ой-ля-ля!.. Трудоемкость оценивается в человеко-часах/днях/месяцах/годах/столетиях/тысячелетиях. Методика проста: считается время потраченное людьми на выполнение работы. Нормирование труда и расчет трудозатрат появились в промышленном производстве. Одним из основателей этого направления является Тейлор (вспомните работу Ленина «О научной системе выжимания пота»... именно об этом, правда потом эту «буржуазную» «науку» коммунисты назвали НОТ). Но расчет трудозатрат вполне можно использовать и в «кустарном» производстве. Трудоемкость создания, например, ERP-систем оценивается в тысячи человеко-лет (SAP называла цифру в 5 000 ч-л, Oracle в 2 500 ч-л).

>>3. Если задача уже была ранее решена, рассмотреть альтернативные варианты (как другой инструмент того же класса эту задачу решает -- другой язык).
И что?.. И зачем?.. Если в одной комнате темно, то в других должно быть светлее? Почему?

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

1. Ваша методология имеет четкую формулировку (отчуждаемое от Вас описание)?
«Отчуждать» - отчуждал (см. например, http://www.ssp.com.vn/?o=modules&n=product&f=product_detail&id=Soft_10), а вот описывать... не писатель я...

2. Была ли она реализована? На чем?
... на компьютерах... :) А средств разработки много – это и средства проектирования и средства работы с СУБД и средства разработки... В разных проектах использовались разные компоненты. Это же система...

3. К каким классам задач применялась?
Управление предприятиями. Были и другие проекты, как я уже говорил...

Вопросы простые и допускают односложные ответы.
Получите ответы, но что Вы с ними делать-то будете? :)

1. Некая сущность (язык) может использоваться в каком-то качестве
2. Это использование обусловлено конкретной ситуацией (это не означает, что такой подход разумен и полезен в отношении конкретных условий)
Сначала я думал, что это просто описка... но тут, похоже, все серьезнее...

>> Не надо обсуждать мою методологию... У участников обсуждения, наверняка, хватает собственного опыта (КСП я, понятно, в расчет не беру).

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

Есть хорошее правило: либо человек несет ответственность за свои слова и тогда он должен по запросу назвать источник информации ("ссылку в студию"), либо не несет (не буду квалифицировать -- и так понятно).
Ну, и... что же дальше... Цитаты есть, реакции – нет. Зачем же я старался?..

>> Вместо разработки новых технологий... пимпочки прикручиваем, и объясняем всем, что с пимпочками безопаснее бетон рубить...
> Каждому -- свое. Одни маршруты прокладывают и называются штурманами. Другие ведут машину и называются пилотами. Третьи готовят машину к гонке и называются механиками. Четвертые машину собирают из комплектующих и называются рабочими. Пятые прорабатывают технологию производства и называются технологами. Шестые машину проектируют и называются конструкторами. Седьмые организуют производство и называются менеджерами. Разделение труда.
Можно я одну мысль скажу... только Вы не обижайтесь... Сегодня не Ваш день... видимо. Какое отношение Ваш штурман имеет к моим пимпочкам? :)

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

Интерфейсов очень мало, они определяются одной структурой и конфликта быть не может... по определению. Другой пример. В теме «Семантическое моделирование» описан интерфейс позволяющий собирать систему управления предприятием из произвольного количества подсистем (правда, там не говорилось, что это интерфейс). Так он вообще один! Как он может конфликтовать сам с собой?.. Вообще, можно совершенно строго (формально) вывести понятие интерфейса и доказать его... «односложность»... Можно... но не здесь.

Я выделил жирным шрифтом рефрен "интерфейс -- один".
Это и побуждает меня думать, что Вы настроены критически не к "какому-то там" квалифицирующему импорту (IMHO, естественно вытекающему из модульной структуры), а именно к модульности.
На мой взгляд, модульность предполагает множественность интерфейсов.

Жаль, но видимо я плохо объяснил... «Механизм» был описан через модули, но интерфейс должен быть определен на той стадии разработки, когда еще никаких модулей нет, и он должен поддерживаться на всех последующих стадиях, в том числе, на тех стадиях, где модулей и не должно быть.

А на каких стадиях модульности не должно быть?
Насколько я понимаю, модульность является неотъемлимой чертой всякой развитой отрасли.
Мы, как правило, не можем позволить себе роскошь строить вообще с нуля (иногда это просто невозможно).
Мы используем уже разработанные кем-то компоненты и добавляем к ним свои (причем чем меньше, тем лучше).
Тут многократно поминались и сборочное программирование (термин Ершова) и приснопамятная конференция НАТО 1968г., породившая стремление к построению программ из (готовых) компонентов, как это делается в промышленности.
А Вы что же -- тянете нас в каменный век? ;)

Ответ на »сообщение 4070« (Руслан Богатырев)
___________________________

3) что она не может быть использована для задач, поставленных при ее разработке

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

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

Построение программных систем, комплексов и пр...

Это очень абстрактная постановка. Где кончается "несколько" и начинается "куча"? Как отличить программу от программной системы?

Хм... Например, высокая трудоемкость на всех стадиях...

Как оценивается трудоемкость? Какие метрики? Для каких ролей/специальностей? Если речь идет о промышленном программировании (а не о кустарном), то автоматически появляется разделение труда.

>>3. Если задача уже была ранее решена, рассмотреть альтернативные варианты (как другой инструмент того же класса эту задачу решает -- другой язык).
И что?.. И зачем?.. Если в одной комнате темно, то в других должно быть светлее? Почему?

Чтобы был предметный разговор. Прямые вопросы:
1. Ваша методология имеет четкую формулировку (отчуждаемое от Вас описание)?
2. Была ли она реализована? На чем?
3. К каким классам задач применялась?

Вопросы простые и допускают односложные ответы.

>> Зачем эти ухищрения при написании программ? Они нужны для построения чего существенно иного, для строительства программных сред, комплексов, систем... коими и является то же BlackBox и иже с ним. >>Правильно?
Нет, далеко не так. Он нужны для того, чтобы, оставаясь в рамках языка программирования (без привлечения дополнительных инструментов), можно было использовать его как: язык макетирования, язык моделирования, язык проектирования, язык спецификаций, язык реализации, язык развертывания, язык эксплуатационной/операционной поддержки.
==А как сказанное Вами только что соотносится с тем, что Вы сказали вчера: «Один и тот же язык программирования может использоваться как язык макетирования, язык моделирования, язык спецификаций, язык проектирования, язык реализации, язык развертывания, язык эксплуатационной/операционной поддержки, но это не означает, что такой подход разумен и полезен в отношении конкретных условий (предметной области, предпочтений и квалификации исполнителей, условий проекта и т.п.).»... (выделено мной). Даже не знаю, как Вас теперь понимать...

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

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

Частично согласен. Пока мне предстоит еще понять, чем (в Вашем понимании) отличается программа от системы (давайте среды и комплексы пока оставим в покое).

От того, что тот «топор» имеет дополнительные плюсы никак не следует, что «топор» в принципе является инструментом для строительства зданий... Вот избу срубить – это да...

Из того, что некая система существует, не вытекает:
1) что ее используют;
2) что ее используют по назначению;
3) что она не может быть использована для задач, поставленных при ее разработке

Не надо обсуждать мою методологию... У участников обсуждения, наверняка, хватает собственного опыта (КСП я, понятно, в расчет не беру).

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

Ух... Вы предлагаете перелопатить 4000 сообщений? Можно я не буду тратить столь много времени и просто приведу первые попавшиеся под руку цитаты?

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

РБ> В отношении ОС -- это, пожалуй, основное поле Оберон-технологий, где они формировались и оттачивались. ( »сообщение 10«)... (не станете же Вы утверждать, что операционные системы – это не системы)

То, как Вы понимаете системы (точнее, мое представление о Вашей интерпретации), не позволяет мне говорить ни да, ни нет. Вопросы: Система уравнений -- это система? Система взглядов -- это система? В первом случае -- математическое понятие. Во втором -- философское.

Вместо разработки новых технологий... пимпочки прикручиваем, и объясняем всем, что с пимпочками безопаснее бетон рубить...

Каждому -- свое. Одни маршруты прокладывают и называются штурманами. Другие ведут машину и называются пилотами. Третьи готовят машину к гонке и называются механиками. Четвертые машину собирают из комплектующих и называются рабочими. Пятые прорабатывают технологию производства и называются технологами. Шестые машину проектируют и называются конструкторами. Седьмые организуют производство и называются менеджерами.  Разделение труда.

Ответ на »сообщение 4067« (info21)
___________________________
Ровно наоборот: в нем только самое необходимое, с помощью которого можно эффективно реализовывать любые более сложные вещи.
«Необходимое» - это Ваша точка зрения. Другому этого покажется мало, третьему избыточно много...
«Любые более сложные»?.. При всем моем уважении... :(

"исключит ... сократит ... будет почтрачено" -- пока это благие пожелания в будущем времени.
С какой стати? Срок проектов разработки систем у нас реально был снижен на 2-3 порядка... Если бы еще были нормальные инструментальные средства... то, как говорит РБ, технология могла бы быть отчуждаемой...

А Оберон/КП реально помогает заниматься проектированием, не добавляя "от себя" головной боли.
Проектированием?.. Видимо мы различно смотрим на этот процесс...

Ответ на »сообщение 4065« (Руслан Богатырев)
___________________________
1. Четко сформулировать задачу
Построение программных систем, комплексов и пр...

2. Указать ее ограничения
Хм... Например, высокая трудоемкость на всех стадиях...

3. Если задача уже была ранее решена, рассмотреть альтернативные варианты (как другой инструмент того же класса эту задачу решает -- другой язык).
И что?.. И зачем?.. Если в одной комнате темно, то в других должно быть светлее? Почему?

Простите, но этого сделано не было.
А оно надо?..

Здесь говорилось о несколько иной проблемной области...
Давайте конкретно -- назовите область и кто о ней говорил.
Построение сред, систем, комплексов. Говорил об этом и я, и Илья Ермаков, и др.

Хм?.. И к чему были эти пустые вопросы???

>> Зачем эти ухищрения при написании программ? Они нужны для построения чего существенно иного, для строительства программных сред, комплексов, систем... коими и является то же BlackBox и иже с ним. Правильно?
Нет, далеко не так. Он нужны для того, чтобы, оставаясь в рамках языка программирования (без привлечения дополнительных инструментов), можно было использовать его как: язык макетирования, язык моделирования, язык проектирования, язык спецификаций, язык реализации, язык развертывания, язык эксплуатационной/операционной поддержки.
А как сказанное Вами только что соотносится с тем, что Вы сказали вчера: «Один и тот же язык программирования может использоваться как язык макетирования, язык моделирования, язык спецификаций, язык проектирования, язык реализации, язык развертывания, язык эксплуатационной/операционной поддержки, но это не означает, что такой подход разумен и полезен в отношении конкретных условий (предметной области, предпочтений и квалификации исполнителей, условий проекта и т.п.).»... (выделено мной). Даже не знаю, как Вас теперь понимать...

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

Базовые средства (перечисленные мной выше) могут (а не должны!) быть встроены в язык. Если Вы обратили внимание, то я провожу границу между Обероном (к которому питаю несколько большую симпатию) и КП. Так вот, КП такими средствами обладает в большей мере, чем классический Оберон. И он лучше подходит для задач программной инженерии, чем Оберон. Здесь нет противоречий.
От того, что тот «топор» имеет дополнительные плюсы никак не следует, что «топор» в принципе является инструментом для строительства зданий... Вот избу срубить – это да...

То, что с моей стороны говорилось о построении систем, конечно, было очень поверхностно, вдаваться глубже в рамках форума не имеет смысла, но все же... похоже многие прочувствовали, что построение системы – это не написание программы.
А не надо в формуе это делать подробно. Напишите (или дайте ссылку) на свою работу (на своем сайте), в которой лаконично излагается Ваша методология. Тогда будет, что обсуждать.
Не надо обсуждать мою методологию... У участников обсуждения, наверняка, хватает собственного опыта (КСП я, понятно, в расчет не беру).

А вместо этого нам говорят, что Оберон едва ли не идеальное средство для решения подобных задач... в нем так много удобных, полезных и надежных механизмов.
Давайте в нашей дискуссии не использовать таких приемов, как формулировка неких несуществующих мифов с последующей попыткой их развенчать. Говорите коротко и конкретно -- в таком-то сообщении такой-то товарищ (господин, гражданин) выдвинул такой-то тезис. Вы не согласны -- и далее Ваша аргументация. В противном случае конструктива не будет.
Ух... Вы предлагаете перелопатить 4000 сообщений? Можно я не буду тратить столь много времени и просто приведу первые попавшиеся под руку цитаты?
AVC> Но она не обеспечивает должный контроль совместимости типов и целостности программной системы поверх модулей.
AVC>Именно таким контролем раздельная компиляция и отличается от независимой.
...
AVC>Данный подход еще как-то работал на уровне отдельных приложений, но оказался недостаточно неприспособленным для перехода к компонентному программированию.
( »сообщение 8« ) Уже в самых первых сообщениях речь пошла о системах...
РБ> В отношении ОС -- это, пожалуй, основное поле Оберон-технологий, где они формировались и оттачивались. ( »сообщение 10«)... (не станете же Вы утверждать, что операционные системы – это не системы)
СГ> А в динамически расширяемых модульных системах на момент компиляции модуля не известно когда "отдавать". Такое решение можно принять только динамически, во время выполнения. ( »сообщение 145« )
AVC> Как раз Оберон позволяет создавать динамические модульные системы, где конкретная конфигурация модулей определяется (и меняется) во время работы ( »сообщение 169« )
и т.д.
Удовлетворены?

Развитие методик «системостроительства» не только исключит потребность в ухищрениях, но и серьезно сократит область применения 3GL, аналогично тому, как развитие 3GL сократило применение ассемблеров.

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

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

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

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

.. в нем так много удобных, полезных и надежных механизмов.

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

Развитие методик «системостроительства» не только исключит потребность в ухищрениях, но и серьезно сократит область применения 3GL, аналогично тому, как развитие 3GL сократило применение ассемблеров. И время на изучение техник (a-la «квалифицированного импорта») будет просто потрачено не только впустую, но и со вредом (искажается нормальное восприятие задачи, преломляется через неподходящий для данной задачи инструмент).

"исключит ... сократит ... будет почтрачено" -- пока это благие пожелания в будущем времени.
А Оберон/КП реально помогает заниматься проектированием, не добавляя "от себя" головной боли .