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

ГВ>>Ну, если бы не он был автором и "ведущим кем-то там" по разработке языка, то я упомянул бы другого. Я аргументировал только его подходом, а не личными качествами (маразмом там, старостью, генальностью и пр.) Аналогично и про MS. Возможно, фраза была несколько неудачно построена... :(

VD>Правильно интеллектуальность не качество. ;)

Смешно. :)

ГВ>>Опять к личностям. OK. Тогда назови хоть одну из тех догм, которым я, по твоему мнению, подчиняюсь.

VD>"С++ законченый язык. Его средствами можно реализовать хоть черта лысого, а занчит менять в нем ничего не нужно."

А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.

ГВ>>От блин! :) Vlad, давай больше Страуса вообще не будем упоминать. И Гейтса лично тоже. :)

VD>Ну, тогда и на MS нечего клепать.

Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями. И следы этого подхода есть, в том числе, и в языке программирования, который (возможно, — ошибочно) противопоставлен другому языку, с гораздо более развитой моделью. Следы эти таковы, что C# "упростился" для ускорения изучения, но из него выброшено много, ИМХО, важного. Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.

[...]

VD>Я хочу сказать, что если проблемы есть, то их нужно решать, а не городить огород на ровном месте и не объяснять, что мол, а мне и так нравится.

Один из вопросов, который предлагается задать себе авторам предложений по расширению C++:

"Можно ли это сделать имеющимися средствами языка?"

Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

Например, я показал тебе "делегатами", что такую, в частности, штуку можно сделать на базе обычного C++. ==> Незачем вводить такое языковое расширение.

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

ZEN>Для COM-порта есть JavaAPI.
ZEN>Свой класслоадер наследуешь от абстрактного класса java.lang.ClassLoader, переопрееляешь пару-тройку методов и всё.
Ты не понял о чем речь. Посмотри на классы из System.Reflection.Emit. Подобного в джаве нет.

... Янус версия 1.0 alpha 2

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

ГВ>А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.
Это уже не смешно. За сколько там лет существования С++ не сделали ни одного нормального компилятора. Так может сам язык в этом виноват?


ГВ>Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями. И следы этого подхода есть, в том числе, и в языке программирования, который (возможно, — ошибочно) противопоставлен другому языку, с гораздо более развитой моделью.
Елки палки, устали уже тебе объяснять что модель у С++ довольно однобоко развита. Вся его развитость начинается и заканчивается шаблонами и множественным наследованием реализаций. Когда же тебе приводят кучу вещей когда шарп намного гибче плюсов, ты либо говоришь что это не имеет отношения к языку либо не нужно. Знаешь, уже не интересно. Можно сколь угодно доказывать идеологическую правильность плюсов но практика говорит что на шарпе проекты пишутся быстрее и сменьшим количеством ошибок. И код получается значительно понятнее и легче модифицируемым.

ГВ> Следы эти таковы, что C# "упростился" для ускорения изучения, но из него выброшено много, ИМХО, важного.
Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

ГВ>Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.
С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.

ГВ>"Можно ли это сделать имеющимися средствами языка?"

ГВ>Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

... Янус версия 1.0 alpha 2

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

AVK>Здравствуйте <Аноним>, Вы писали:

А>>Подобные заявления означают, что ты вообще ничего не понимаешь в том, как происходила стандартизация C++ и больше говорят о тебе, чем о Страуструпе. Ты бы почитал что-нибудь.

AVK>Ты бы прежде чем народ обкакивать представился бы что ли, а то некрасиво получается однако.

Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

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

VD>Здравствуйте Аноним, Вы писали:

А>>Подобные заявления означают, что ты вообще ничего не понимаешь в том, как происходила стандартизация C++ и больше говорят о тебе, чем о Страуструпе. Ты бы почитал что-нибудь.

VD>Я я что-нибудь почитал. Но стандарт от этого прямее не стал. Да и у MS многое стандартизовано. Тот же .NET. Да и для меня нет разницы между стандартами дефакто и бумажными. Первые мне даже больше нарвятся. Они к жизни ближе. Я когда писал на С, всегда предпочитал вариант Ричи, чем ансишный.

Многое стандартизовано? Что например? А, ну конечно, я совершенно забыл про ECMA стандарт на C#. Интересно, смогут ли они так же быстро протащить его через ISO? Что касается варианта Ричи vs ANSI, то эту чушь я даже комментировать не буду.

Здравствуйте <Аноним>, Вы писали:

А>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься
Вот лично вас я не знаю и уровень ваш не неизвестен. Кто такой Влад я знаю, и сколько он на С++ питсал я тоже знаю. Так что пока что доверия больше ему.

