Здравствуйте, Maxim S. Shatskih,

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

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

Отсюда и своеобразная притягательность ООП и регулярные упрёки. Но ведь не может же, например, грамматика (sic! — на горизонте парадигма) русского языка ответить на вопрос: "что делать с главным героем?" Грамматика только подскажет, как написать это грамматически корректно.

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

Ещё и Алан Кей подлил масла в огонь, сказав, что всё есть объекты и сообщения между ними. Таким образом он ткнул пальцем в дуальность "действие <-> сущность", свойственную объектно-ориентированным инструментам. Это, с одной стороны, подтверждает мощность ООП, а с другой даёт плодородную почву для дичайшего хаоса.

Это была преамбула. Теперь по делу.

MSS>В этой теме я хочу коснуться именно принципиальных, концептуальных проблем ОО парадигмы, а не применимости ее в конкретных проектах.
MSS>Итак.

Собственно, ты совершаешь ошибку. "Парадигма ООП" не может сама по себе ответить на конкретные вопросы. Сколько ни вникай в сущность понятия "объект", всё равно не поймешь, что же такое "движение": это объект TMovement или метод Move. Напоминаю: ООП — скорее способ выражения, чем готовые рецепты.

MSS>1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.

И правильно делают. Паттерны ООП выражают очень общие идеи. Многонитевость, параллельность вычислений — это уже конкретная область применения. Разрешение вопроса "кто владеет локом" — из той же серии.

MSS>2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.

То же самое, что и для 1). Здесь нужно в конкретном случае ставить конкретные вопросы о том, как лучше выразить решение задачи в терминах ООП при наличии конкретных ограничений. То есть, неверно утверждать: "ОО-шное решение, это только...". Нельзя обвинять русский язык в том, что большая часть авторов, которые на нём пишут — кретины и из-под пера у них выходит кретинизм.

MSS>Общее у этих двух недостатков: ОО предполагает кучу мелких сущностей, каждая из которых состоит из кода и из элемента данных. Это не всегда удобно. Иногда бывает удобно иметь сложные структуры именно одних лишь данных, а код к ним прилеплять уже по мере необходимости с различных боков. Т.е. классический процедурный, не ОО подход.

Вот! Вот оно!!! Но ОО ничего такого не предполагает само по себе!!!! "Мелкость" или "крупность" сущности — относительные понятия. То, что мелко в рамках решения одной задачи, становится очень крупным в рамках другой.

ООП было порождено исследованиями в области формализации знаний. Потому-то оно и стимулирует к большой детализации и структурированию. Знания ведь тоже хочется детализировать и структурировать, правда?

Но увы, процесс познания бесконечен, а abstraction penalty никто не отменял, так что, всегда нужно идти на компромисс. А компромисс в каждом конкретном случае — свой собственный.

MSS>Ну вот примерно так.
Ага. Так, или примерно так.

Здравствуйте, VladD2, Вы писали:

VD>Скажу больше в ООП нет и итерации.
VD>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений.

Что-что?

Здравствуйте, absolute, Вы писали:

A>Так вот. Параллельное программирование с использованием потоков и семафоров можно сравнить с ручным использованием стеков и адресов возврата для повседневного вызова процедур. Использование же активных объектов позволяет работать с параллелизмом на гораздо более высоком семантическом уровне.

Ясен пень. Не будь ключевых слов AWAIT, ACTIVE, EXCLUSIVE — дык и не догадались бы ни за что про conditional vars, threads и critical sections. Слава Вирту! Кхм. Вопрос по ходу: знаешь, что такое некорректный приём? Это сказать что-то правильное (первый прцитированный абзац), а потом — что-то несуразное, но связать эти два высказывания словами "точно также" или как-то так.

A>Прорыв сравним здесь с написанием вызова подпрограммы одной строчкой. Ничего хитрого там действительно нет. Например, оператор AWAIT языка Active Oberon, будучи разложен на элементарные действия, по сложности примерно равен вызову подпрограммы. Но в тексте программы он будет представлен одной строчкой, ясно показывающей наши намерения.

Тема семантического уровня не раскрыта. В чём глобальный дифференс между вставкой ключевого слова AWAIT и вот такой конструкцией:

