Здравствуйте, Kisloid, Вы писали:
K>здесь
K>Хочется узнать ваше мнение
Думаю это перегиб. C++ изначально задумывался как объектно-ориентирование расширение C, причём расшерение, сохраняющее одну из главных прелестей языка — тестную связь с аппаратурой и возможность работать с ней напрямую. Причём работать эффективно. В тоже время язык обладает полномасштабной поддержкой концепций ООП. Сочетание этих важных особенностей языка во многом и обеспечило столь огромную его популярность. Однако C++ не задумывался для работы со сборщиками мусора. В нём до последнего времени не было поддержки свойств, нет поддержки атрибутов — метаинформации. То есть того, что вышло во многих задачах на передний край в наше время.
Управляемый C++ — это уже не совсем C++. А само создание этого языка скорее напоминает попытку перетащить под .NET многочисленное и могучее сообщество C++. Лично я сомневаюсь, что Managed С++ станет главным языком под .NET. Слова микрософт о том, что они хотят его таким сделать выглядят скорее реверансом в сторону C++ разработчиков и извинением за попытку менторским образом заставить всех переходить на .NET, чем выражение реальных планов MS. Это, кстати со всей очевидностью следует из тех изменений, которые были внесены в язык. Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
E>Мало уступает, да? E>А как тогда на C# сделать такое: А generic-и так могут?
Доделают в третьей версии языка.
А если серьёзно, то вспомните поговорку:
"Умный человек — это тот, кто знает, как выпутаться из сложной ситуации, а мудрый — тот, кто знает, как в неё не попадать". Приведённый вами пример по-моему как раз из этой серии. Вы здорово спасли положение, используя C++, но в C# по-моему несколько проще было бы написать более правильный код и проще отрефакторить существующий.
Боже мой! Я фанат C++ и защищаю эту мерзость! Какой позор... Смайлика с харакири здесь нет?
AF> Управляемый C++ — это уже не совсем C++. А само создание этого языка скорее напоминает попытку перетащить под .NET многочисленное и могучее сообщество C++. Лично я сомневаюсь, что Managed С++ станет главным языком под .NET. Слова микрософт о том, что они хотят его таким сделать выглядят скорее реверансом в сторону C++ разработчиков и извинением за попытку менторским образом заставить всех переходить на .NET, чем выражение реальных планов MS. Это, кстати со всей очевидностью следует из тех изменений, которые были внесены в язык. Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
C++/CLI это тот же С++ плюс добавленный набор синтаксических фич для работы с managed кодом. Я считаю что он будет использоваться для поддержки ранее написанного на С++ коде, для тех участков где действительно важна скорость, там где GC не справляется (а такие места я думаю есть и будут есть). Причем на С++/CLI можно в приниципе писать точно так же как и на Си шарпе, плюс возможности писать unmanaged код (знаю что в С# есть unsafe участки, но все таки это не то).
Лично я считаю, что эти два языка не взаимоисключают друг друга, у них совершенно разная философия, они будут долго существовать вместе как мне кажется.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Здравствуйте, Kisloid, Вы писали:
AF>> Управляемый C++ — это уже не совсем C++. А само создание этого языка скорее напоминает попытку перетащить под .NET многочисленное и могучее сообщество C++. Лично я сомневаюсь, что Managed С++ станет главным языком под .NET. Слова микрософт о том, что они хотят его таким сделать выглядят скорее реверансом в сторону C++ разработчиков и извинением за попытку менторским образом заставить всех переходить на .NET, чем выражение реальных планов MS. Это, кстати со всей очевидностью следует из тех изменений, которые были внесены в язык. Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
K>C++/CLI это тот же С++ плюс добавленный набор синтаксических фич для работы с managed кодом. Я считаю что он будет использоваться для поддержки ранее написанного на С++ коде, для тех участков где действительно важна скорость, там где GC не справляется (а такие места я думаю есть и будут есть). Причем на С++/CLI можно в приниципе писать точно так же как и на Си шарпе, плюс возможности писать unmanaged код (знаю что в С# есть unsafe участки, но все таки это не то).
Полностью согласен.
K>Лично я считаю, что эти два языка не взаимоисключают друг друга, у них совершенно разная философия, они будут долго существовать вместе как мне кажется.
И тут полностью согласен. Собственно именно это я и имел в виду, когда написал, что статья содержит явный перегиб.
Для меня ближе, роднее и любимее С++ — как для микроэлектронщика. Ну люблю я в регистрах покопаться... Но как для архитектора или дизайнера — мне ближе Java или C# (возможно и Smalltalk и даже Оберун, если бы я их знал )
Чем мне понравился тот же C# — так это та же Jaba, но язык живой, со множеством полезных, практичных доплнений, делающих его более удобным и практичным.
Я думаю что у обоих языков есть хорошее будущее — у каждого своё — своя область, где он более удобен. Со временем появятся новые языки, которые превзойдут и тот и другой (в своей области применения) и двинутся дальше.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
E>>Мало уступает, да? E>>А как тогда на C# сделать такое: А generic-и так могут?
AF>Приведённый вами пример по-моему как раз из этой серии. Вы здорово спасли положение, используя C++, но в C# по-моему несколько проще было бы написать более правильный код и проще отрефакторить существующий.
Приведенный там пример показал не только то, что в C++ можно спасать положение, а необходимость спасать положение потребуется в любом языке, т.к. мудрых людей, способных сразу сделать все правильно, крайне мало (к тому же я сомневаюсь, что мудрый человек вообще займется программированием). А на счет отрефакторить существующий код... В том конкретном примере проведение рефакторинга и переписывание кода "как надо" означало бы автоматическую потерю совместимости с уже написанным клиентским кодом. А затраты на рефакторинг клиенского кода вообще бы оказались недопустимыми.
Как оказалось, шаблоны C++ позволяют делать вещи, которые нельзя сделать generic-ами Java/C# -- динамически создавать объекты с передачей аргументов конструкторами.
Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста, кого-то вроде меня
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, eao197, Вы писали:
E>>>Здравствуйте, AndreyFedotov, Вы писали:
AF>>>>Как мне кажется — под .NET основным языком был и всегда будет C#, тем более, что вторая версия языка мало в чём уступает C++.
E>>>Мало уступает, да? E>>>А как тогда на C# сделать такое: А generic-и так могут?
AF>>Приведённый вами пример по-моему как раз из этой серии. Вы здорово спасли положение, используя C++, но в C# по-моему несколько проще было бы написать более правильный код и проще отрефакторить существующий.
E>Приведенный там пример показал не только то, что в C++ можно спасать положение, а необходимость спасать положение потребуется в любом языке, т.к. мудрых людей, способных сразу сделать все правильно, крайне мало (к тому же я сомневаюсь, что мудрый человек вообще займется программированием).
Совершенно согласен. Отделный +1 по поводу мудрого человека.
E>А на счет отрефакторить существующий код... В том конкретном примере проведение рефакторинга и переписывание кода "как надо" означало бы автоматическую потерю совместимости с уже написанным клиентским кодом. А затраты на рефакторинг клиенского кода вообще бы оказались недопустимыми.
Бывает и так, но я вообще-то имел в виду инструментальные средства для рефакторинга, которых для C++ я пока не видел.
E>Как оказалось, шаблоны C++ позволяют делать вещи, которые нельзя сделать generic-ами Java/C# -- динамически создавать объекты с передачей аргументов конструкторами.
Да, согласен. Но часто бывает так, что в каждом языке есть некоторая своя фенечка, которой в других языках нет и в некоторых ситуациях именно эта фенечка является безумно удобной и полезной. В том же Smalltalk были подобные фенечки (по рассказам — вроде перехвата вызовов методов). Это не означает обязательного превосходства данного языка.
Хотя в целом, Евгений, я с вами согласен — C++ — очень хороший язык. Замечу, что C# — тоже на мой взгляд. Но за ним нет пока такого громадного опыта и истории.
E>Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста, кого-то вроде меня
Именно. У них разные цели, задачи и предназначение.
If you arenґt C++ programmer... study C++, right now!
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Приведенный там пример показал не только то, что в C++ можно спасать положение, а необходимость спасать положение потребуется в любом языке, т.к. мудрых людей, способных сразу сделать все правильно, крайне мало (к тому же я сомневаюсь, что мудрый человек вообще займется программированием). А на счет отрефакторить существующий код... В том конкретном примере проведение рефакторинга и переписывание кода "как надо" означало бы автоматическую потерю совместимости с уже написанным клиентским кодом. А затраты на рефакторинг клиенского кода вообще бы оказались недопустимыми.
Очень советую попробовать использовать системы рефакторинга. Думаю после этого ты изменишь свое мнение. Незнаю уж почему, но рефакторинг доступен только для шарпа и явы, так что пробовать прийдется на них. Но рефакторинг намного лучше нежели заплаты и ужимки с целью обмануть свой же код. А лучше он потому, что в его результате получается чистый код который легко поддерживать и равивать.
E>Как оказалось, шаблоны C++ позволяют делать вещи, которые нельзя сделать generic-ами Java/C# -- динамически создавать объекты с передачей аргументов конструкторами.
Это все делать можно. На то есть интерфейсы и делегаты. Единственное что действительно нельзя делать на дженериках, и что можно делать на шаблонах — заниматься вычислениями во время компиляции. Это следствие компонентной природы жденириков и макросно-компиляционной природы шаблонов.
E>Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста,
Согласен.
E> кого-то вроде меня
Кокетничаешь?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
E>>Что же касается исходного вопроса, то C# не сможет быть заменен C++ в принципе. Ни оригинальным C++, ни managed C++, ни C++/CLI. Так что в блоге, на который была дана ссылка, есть только брюзжание старого программиста,
VD>Согласен.
E>> кого-то вроде меня
VD>Кокетничаешь?
Нет, подумываю о смене деятельности. Например, о переходе в технические писатели. Вот кой-какой опыт. Или вот еще.
Жаль только, что правописание хромает.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Есть одно ёмкое русское слово очень хорошо подходящее для описания данного эссе — бред.
VD>Думаю, что C++/CLI повторит судьбу первой версии МС++. Вообще-то об этом тут уже не раз говрилось. Сделай поиск по CLI...
Повторит судьбу в каком смысле? В том что оставшиеся непокобелимые остатки C++ девелоперов таки попробуют C++/CLI, подсядут на .NET, так между прочим случайно попробуют C# и опаньки? Знакомая история
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Повторит судьбу в каком смысле? В том что оставшиеся непокобелимые остатки C++ девелоперов таки попробуют C++/CLI, подсядут на .NET, так между прочим случайно попробуют C# и опаньки? Знакомая история
Именно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kisloid, Вы писали:
K>Хочется узнать ваше мнение
По сути эти дискуссии сводятся к двум пунктам
1. Если что-то надо учить больше двух месяцев, то это бесполезно и даже вредно
2. Брось это старье, смотри сюды, какая фенька, и "мы наш мы новый мир построим".
По пункту 2 нужно понять, что есть два типа программ — с заложенным интеллектуальным трудом и без оного. Всяческие веб-конференции, калькуляторы и небольшие программы складского учета в принципе все равно, на чем писать. Более сложные программы обычно наследуют старый код, написание которого по новой требует времени программистов-специалистов в предметной области. Т.е., если калькулятор или даже RSDN я сейчас сяду и напишу, то FineReader я не напишу, потому что не представляю, как это делается.
Причем надо еoе заметить, что IT индустрия замедляется, и дело даже не в том, что технологии медленнее заменяют друг друга, а в том что новые технологии очень похожи на старые, причем зачастую наблюдается регресс — неплохие языки Java и C# до сих пор иногда продвигаются как спеицальный такой C++ для идиотов (вспомним про понятие Learning Curve и плавно перейдем к пукту 1). Отметим только такое "исключение", как Asp.Net, где зачастую наследуется код VB...
По пункту 1. Почему когда у нас случается острый аппендицит, мы все жутко боимся и стараемся дать кому-нибудь денег, только не попасть к свежеиспеченному хирургу, несомненно изучившему самые современные технологии и способы удаления аппендицита. Архитектору-энтузиасту с красным дипломом мы все равно побоимся доверить проект небоскреба. Во многи профессиях опыт в лет 10 считается обязательным, и только программистов перестают брать на работу в 35 лет. Это связано именно с быстрым развитием отрасли в последние годы, но концепции программирования фактически устоялись — обаалдеть нововведение в C# — generics! Ех-ты-ж! Что это мне напоминает?
И тут наоборот, сбывается мечта идиотов — в работе реально нужны мощные инструменты, так как у программистов появляется время их освоить.
Ну а то, что стандартизаторы С++ тормозят развитие языка, это наша общая большая беда. reflection и properties не хватает, конечно. Поразительно, что многочисленные пользовтаели, стонущие из-за их отсутсвия, не могут уже много лет самоорганизоваться и потребовать этих измениий.
Здравствуйте, Xentrax, Вы писали:
X>Ну а то, что стандартизаторы С++ тормозят развитие языка, это наша общая большая беда. reflection и properties не хватает, конечно. Поразительно, что многочисленные пользовтаели, стонущие из-за их отсутсвия, не могут уже много лет самоорганизоваться и потребовать этих измениий.
И только к счастью, что не могут. С++ не задумывался для этих целей. И не стоит курочить язык, что бы сделать гибрид слона с попугаем. Эти возможности есть в C# и в Java — так зачем их тащить на C++? Не лучше ли сделать в C# или Java более удобные generics и расслабиться?
Здравствуйте, Xentrax, Вы писали:
X>или даже RSDN я сейчас сяду и напишу
Не напишешь. Потому что количество неотвратимо переходит в качество. Борьба со сложностью это на настоящий момент наиважнейшая задача создания информационных систем. Непонимать этого значит заведомо провалить любой мало мальски сложный проект.
Здравствуйте, Kisloid, Вы писали:
K>Хочется узнать ваше мнение
Как я понимаю вопрос стоит в C# vs managed C++?
Не так давно потребовалось мне поработать с железкой. Весь интерфейс с ней составлял кучу сишных хедеров и либов. Разумеется решил использовать С++, благо в нем можно достаточно просто мешать managed & unmanaged код. Эх! Давно не брал я в руки шашки (года 3), пора вспомнить молодость плюсовую и заодно погонять С++ под дотнетом! В результате получил кучу "удовольствий", о которых успел уже толком подзабыть за время своей C#-ной деятельности.
Для начала я лишился решарпера и всех прибамбахов студии. Привык, блин, к хорошему. Поиск элементарных ошибок путем компиляции всего проекта... мда, невесело. Ну да ладно, в 2005-й студии ситуация обещают поправить, а вот решарпер даже и не планируют делать для С++. Как я раньше без него работал, хз.
Дальше с интересом отметил ужасающую скорость компиляции. В разы медленнее кода на C#. А ведь когда-то вполне было нормальным минут на 5 запустить компиляцию и спокойненько покурить, и не жаловался! Ну да ладно, фасад для сишних либ получился не особо большой, терпимо.
Пришлось заодно вспомнить приколы с хедерами, с раздельной декларацией и реализацией метода.
Ну и конечно, куча мелочевок, завязанных именно на синтаксис:
1. Events, properties ну очень "красиво" и громоздко выглядят.
2. Так же весьма "приятно" постоянно писать __box для боксинга.
3. Приведение типов... вместо as и (Type) извольте использовать громоздкие __try_cast & dynamic_cast.
4. Передача аргументов для функции с переменным количеством оных вынуждает использовать конструкцию Object* args[] = { ... }; Method(args);
5. Постоянная путаница с . -> :: для обращения к членам класса... а все дурацкая, выработавшаяся уже привычка везде писать "."
6. Поимел проблемку с NullReferenceException при __nogc new. Решилось поиском в гугле и прописыванием нужной либы линкеру. Уж и забыл, что линкер имеется
Вообщем веселье....
А теперь вопросец. Мне понятно, почему я не хочу использовать С++ для написание софта под дотнет, за исключением разве что интеропа к легаси коду. Отсутствие полезных тулзов (решарпер), тормозной компилятор, громоздкий синтаксис. Так в чем же плюсы плюсов? К чему собственно агитирует автор по исходной ссылке? К лени и нежеланию учить другой язык?
olegkr,
> Как я понимаю вопрос стоит в C# vs managed C++?
vs. C++/CLI, а большинство твоих претензий относится к Microsoft Managed Extensions for C++.
> Для начала я лишился решарпера и всех прибамбахов студии.
VisualAssist не пробовал?.. — Впрочем, не знаю, умеет ли он все, что ожидается в этом смысле от Resharper...
> Дальше с интересом отметил ужасающую скорость компиляции. В разы медленнее кода на C#.
Если использовать C++/CLI в режиме, аналогичном C#, т.е. импортировать namespaces .Net, а не пользоваться #include, скорость компиляции будет +- такая же. А за счет использования компоновщика потенциально еще и чуть быстрее, т.к. при изменении одного файла остальные не нужно перекомпилировать.
> Пришлось заодно вспомнить приколы с хедерами, с раздельной декларацией и реализацией метода.
Если использовать C++/CLI в режиме, аналогичном C#, то это не нужно. Хотя, имхо, полезно.
> Ну и конечно, куча мелочевок, завязанных именно на синтаксис: > 1. Events, properties ну очень "красиво" и громоздко выглядят. > 2. Так же весьма "приятно" постоянно писать __box для боксинга. > 3. Приведение типов... вместо as и (Type) извольте использовать громоздкие __try_cast & dynamic_cast. > 4. Передача аргументов для функции с переменным количеством оных вынуждает использовать конструкцию Object* args[] = { ... }; Method(args);
Это все о Managed Extensions for C++, а не о C++/CLI.
> 5. Постоянная путаница с . -> :: для обращения к членам класса... а все дурацкая, выработавшаяся уже привычка везде писать "."
Спорный вопрос, что лучше.
> 6. Поимел проблемку с NullReferenceException при __nogc new. Решилось поиском в гугле и прописыванием нужной либы линкеру. Уж и забыл, что линкер имеется
Тут не знаю, как это будет в C++/CLI.
> Так в чем же плюсы плюсов?
В больших возможностях: в более развитой объектной модели, в поддержке детерменированного разрушения в т.ч. и для ref classes, в наличии полноценных шаблонов и т.п.
> К чему собственно агитирует автор по исходной ссылке?
К тому, чтоб посмотреть на C++/CLI.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Xentrax, Вы писали:
X>>или даже RSDN я сейчас сяду и напишу
AVK>Не напишешь. Потому что количество неотвратимо переходит в качество. Борьба со сложностью это на настоящий момент наиважнейшая задача создания информационных систем. Непонимать этого значит заведомо провалить любой мало мальски сложный проект.
Я позволил себе выделить вашу очень смешную фразу, про то что я не смогу написать RSDN. Я как программист (он же разработчик) и вообще дипломированный специалист по АСУиОбработкеИнформации умею бороться со сложностью, поэтому RSDN я знаю как писать. И даже знал 5 лет назад.
Я вам сейчас кратко расскажу про информационную сложность.
Предположим как вам решение, включающее себя спутниковые приемники (включая инфраструтуру — антенны, кабели, триподы), лазерные нивелиры, высокточные теодолиты (включая новые модели с выделением дополнительной информации из изображений), роботизированные бульдозеры, контроллеры, сети виртуальных базовых станций, людей в офисе и в поле, соединить это все информационными потоками и логически — и физически — через радио-модемы, лазерные лучи, GPRS, CDMA, создать собственные процессоры для этого оборудования, да еще и обеспечить интегарцию всего этого с конкурентами, итд итп. Так вот, написать это я не смогу, хотя уже 5-ый год в этом.
Потому что я не могу в одиночку охватить всю предметную область. Что уж там говорить — в самой обычной американской дороге заложено науки и расчетов побольше чем в среднего размера сайте.
Да просто, чтобы посчитать гридовые координаты для какой нибудь несчастной малайзийской деревни нужны специальные выверенные алгоритмы, и определенные параметры преобразований. И если у вас в вашем алгоритме (написанном 10 лет назад на С) появится ошибка, то команда бородатых сурвейеров, потратившая месяц-два времени, и нагулявшийсь по местным джунглям, разбившая там пару теодолитов за $50000 каждый, будет очень удивлена объяснением, что зато язык C# позволяет бороться с информационной сложностью. Был у нас приблизительно такой случай
А ведь у нас это все работает. И написано вовсе не на C#. И язык для таких задач уже не важен, более того, для некоторых процессоров наши разработчики вынужены писать на ассемблере очень сложную логику просто потому, что нет для них компилятора даже языка C.
Чтобы получить фиксированное решение на 50 километровой базовой линии, недостаточно хорошо знать язык C#. Чтобы у вас безотражательный теодолит работал на расстоянии в километр, C# уже не поможет. Зная C#, вы не построите сеть виртуальных базовых станций, потому что дело не в языке, а в математике. И вот, я каждый день вижу людей, которые все это делают. И это работает.
А ведь есть еще маркетинг, дистрибуция, техподдержка, десятки офисов по всему миру. И растущие прибыли, хотя ни в одной системе в компании .Net пока не используется, хотя учитывая разговоры о том, что наш сайт пора выбрасывать, то, думаю, эту, самую важную часть решения перепишут на чем-нибудь новомодном.
), я не знаю, чем вы по жизни занимаетесь, но это же правда смешно. Вы СЕРЬЕЗНО думаете, что нет ничего сложнее, чем соединить GotDotNet и RSDN???
Ну да, я тоже пишу фактически как хобби на .Net/ASP.Net комплекс, который на лету по построенным индексам считает параметры рынка коммерческой недвижимости в динамике и статике на основе данных, которые операторы готовят, анализируют и фильтруем на шумы заранее. Ну что-то типа недо-OLAP. И в общем, информационная сложность этого "решения", мягко говоря, никакая. Не думаю, что RSDN на 2 порядка сложнее, чем моя программка.
----
Еще раз. Есть задачи, где неважно на каком языке вы пишете, а важно, ЧТО вы пишете, и какие ЗНАНИЯ вы туда закладываете. Хотя наверное стоит забить на сотни миллионов долларов интеллектуальных инвестиций, сделанных в код, и перейти на язык, в котором сделано множество существенных улучшений, например используется необычайно прогрессивная и насущная технология реализации интерфейсов вместо устаревшего и неприменимого в реальных задачах множественного наследования.
---
Во, я тут вспомнил, что мне это напоминает. Я однажды на форуме Лингво посмел сказать, что их полная версия дороговата, и что пора думать об апдейте со скидкой. Ёёёёё, как мне там разработчики стали доказывать, что лингвисты — самая нужная, важная и тяжелая профессия на земле.
Собственно именно это я и имел в виду, когда написал, что статья содержит явный перегиб. 
Если нам не помогут, то мы тоже никого не пощадим.
перепишут на чем-нибудь новомодном. 