А> и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?
Не стоит возводить себе идолов, это грех. Вон Эйнштейн на что гениальный физик, но в квантовую механику так и не поверил до своей смерти, хотя сам же заложил ее основы. Любым людям свойственно ошибаться, даже гениальным.

... Янус версия 1.0 alpha 2

Здравствуйте <Аноним>, Вы писали:

А>Многое стандартизовано? Что например? А, ну конечно, я совершенно забыл про ECMA стандарт на C#.
Есть еще стандарт на CLI того же ECMA.

... Янус версия 1.0 alpha 2

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

VD>>"С++ законченый язык. Его средствами можно реализовать хоть черта лысого, а занчит менять в нем ничего не нужно."

ГВ>А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.

Дык еще немножко и улучшать уже будет нечего. У них же "немгожко" — это лет пять.

ГВ>Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями.

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

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

Да нет там никакой "модели". Там груда фичь. Так и в Шарпе их не мало. Модель там, кстати, куда стройнее. Вот добавят шаблоны и вообще про С++ можно будет забыть (ну, в большинстве случаев).

ГВ>Следы эти таковы, что C# "упростился" для ускорения изучения

И дла укорения работы. Это, по-моему, куда важнее.

ГВ>, но из него выброшено много, ИМХО, важного. Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.

Вот не любишь ты по русски выражаться. "комбинирования абстракций" — это множественное наследование или шаблоны?

ГВ>Один из вопросов, который предлагается задать себе авторам предложений по расширению C++:

ГВ>"Можно ли это сделать имеющимися средствами языка?"

А я бы добавил: И насколько эти срдства выразительны, и дают ли они приемлемый результат?

ГВ>Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

Чтобы жить проще. В С++ избыточность была исконно. Большинство прогаммистов используют его процентов на 10. Может по этому поводу С++ кастрировать?

ГВ>Например, я показал тебе "делегатами", что такую, в частности, штуку можно сделать на базе обычного C++. ==> Незачем вводить такое языковое расширение.

Это не обычный С++. И та гора кода которую ты наворотил как раз и показывает, что столь необходимую и часто встречающуюся концепцию нужно было интегрировать в язык. Кроме теории есть еще жизнь и она подсказывает очень простые истенны: не удобно — значит не используем, удобно — используем. А про концепции и полноту — это демогогия. Ты сам прекрасно понимаешь, что от изменения поведения указателей на методы никакая концепция не пострадает. Это всего лишь не желание людей признавать (а может осозновать) свои ошибки.

Еще раз задаю вопрос: Что плохого было бы если в язык добавили хотябы указатели на методы в стиле делегатов?

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

А>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

Не тебе судить о том, что я знаю, а что нет. Сам то даже представиться боишься.

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

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

A>Расскажи-ка мне про преимущества Си Кернигана и Ритчи на примере следующего фрагмента:

A>

A>double sqrt(x)
A>double x;
A>{
A>/* какой-то код */
A>}

A>main()
A>{
A>    double z = sqrt(2);
A>}
A>

Не нужно доводить до маразма. Ричевский С времен второго (а может и третьего, уже не помню) издания Кернигана совершенно удобоваримый стандарт. Ансишный тех времен был вообще не удобен. По крайней мере реализованный в MC C 5.

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

А>>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

VD>Не тебе судить о том, что я знаю, а что нет. Сам то даже представиться боишься.

<moderator>
Алё, гараж, calm down, please.
</moderator>

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

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

ГВ>>А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.
AVK>Это уже не смешно. За сколько там лет существования С++ не сделали ни одного нормального компилятора. Так может сам язык в этом виноват?

Думаю, что здесь, действительно, одна из причин — относительная сложность C++ как языка и долгая возня с принятием его стандартного описания, а вторая причина — знаменитое "и так сойдёт, всё равно никто этим не пользуется". ИМХО, не в последнюю очередь по этим прчинам притормозилось развитие многих инструментальных средств, в том числе — и библиотек.

ГВ>>Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями. И следы этого подхода есть, в том числе, и в языке программирования, который (возможно, — ошибочно) противопоставлен другому языку, с гораздо более развитой моделью.
AVK>Елки палки, устали уже тебе объяснять что модель у С++ довольно однобоко развита. Вся его развитость начинается и заканчивается шаблонами и множественным наследованием реализаций. Когда же тебе приводят кучу вещей когда шарп намного гибче плюсов, ты либо говоришь что это не имеет отношения к языку либо не нужно.

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

AVK>Знаешь, уже не интересно. Можно сколь угодно доказывать идеологическую правильность плюсов но практика говорит что на шарпе проекты пишутся быстрее и сменьшим количеством ошибок. И код получается значительно понятнее и легче модифицируемым.

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

ГВ>> Следы эти таковы, что C# "упростился" для ускорения изучения, но из него выброшено много, ИМХО, важного.
AVK>Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.

