Ответ на »сообщение 1185« (icWasya)
___________________________
К счастию, овладение продуктами М$ не составляет особого труда.

»сообщение 1184«
>"Семь раз отмерь, один раз отрежь".
Пока все один раз ортмеряют, M$ успеет семь раз отрезать

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


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


Народная мудрость решает эту проблему простым и надёжным способом:
"Семь раз отмерь, один раз отрежь". А если резать сразу, то получается Windows (tm). :)

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

Интересно, почему погасла идея Лексикона Ершова?
Война языковых конфессий? Оторванность от практики?
Интеллектуальная лень? Или просто я не в курсе?

Просто народ не созрел. Да и двигать особо некому. Человечество мельчает год от года.

"Совершенномудрый относится к любому делу как к трудному, поэтому он не испытывает трудности".
>>> "А вдруг придется корректировать базовый объект?".
>>> А кто его такой придумал, что приходится корректировать?
То-то и оно, что реальные объекты никто не придумал
(если Вы, конечно, не глубоко религиозный человек).
А т.н. "объекты" ООП придумывают люди.
Корректировать приходится представления, модели объекта.
Любая модель несовершенна и частична. Изменение требований,
условий - течение жизни - вынуждает менять "базовый объект",
если программа не однодневка и не решает сиюминутные задачи.

Любите решать статичные и давно хорошо прожёванные задачки?
Понимаю. Тоже люблю иногда для отдохновения и гешефта.
Но о чём тут базарить прилюдно на площади?

Об Ариане, Канчели, скобках Лиспа и простоте Оберона?
Ну, и конечно, любимое: "Дурак! Сам дурак!"

Хорошо же!
Интересно, на чём будет написан софт для лунной станции?

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

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

Ну это прямо слова Jack Of Shadows и других лисперов насчёт скобок в Лиспе... :о))


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

>>> ... Имхо, это идеальный подход для Функционального программирования.
>>> Но он, как я понимаю, плохо совместим с принципами ООП.

>>> Оберон и КП - языки компонентно-ориентированные, то есть близки к ООП.
>>> Можно ли совместить методику Джексона с Оберон-технологией?

Как-то очень непонятно. Где, что, с чем не совместимо? Априорно несовместимо? Это, боюсь, слишком сильный тезис. И неправильный.

Что такое тут "принципы ООП"?
Как раз, скажем, КП заточен под "ограниченное ООП" (абстрактный родитель --> несколько конкретных, нерасширяемых потомков). Остальное -- для совместимости со старыми Оберонами (EXTENSIBLE вообще надо спрятать в SYSTEM и т.п.).

"принципы ООП" - я неправильно выразился, правильнее "возможности ООП" - построение иерархий классов (расширяемых типов).

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

Третий кит - жёсткая модульность + строгая типизация - вполне могут использоваться методикой Джексона, но будет ли тут уже "Оберон-технология"? В ней уже как бы и нужды нет...

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

Ответ на »сообщение 1179« (Как слышно? Приём!)
___________________________
>>>Только вот сама постановка задачи, как правило, меняется
Кто мешает тебе выдумать порох непромокаемый?(с)Козьма Прутков.
Зачем же реализовывать задачу с неустоявшейся постановкой?
Нет, конечно есть стимулы, способные подвигнуть программиста реализовывать задачу, в правильности постановки которой он не уверен. Но тогда на что  жаловаться?

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

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

По большому счёту и вообще говоря Вы, конечно, правы.

Но почему все эти чудеса IDE и компиляторов не сильно или, мягче скажем,
непропорционально сильно продвинули нас в написании программ
по сравнению с тем временем, когда (о ужас!) для исправления пяти строчек
приходилось ждать сутки для получения пяти новых перфокарт в своей колоде?

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

>>>Но вторая (задача) уже никак не связана со структурой реального объекта

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

По предновогодним ссылкам Снегурочки на osp складывается впечатление,
что разработка ведётся всегда по хорошо и твёрдо поставленной задаче.
Соответственно, главное - хорошенько разобраться в ней и удовлетворить
спецификациям. Разработать интегрированный движок к диффиренцированной
по данным модели. Только вот сама постановка задачи, как правило, меняется
меняя структуру движка и при достаточно сильном изменении запланированная
машинерия приходит в несоответствие задаче.

К Оберону сказанное мной относится в меньшей мере.
Здесь полагание на IDE :) и компилятор как раз трудно заметить.
Может поэтому больше надежды получить tips & tricks.

Интересно, почему погасла идея Лексикона Ершова?
Война языковых конфессий? Оторванность от практики?
Интеллектуальная лень? Или просто я не в курсе?

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

>>> Мне нравится эта идея:
>>> структура входных/выходных данных порождает структуру программы
То, что в состоянии отловить правильный компилятор - мизер.
И его значение - электрошооквая профилактика ошибок у новичка.

Как практика показывает, не мизер. Из-за совокупного эффекта. Количественно, в процентах от времени работы, ловля ошибок, например, работы с памятью может занимать приличное время... Если этого "мизера" нет, то это же самое время я потрачу на проработку модели и логики приложения, не распыляясь на "ловлю блох". Итого имеем вместо 50-60% процентов времени, просиживаемого в отладчиках, отладку "на лету", практически Just-in-Time :-)
Мне известны реальные случаи, когда команда из 7-10 человек две-три недели ловит единственную ошибку работы с памятью, которая возникает непредсказуемо... Причины обычно оказываются смехотворны - либо ошибка освобождения памяти, либо отсутствие строгой типизации в С++...
Видел я коммерческие продукты - во всем остальном сделанные очень неплохо, которые за три часа непрерывной работы съедают "в никуда" 2 Гб своп-файла...
И поди отлови теперь в огромном коде эти утечки... Только и остается, что шаманить с бубнами от Numega...

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

>>> Мне нравится эта идея:
>>> структура входных/выходных данных порождает структуру программы

А мне нравится немного другая:
структура реального объекта порождает структуру модели и структуру программы.


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