Ответ на »сообщение 2793« (Jack Of Shadows)
___________________________

Так что рассказывая о том какой надежный оберон не налегайте слишком на "грамотное проектирование" всего и вся.

Ну конечно, никакой он ненадежный. Может, хоть эта новость согреет кому-то душу.

Ответ на »сообщение 2790« (Денис Зайцев)
___________________________

А можно привести простой пример: как Вы думаете, 1С (и другие аналогичные отечественные системы) разработаны на основании раз и навсегда написанного ТЗ?

Ссылка на 1C понятна. Но знаете, есть ма-а-аленькая такая разница между созданием коробочного софта и разработкой заказного, для географически и ментально удаленного заказчика да еще распределенной командой в предельно сжатые сроки. Я не призываю всех мерять все на свой аршин, но хочу обратить внимание, что есть ситуации, когда НЕТ возможности обобщать и ввиду отсутствия конкретики. И в этом случае применять не глядя ООП для всего подряд - неразумно. Как минимум.

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

Ответ на »сообщение 2792« (AVC)
___________________________
>>>в статье речь идет о семантической (а не бинарной) хрупкости базового класса.
Так и я о том же. Насколько я понял, речь идет о некорректном наследовании  реализации. На мой взгляд множественная реализация одних и тех же функций гораздо опаснее.
Тут встает вопрос компетентности. Обычно иерархию разрабатывают и реализуют базовые классы наиболее опытные члены команды. Множество потомков приходится писать множеству людей различной квалификации.
Если они получат только интерфейсы, каждый будет писать реализацию по своему и мы получим десятки, а иногда сотни классов с соответствующим качеством кода. И да поможет нам бог при отладке - баг может быть где угодно.
Если же общая часть функциональности реализуется в базовых объектах, то она может быть отлажена до начала работы над наследниками. И при отладке полной системы можно быть кое в чем уверенным. Если при массовых операциях какой то из наследников ведет себя некоректно, то это легко локализовать.
У меня вырожденный случай: наследников пишут студенты :(
Если я им дам только интерфейсы, то вообще систему никогда не соберу.

Господа, раз уж разговор зашел о надежности языков программирования, читайте классиков - гениальные люди :))
Как очень точно и емко высказался по поводу надежности языков программирования, отец Советской Школы Программирования, товарищ Сталин - "нет человека - нет проблемы" :))

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

Так что рассказывая о том какой надежный оберон не налегайте слишком на "грамотное проектирование" всего и вся. Эти 2 вещи вообще то противоречат друг другу :))

Я прошу прощения, что несколько "выпал" из беседы (из-за обстоятельств).

Вот, как мне кажется, неплохая статья, описывающая потенциальные опасности наследования реализации:
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
Ее автор, Аллен Голуб, в свое время написал неплохую книгу, вышедшую у нас под названием "Правила программирования на Си/С++", затем переключился на Яву.

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

Ответ на »сообщение 2790« (Денис Зайцев)
___________________________
>>>Начинают проявляться истинные причины спора - различный опыт в различных условиях...
Разумеется, я давно об этом говорю.

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

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

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

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

Начинают проявляться истинные причины спора - различный опыт в различных условиях...

Можно, конечно, в очередной раз сослаться на статью
http://russian.joelonsoftware.com/Articles/FiveWorlds.html

А можно привести простой пример: как Вы думаете, 1С (и другие аналогичные отечественные системы) разработаны на основании раз и навсегда написанного ТЗ? Которое предусматривало все возможные дальнейшие изменения в форматах документов, законодательстве, деноминацию и т.п.? Сомневаюсь.
Если бы никто не брался за работу без предварительно и чётко оговорённых спецификаций, было бы что-либо подобное написано? Нет. И работали бы сейчас бухгалтеры по старинке, с помощью ручки, бумаги да калькулятора. Потому что надменные программисты считали бы, что не стоит и браться за то, что слишком расплывчато, да к тому же подвержено изменениям. "Вот когда государство вступит в ВТО, НАТО, ЕС и прочая, приведёт законодательство в соответствии с международными стандартами, - тогда да, тогда можно будет подумать. А пока я лучше напишу HTTP-сервер на платформе J2EE с поддержкой технологий SSL, UML, XML, SOA и USB".

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

Ответ на »сообщение 2785« (Руслан Богатырев)
___________________________
>>>Просто жизнь привела к мысли, что любая программируемая задача (если она делается тобой или твоим коллективом впервые) наверняка будет сделана, мягко говоря, очень неоптимально. ООП хорошо, когда работаешь по накатанной (и то, надо делать поправку на ветер -- хорошо разбираться в структуре используемой библиотеки классов, ибо программируешь в режиме умолчаний наследования и "делегирования" ответственности).
Хочу поделится радостью :)
На днях разыскал меня заказчик с которым мы не виделись десять лет. Списали его установку, для котрый мы когда-то написали программу анализа результатов. Еще на Pascal for Windows. С новой установкой пришла куча математики, но его она не устраивает. Когда то я доводил его до белого каления своими распросами. Зато теперь я из телефонного разговора понял, что нового в технике и какие доработки нужны в программе. Самое забавное, что базовую иерархию классов менять не придется. Хоть снимай с полки P4W :)
Я это к чему? Чтобы сделать программу, полезную для конкретного специалиста, нужно научится делать его работу. Тогда становится понятно, чем может помочь компьютер и как это реализовать.

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

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

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

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