ГВ>>Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.
AVK>С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.

Ну что тут сказать. Хорошо, если C#/.NET позволяют это делать просто, быстро и надёжно. Сама по себе среда, как я понимаю, спроектирована для поддержки таких решений.

ГВ>>"Можно ли это сделать имеющимися средствами языка?"

ГВ>>Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

AVK>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

Ну да, правильно. ;) И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется. А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.

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

ГВ>Думаю, что здесь, действительно, одна из причин — относительная сложность C++ как языка и долгая возня с принятием его стандартного описания, а вторая причина — знаменитое "и так сойдёт, всё равно никто этим не пользуется". ИМХО, не в последнюю очередь по этим прчинам притормозилось развитие многих инструментальных средств, в том числе — и библиотек.
А ты как думал. И эти моменты язык тоже учитывать обязан.

ГВ>Подожди, Andrew. Я говорил именно о языке.

Знаешь, по мере развития языки становятся все менее отделимы от окружения. Разговаривать о шарпе или джаве отдельно от их рантайма бессмысленно.
GC это свойство языка или рантайма? Boxing/unboxing? У дотнета вобще есть специфика, ввиду его ориентированности на много языков собственно язык играет очень маленькую роль. И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.

ГВ> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.
Ну нельзя этого делать. Шарп или джава бесполезны без своего окружения.

ГВ>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ, но... я пока в этом сомневаюсь.
Есть еще джава.

ГВ>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...
А мне не кажется, я пробовал и поэтому знаю.

ГВ>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.
Но назвать это "много" и "сильно порезано" мягко говоря преувеличение.

AVK>>С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.
ГВ>Ну что тут сказать. Хорошо, если C#/.NET позволяют это делать просто, быстро и надёжно. Сама по себе среда, как я понимаю, спроектирована для поддержки таких решений.
В том числе и для этого.


AVK>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>Ну да, правильно. И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.
СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

ГВ> А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.
CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.

... Янус версия 1.0 alpha 2

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

VD>Здравствуйте Аноним, Вы писали:

А>>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

VD>Не тебе судить о том, что я знаю, а что нет. Сам то даже представиться боишься.

Почему не мне? Из того, что ты написал, кое-какие выводы сделать можно. Я уж как-нибудь сам решу о чем мне судить. И, кстати, не надо себе льстить. Ну кого мне здесь бояться? Просто я не настолько большой фанат RSDN, чтобы регистрироваться.

VD>Я говорил о том, что ни комитет, ни Страуструп не хотят исправлять свои явные недоработки и ошибки. А так же о том, что у товарища начинается старческие болезни в юном возрасте. А сделать такие выводы позволяет его публичные выступления. Возьми хотя бы его бред о реализации GC средствами С++. И это в языке который сидит по уши в 80-ых, где даже нет нормального способа получить информацию о типах в рантайме.


Если какой язык и сидит по уши в 80-х, то это C#. Его объектная модель очень похожа на объектные модели самых первых объектно-ориентированных языков.

Здравствуйте <Аноним>, Вы писали:

А>Почему не мне? Из того, что ты написал, кое-какие выводы сделать можно.
Пока никаких, отни пустые слова

А> Я уж как-нибудь сам решу о чем мне судить.
Только оставляй тогда свои суждения при себе

А>И, кстати, не надо себе льстить. Ну кого мне здесь бояться? Просто я не настолько большой фанат RSDN, чтобы регистрироваться.
Хреновая отмазка. Для того чтобы зарегистрироваться на RSDN совсем не обязательно быть ее фанатом. В конце концов мог бы просто в письме придставится.

А>
А>Если какой язык и сидит по уши в 80-х, то это C#. Его объектная модель очень похожа на объектные модели самых первых объектно-ориентированных языков.
Подобные суждения свидетельствуют о том что ты просто не представляешь себе что такое шарп и дотнет.
Мне вобще нравится позиция что мол я знаю что такое дотнет только по слухам но это дерьмо. И разбиратся с ним я не буду потому что дерьмо.

... Янус версия 1.0 alpha 2

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

ГВ> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.

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

ГВ>А понеслось всё разом. Глупо было бы спорить, утверждая, что на данный момент рантайм C++ так же развит в смысле поддержки RTTI, как и для .NET-овских языков. Но, с другой стороны, рантайм для C++ — это целевая операционная система (кстати, практически все) + процессор (аналогично) + стандартные библиотеки ОС. Ммм...

Слова... слова... рантайм С++ — это CRT + STL. Последнюю и рантаймом назвать нельзя.

ГВ>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ


Ну, Ява тоже почти везде есть. И почему ты тогда о ней не говоришь? Может быть просто по тому, что потребителю в основном нужен софт для Виндовс? А тогда что говорить о переносимости? В конце концов переносимее С языка нет. Что же теперь и С++ выбрасить?

