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

которая, например, будет гарантировано обыгрывать нынешнего фаворита -- чешскую Rybka Васика Райлиха.

Можно упростить условие -- пусть будет играть хотя бы на равных.

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

Не зная конкретики не будем браться - самый простой путь.
Или сядем за учебники и будем месяцами(иногда годами) разбираться в предмете.

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

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

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

>>>Если же строится что-то впервые
А пример можно? Просто интересно, в каких областях можно написать что-то путное не разбираясь в этом предварительно.

Вообще с Оберонами несложная модель получается (меньше, чем на страничку).

Оберон (классический) строится на нескольких элементарных вещах.

1. Базовые сущности императивного программирования: константы, переменные, типы, процедуры (исх. модель – классический Паскаль).
2. Базовые конструкции императивного программирования: последовательность, ветвление, цикл, рекурсия.
3. Базовые понятия модульно-расширяющего программирования.
a) module (модуль) -- средство информационного сокрытия (по Парнасу, исх. модель – язык Mesa), механизм экспорта-импорта сущностей.
b) SYSTEM (псевдомодуль) – локализация низкоуровневых вещей языка, средство общения с компилятором и run-time.
c) procedure type (процедурный тип) – средство коммутации кода.
d) record (запись) – средство агрегирования разнородных данных (по Хоару) + средство инкапсуляции.
e) type extension (расширение типа) – средство развития функциональности (по Гуткнехту).

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

Ответ на »сообщение 2769« (Антон Григорьев)
___________________________

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

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

Поэтому либо надо принять продуманный минимализм как средство надежности, понимая, что человеческий фактор всегда будет главным, либо пытаться окружать себя "автопилотами". Все равно придется идти на компромисс: вопрос в том, где остановиться в погоне за автопилотами, создающими иллюзию надежности: одни останавливаются в самом начале (Оберон), другие чуть-чуть насыщают модными средствами (КП), третьи моду по максимуму "вылизывают" (Java, C#), ну а четвертые наворачивают механизЬмов от души (C++).

Помнится, когда я брал интервью у Леона Кацнельсона, директора по конкурентным технологиям IBM, то в неформальной беседе выяснил, что в IBM даже бытует такая концепция -- бороться со сложностью другой сложностью. Что ж, можно и так... Каждому, как говорится, свое...

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

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

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

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

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

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

Ответ на »сообщение 2760« (Антон Григорьев)
___________________________

Ответ на »сообщение 2755« (Илья Ермаков)
___________________________

Чем ваша фраза отличается от такой?

Нет проверки границ массива - программист просто ОБЯЗАН, обязан всей идеологией, всеми нормами, всеми примерами, которые видит, проверять их самомстоятельно.


Принципиально отличается. В Блэкбоксе стандартные типы Framework'a нельзя использовать неправильно, без инициализации. Не получится. Потому что писавший библиотеку это запретил, применив прием абстрактного типа данных, с сокрытием реализации и инстанционирования. Чем не устраивает такой подход? В языке с конструкторами безграмотный разработчик может не описать конструктор для разрабатываемого класса. В Обероне безграмотный разработчик может не использовать сокрытие реализации или LIMITED. В любом случае ошибку может совершить разработчик класса, и не на уровне опечатки, а на уровне сознательного ляпа. А застраховать от забывчивости разработчиков клиентских модулей можно 100% и там, и там. (Только применив открытый класс с конструктором, разработчик уже повязан обратной совместимостью по рукам и ногам, а "третья сторона" не может предоставить прозрачно инсталлируемых расширений. Если разработчик вынужден применять АТД, то избегнет в дальнейшем сильной головной боли и скажет не один раз спасибо).

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

А что Вы понимаете под надежностью? И что -- под надежным языком? Вопрос не праздный.

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

А вот если использовать ООП, то Оберон не имеет никаких жёстких ограничений, заставляющих писать корректный код. Я понимаю, что хорошо подготовленный программист разберётся, выберет нужный стиль и будет его строго придерживаться, даже если выгоды от этого неочевидны. Но ведь Оберон позиционируется как идеальный язык для "програмирующего непрограммиста". Человеку, который программирует от случая к случаю, сложно будет доказать необходимость создания фабрики для каждого класса и упрятывания самого класса внутри модуля, особенно в маленьком проекте. И мы получим ситуацию С/С++ - все слышали, как писать не надо, многие с этим даже согласны, но так быстрее и проще (т.е. выглядит быстрее и проще), поэтому почти все пишут так, как не надо.

Ответ на »сообщение 2766« (Руслан Богатырев)
___________________________
>>>Для чего задумывался класс? Для инкапсуляции (данные + поведение) -- что по Хоару (record class), что по Далу-Нигаарду. Инкапсуляции прозрачной, не предусматривающей information hiding.
Мы тут уже договорились, что класс нужен для борьбы со сложностью задачи - он позволяет структурировать предметную область, можно называть это инкапсуляцией.
А модуль необходим для борьбы со сложностью программы. Он позволяет структурировать архитектурные и алгоритмические решения, это тоже можно называть инкапсуляцией.
В сложных случаях необходимы оба инструмента.
А согласуются они плохо :(

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

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

>>>Это и есть, с моей точки зрения, чисто операционный подход (не важно зачем, важно как; khow how), в противовес концептуальному (know why). Вы не обратили внимание, что сейчас программирование как деятельность сводится преимущественно к программированию на конкретном языке? Оно к нему прилипло намертво. Мы обсуждаем все больше технические проблемы того или иного языка или (как в случае данной дискуссии), как средства одного языка воплотить в другом. Может, не от того танцуeм? Может, прежде чем строить, думать надо?
+1
Золотые слова.
Сначала определиться с целью, потом подбирать методы.
Мы тут постоянно спорим, что лучше, домкрат или разводной ключ.
A  Jack Of Shadows утверждает, что самый правильный инструмент - краскопульт: он не требует нажима :Р
(он раньше красил кисточкой, а теперь знает Истину и пользуется только краскопультом)
И никто не утруждает себя пояснениями, что именно они делают.

Ответ на »сообщение 2766« (Руслан Богатырев)
___________________________
Это и есть, с моей точки зрения, чисто операционный подход (не важно зачем, важно как; khow how), в противовес концептуальному (know why).
Тогда уже - know what for.