Antonariy писал(а):ATL, MFC и всякие другие прибамбасы.
Не принимается. ATL и MFC не появились в сях с плюсами — это продукты MS для MS-овской ОС, созданные, ага, для сей с плюсами. Но сами си с плюсами появились задолго до того, как были созданы ATL и MFC. В сях с плюсами появились шаблоны (благодаря которым стало возможно ATL) и классы (благодаря которым стали возможны MFC). Но ни шаблоны, ни классы не появились там благодаря каким-то аппаратным улучшениям. Просто Страуструп придумал это. А могли бы придумать Кен и Томпсон чуть раньше.
Antonariy писал(а):Просьба назвать хоть одно улучшение железа, из-за которого процесс разработки в VB6 замедлился.
В такой постановке я эту просьбу выполнить не могу.
Прости, но ты именно так сказал. Ты сказал, что с появлением у железа новых возможностей разработка на VB6 именно
усложняется и
замедляется. Это не так: я как написал бы некоторую программу десять лет назал, за столько же времени напишу её и сейчас (если не быстрее) — но никак не медленнее. Поэтому я и назвал эту фразу ерундой. А вовсе не потому, что, как думает Денис, мне .NET не нравится, а тебе — да.
Мысль была в том, что появление новых возможностей, даже возможностей операционной системы, не работающих на устаревшем железе, к примеру AERO, заставляет хотеть конечных пользователей ими насладиться, а нас — удовлетворить желание. Доступ к этим возможностям через VB в разы сложнее, чем через .NET, а выгоды сомнительны.
Мысль понятна, и я с ней согласен. Но вот в чём дело: с появлением AERO никто не мешал вынести доступ к его возможностям в какой-либо внешний интерфейс (в винапи, в какой-то COM-интерфейс). Тогда возможностями Аэро смог бы воспользоваться и Дельфист, и ВБ-шник и сишник и ассемблерщик. Да хоть кто. А MS, значит, принципиально сделала так, чтобы новые фичи могли быть поюзаны только из .net-а. И вот
это — мерзко.
Главная мысль была в той части фразы, которую ты проигнорировал. В отличии от VB .NET будет иметь (или уже имеет, не в курсе) унифицированный интерфейс для работы с любым устройством, как ADO — для баз. А создатели устройств будут писать драйвера под .NET, под этот интерфейс. А под win32 постепенно перестанут по мере того, как win32-софт будет вытесняться .NET-софтом, а фреймворк "сближаться" с ядром винды.
Фишка в том, что унифицированный интерфейс для работы с устройствами уже давно существовал. New Idiotic Generation в MS решило в лучших традициях MS сделать нечто "такое-же, но своё" и изобрела
велосипед свой унифицированный механизм (поверх над существующим — полностью свой-то сделать слабо).
Я предвкушаю, что ты сейчас скажешь, мол, с существующим интерфейсом было сложно работать и он не ООП-ный. Насчёт сложности я не соглашусь — кому сложно, тот пусть переквалифицируется в менеджеры и "оптимизирует бизнесс-процессы". Насчёт ООП-ности: совершенно никто не мешал сделать ООП-обертку над существующим унифицированным интерфейсом. Обычную COM-based ООП-оберкту, которую могли бы поюзать изо всех мест, в том числе из VB6.
Но фишка в том, что добавить унифицированный ООП-интерфейс для работы с устройствами в VB6 (даже не в винду, а просто в VB6) менее прибыльно, чем создать новую платформу.