ГВ>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...

Заметь! При этом сам язык куда компактнее плюсов, очень быстро компилируется и прекрасно парстся (что критичиски важно для визуальных сред).

AVK>>Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

Ну, еще const зря покоцали.

ГВ>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.

Между прочим шаблоны вещь относительно молодая. На плюсах писали и раньше когда компиляторы шаблонов еще не поддерживали. Вон глянь на MFC...

AVK>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>Ну да, правильно. И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.

А-га. А .NET и Ява от сырости завелись.

AVK>А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.

А чья? Почему в CORBA все еще сложнее и запутаннее, хотя она только сейчас до компонентности добирается?

Почитай Бокса. У него есть замечательный анализ COM-а. Там как раз рассматриваются особенности COM-а и объясняется почему это сделано, так, а не иначе. Думаю тебя несколько удивит, что практически все нвеено недоработанностью того самого С++. Главный недостаток стандарта С++ — это то, что рантай в нем практически не оговорен. Все сводится к идеомам 70-ых.

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

А> Просто я не настолько большой фанат RSDN, чтобы регистрироваться.

A! Ну-ну...

А>Если какой язык и сидит по уши в 80-х, то это C#. Его объектная модель очень похожа на объектные модели самых первых объектно-ориентированных языков.

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

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

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

ГВ>>Думаю, что здесь, действительно, одна из причин — относительная сложность C++ как языка и долгая возня с принятием его стандартного описания, а вторая причина — знаменитое "и так сойдёт, всё равно никто этим не пользуется". ИМХО, не в последнюю очередь по этим прчинам притормозилось развитие многих инструментальных средств, в том числе — и библиотек.
AVK>А ты как думал. И эти моменты язык тоже учитывать обязан.

Это — деградация в чистом виде. Сейчас объясню, почему я так думаю.

Я немного сгущу краски, но всё-таки...

Хочешь интересную аналогию? Яркий, пример языка непосредственно производного от своего "окружения" (рантайма) — Ассемблер какого-то процессора. ИМХО, языки выского уровня как раз и строились для отсечения программиста от рантайм-окружения с помощью математических или иных абстракций. Ну например: LISP — лямба-исчисление, PROLOG — хорновские дизъюнкты, SQL — реляционная алгебра. В то же время языки "системного" программирования базируются на императивной концепции — PL/1, C. И ещё инженерно-расчётные — Fortran, Basic. Не учитываю здесь исследовательские проекты и прочее.

Проектирование систем (а прикладная программа, особенно большая — тоже система. Да, их часто пишут бесситемно, но это к делу не относится) всё равно тяготеет к предсказуемости поведения системы, в противном случае она просто неустойчива. Как часть решения — языки со статической сильной типизацией. Потому-то, ИМХО, и считается неуёмный RTTI и манипуляции кодом "на лету" признаком "плохого стиля". Таким образом вносится нестабильность в систему, да и добавляется ручной работы. А зачем работать руками, когда часть согласования абстракций можно переложить на транслятор? Только абстракции нужно выбрать правильно.

Развитие языков системного программирования в объектно-ориентированные (C++, Ada и ещё, кажется CLU — но последний, ИМХО, полуисследовательский) произошло, ИМХО, на базе "всасывания" модели Simula-67 и Smalltalk, которые сами по себе появились из... по-моему, это называется исчисление на фреймах (фреймы/слоты — пра-образ нынешних классов/методов, по совместительству — подраздел исследований в области ИИ). Только отказались от единственного базового класса ради жёсткой типизации, что само по себе делается ради поддержки детерминированности поведения системы. При этом, обрати внимание — в распространённых языках всегда вводится абстракция от вычислительной среды. Увы, императивная, поскольку языки связаны фон-неймановской архитектурой, но — абстракция. Цель, ИМХО, обеспечить максимальную переносимость и эффективность.

Кстати, цели у всех одни и те же — поменьше поработать + побольше получить денег за выданный результат, в данном случае — снизить объём механической работы, путём поиска адекватных абстракций.

ИМХО, в таком способе развития есть немалая польза и для окружающих всё это хозяйство наук. Если ахитектура исполнительной среды и языки высокого уровня относительно свободны один от другого, то можно развивать и то и другое за счёт развития теории трансляции и использования новых методов, прежде всего — математических. То есть, "удалённость" взаимной абстракции растёт так или иначе, но при этом развивается и теоретическая база. Обратная дорога — суть немедленная деградация.