void func()
{
  my_cond_var.wait();

?

Я совершил контрпрорыв?

Здравствуйте, IT, Вы писали:

IT>Честно говоря, надоели уже до чёртиков все эти разговоры про недостатки ООП.

о боже, ты ли это говоришь?
На самом деле ООП не решает некоторые задачи, и его возможности неплохо бы расширить.

Здравствуйте, Дарней, Вы писали:

Д>о боже, ты ли это говоришь?

Я знал что ты здесь появишься и обязательно отметишься

Д>На самом деле ООП не решает некоторые задачи, и его возможности неплохо бы расширить.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тема семантического уровня не раскрыта. В чём глобальный дифференс между вставкой ключевого слова AWAIT и вот такой конструкцией:

ГВ>

ГВ>void func()
ГВ>{
ГВ>  my_cond_var.wait();
ГВ>

ГВ>?

ГВ>Я совершил контрпрорыв?

У AWAIT имеется аргумент — булевское выражение произвольной сложности, которое записывается здесь же.

Стало быть, разница как между обменом данными с помощью глобальных переменных против их передачи через аргументы.

absolute wrote:
> У AWAIT имеется аргумент — булевское выражение произвольной сложности,
> которое записывается здесь же.
А что это меняет? В том же pthread можно по предикатам ждать, в Win32
прямого аналога нет, но он делается без особых проблем (мы ведь помним,
что все многопоточные паттерны сводятся к семафору и мьютексу).

> Стало быть, разница как между обменом данными с помощью глобальных
> переменных против их передачи через аргументы.
Да ни чуть. Разница в наборе встроенных примитивов синхронизации. То
есть разницы, по сути, нет.

Здравствуйте, absolute, Вы писали:

A>У AWAIT имеется аргумент — булевское выражение произвольной сложности, которое записывается здесь же.

Ну да. Лямбда. То же самое можно сделать хоть на C.

A>Стало быть, разница как между обменом данными с помощью глобальных переменных против их передачи через аргументы.

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

Тема семантического уровня пока не раскрыта.

Здравствуйте, Геннадий Васильев, Вы писали:

> Ничего общего. Или в это выражение можно запихнуть локальные переменные?

Да, можно использовать локальные переменные и поля данных объекта.

> Если да, то какой в этом смысл?

Смысл — максимальная инкапсуляция синхронизации.
В локальных переменных. Внутри объектов. Внутри модулей.

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

Здравствуйте, absolute, Вы писали:

>> Ничего общего. Или в это выражение можно запихнуть локальные переменные?

A>Да, можно использовать локальные переменные и поля данных объекта.

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

>> Если да, то какой в этом смысл?
A>Смысл — максимальная инкапсуляция синхронизации.
A>В локальных переменных. Внутри объектов. Внутри модулей.

Поясни, плз., что такое "инкапсуляция синхронизации". Это инкапсуляция примитивов или синхронизируемых сущностей?

absolute wrote:
>> Ничего общего. Или в это выражение можно запихнуть локальные переменные?
> Да, можно использовать локальные переменные и поля данных объекта.
Какое замечательное поле для race condition'ов. Синтаксис Оберона
вспоминать лень, пишу в псевдокоде:

class Clazz1
{
    int a=0;
};
class Clazz2
{
    Clazz1 cl1;
};

class Clazz3
{
    Clazz2 cl2;

    void doSomething()
    {
        AWAIT(cl2->cl1->a != 0)        
    }
};

Clazz3 cl3;
Clazz2 cl2=cl3->cl2;

cl3.doSomething(); //Ждемс...

//а в это время из другого потока
cl2->cl1=NULL; //Угадайте, что произойдет если как
//раз в этот момент происходило обращение к переменной cl1
//через поле в cl2?

> В отличие от более повсеместных подходов, когда блокировка на объект
> находится снаружи объекта, и неизвестно кто имеет доступ к ней (обычно —
> кто угодно).
Что совершенно правильно. Самоблокировка только способствует
трудноуловимым deadlock'ам и прочим ошибкам.

Здравствуйте, IT, Вы писали:

IT>ООП хорошо решает то, что решает хорошо. Речь как раз о том стоит ли пытаться впихнуть в ООП всё, что способен сочинить около объектного воспалённый мозг разработчика.

Если такая задача стоит перед разработчиком — возможно, стоит.
Кстати, чего лично мне очень не хватает — это удобной поддержки Inversion of control/системы сервисов на уровне языка. Кому-нибудь еще это нужно, интересно?

Здравствуйте, Дарней, Вы писали:
Д>Если такая задача стоит перед разработчиком — возможно, стоит.
А может, просто ввести какую-нибудь ортогональную концепцию?

Здравствуйте, Sinclair, Вы писали:

S>А может, просто ввести какую-нибудь ортогональную концепцию?

совсем ортогональную не получится. Скорее, что-то Х-образное

Здравствуйте, Геннадий Васильев, Вы писали:

VD>>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений.

ГВ>Что-что?

Пар-р-радигма.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.

Параллельное программирование — это отдельная проблема, ортогональная к "ОО vs. не-ОО".

MSS>2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.

Почему? Есть, например паттерн flyweight (если мне память не изменяет).

Что же до теоретических проблем, то они, конечно, есть. Шутки шутками, но теоретики до сих пор ломают копья на тему преимуществ одиночного и множественного наследований

Вообще, в фундаменте ОО лежит много весьма спорных аксиом. Я, например, готов поспорить с тем, что:

Всё есть объект

Объект должен обладать идентичностью (OID)

Так что до многонитёвости нам ещё брести и брести...

Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений.

ГВ>>Что-что?

ANS>Пар-р-радигма.

Угу, слышали

Автор: Геннадий Васильев
Дата: 13.04.06

.

Здравствуйте, Геннадий Васильев, Вы писали:

A>>Так вот. Параллельное программирование с использованием потоков и семафоров можно сравнить с ручным использованием стеков и адресов возврата для повседневного вызова процедур. Использование же активных объектов позволяет работать с параллелизмом на гораздо более высоком семантическом уровне.

ГВ>Ясен пень. Не будь ключевых слов AWAIT, ACTIVE, EXCLUSIVE — дык и не догадались бы ни за что про conditional vars, threads и critical sections. Слава Вирту! Кхм. Вопрос по ходу: знаешь, что такое некорректный приём? Это сказать что-то правильное (первый прцитированный абзац), а потом — что-то несуразное, но связать эти два высказывания словами "точно также" или как-то так.

exclusive и await — более высокоуровневые "штуки", чем critical section и conditional variable. Так что можно придраться к слову "гораздо", но не больше того.

exclusive и await описывают происходящее с объектом-монитором и вошедшим в него потоком управления. За кадром остаются вопросы планирования, диспетчеризации, разделения доступа... даже существования потоков.

critical section и conditional variable — строительные кирпичи, позволяющие, во-первых, локализовать реализацию монитора в пределах одного объекта (противоположность — это глобальный менеджер мониторов), а во-вторых, при желании, прицельно планировать потоки, ожидающие исключительного доступа или наступления событий.

Вот пример: в винапи нет примитива "conditional variable", поэтому в boost/thread его выразили через громоздкую конструкцию со встроенным планировщиком (в pthreads это же самое сделано где-то в недрах).
Однако для синхронизации конструкции "один поставщик — очередь — один потребитель" не возникает вопросов голодания или ложных срабатываний; в качестве будильника достаточно использовать единственный SetEvent / ResetEvent.

Нужно ли разработчику следить за всем этим добром? Если он хочет выжать все соки — конечно, нужно. Как иногда приходится делать ассемблерные вставки.
В остальных случаях — напишем протокол о намереньях: "Се моё!... Ждать здесь!... Я всё сказал!". А если дефолтный планировщик не устраивает, то можем выразить любую политику планирования прямо на высоком уровне, не обращая внимания на возможности и рамки, зашитые в ОС.

Здравствуйте, Кодт, Вы писали:

A>>>Так вот. Параллельное программирование с использованием потоков и семафоров можно сравнить с ручным использованием стеков и адресов возврата для повседневного вызова процедур. Использование же активных объектов позволяет работать с параллелизмом на гораздо более высоком семантическом уровне.

ГВ>>Ясен пень. Не будь ключевых слов AWAIT, ACTIVE, EXCLUSIVE — дык и не догадались бы ни за что про conditional vars, threads и critical sections. Слава Вирту! Кхм. Вопрос по ходу: знаешь, что такое некорректный приём? Это сказать что-то правильное (первый прцитированный абзац), а потом — что-то несуразное, но связать эти два высказывания словами "точно также" или как-то так.

К>exclusive и await — более высокоуровневые "штуки", чем critical section и conditional variable. Так что можно придраться к слову "гораздо", но не больше того.

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

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

Да, согласен, что с {ACTIVE} и с {AWAIT} ситуация чуть посложнее. Но опять не заметно большой разницы. В сущности, ACTIVE можно эмулировать с некоторыми ограничениями (автозапуск метода в отдельном потоке). AWAIT, в общем — тоже.

К>exclusive и await описывают происходящее с объектом-монитором и вошедшим в него потоком управления. За кадром остаются вопросы планирования, диспетчеризации, разделения доступа... даже существования потоков.

Я бы сказал, что очень хочется верить, что все эти вопросы остаются за кадром. Помилуйте, как можно оставить за кадром вопрос существования потоков при наличии явной декларации active? Что такое exclusive, как не забота о разделении доступа? Что такое await, как не приостановка потока? Если у нас active-метод вызывает не-active-метод, то следует ли учитывать то, что вызванный метод работает в новом потоке? Даже если назвать "поток" хоть бурбумумзиком, всё равно это отдельный стек и (квази-)параллельные вычисления со всей спецификой.

Что же до собственно планирования и диспетчеризации, то это и в рамках C обычно остаётся за кадром.

К>critical section и conditional variable — строительные кирпичи, позволяющие [...]

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

Cразу замечу, что аналогия с ассемблером здесь не подходит, потому что "семафор" и сам по себе абстракция над тем же железом.

---

Ладно, на самом деле тут всё, конечно, понятно. Дело здесь, конечно, не в какой-то абстрактной "высокоуровневости", а в том, что семантика await/exclusive/active просто и незатейливо соответствует целям разработчиков всей системы Active Oberon. То есть, здесь если и имеет смысл вести речь о каких-то "уровнях", то лишь с точки зрения близости механизмов языка и целей разработчиков. А хотели они, как это написано в их же документах:

[...]

Our motivation is the belief that system software does not have to be
gigantic to be useful or powerful. A sustainable approach to computing
is more desirable than a reliance on Moore’s law to support ever-growing
software systems, sometimes with countless ‘features’ of doubtful utility
(but great marketability).

[...]

The specific goals for our project were to:
1. Design a lean and efficient kernel for general active object-based
systems. The kernel should be applicable in many areas, e.g.,
in an operating system similar to Oberon, in a server operating
system, in an embedded control system or as an operating system
for small devices (i.e., mobile computers). Therefore, it should
also be realizable on a wide range of hardware, from powerful
multiprocessor server machines down to modest hand-held and
wearable devices.
2. Implement the kernel on powerful industry-standard machines,
specifically the Intel 32-bit multiprocessor system architecture.
3. Use the kernel as a testbed to implement a general-purpose active
object-based operating system. The system should host its own
development environment and other applications like servers.
4. Port the current ETH Oberon system to run in an active object
on the system, providing compatibility with existing Oberon applications.

Это была выдержка из раздела Introduction/Motivation. Короче, "active object-based" — включён в состав целей явно, без лишних реверансов. Ну и по маркетологии проехались походя, респект. В принципе, всё понятно: всё вокруг сложное, хотелось бы поискать пути для упрощения, искать будем в Обероне. Где тут "уровень абстракции", которым существенно отличается оберон от всех-всех-всех прочих — похоже, только апологетам известно.

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

Так и с Обероном. Понятна цель разработчиков: сделать active object-based систему. Обсуждаемые примитивы хорошо подходят как для всеобщего object, так и для active. Ну и всё. Вот вам и альфа, и омега. Для исследовательского проекта — прекрасно. Должна ли быть реальная будущая ОС именно объектной — вопрос более чем открытый. А коль скоро не определено, какой должна быть будущая супер-ОС, то есть, не определены конечные цели, то бессмысленно говорить о том, что active/await/exclusive "более абстрактны", чем семафоры. В рамках идей Питера Мюллера и Ко — да, для остальных — бабушка надвое сказала.

ГВ>Так и с Обероном. Понятна цель разработчиков: сделать active object-based систему.

Это было не совсем верно. Конечно, active object-based — это одна из целей. Более общая цель — поискать пути развития. Нашли они его? Неясно.

ГВ>А коль скоро не определено, какой должна быть будущая супер-ОС, то есть, не определены конечные цели,

...которые будут соответствовать целям статистического большинства, иначе такая ОС просто не получит поддержки в массах. Мне очень сильно сдаётся, что под обозначением "ОС" пресловутые массы гораздо легче примут инструмент для управления компьютерами, а не воплощение очередного мегаправильного "взгляда на мир".

ГВ>то бессмысленно говорить о том, что active/await/exclusive "более абстрактны", чем семафоры. В рамках идей Питера Мюллера и Ко — да, для остальных — бабушка надвое сказала.

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