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

>>>Честно говоря, к метапрограммированию отношусь достаточно сдержанно.

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

Ответ на »сообщение 4373« (Как слышно? Приём!)
___________________________

>>>Так что DAG и тем более иерархия дерева отдыхает.

Здесь, IMHO, какая-то путаница.
В Обероне даг модулей есть прямое отражение иерархии абстракций.
Параллелизм здесь не при чем.

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

>>>Если руководитель команды (team leader проекта) не владеет (желательно очень хорошо) инструментами своих подчиненных, то в области программирования он быстро потеряет уважение и контроль.

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

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

Как дела с распараллеливанием в Обероне?

Ответ на »сообщение 4368« (Сергей Перовский)
___________________________

Так ли уж принципиально? Таблица регистрации СОМ-компонентов вполне работоспособный механизм.

Да принципиально. Аргументацию, думаю, повторять не стоит. Не убедила -- значит, не убедила.

Т.е. в Вашей конструкции язык более высокого уровня хорошо согласуется с Обероном? Очень хорошо и естественно, т.к. Вы разрабатывали кластерный подход изначально исходя из Оберона в качестве базы. Значит ли это, что такая пара языков лучше других?

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

Почему Вы думаете, что на операционном уровне регламентация невозможна?

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

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

Это -- менеджер.

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

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

Ответ на »сообщение 4366« (Стэн)
___________________________

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

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

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

Интересный момент. Основные проблемы недопонимания (линии разлома) происходят между:
* заказчиком и исполнителем ("замысел"),
* аналитиком и архитектором/проектировщиком ("проект"),
* проектировщиком и программистом ("строительство").

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

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

Проекты по заказному ПО по финансовым параметрам обычно разделяют на "fixed price" (фиксирована цена и сроки) и "time and material" (оплата по факту реально произведенных работ с учетом затрат на ресурсы). У нас все больше привыкли к fixed price -- поэтому сначала "стаканят" цену. А потом каждая сторона начинает выжимать из этого свою выгоду. Заказчик при такой схеме заинтересован выламывать руки исполнителю (цену-то уже не поменяешь, а за ту же цену получить побольше и получше -- кто ж не хочет). Исполнитель тоже не дурак -- начинает в ответ давить на заказчика смещением сроков, падением качества и т.д. и т.п. Другими словами, устанавливать fixed price на новые (еще не создававшиеся раньше исполнителем) вещи -- страшные риски (для обеих сторон). На Западе пришли к пониманию, что если важен результат, то требуется доверие (по принципу: "доверяй, но проверяй"). А это обеспечивает time and material. Поэтому нередко схема отношений выглядит так: дается на пробу мелкий проект ("покраска забора"). Справились хорошо? Тогда можно переходить к "time and material". Некоторые наши компании при работе на западных заказчиков идут дальше -- создают внутреннюю систему управления проектами, доступ к которой (дистанционно) получают представители заказчика. Вплоть до того, что они могут на те или иные работы запрашивать конкретных проверенных в деле исполнителей: Иванова, Петрова, а не Сидорова. И следить за исполнением заданий. Т.е. заказчик рулит ресурсами (в разумных, разумеется пределах) и даже спускается (если позволяет квалификация и уровень взаимоотношений с компанией-исполнителем) на уровень проектировщика. Отдача много выше. Доверие растет с каждым проектом. Клиент становится постоянником. Под него фактически формируется отдельное подразделение.

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

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

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

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

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

>>>5. Начальник участка (прораб, он же team leader)

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

Ответ на »сообщение 4350« (Руслан Богатырев)
___________________________
>>>Ни о каком языке конструирования он не говорил (а язык -- это принципиально).
Так ли уж принципиально? Таблица регистрации СОМ-компонентов вполне работоспособный механизм.
>>>И языку кластеров механизм импорта языка Оберон только помогает, поскольку в противном случае (в подходе ASU) импорт становится теневым и выносится на уровень операционный без регламентации (я уже приводил различия между языком и средой -- первый фиксирован, вторая -- с каждой версией принимает все новые более размытые очертания).
Тут по моему не очень четко сформулировано: смешиваются несколько утверждений.
>>>И языку кластеров механизм импорта языка Оберон только помогает
Т.е. в Вашей конструкции язык более высокого уровня хорошо согласуется с Обероном? Очень хорошо и естественно, т.к. Вы разрабатывали кластерный подход изначально исходя из Оберона в качестве базы. Значит ли это, что такая пара языков лучше других?
>>>поскольку в противном случае импорт становится теневым и выносится на уровень операционный без регламентации.
Очень спорное утверждение, что стандартизовать можно только язык.
Реализации языков тоже заметно отличаются друг от друга. А стандарты на физические интерфейсы соблюдаются тщательно и часто обеспечивают обратную совместимость.
Почему Вы думаете, что на операционном уровне регламентация невозможна? Потому, что сейчас этого нет? Очень сомнительный аргумент.

Ответ на »сообщение 4365« (Как слышно? Приём!)
___________________________

Спасибо. Смешное сравнение :)

За этим у нас не заржавеет. Лишь бы польза была.

Раз уж затронул тему строительства применительно к программированию, хотел бы обратить внимание вот на какие аналогии:

1) строительство -- заказное и полузаказное ПО (промышленное производство);
2) автомобилестроение (машиностроение) -- тиражируемое ПО (промышленное производство);
3) народный промысел -- заказное ПО (индивидуальное производство), частный сектор условно-бесплатного ПО.

При этом программист по характеру деятельности (диктуется склонностями, это может быть как в индивидуальном производстве, так и в промышленном):
1. просто умелец (на все руки мастер)
2. монтажник
3. плиточник-облицовщик
4. сантехник
5. технолог
6. архитектор
7. инженер
8. врач
9. учитель
10. писатель