Программная система синтезирует математические и аппаратные абстракции. У шаблонов в этом смысле — много положительных качеств с рациональной точки зрения. С одной стороны — можно построить очень сложную абстракцию, с другой — эффективно превратить её в исполняемый код. И при этом остаться в рамках парадигмы сильной типизации и контроля компилятора, т.е. — минимизации механической работы. ИМХО, языки системного программирования как раз и двигаются (двигались?) в эту сторону и generic-программирование — очень неплохая ступенька в этом развитии.

То есть, языки системного программирования принципиально не сращиваются с runtime-системой но тяготеют к предоставлению способов реализации математических методов в рамках требований детерминированости поведения системы. Соответственно, модель квалифицированного специалиста — подкован в системном, математическом и философском смыслах. Последнее — поскольку философия вообще основа для формирования мышления, систематизирующего взаимодействия в окружающем мире.

Однако, когда возник бум программирования, то что произошло? Да то, что и должно было произойти — привлеклась масса попросту неквалифицированных специалистов, у которых превалирует примитивный ("императивный") способ изложения: "делай раз — будет так, делай два — будет эдак и точка". Они просто не натренированы выражать своё абстрактное мышление в математических терминах и строить абстракции — тоже. То есть, фактически, произошёл "откат" в... примерно 50-е — 60-е годы. Такие спецы составляют сейчас абсолютное большинство (по крайней мере, в своём окружении пересчитывал неоднократно :( ). Они же — основная масса потребителей средств программирования, которые, в ориентации на тупую аудиторию уже конструктивно ограничиваются. В них попросту нет того, что могло бы быть. Нет анализа семантики программы, нет построителей графов, нет никаких встроенных математических механизмов, что разумно было бы ожидать от сред поддержки програмирования. Ни хрена этого нет! Есть только набор "методов", бантики-картиночки и встроенная поддержка построения (ах, извините — "организации") всей этой толпы и раздачи ей малоквалифицированной работы. Но это-то ладно. Однако здесь есть ещё очень интересная завязка на то, что при таких делах интеллектуальные средства развиться просто не смогут! Их же тоже будут писать под управлением таких же менеджеров, бестолковых аналитиков и т.п. Они же просто массой всех задавят.

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

И что мы получаем на сегодняшний день (кстати, протяженност этого "дня" — уже где-то лет тридцать)? .NET — явно определяет ограничения на комбинаторику своих языков за счёт навязывания структуры reflection+RTTI. А если отказаться от reflection, то целесообразность .NET представляется очень сомнительной. Да, он подходит для части языков, но есть же и другие (ну да — тот самый, очень "сложный", в первую очередь ;) ), тем более — признанные разработчиками! То есть, по сути, частное окружение пытается навязать свою модель разработчикам, которым, по идее, не должно быть до него никакого дела. JVM в данном случае — чуть "иная" система, поскольку разработана для поддержки одного языка. Но .NET-то рвётся в гегемоны! Но сделан-то он для "упрощения"...

ГВ>>Подожди, Andrew. Я говорил именно о языке.

AVK>Знаешь, по мере развития языки становятся все менее отделимы от окружения. Разговаривать о шарпе или джаве отдельно от их рантайма бессмысленно.

Это следствие бушующего идиотизма, извини за прямоту и не прими в свой адрес. ИМХО, это признак деградации. Поскольку создаёт жёсткую зависимость разработчиков от платформы, на которой их программы будут работать. Язык высокого уровня отделяет разработчика от исполнительной системы.

AVK>GC это свойство языка или рантайма? Boxing/unboxing?

GC — свойство рантайма, Boxing/Unboxing — способ совмещения managed- и unmanaged-кода. То есть, попросту — ещё один способ организации взаимодействия. Принципиального новшества нет!

AVK>У дотнета вобще есть специфика, ввиду его ориентированности на много языков собственно язык играет очень маленькую роль.

Блеск! Ассемблер как парадигматическая основа всех основ!

AVK>И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.

Не я один хотел бы получить развитый компилятор/интерпретатор/анализатор/type-info-генератор для С++.

ГВ>> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.
AVK>Ну нельзя этого делать. Шарп или джава бесполезны без своего окружения.

Угу. А шарп — так вообще надстройка над CLR и не более того.

ГВ>>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ, но... я пока в этом сомневаюсь.
AVK>Есть еще джава.

Java, кстати, кажется и на .NET реализована. Что доказывает их подобие и косвенно — ориентацию .NET на перехват инициативы у Java. Но никак не на подержку неограниченного повышения эффективности одного человека.

ГВ>>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...
AVK>А мне не кажется, я пробовал и поэтому знаю.

Что я думаю о сложностях — см. выше. Всё очень сильно взаимосвязано.

ГВ>>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.
AVK>Но назвать это "много" и "сильно порезано" мягко говоря преувеличение.

