Вы смотрели потрошка .NET? Беру файл dotnetfx35.exe, захожу в него в TC по Ctrl+Dn:

\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX20\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX30\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFX35\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etMSP\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\Tool s\
\dotnetfx35.exe\wcu\.\.\.\.\.\dotNetFramework\dotN etFx35setup.exe

Как видим, .NET 3.5 представляет из себя ровно всю плеяду дотнетов предыдущих версий, непонятно только куда подевался 1.1. Теперь можно порассуждать про экономное использование ОЗУ за счёт повторного использования компонентов и библиотек. Т.е. пользуясь технологией .NET вы получаете снежный ком, который в один прекрасный момент безусловно рухнет под собственной тяжестью. Впрочем, может всё ещё закончился красиво, поддержка 2.0 и 3.0 будет постепенно убрана. Но не расслабляйтесь пока, решать это не вам, а могучему m$.

Оберон-парадигма, как мне кажется, предлагает несколько другой путь (очень хочется в это верить). Лодка не плывёт далеко, хотя Бомбаров это не смущает, но она за счёт своей лёгкости меняет курс быстрее Титаника. Но грести приходится всё-таки ручками, на что многие обижаются. Можно конечно прицепить мотор, но уже требуется топливо и теряется совместимость с весельной версией лодки.

Расскажу ещё байку про дотнет из книги Сержа Тарасова "Дефрагментация мозга. Софтостроение изнутри". Сама книга мне очень понравилась. Байка же, как мне кажется, иллюстрирует недостатки "титанического" подхода.

Когда старая школа молода


Изменения происходят столь быстро, что приходится записывать в ряды старой школы системы с приложениями на последних версиях автономного Visual Basic 6, безвозвратно растворившегося в бурлящей пучине. NET. Теперь, спустя немногим более десяти лет, когда начинают всплывать проблемы с поддержкой из-за отсутствия специалистов, принимаются решения о переделке систем в новой технологии с минимальными изменениями функциональной полезности или вовсе без оной. Тут-то и могут вскрыться интересные подробности.
В одной крупной электрической компании имелась база данных, собирающая эксплуатационную и прочую информацию за несколько лет от разнообразных датчиков и устройств в распределительной сети национального масштаба. Некоторые параметры отличались очень коротким интервалом замеров - «каждые N секунд». В итоге размер хранилища составляет около 3 терабайт информации за несколько фиксированных лет эксплуатации.
В общем, такой размер не является маленьким и для промышленных СУБД, требуя дополнительных усилий в проектировании, реализации, настройке и поддержке. Но пикантность ситуации состояла в том, что база данных была организована в виде двоичных файлов собственного формата.
Признаюсь, последний раз я видел такой подход в далёком 1994 году, когда мы переводили паспортные столы Санкт-Петербурга с подобных плоских файлов на прогрессивный по тем временам и, что важнее, открытый формат DBF под Clipper и FoxPro для MS-DOS и Novell-серверов. С оговорками перехода от флоппи-нет [115 - От англ. floppy net - жаргонное обозначения псевдосети передачи информации между устройствами с помощью гибких дисков. В современном варианте звучало бы как «флэшка-нет».] на каналы удалённой связи, многие паспортные службы долгое время продолжали в этой системе работать, характерные алфавитно-цифровые экраны в DOS-окошке я наблюдал уже в начале 2000-х годов.
В долговременной памяти всплыли воспоминания случаев необходимости ручного декодирования форматов. К великому счастью, программисты системы не занимались тогда «эволюционной» разработкой, а знали область, в которой работают, и добросовестно поддерживали проектную документацию в актуальном состоянии. Кроме возможности прочитать собственно об устройстве системы, все описания форматов двоичных файлов также были на месте. Возникший было тёмный призрак индустриальной археологии растворился в лучах взошедшего солнца.
Поскольку в нашу задачу входило предпроектное обследование, начались интересные опыты с технологиями новыми. Начали с прототипа конвертера, извлекающего данные из старых форматов и распределяющего их по таблицам промышленной СУБД, в качестве которой выступал SQL Server. Логично было бы написать такой прототип на C++ или другом языке с возможностями прямого доступа к памяти на уровне битов, но ввиду планируемой общей разработки исключительно на C# необходимо было оценить соответствующую программу в ипостаси распаковщика байтов.
Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. A ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked(). В итоге код достаточно простого алгоритма пестрел вот такими вставками, которые, на минуточку, суть рекомендуемые практики. Нас настигла расплата за автоматическое управление памятью.

Convert.ToUInt32(«00110000», 2);
unchecked((ushort) 0xC0);

Вторым пунктом была собственно база данных. На логическом уровне структура для тестируемого случая никаких сложностей не представляла: одна узкая длинная таблица, связанная с несколькими короткими справочниками, практически «звезда», но в режиме постоянного добавления пачек новых записей. Трудность представлял собой уровень физический. Втиснуть число-признак, кодируемое тремя битами, в те же три бита на уровне СУБД стандартные средства не позволят. Минимальный размер - байт. Использовать нестандартные битовые поля в принципе можно, но тогда мы лишимся поддержки ссылочной и прочей целостности, возможности использовать SQL для выборок без переупаковки значений в битовые структуры и фактически будем использовать СУБД в качестве продвинутого аналога файлового хранилища с улучшенными функциями администрирования.
Поскольку целью было упрощение работы с пользовательскими запросами, то лишать их доступа к данным посредством прямого и понятного человеку SQL было решительно невозможно. При использовании минимальных по размеру стандартных типов данных прогнозируемый размер базы данных без учёта дополнительных индексов превысил 6 терабайт, то есть минимум удвоился по сравнению с двоичными файлами. Сжатие данных несколько скрасило ситуацию, полученные 4,5 терабайта выглядели уже неплохо. За всё надо платить, в том числе за стандартность доступа и представления данных.
Третьим пунктом была загрузка данных из C#-пpилoжeния в базу данных. Поскольку интенсивность вставки из прибывающих от датчиков текстовых файлов составляла почти 400 тысяч записей каждые 10 минут, то, разумеется, приложение должно было справляться с этой задачей за меньшее время. Оптимальной, как и следовало ожидать, оказалась пакетная загрузка, игнорирующая ограничения целостности РСУБД. Такова обычная цена компромисса.
Что имеем по итогам более чем 10-летнего развития технологий? Появилась возможность стандартизировать хранение и доступ к большому массиву данных, используя вполне обычное серверное оборудование корпоративного класса и 64-разрядную промышленную СУБД. Возникла необходимость переделывать программное обеспечение из-за утраты поддержки среды разработки поставщиком и соответствующих компетенций на рынке труда.
Но я совсем не уверен, что ещё через 10 лет новые подрядчики, вынужденные в очередной раз переписывать систему, найдут документацию в том же полном виде, в котором нашли её мы. Если вообще найдут хоть что-то, кроме кода, остатков презентаций и наших отчётов.