В этой теме я хочу коснуться именно принципиальных, концептуальных проблем ОО парадигмы, а не применимости ее в конкретных проектах.
Итак.
1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.
В этом разделе программирования очень важную роль играют атомарные операции, в общем почти транзакции (свойства A и I точно есть). То есть — некая совокупность изменений связанных структур данных должна делаться обязательно до конца, и ее промежуточные состояния не видимы другим субъектам исполнения.
В свете этих атомарных операций большую роль играет то, какие именно куски большой структуры есть объект атомарной операции. Грубо говоря, "какой лок что защищает".
Еще одна сложность в том, что зачастую по ходу этой "транзакции" нужно делать какие-то медленные, занимающие неизвестное время операции. Естественно, это нужно делать вне "транзакции" (иначе потеря скалабильности и шансы на дедлок), т.е. разбивать "транзакцию" на две, вводить промежуточное состояние всей большой структуры, во время которого и делается медленная операция.
Классическое ОО, которое означает — "куча мелких кусочков, каждый есть чуть-чуть данных и чуть-чуть кода" не дает средств как-то вразумительно это описать. То есть — структурный, Сишный подход в коде, богатом многонитевостью, ничем не хуже. "ООшность" не дает выигрыша, например, в случае, когда большая структура (над которой оперируют транзакции) есть родитель с переменным количеством дочерних объектов, да еще и со ссылками наружу.
2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.
ООшное решение для такого — обернуть каждый элемент данных в объект, создать контейнер объектов, и потом итерировать контейнер.
Кроме итераций, ОО практически ничего не предлагает.
Пример: сохранение в файл большого количества мелких элементов данных. Если такая задача стоит часто и требования к ней по скорости высоки, то имеет смысл хранение данных в памяти проектировать именно "от сохранения в файл". Т.е. — много страниц, каждая из которых сохраняется в файл одним вызовом write(). В странице находятся элементы данных, которые идут там "встык", как в Сишном массиве. Удаление из середины и реюз удаленного места делается, например, списком пустых мест.
Это не-ООшный паттерн. Совсем. Операции оперируют над отдельными объектами, в то время как хранятся сразу агрегаты объектов, и есть агрегатные операции — сохранение в файл.
ОО для решения задачи может только предложить проитерировать контейнер и сериализовать каждый объект отдельно, с чудовищными накладными расходами.
Или взять задачу поиска, отбора элементов данных по какому-то признаку. ООшный стиль будет иметь много больший оверхед, чем вот такой "страничный".
В этом мне видится причина, почему "не пошли" ООБД. Связывать каждый элемент данных с кодом — расточительно. Это требует, например, на неких массовых операциях — инстанцирования каждого объекта. Медленно. SQLный SELECT быстрее.
Общее у этих двух недостатков: ОО предполагает кучу мелких сущностей, каждая из которых состоит из кода и из элемента данных. Это не всегда удобно. Иногда бывает удобно иметь сложные структуры именно одних лишь данных, а код к ним прилеплять уже по мере необходимости с различных боков. Т.е. классический процедурный, не ОО подход.
Здравствуйте, Maxim S. Shatskih, Вы писали:
> 1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование. > ... > Классическое ОО, которое означает — "куча мелких кусочков, каждый есть чуть-чуть данных и чуть-чуть кода" не дает средств как-то вразумительно это описать.
Модель активных объектов в стиле Active Oberon постулирует:
Объект — это чуть-чуть данных и чуть-чуть кода для согласованных атомарных действий над этими данными.
И есть активные объекты — обладающие собственным потоком управления.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.
MSS>В этом разделе программирования очень важную роль играют атомарные операции, в общем почти транзакции (свойства A и I точно есть).
+1
В принципе, неплохо бы иметь полноценные транзакции для операций над объектами. Это было бы полезно в ряде задач, во всяком случае — прикладных.
MSS>2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.
+1
может быть, еще:
3) Объект не может менять свой тип.
Есть конечно паттерн State, но это просто костыль.
Здравствуйте, absolute, Вы писали:
A>Модель активных объектов в стиле Active Oberon постулирует: A>Объект — это чуть-чуть данных и чуть-чуть кода для согласованных атомарных действий над этими данными. A>И есть активные объекты — обладающие собственным потоком управления.
это в чистом виде синтаксический сахар, который ничего не решает
Здравствуйте, absolute, Вы писали:
A>Кому синтаксический сахар, а кому и более высокий уровень абстракции.
A>Надеюсь, не нужно объяснять разницу между этими понятиями?
Не нужно.
А что нужно — объяснить, по сравнению с чем более высокий.
Здравствуйте, absolute, Вы писали:
A>Здравствуйте, Maxim S. Shatskih, Вы писали:
>> 1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование. >> ... >> Классическое ОО, которое означает — "куча мелких кусочков, каждый есть чуть-чуть данных и чуть-чуть кода" не дает средств как-то вразумительно это описать.
A>Модель активных объектов в стиле Active Oberon постулирует: A>Объект — это чуть-чуть данных и чуть-чуть кода для согласованных атомарных действий над этими данными. A>И есть активные объекты — обладающие собственным потоком управления.
Да, мне тоже кажется, что ОО никак не противоречит параллельности. Если на концептуальном уровне каждый процес (или нить) — это объект, то переходим от параллельности процессов к взаимодействию объектов.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Дарней, Вы писали:
A>>По сравнению с процессами, потоками и семафорами.
Д>Не вижу особой разницы. Все делается точно так же, только называется по другому
Попробуем провести такую параллель.
Существует очень хорошая, полезная и мощная концепция под названием "вызов подпрограммы". Чтобы произвести вызов подпрограммы, нужно положить на стек аргументы, адрес возврата, осуществить переход, в конце выполнения подпрограммы снять адрес возврата и перейти по нему, оставив на стеке результаты, которые затем будут использованы вызывающим кодом.
Последовательность нехитрая, но несколько утомительная для постоянного ручного кодирования. К счастью, программисты давным-давно могут уже не задумываться об этом. Операция "вызов подпрограммы" давно автоматизирована как на уровне языков программирования, так и на аппаратном уровне предоставлением машинных команд вызова и возврата.
Так вот. Параллельное программирование с использованием потоков и семафоров можно сравнить с ручным использованием стеков и адресов возврата для повседневного вызова процедур. Использование же активных объектов позволяет работать с параллелизмом на гораздо более высоком семантическом уровне. Прорыв сравним здесь с написанием вызова подпрограммы одной строчкой. Ничего хитрого там действительно нет. Например, оператор AWAIT языка Active Oberon, будучи разложен на элементарные действия, по сложности примерно равен вызову подпрограммы. Но в тексте программы он будет представлен одной строчкой, ясно показывающей наши намерения.
Здравствуйте, LaptevVV, Вы писали:
LVV>Да, мне тоже кажется, что ОО никак не противоречит параллельности. Если на концептуальном уровне каждый процес (или нить) — это объект, то переходим от параллельности процессов к взаимодействию объектов.
Отлично!
Именно так!
Средства межпроцессного взаимодействия, имеющие первостепенное значение в операционных системах "с процессами", превращаются в межобъектное взаимодействие. А межобъектное взаимодействие у нас одно — посылка сообщения. Или, на практике, процедурный вызов метода объекта.
Более того, все средства IPC можно реализовать на самом языке программирования Active Oberon. Ещё один бонус — все они будут подчиняться сильной типизации, в отличие от традиционно бестиповых IPC (например pipe — "поток неструктурированных байт", и т. п.).
Maxim S. Shatskih wrote: > Итак. > 1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное > программирование.
Ничуть. Все основные способы параллельности либо ортогональны ОО, либо
прекрасно выражаются с помощью ОО.
В частности:
1. Блокировки — абсолютно ортогональны ОО.
2. Атомарные структуры — прекрасно сосуществуют с ОО.
3. Параллельность с помощью посылки асинхронных сообщений — так вообще
как будто для ОО делалась.
> В этом разделе программирования очень важную роль играют атомарные > операции, в общем почти транзакции (свойства A и I точно есть). То есть > — некая совокупность изменений связанных структур данных должна делаться > обязательно до конца, и ее промежуточные состояния не видимы другим > субъектам исполнения.
См. JBoss4 — там делаются транзакции на (почти) произвольных графах
объектов с помощью инструментации байт-кода. В любом случае, эта
проблема к ОО отношения не имеет.
> Классическое ОО, которое означает — "куча мелких кусочков, каждый есть > чуть-чуть данных и чуть-чуть кода" не дает средств как-то вразумительно > это описать. То есть — структурный, Сишный подход в коде, богатом > многонитевостью, ничем не хуже. "ООшность" не дает выигрыша, например, в > случае, когда большая структура (над которой оперируют транзакции) есть > родитель с переменным количеством дочерних объектов, да еще и со > ссылками наружу.
ОО как раз позволяет неплохо выделить working set и следить за
контекстом выполнения. В чистом С это, естественно, тоже делается, но
уже достаточно искусственно.
Совершенно естественный код. И совершенно непотокобезопасный.
Теперь перепишем на С++:
std::string str="A tokinezed, string! Here!";
//Неплохо бы инкапсюлировать состояние токенизации.
//Конечно же, для этого лучше взять объект.
Tokenizer tok(str," , !");
for(std::string cur=tok.begin();!cur.empty();cur=token.next())
{
//Сразу возникает вопрос - а с какими потоками
//разделяется std::cout? Ну ладно, считаем вывод thread-safe
std::cout<<cur;
}
(Я сейчас про Erlang говорить не буду)
> 2). В ОО очень плохо решен вопрос операций сразу на большим количеством > похожих элементов данных. > ООшное решение для такого — обернуть каждый элемент данных в объект, > создать контейнер объектов, и потом итерировать контейнер.
Во-первых, смотрим на OpenMP — это я про то, что итерация замечательно
парллелится.
Во-вторых, смотрим на "map-reduce" — тоже замечательно дружит с ОО.
В-третьих, пока процессоры еще не научились делать что-либо, отличное от
последовательного перебора (ну за исключением векторных вычислений, но
это слишком узкий класс).
> Пример: сохранение в файл большого количества мелких элементов данных. > Если такая задача стоит часто и требования к ней по скорости высоки, то > имеет смысл хранение данных в памяти проектировать именно "от сохранения > в файл". Т.е. — много страниц, каждая из которых сохраняется в файл > одним вызовом write(). В странице находятся элементы данных, которые > идут там "встык", как в Сишном массиве. Удаление из середины и реюз > удаленного места делается, например, списком пустых мест.
Welcome to C++ — отображем файл на память, и используем аллокатор,
создающий объекты прямо в файле (см. Boost.Shmem). Можно даже контейнеры
в дисковую память отображать — я таким макаром mini-ООСУБД написал за час.
> Или взять задачу поиска, отбора элементов данных по какому-то признаку. > ООшный стиль будет иметь много больший оверхед, чем вот такой "страничный".
Ничуть. Берем Boost.RTL (Relational Template Library) и делаем,
например, так:
// allocate the expression to query for people joined
// between 12/5/2003 and 12/25/2003, and sort them by name
expr_type expr = key_index<mpl::vector<name, id> >(
range_selection(
key_index<mpl::vector<joined, id> >(t),
lower_bound(row<mpl::vector<joined> >(date(2003, Dec, 5))),
lower_bound(row<mpl::vector<joined> >(date(2003, Dec, 25)))
)
);
transaction tr;
// modify the table through the transaction
tr.insert(t, employee_tuple(11, "K", date(2003, Dec, 7)));
tr.insert(t, employee_tuple(12, "CC", date(2003, Dec, 17)));
tr.remove(t, *t.lower_bound(row<mpl::vector<id> >(5)));
expression_registry exprs;
exprs.add(expr);
// commit the transaction. Tell it to update the expression.
// two indexes get incrementally updated rather than rebuilt.
tr.commit(exprs);
// reuse the query
print(expr);
(кстати, это еще и к вопросу о транзакциях)
> Общее у этих двух недостатков: ОО предполагает кучу мелких сущностей, > каждая из которых состоит из кода и из элемента данных. Это не всегда > удобно. Иногда бывает удобно иметь сложные структуры именно одних лишь > данных, а код к ним прилеплять уже по мере необходимости с различных > боков. Т.е. классический процедурный, не ОО подход.
В ОО-подходе аггрегатная сущность может служить адаптером для мелких
сущностей. Так что ничего не противоречит.
Здравствуйте, absolute, Вы писали:
A>Кому синтаксический сахар, а кому и более высокий уровень абстракции.
A>Надеюсь, не нужно объяснять разницу между этими понятиями?
Синтаксический сахар для того и делается чтобы поднять уровень абстракции. Так что понятия зависимые но не сопостовимые.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Честно говоря, надоели уже до чёртиков все эти разговоры про недостатки ООП. Я предлагаю прекратить подобные инсинуации и начать проще относиться к жизни в целом и к ООП в частности. Нужно всего-то лишь перестать думать об ООП как о панацее и/или серебряной пуле и всё сразу станет на свои места.
Лично я уже давно отношусь к ООП просто как к набору удобных, хорошо зарекомендовавших себя дизайн паттернов, которые экономят мне кучу времени. Как-то после первого года работы на C++, мой шеф заставил меня писать обратно на чистом C, якобы в целях какой-то там совместимости. Помню, ломка у меня тогда началась с первых же строк кода. И что забавно после завершения работы я обнаружил практически у всех моих методов наличие первого параметра с характерным названием this. Т.е. что я сделал? Правильно, использовал один из паттернов, традиционно применяемых в ООП. А виндузовые handlers ничего не напоминают? Ну, например, ассоциации с паттерном инкапсуляция не напрашивается? А polymorphic behavior никто с помощью указателей на функции в C не делал? Я делал, очень удобно было реализовывать обработчики всевозможных событий, хотя даже само слово событие вошло в мой лексикон гораздо позже.
И что, после 15 лет все эти возможности куда-то испарились или стали невостребованными? Я думаю, что нет. Просто отдельные индивидуумы, выучив определение трёх основных составляющих ООП начинают пихать его во все нужные и ненужные места и потом искренне удивляются, почему это в ООП плохи дела с “параллельным программированием” и злобные основоположники парадигмы забыли решить “вопрос операций сразу на большим количеством похожих элементов данных”.
А может просто хватит заниматься фигнёй?
В общем, вывод может быть такой. У ООП есть только один недостаток – возможность использовать его не по назначению.
Но такие недостатки можно найти практически у любого предмета. Например, большой недостаток молотка заключается в том, что им очень больно попадать по пальцам, проблема лобзика в том, что им очень неудобно валить Беловежскую пущу, а к несомненным недостаткам выхлопной трубы можно отнести явное неудобство через неё регулировать клапана двигателя практически любого современного автомобиля.
И даже венец творения природы человек не лишён подобных недостатков. Видишь ли, не через любое отверстие в нём можно качественно удалить ему гланды
ЗЫ. Руки прочь от ООП!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.
Ты путашь отсуствие средств поддержки многозадачности в языках, библиотеках или фрэйворках с проблемами прадигмы. У ООП нет проблем с многозадачностью, так как она никак не противречит коцепции.
MSS>ООшное решение для такого — обернуть каждый элемент данных в объект, создать контейнер объектов, и потом итерировать контейнер. MSS>Кроме итераций, ОО практически ничего не предлагает.
Скажу больше в ООП нет и итерации.
ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений. Алгоритмические проблемы не относятся к области охватываемой ООП. Объекты могут быть целью алгоритма или данными обрабатываемыми алгоритмом, но это не одно и тоже.
Более того, ООП позволяет работать с данными как с абстракциями. Например, разумные люди вводят абстракцию словаря, инкапсулируют ее в объект и получают возможность быстро получать значение сопоставленное с ключем даже не задумываясь о том используется для этого итерация/рекурсия или вычисление хэш-фукнции.
Так что ты просто не понимашь что такое ООП и его цели. Ну, а далее как, сказал IT, как следствие получается забивание гвоздей микроскопом и возмущение от того, что это неудобно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
IT>Честно говоря, надоели уже до чёртиков все эти разговоры про недостатки ООП.
Есть такое страшное слово — "парадигма". Достаточно нечто обозвать парадигмой, как вокруг этого нечто образуется своя толпа фанатов и фанатиков, с пеной у рта начинающих доказывать состоятельность и всеобъемность этой парадигмы другой толпе фанатов и фанатиков.
Сейчас, боюсь, силами С# начнут проталкивать функциональную парадигму.
Силами какой-нибудь Singularity — парадигму, что "все есть объект или процесс".
"И если увидишь где человека, слово 'парадигма', рекущего, перекрестись на все стороны света и плюнь через левое плечо два раза, а через правое — три, поелику есть то сам чорт и бес, вразумлению человеческому невнемлющий."
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Ну вот примерно так.
Нет. Это все к OOП мало отношения имеет. Уже описали.
У ООП есть один глобальный недостаток. Он дает видимость того, что с помощью ООП мы легко можем смоделировать реальный мир. Только это неправда. Человек не природа и у него ошибок слишком много чтобы это все легко повторить. Поэтому для моделирования нужно соблюдать еще правила дизайна. И за пределы возможностей компьютеров и программных языков выйти нельзя.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Maxim S. Shatskih, Вы писали:
VD>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений. VD>Более того, ООП позволяет работать с данными как с абстракциями.
Я бы назвал способ смотреть на данные первоочередным для объектного подхода: данные наделются способностью делать что-то для нас, в отличие от действий над пассивными данными характерными для процедурного подхода.
Во-первых, на ООП сильно повлияла теория фреймов. Фреймы нужны для формализации знаний. То есть, если несколько огрубить, то инструменты ООП — это инструменты формализации знаний в приемлемом для компьютера виде.
Как всякий инструмент, они не являются решением сами по себе. Но как всякий мощный инструмент — позволяет сделать очень многое. Близкая аналогия ООП — литература. Упование на паттерны (типичные сюжетные ходы) не сильно поможет написать, скажем, хорошую книгу. Наоборот, оно может привести к тому, что произведение назовут "штамповкой".
Отсюда и своеобразная притягательность ООП и регулярные упрёки. Но ведь не может же, например, грамматика (sic! — на горизонте парадигма) русского языка ответить на вопрос: "что делать с главным героем?" Грамматика только подскажет, как написать это грамматически корректно.
Во-вторых. Как ни странно, но большую часть проблем ООП можно свести именно к субъектам применения. Люди-то в и "обычной" жизни всё время путают, где объект и где субъект, а вы хотите, чтобы они ещё и правильные объектные программы писали! Вот отсюда растут ноги у путаниц в субъектно-объектных отношениях, у вечного вопроса "должен ли контейнер быть частью объекта?" и тому подобной чепухи.
Ещё и Алан Кей подлил масла в огонь, сказав, что всё есть объекты и сообщения между ними. Таким образом он ткнул пальцем в дуальность "действие <-> сущность", свойственную объектно-ориентированным инструментам. Это, с одной стороны, подтверждает мощность ООП, а с другой даёт плодородную почву для дичайшего хаоса.
Это была преамбула. Теперь по делу.
MSS>В этой теме я хочу коснуться именно принципиальных, концептуальных проблем ОО парадигмы, а не применимости ее в конкретных проектах. MSS>Итак.
Собственно, ты совершаешь ошибку. "Парадигма ООП" не может сама по себе ответить на конкретные вопросы. Сколько ни вникай в сущность понятия "объект", всё равно не поймешь, что же такое "движение": это объект TMovement или метод Move. Напоминаю: ООП — скорее способ выражения, чем готовые рецепты.
MSS>1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.
И правильно делают. Паттерны ООП выражают очень общие идеи. Многонитевость, параллельность вычислений — это уже конкретная область применения. Разрешение вопроса "кто владеет локом" — из той же серии.
MSS>2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.
То же самое, что и для 1). Здесь нужно в конкретном случае ставить конкретные вопросы о том, как лучше выразить решение задачи в терминах ООП при наличии конкретных ограничений. То есть, неверно утверждать: "ОО-шное решение, это только...". Нельзя обвинять русский язык в том, что большая часть авторов, которые на нём пишут — кретины и из-под пера у них выходит кретинизм.
MSS>Общее у этих двух недостатков: ОО предполагает кучу мелких сущностей, каждая из которых состоит из кода и из элемента данных. Это не всегда удобно. Иногда бывает удобно иметь сложные структуры именно одних лишь данных, а код к ним прилеплять уже по мере необходимости с различных боков. Т.е. классический процедурный, не ОО подход.
Вот! Вот оно!!! Но ОО ничего такого не предполагает само по себе!!!! "Мелкость" или "крупность" сущности — относительные понятия. То, что мелко в рамках решения одной задачи, становится очень крупным в рамках другой.
ООП было порождено исследованиями в области формализации знаний. Потому-то оно и стимулирует к большой детализации и структурированию. Знания ведь тоже хочется детализировать и структурировать, правда?
Но увы, процесс познания бесконечен, а abstraction penalty никто не отменял, так что, всегда нужно идти на компромисс. А компромисс в каждом конкретном случае — свой собственный.
MSS>Ну вот примерно так.
Ага. Так, или примерно так.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Скажу больше в ООП нет и итерации. VD>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений.
Что-что?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, absolute, Вы писали:
A>Так вот. Параллельное программирование с использованием потоков и семафоров можно сравнить с ручным использованием стеков и адресов возврата для повседневного вызова процедур. Использование же активных объектов позволяет работать с параллелизмом на гораздо более высоком семантическом уровне.
Ясен пень. Не будь ключевых слов AWAIT, ACTIVE, EXCLUSIVE — дык и не догадались бы ни за что про conditional vars, threads и critical sections. Слава Вирту! Кхм. Вопрос по ходу: знаешь, что такое некорректный приём? Это сказать что-то правильное (первый прцитированный абзац), а потом — что-то несуразное, но связать эти два высказывания словами "точно также" или как-то так.
A>Прорыв сравним здесь с написанием вызова подпрограммы одной строчкой. Ничего хитрого там действительно нет. Например, оператор AWAIT языка Active Oberon, будучи разложен на элементарные действия, по сложности примерно равен вызову подпрограммы. Но в тексте программы он будет представлен одной строчкой, ясно показывающей наши намерения.
Тема семантического уровня не раскрыта. В чём глобальный дифференс между вставкой ключевого слова AWAIT и вот такой конструкцией:
void func()
{
my_cond_var.wait();
?
Я совершил контрпрорыв?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
Д>о боже, ты ли это говоришь?
Я знал что ты здесь появишься и обязательно отметишься
Д>На самом деле ООП не решает некоторые задачи, и его возможности неплохо бы расширить.
ООП хорошо решает то, что решает хорошо. Речь как раз о том стоит ли пытаться впихнуть в ООП всё, что способен сочинить около объектного воспалённый мозг разработчика.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Тема семантического уровня не раскрыта. В чём глобальный дифференс между вставкой ключевого слова AWAIT и вот такой конструкцией:
ГВ>
ГВ>void func()
ГВ>{
ГВ> my_cond_var.wait();
ГВ>
ГВ>?
ГВ>Я совершил контрпрорыв?
У AWAIT имеется аргумент — булевское выражение произвольной сложности, которое записывается здесь же.
Стало быть, разница как между обменом данными с помощью глобальных переменных против их передачи через аргументы.
absolute wrote: > У AWAIT имеется аргумент — булевское выражение произвольной сложности, > которое записывается здесь же.
А что это меняет? В том же pthread можно по предикатам ждать, в Win32
прямого аналога нет, но он делается без особых проблем (мы ведь помним,
что все многопоточные паттерны сводятся к семафору и мьютексу).
> Стало быть, разница как между обменом данными с помощью глобальных > переменных против их передачи через аргументы.
Да ни чуть. Разница в наборе встроенных примитивов синхронизации. То
есть разницы, по сути, нет.
Здравствуйте, absolute, Вы писали:
A>У AWAIT имеется аргумент — булевское выражение произвольной сложности, которое записывается здесь же.
Ну да. Лямбда. То же самое можно сделать хоть на C.
A>Стало быть, разница как между обменом данными с помощью глобальных переменных против их передачи через аргументы.
Ничего общего. Или в это выражение можно запихнуть локальные переменные? Если да, то какой в этом смысл?
Тема семантического уровня пока не раскрыта.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
> Ничего общего. Или в это выражение можно запихнуть локальные переменные?
Да, можно использовать локальные переменные и поля данных объекта.
> Если да, то какой в этом смысл?
Смысл — максимальная инкапсуляция синхронизации.
В локальных переменных. Внутри объектов. Внутри модулей.
В отличие от более повсеместных подходов, когда блокировка на объект находится снаружи объекта, и неизвестно кто имеет доступ к ней (обычно — кто угодно).
Здравствуйте, absolute, Вы писали:
>> Ничего общего. Или в это выражение можно запихнуть локальные переменные?
A>Да, можно использовать локальные переменные и поля данных объекта.
Ага, спасибо... Тут я в самом деле ошибся — действительно, можно вставить локальные переменные. Правда, то же самое доступно и в других языках: локальную переменную как параметр в wait() тоже можно положить.
>> Если да, то какой в этом смысл? A>Смысл — максимальная инкапсуляция синхронизации. A>В локальных переменных. Внутри объектов. Внутри модулей.
Поясни, плз., что такое "инкапсуляция синхронизации". Это инкапсуляция примитивов или синхронизируемых сущностей?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
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/системы сервисов на уровне языка. Кому-нибудь еще это нужно, интересно?
Здравствуйте, Дарней, Вы писали: Д>Если такая задача стоит перед разработчиком — возможно, стоит.
А может, просто ввести какую-нибудь ортогональную концепцию?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений.
ГВ>Что-что?
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>1). ООшные дизайн паттерны плохо учитывают многонитевость и параллельное программирование.
Параллельное программирование — это отдельная проблема, ортогональная к "ОО vs. не-ОО".
MSS>2). В ОО очень плохо решен вопрос операций сразу на большим количеством похожих элементов данных.
Почему? Есть, например паттерн flyweight (если мне память не изменяет).
Что же до теоретических проблем, то они, конечно, есть. Шутки шутками, но теоретики до сих пор ломают копья на тему преимуществ одиночного и множественного наследований
Вообще, в фундаменте ОО лежит много весьма спорных аксиом. Я, например, готов поспорить с тем, что:
Всё есть объект
Объект должен обладать идентичностью (OID)
Так что до многонитёвости нам ещё брести и брести...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>>ООП — это способность глядеть на мир через призму объектов и передачи между неми сообщений.
ГВ>>Что-что?
ANS>Пар-р-радигма.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
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 "более абстрактны", чем семафоры. В рамках идей Питера Мюллера и Ко — да, для остальных — бабушка надвое сказала.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Так и с Обероном. Понятна цель разработчиков: сделать active object-based систему.
Это было не совсем верно. Конечно, active object-based — это одна из целей. Более общая цель — поискать пути развития. Нашли они его? Неясно.
ГВ>А коль скоро не определено, какой должна быть будущая супер-ОС, то есть, не определены конечные цели,
...которые будут соответствовать целям статистического большинства, иначе такая ОС просто не получит поддержки в массах. Мне очень сильно сдаётся, что под обозначением "ОС" пресловутые массы гораздо легче примут инструмент для управления компьютерами, а не воплощение очередного мегаправильного "взгляда на мир".
ГВ>то бессмысленно говорить о том, что active/await/exclusive "более абстрактны", чем семафоры. В рамках идей Питера Мюллера и Ко — да, для остальных — бабушка надвое сказала.
Поскольку мегаправильные идеи у каждого свои. Договариваемся мы обычно о компромиссах. Для ОС мне представляется таким компромиссом вовсе не повсеместная "объектность", а управление тем, что легко выражается процессором и памятью: то есть, как ни банально это прозвучит — та же память и процессы. Прочие суперидеи на данный момент с той или иной сложностью реализуются с помощью этих двух простеньких штучек.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Дарней, Вы писали:
Д>3) Объект не может менять свой тип.
Это верно для языков со статической типизацией (С++/Java).
В динамически-типизированных язаках (Smalltalk, Python) мы можем говорить о типе объекта только когда начнем этот объект использовать.
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
Перекуём баги на фичи!