ИМХО — нет, поскольку это откат назад в грубом виде. Кстати, на такой оборот речи меня навела дискуссия Vlad2-Аноним где-то в соседних ветках. (http://www.rsdn.ru/forum/?mid=93371

Автор:
Дата: 31.08.02

)

Нас грубо подталкивают к эффективности реализации примитивных систем, но усложняют деятельность более высокого порядка.

AVK>>>С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.
ГВ>>Ну что тут сказать. Хорошо, если C#/.NET позволяют это делать просто, быстро и надёжно. Сама по себе среда, как я понимаю, спроектирована для поддержки таких решений.
AVK>В том числе и для этого.

Но появятся ли новые?...

AVK>>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>>Ну да, правильно. ;) И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.
AVK>СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

Это была фигура речи, только для оттенения того, что на C++ это всё-таки было реализовано. Я тоже не считаю COM образцом красоты.

ГВ>> А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.
AVK>CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.

А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"? ;)

Извини, предыдущее случайно поспешно отправил

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

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

ГВ>> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.

VD>Так дело в том, что на сегадня современный язык должен быть тесно и безшовно интегрирован с рантаймом. Это требование времени не просто слова. Их необходимость подтверждает сама жизнь.

Аргумент к морали. Некорректно. Извини. Начинаешь из воздуха и заканчиваешь тем же. Жизнь подтверждает много разных необходимостей.

ГВ>>А понеслось всё разом. Глупо было бы спорить, утверждая, что на данный момент рантайм C++ так же развит в смысле поддержки RTTI, как и для .NET-овских языков. Но, с другой стороны, рантайм для C++ — это целевая операционная система (кстати, практически все) + процессор (аналогично) + стандартные библиотеки ОС. Ммм...

VD>Слова... слова... рантайм С++ — это CRT + STL. Последнюю и рантаймом назвать нельзя.

Естественно. C++ — компилируемый язык.

ГВ>>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ

VD>Ну, Ява тоже почти везде есть. И почему ты тогда о ней не говоришь?

Просто мы на нетовскую тему завелись.

VD>Может быть просто по тому, что потребителю в основном нужен софт для Виндовс? А тогда что говорить о переносимости? В конце концов переносимее С языка нет. Что же теперь и С++ выбрасить?

C++ удобнее C в том смысле, что позволяет получать программы с тем же быстродействием (и даже выше), но с более дешёвым сопровождением. Если он не по-дурацки применён, конечно.

ГВ>>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...

VD>Заметь! При этом сам язык куда компактнее плюсов, очень быстро компилируется и прекрасно парстся (что критичиски важно для визуальных сред).

Угу. Заметил. Знаешь, сам факт приведения такого аргумента — уже не очень хороший признак. Скорее всего — признак тупости визуальных сред. Ведь можно держать внутреннее представление программы в виде графа, к примеру и докомпилировать его по ходу редактирования, а не возиться с исходниками каждый раз.

AVK>>>Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

VD>Ну, еще const зря покоцали.

Мдаа.. Устойчивость софта делает нам ручкой. Медленно-медленно... Если это всё ориентировано на полупрофессионалов, то каша раньше или позже нам гарантирована!

ГВ>>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.

VD>Между прочим шаблоны вещь относительно молодая. На плюсах писали и раньше когда компиляторы шаблонов еще не поддерживали. Вон глянь на MFC...

...сплюнь и больше не заглядывай. C++ без шаблонов теряет огромную часть своих достоинств и комбинационых возможностей.

AVK>>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>>Ну да, правильно. И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.

VD>А-га. А .NET и Ява от сырости завелись.

Ну я понимаю. Ждать стандарта не хотелось, да и возиться с относительно сложными генераторами/парсерами — тоже. Тут ява подвернулась. А MS уж мимо пройти не могла.

AVK>>А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.

VD>А чья? Почему в CORBA все еще сложнее и запутаннее, хотя она только сейчас до компонентности добирается?

Уж не C++ ли ты хочешь в этом обвинить? А может, это всё-таки распри OMG какие-нибудь виноваты?



VD>Почитай Бокса. У него есть замечательный анализ COM-а. Там как раз рассматриваются особенности COM-а и объясняется почему это сделано, так, а не иначе. Думаю тебя несколько удивит, что практически все нвеено недоработанностью того самого С++. Главный недостаток стандарта С++ — это то, что рантай в нем практически не оговорен. Все сводится к идеомам 70-ых.

URL кинь, если не жалко. Постараюсь прокомментировать.

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

ГВ>Хочешь интересную аналогию? Яркий, пример языка непосредственно производного от своего "окружения" (рантайма) — Ассемблер какого-то процессора.
Неправильный пример, причем сильно неправильный. У Ассемблера своего рантайма 0. Весь его рантайм зависит от ОС, системы команд процессора, архитектуры компьютера и т.д. В нашем же случае мы имеет стандартизованный рантайм, одинаковый на любом компьютере.

