> Аналогии понятны, но в чем состоит интроспективность операционной системы, из вашего поста мне не было ясным.
операционные системы (кроме некоторых совсем уж ужатых embedded) позволяют пользователю (и его программам) задавать вопросы о состоянии системы, и менять параметры системы исходя из этого. скажем, пользователь может спросить, сколько свободной памяти осталось. или узнать, реализована ли в системе конкретная процедура, пороверив наличие соответствующего исполняемого файла. или спросить, какой тип у определённого файла данных. или проверить, бежит ли некая программа, и если бежит — убить.
> Опять же, видимо, в силу моего ограниченного опыта, не совсем понятно, что нормальная программа (а не дебаггер-трассировщик какой-нибудь) может сделать с "полноценным типированным объектом" такого нетривиального. Есть, конечно, отдельные случаи, когда имеет смысл выяснить, поддерживает ли объект тот или иной интерфейс (C++ RTTI, COM IIDs etc.), но кажется, по большей части такая практика свидетельствует о неполноценности дизайна, который приводит к череде if-ов, разбросанных там-сям в программе и крайне тяжело поддерживаемых в больших проектах. Кажется, за такую практику Страуструп где-то и критиковал SmallTalk.
мой предыдущий пост был достаточно сумбурен, и этот обещает быть не лучше. :)
основная идея в следующем: говоря о data-oriented programming, я не пытаюсь что-либо рекламировать. я очевидным образом не сумел сформулировать самый важный пункт: DOP не есть что-то, что получается посредством сознательного применения каких-то там специальных методик. DOP — это то, что остаётся после отказа от явных глупостей. разумеется, придерживающиеся философии DOP системы делают практичными некоторые методики, о которых в C++ и иже с ним даже думать не получается, но это уже следствие и в данном контексте менее интересно.
например, я не в коем случае не утверждаю чего-либо о [не]желательности полноценного дизайна. ясное дело, наличие дизайна объективно лучше, чем отсутствие такового. означает ли это, что система не должна в принципе допускать возможности работать иным образом?
давайте я для простоты перечислю (некоторые) фундаментальные аспекты философии C++ и иже с ним, которые я считаю глупостями:
1. тип объектов как нечто, присутствующее лишь во время компиляции. это чисто философски неприятно:
0 — это число 0, а ни в коем случае не указатель на объект, сидящий по адресу 0, и не значок с кодом 0.
"abc" — это строка "abc", а не число 1633837824 и не указатель на объект по соответствующему адресу.
если мне захочется писать на ассемблере, я найду себе ассемблер. если же я рассматриваю объекты не как куски памяти, а как объекты, то я не желаю и думать про куски памяти, и я хочу чтобы мой runtime environment помогал мне в этом.
2. тип объектов как нечто, присутствующее лишь при компиляции. это чисто философски неприятно ещё и по той простой причине, что выкидывать информацию вообще в принципе некрасиво. кто он, чёрт возьми, такой, этот компилятор, и почему он считает себя умнее меня?
вообще, C++ и иже с ним навязывают разработчику определённые глобальные оптимизации, ценность которых, мягко говоря, неочевидна, и которые предполагают что разработчик либо пишет тупые batch-утилиты, либо знает Абсолютно Всё На Свете заранее.
3. (как следствие из предыдущих пунктов) unsafe runtime environment. в наше время это просто смешно, это даже оптимизацией не назовёшь, это мазохизм чистой воды (не говоря уже о проблемах с security).
> В целом ясно почти наверняка, что Вы знаете, о чем говорите :-), а мой опыт в OOP уж точно выкристализован действительно не в самом нормальном контексте С++ и не обогащен в достаточной мере иными ОО-языками. Просто пока содержательная часть ваших утверждений для меня не очень ясна - это следовало бы отметить, а не кивать головой в знак понимания того, чего я пока не понимаю.
no subject
операционные системы (кроме некоторых совсем уж ужатых embedded) позволяют пользователю (и его программам) задавать вопросы о состоянии системы, и менять параметры системы исходя из этого. скажем, пользователь может спросить, сколько свободной памяти осталось. или узнать, реализована ли в системе конкретная процедура, пороверив наличие соответствующего исполняемого файла. или спросить, какой тип у определённого файла данных. или проверить, бежит ли некая программа, и если бежит — убить.
> Опять же, видимо, в силу моего ограниченного опыта, не совсем понятно, что нормальная программа (а не дебаггер-трассировщик какой-нибудь) может сделать с "полноценным типированным объектом" такого нетривиального. Есть, конечно, отдельные случаи, когда имеет смысл выяснить, поддерживает ли объект тот или иной интерфейс (C++ RTTI, COM IIDs etc.), но кажется, по большей части такая практика свидетельствует о неполноценности дизайна, который приводит к череде if-ов, разбросанных там-сям в программе и крайне тяжело поддерживаемых в больших проектах. Кажется, за такую практику Страуструп где-то и критиковал SmallTalk.
мой предыдущий пост был достаточно сумбурен, и этот обещает быть не лучше. :)
основная идея в следующем: говоря о data-oriented programming, я не пытаюсь что-либо рекламировать. я очевидным образом не сумел сформулировать самый важный пункт: DOP не есть что-то, что получается посредством сознательного применения каких-то там специальных методик. DOP — это то, что остаётся после отказа от явных глупостей. разумеется, придерживающиеся философии DOP системы делают практичными некоторые методики, о которых в C++ и иже с ним даже думать не получается, но это уже следствие и в данном контексте менее интересно.
например, я не в коем случае не утверждаю чего-либо о [не]желательности полноценного дизайна. ясное дело, наличие дизайна объективно лучше, чем отсутствие такового. означает ли это, что система не должна в принципе допускать возможности работать иным образом?
давайте я для простоты перечислю (некоторые) фундаментальные аспекты философии C++ и иже с ним, которые я считаю глупостями:
1. тип объектов как нечто, присутствующее лишь во время компиляции. это чисто философски неприятно:
0 — это число 0, а ни в коем случае не указатель на объект, сидящий по адресу 0, и не значок с кодом 0.
"abc" — это строка "abc", а не число 1633837824 и не указатель на объект по соответствующему адресу.
если мне захочется писать на ассемблере, я найду себе ассемблер. если же я рассматриваю объекты не как куски памяти, а как объекты, то я не желаю и думать про куски памяти, и я хочу чтобы мой runtime environment помогал мне в этом.
2. тип объектов как нечто, присутствующее лишь при компиляции. это чисто философски неприятно ещё и по той простой причине, что выкидывать информацию вообще в принципе некрасиво. кто он, чёрт возьми, такой, этот компилятор, и почему он считает себя умнее меня?
вообще, C++ и иже с ним навязывают разработчику определённые глобальные оптимизации, ценность которых, мягко говоря, неочевидна, и которые предполагают что разработчик либо пишет тупые batch-утилиты, либо знает Абсолютно Всё На Свете заранее.
3. (как следствие из предыдущих пунктов) unsafe runtime environment. в наше время это просто смешно, это даже оптимизацией не назовёшь, это мазохизм чистой воды (не говоря уже о проблемах с security).
> В целом ясно почти наверняка, что Вы знаете, о чем говорите :-), а мой опыт в OOP уж точно выкристализован действительно не в самом нормальном контексте С++ и не обогащен в достаточной мере иными ОО-языками. Просто пока содержательная часть ваших утверждений для меня не очень ясна - это следовало бы отметить, а не кивать головой в знак понимания того, чего я пока не понимаю.
это правильно. :)