ГВ>ИМХО, языки выского уровня как раз и строились для отсечения программиста от рантайм-окружения с помощью математических или иных абстракций.
А сейчас вместо отсечения языка стали отсекать его рантайм. Джава тому примером. Почему ты решил что это хуже? В плане переносимости наоборот намного лучше. Я уже тебе писал — для джавы совместимость бинарная, что по определению на порядок большая степень изоляции от окружения. Думаешь для чего еще выдумали JVM и CLR.

ГВ>PROLOG — хорновские дизъюнкты,
Какие? Ты где такой термин откопал? Его нгазывают логическрим языком, реляционным, языком исчисления предикатов, но вот такое вижу впервые.
В общем хороший пример — язык очень глубоко завязан на свой рантайм, там даже БД встроена в рантайм и поддерживается на уровне языка. Впорочем лисп, как ты понимаешь, тоже без своего окружения ничто, это вобще скрипт по сути.

ГВ> SQL — реляционная алгебра.
А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

ГВ>Проектирование систем (а прикладная программа, особенно большая — тоже система. Да, их часто пишут бесситемно, но это к делу не относится) всё равно тяготеет к предсказуемости поведения системы, в противном случае она просто неустойчива. Как часть решения — языки со статической сильной типизацией. Потому-то, ИМХО, и считается неуёмный RTTI и манипуляции кодом "на лету" признаком "плохого стиля".
Ты по моему чего то не понимаешь. Это для инженерных расчетов можно себе позволить перекомпилировать исходники на каждый чих. А теперь представь себе следующую ситуацию — у нас сетка скажем из 100 машинок. На них стоит некий софт, в соответствии с "хорошим" стилем собранный статической линковкой. Все это работает в режиме 24х7. 1 час простоя обходится скажем в $10K. И вот теперь представь — для 5 рабочих мест ты что то поменял. Менять придется везде.
В общем глупо объяснять преимущества компонентных технологий. Они существенно увеличивают надежность системы. У тебя видимо несколько специфическая предметная облась если ты этого не замечаешь.

ГВ> Таким образом вносится нестабильность в систему, да и добавляется ручной работы. А зачем работать руками, когда часть согласования абстракций можно переложить на транслятор? Только абстракции нужно выбрать правильно.
Следуя твоей логике нужно отказаться и от полиморфизма. Ибо рефлекшен по сути и есть полиморфизм, только более высокого уровня нежели тот который обеспечивается виртуальными методами.

ГВ>При этом, обрати внимание — в распространённых языках всегда вводится абстракция от вычислительной среды. Увы, императивная, поскольку языки связаны фон-неймановской архитектурой, но — абстракция. Цель, ИМХО, обеспечить максимальную переносимость и эффективность.
Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.

ГВ>Кстати, цели у всех одни и те же — поменьше поработать + побольше получить денег за выданный результат, в данном случае — снизить объём механической работы, путём поиска адекватных абстракций.
Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.

ГВ>ИМХО, в таком способе развития есть немалая польза и для окружающих всё это хозяйство наук. Если ахитектура исполнительной среды и языки высокого уровня относительно свободны один от другого, то можно развивать и то и другое за счёт развития теории трансляции и использования новых методов, прежде всего — математических. То есть, "удалённость" взаимной абстракции растёт так или иначе, но при этом развивается и теоретическая база. Обратная дорога — суть немедленная деградация.
Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.

А потом — ты хоть раз видел программу на С++ компилирующуюся и под уних и под Win32? Я видел. Там половина кода в #ifdef ХХХ. Поэтому реально портируют софт с использованием cygwin. А это как раз и есть тот самый рантайм. Поэтому про переносимость С++ не надо, хреновая она совсем.

ГВ>То есть, языки системного программирования принципиально
Очень расплывчатый термин. Нет таких языком программирования. Есть задачи. Вот для этих задач (я имею ввиду написание ОС-специфичных вещей) С++ и нужен. И не потому что он обеспечивает высокую степень абстракции а наоборот, слишком тонкий слой отделяет его от ОС.

ГВ>Однако, когда возник бум программирования, то что произошло? Да то, что и должно было произойти — привлеклась масса попросту неквалифицированных специалистов, у которых превалирует примитивный ("императивный") способ изложения: "делай раз — будет так, делай два — будет эдак и точка".
Т.е. ты меня и Влада считаешь неквалифицированными программистами?

ГВ> Они просто не натренированы выражать своё абстрактное мышление в математических терминах и строить абстракции — тоже.
Однако почему то на джаве и шарпе у меня получается писать быстрее и качественнее.
Следуя твоей логике — если это так то это означает что я не умею строить абстракций?

ГВ>То есть, фактически, произошёл "откат" в... примерно 50-е — 60-е годы. Такие спецы составляют сейчас абсолютное большинство (по крайней мере, в своём окружении пересчитывал неоднократно ). Они же — основная масса потребителей средств программирования, которые, в ориентации на тупую аудиторию уже конструктивно ограничиваются.
Попробуй взглянуть на это с другой стороны. В софтостроении потихонечку произошла маленькая революция. Возможно это и возвращение старых идей, но на новом уровне. Тебе же объясняют — на шарпе получается писать намного быстрее и намного качественней даже профессионалам. А то что язык дисциплинирует тех самых чайников это его плюс. Джава в большей степени, шарп в меньшей. Тут альтернатива простая — либо средненькие программеры, либо никакие. В последнее время я предпочитаю брать на работу людей незнакомых с тем что применяется. Научить значительно проще чем переучить.

ГВ> В них попросту нет того, что могло бы быть. Нет анализа семантики программы, нет построителей графов, нет никаких встроенных математических механизмов, что разумно было бы ожидать от сред поддержки програмирования. Ни хрена этого нет!
Оно и в плюсах ничего нет. Математика не поспевает за программиролванием. Пожалуй единственным успешным применением математики в программировании является теория множеств и теория графов. При чем sql сервера потихоньку вылазят из своих реляционных штанишек. Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.

ГВ> Есть только набор "методов", бантики-картиночки и встроенная поддержка построения (ах, извините — "организации") всей этой толпы и раздачи ей малоквалифицированной работы. Но это-то ладно. Однако здесь есть ещё очень интересная завязка на то, что при таких делах интеллектуальные средства развиться просто не смогут! Их же тоже будут писать под управлением таких же менеджеров, бестолковых аналитиков и т.п. Они же просто массой всех задавят.
Дорогой ты мой, их не посылать надо а делать из них нормальных спецов. Других нет.

ГВ>Вот тебе и "язык должен учитывать все эти проблемы...".
Обязательно. Иначе это не язык а абстракция.

ГВ>Проблемы кого? Проблемы недоучившихся школьников?
Да

ГВ> То есть, давайте превратим всех в недоучившихся школьников,
Не надо превращать. Они уже есть.

ГВ> потому что так основной массе будет удобнее? Что-то в этом есть неверное, а конкретно — игнорирование интеллектуальной основы (ИМХО).
А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.

ГВ>(ну да — тот самый, очень "сложный", в первую очередь
Тот самый очень сложный под дотнет есть. MC++ называется.

ГВ>), тем более — признанные разработчиками! То есть, по сути, частное окружение пытается навязать свою модель разработчикам, которым, по идее, не должно быть до него никакого дела.
Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.

ГВ>Это следствие бушующего идиотизма, извини за прямоту и не прими в свой адрес.
Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.

ГВ> ИМХО, это признак деградации. Поскольку создаёт жёсткую зависимость разработчиков от платформы, на которой их программы будут работать. Язык высокого уровня отделяет разработчика от исполнительной системы.
Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.

ГВ>GC — свойство рантайма,
Вот вот.

ГВ> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
Абсолютно неверно.

AVK>>И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.
ГВ>Не я один хотел бы получить развитый компилятор/интерпретатор/анализатор/type-info-генератор для С++.
Так в чем проблема то?

AVK>>Есть еще джава.
ГВ>Java, кстати, кажется и на .NET реализована.
J#.

ГВ>Что доказывает их подобие
И гибкость CLR.

ГВ>Но никак не на подержку неограниченного повышения эффективности одного человека.
Практика показывает что эффективность он таки повышает.

ГВ>ИМХО — нет, поскольку это откат назад в грубом виде. Кстати, на такой оборот речи меня навела дискуссия Vlad2-Аноним где-то в соседних ветках. (http://www.rsdn.ru/forum/?mid=93371

Автор:
Дата: 31.08.02

)
Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.

ГВ>Нас грубо подталкивают к эффективности реализации примитивных систем, но усложняют деятельность более высокого порядка.
Как раз наоборот получается. Когда мы пытаемся что то простенькое писать, зачастую на С++ получается не хуже, иногда даже лучше. А вот когда дело доходит до чего то тяжелого тогда и начинают работать все достоинства дотнета или джавы.

AVK>>В том числе и для этого.
ГВ>Но появятся ли новые?...
Почему нет?

AVK>>СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

ГВ>Это была фигура речи, только для оттенения того, что на C++ это всё-таки было реализовано. Я тоже не считаю COM образцом красоты.
Ну уж очень фигово надо признать.

AVK>>CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.
ГВ>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?
А зачем? Она в дотнете уже есть. Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.

... Янус версия 1.0 alpha 2