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

IT>>Это не плохо и не хорошо, а похоже на закон. Потенциально программирование вообще может умереть с созданием очень развитого искусственного интеллекта.
AVK>Пока даже на горизонте ничего подобного не проявляется.

Да, но по мнению некоторых появляются якобы "лишние люди" в программировании, которые не знают ассемблера и потому "не настоящие" Это очень напоминает то, о чем я написал.

A>кстати SQL был подобной попыткой чтоб юзеры могли пользоваться базами
A>данных без помощи программистов. и сколько вы знаете юзеров, которые
A>напрямую пользуют SQL?
Вроде есть

A>получается программисты изобретают технологии которыми никто
A>потом не может пользоваться кроме них самих

да нет, ситуация явно меняется. Сравните с состоянием 10-15 лет назад. VBA и т. п.

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

Вы вернулись к старому спору, кто сильнее слон или бегемот, Java или C++ ...
Имхо из вашего спора все-равно ничего не получится. Я почитал Ваши топики, у обоих куча разумных аргументов, вы оба говорите умные вещи. Но этот спор ИМХО ни к чему не приведет.
Java, C#, C++ — очень хорошие языки, но все они реализованы под конкретные задачи. ERP системы (по крайней мере системные сервисы) или новую операционную систему я бы стал писать на C++, тк этот язык идеально подходит для подобных целей (у меня уже был опыт разработки таких проектов). Сетевые приложения и специализированные серверы лучше программировать на Java, тк будет намного меньше заморочек с утечками памяти; к тому же серверы как правило быстрые многопроцессорные машины, быстродействия Java на них в большинстве случаев хватает (то что GC и другие заморочки Java в данном случае отжирают кучу памяти для большого и мощного сервера все-таки не критично). C# — микрософтовский противовес Java. В недалеком будущем он будет общепризнанным стандартом (не потому, что он слишком хороший или лучше чем Java или С++, а потому что его продвигает микрософт, а как известно побеждают все-таки деньги). Мое мнение — через два года нам придется программировать на C#, но тем не менее С++ все-равно выживет и С++ программисты-профессионалы по-прежнему будут пользоваться спросом.

По теме топика могу сказать, что человеку надо самому определиться, в какой области в дальнейшем он хочет программировать. Сложно быть одновременно квалифицированным Java и C++ программистом. Если годик не программировать на каком-либо языке, то он просто напросто забывается, к тому же отстаешь от развития этого языка. Но в дальнейшем можно всегда наверстать упущенное... Изучайте обе технологии, чтобы не отстать от прогресса.

Best regards.

A>>данных без помощи программистов. и сколько вы знаете юзеров, которые
A>>напрямую пользуют SQL?
IT>Вроде есть
у нас тоже есть один. такие запросы в терминале строчит — иных программеров
заткнет за пояс . но это исключение чем правило

A>>получается программисты изобретают технологии которыми никто
A>>потом не может пользоваться кроме них самих

IT>да нет, ситуация явно меняется. Сравните с состоянием 10-15 лет назад. VBA и т. п.

7 лет назад уровень юзеров у нас был.... нужно было объяснять что "вот это клавиатура, не для того чтобы на ней есть"

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

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

A>>кстати SQL был подобной попыткой чтоб юзеры могли пользоваться базами
A>>данных без помощи программистов. и сколько вы знаете юзеров, которые
A>>напрямую пользуют SQL?
IT>Вроде есть
Слушай, скажи, где такие водятся. Прошу. Лично приеду и посмотрю на такого сознательного юзера
Если он токмо не из управляющего персонала

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

IT>>Вроде есть
A>у нас тоже есть один. такие запросы в терминале строчит — иных программеров
A>заткнет за пояс . но это исключение чем правило

SQL создавался не как язык для пользователей а как стандарт на общение с СУБД. Для пользователей придумали QBE и что то я не слышал об особой успешности этой технологии.

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

A>>>данных без помощи программистов. и сколько вы знаете юзеров, которые
A>>>напрямую пользуют SQL?
IT>>Вроде есть
muh>Слушай, скажи, где такие водятся. Прошу. Лично приеду и посмотрю на такого сознательного юзера
muh>Если он токмо не из управляющего персонала

Сам лично не видел

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

A>имхо. слишком много "левого" народу пришло в программирание.

Ламеры были есть и будут. Причем в любой области деятельности человека.

A>перефразируя опус Эда Поста можно сказать так:
A>"пока живы настоящие программисты будут существовать С++ и Ассемблер"

Асемблер будет даже после смерти этих самы "настоящих". Вопрос в его месте на рынке. На сегодня — это 0.01% от общего количества написанного софта.

A>зы. касательно сабжа. С++ лучше изучать после С. в институте я изучал
A>Фортран, С и Ассемблер. С++ изучил сам на 4-м курсе по книжке "от С к С++"

Я вот согласен, что начинать с С — это правильно. Я только не согласен, что вообще нужно изучать С++ в общеразвивающих целях. Все же язык сложный. На сегодня есть другие более простые языки позовляющие решать 90% проблем. Причем решать белее эффективно. Вот если задача будет рашаться с помощью С++ проще и быстрее (обычно это системное программирование), то можно и его изучить.

A>Java, C# ориентированы на бизнес-задачи.

Ява возможно. Шарп точно претендует на звание универсального языка. Уровень его конечно выше. Но это не отнимает у него универсальности. В .NET даже VB стал значительно более фуникциональным. По большому счету С++ теперь нужен только тогда когда нужно организавать интерграцию со старым миром, т.е. когда требуется системное программирование.

A>есть еще множество других интересных областей и С++ там незаменим

Я вот знаю только один класс задачь который пока на Шарпе решать трудно. Это программирование 3D-графики. Ито это из-за того, что старые API ориентированы как раз на тот самый C++. Сделают апи для .NET и это будет возможно.

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

AVK>>И джава и шарп являются языками со строгой типизацией

A>я имел в виду VB

Дык VB тоже язык со строгой типизаций. В .NET он вообще мало чем от Шарпа по возможностям отличается. По крайней мере с точки зрения описания и использования типов точно ничем.

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

AVK тебе дело говорит. Ты поставь себе новую студию... сделай пару пробных проектов... а потом суди. Отладка в C# и VB.NET ведется так же как и раньше. И ассемблерный листинг тебе польностью доступен.

A>с одной стороны за это платят деньги а с другой — скучно и везде одно и то же — базы, формы и т.д.

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

A>везет же кому-то на проекты типа мониторинга базовых станций сети GSM в реальном времени
A>и вряд ли они делают это на Java .

Вот как раз подобные вещи очень любят клепать на Яве.

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

IT>Потенциально программирование вообще может умереть с созданием очень развитого искусственного интеллекта.

Ну, если он интелект, да еще и искственный, то очень развитым он станет автоматически. Ну, а на счет умереть... дык от такой игрушки кто/что хочешь может умереть.

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

AVK>Отлаживать программы на уровне ассемблера? Ну заете ли, это когда совсем не чем заняться.

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

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

A>>Java, C# ориентированы на бизнес-задачи.

VD>Ява возможно.
Ява тоже весьма универсальная штука. Особенно если учесть то что ее родная библиотека ощутимо больше даже дотнетовской.

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

A>>есть еще множество других интересных областей и С++ там незаменим

VD>Я вот знаю только один класс задачь который пока на Шарпе решать трудно. Это программирование 3D-графики.
Для справки, на джаве подобное апи есть, Java3D называется. Собственно 3D там естественно нативный, с поддержкой акселераторов. На платформе Win32 есть 2 версии, DX и OGL.

VD>AVK тебе дело говорит. Ты поставь себе новую студию... сделай пару пробных проектов... а потом суди. Отладка в >C# и VB.NET ведется так же как и раньше. И ассемблерный листинг тебе польностью доступен.

у меня VC.NET давно стоит. но в основном из-за VC++7.0

A>>везет же кому-то на проекты типа мониторинга базовых станций сети GSM в реальном времени
A>>и вряд ли они делают это на Java .

VD>Вот как раз подобные вещи очень любят клепать на Яве.

угадайте на каком языке пишут 90% программистов в Microsoft?
ответ — не на C# и VB. хотя и это тоже есть.
вот когда они полностью перепишут Windows под .NET тогда посмотрим
как нам с этим жить дальше

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

[properties]
VD>Стоит, не стоит. Это удобно и нет ни одного противопоказания. Но в стандрат не вводят. Мелочь конечно, но пративно.

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

ГВ>>Да, дружище. Забыл ты C++. Указатели на функции и на статические члены типов там живут и благоденствуют.

VD>Уж извени не восвем я его забыл. Указатели на глобальные фуникции там конечно от С остались, но язык то стал ОО. Страуструп попытался сделать указатели в ОО-стиле но получился жудкий уродец котоый на практике никто не применяет.

Я применяю ;)

VD>Делегаты и клосюры это нечто большее. Вот это в отличии от свойств уже сильно облегчает жизнь. Но не для С++-ников. :(

Ну уж! Вознесём молитву делегатам ;) ИМХО, единственное, где они могут облегчить жизнь — это при скрытии деталей реализации вызова с конкретной сигнатурой.

Кстати — делегаты великолепно создаются и не одним способом при наличии полноценного C++ — компилятора. MSVC6 — отстой полнейший для решения подобных задач. а) Частичного инстанцирования нет, б) через ж... под язык работает со вложенными шаблонами.

[...]

VD>>>Первая идея реализована в Дельфи и билдере. Идея проста и элегантна — указатель не зависит от конкретного класса и содержит указатель на экземпляр. По сути хранятся два указателя. Первый указвает на объект. Второй на функию.

ГВ>>Ну да, так примерно и есть.

VD>Где? В Билдере — да. В стандарте — нет.

См. выше. Нужен полноценный компилятор. Intel C++ 5.0 подойдёт. Он, кстати, и в среду встраивается.

[...]

ГВ>> Указатель на функцию можно хранить в inline-static или в специализации этого метода.

VD>Чё-чё. Ты не мудри, ты пальцем покажи. :)

Сегодня или завтра заброшу свой вариант делегатов на C++.

ГВ>> А зачем реализовывать ещё и все методы интерфейса?

VD>Потому, что интерфейс это абстрактный класс. Если от него унаследуешься, то обязан реализовывать все методы.

VD>Помойму ты не понимаешь что я имею ввиду под словом интерфейс. COM знаешь? А CORBA-у? Это от туда термин.

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

[...]

VD>Вот здесь бы и подошли абстракции типа клосюра (у Борлонда) или делегатов у MS. Без них событийное программирование — мрак.

[...]

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

Если вставляются где надо и не надо. Думаешь, я сам не хлебал этой каши? :down:

VD>Главное что нет никакой поддержки компилятора. Нужны всякие кодогененраторв. Ну, и самое противное, что вся хваленая типобезопастность С++ идет под снос. :(

Ну правильно, если её сознательно обходить, то...

VD>>>а не будет недоуменно смотреть и говорить что он знает только типы доступные во время компиляции.

ГВ>>ИМХО, элемент залога устойчивости системы.

VD>Когда речь идет о компонентах, то выбор состоит из вдух вариантов. Как в С++... отключить к чертям проверку типов (например приведением указателей к void*) и пологаться на свои силы и нервы. Вариант Явы и Шарпа... иметь информацию о типах в рантайме и продолжать контроль типов.

VD>Например, в С++ безпроблем можно привести указатель на один объект к указатлю на другой. Все грохнет в рантайме. И грохнет серьезно (обычно AV).

Не верю. Потому, что явное приведение типов — всегда небезопасное занятие. То есть, скажем так — "нерекомендуемое". То есть, "делай, но думай, что делаешь".

VD> В .NET же в рантайме делаются проверки и неправильное приведение вызовет исключение. Но исключение неправильного приведения типов. Такое исключение легко обработать.

С одной стороны, исключение — тот же свал программы, только в профиль, с другой — CLR спроектирован для поддержки "RTTI-oriented"-программирования. Что же тут удивительного?

VD>Страуструпу не раз говорили, что подобный механизм нужен.

А он совершенно справедливо, ИМХО, от него отбрыкивается, как от провоцирующего написание плохого кода.

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

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

ГВ>>Слушай, давай определись — какой аспект рантайма ты имеешь ввиду.

VD>В смысле? Я имею в виду, то что С++ идеологически настроен на генерацию кода. И рантай его подсистема заканчивается на CRT.

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

VD>Чтобы понять о чем я говорю, представь сколько кода нужно для вызова метода информация о котором не была доступна во время компиляции? Т.е. на входе есть имя модуля (длл-ки) и нужно дать мозможность вызвать один из методов класса который находится в этом модуле. На C# это пишится за пол часа. На С++ эта задача в общем не решаема. Решить ее можно применяя разные расширения типа COM.

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

[...]

VD>Согласись, что С++ стал бы только лучше если бы в него добавили бы эти самые делегаты и рефлекшон? Кому от этог хуже.

Делегаты отлично добавляются при наличии полноценного компилятора. MSVC6 — увы... :down:

ГВ>>Основу для такого вывода я нашёл в глоссарии к MS SDK help.

VD>Да. С глосариями у MS всегда были проблемы. Они больше запутывают.

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

[...]

ГВ>>В самом "верхнем" смысле — никакой, кроме той, что C++ гибче.

VD>Ну, что есть того не отнять. Но обратная сторона этой гибкости — неимоверная сложность программирования на нем. На С++ недельный поиск ошибки — это нормально. Для Явы два часа уже аврал. .NET же вообще дает тебе все варианты. Нужна низкоуровневая оптимизация... берем MC++ (который, кстати не урезан, а даже расширен, и поддерживает все возможности С++ известнве MS :) ). А то и вообще на мсиле в рантайме... Нужна безопастность и скорость разработки... берем C# или VB.NET. Нужны экзотические приколы... берем Перл, Эфил и т.п. Т.е. противопоставление есть только в одну сторону. Ну, а гибкость?... Дык она в основном нужна там где проблема не решается штатными методами.

Штатными методами чего? C#? Java? У них по сравнению с C++ набор штатных методов кастрирован.

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

Vlad, ну это уже софистика. Знаешь, "на C++ можно создать приложение меньшего размера с той же функциональностью, что и написанное на C#". Расскажи: что за приложение, сколько окошек/табличек/кода в нём. Там уже и поспорим.

VD>Но как только нужно взаимодействовать с теми же контролами виндовс, как без них не обойтись. Да и вообще становится удобнее писать на С++.

???

VD>Ты что рекламу не смотришь? :)

Я телевизор вообще стараюсь не смотреть.

ГВ>> А что, отсутствие множественного наследования и шаблонов (надеюсь, временное) увеличивает гибкость?

VD>Нет. Это явные недостатки. Причем явно слизанные с Явы и Дельфи. Мы это уже обсуждали. Вопрос в том, что приемуществ явно больше. Да и скорее всего недостатки эти скоро устранят. Уж если Ява дожила до шаблонов... :)

ИМХО, всё гораздо гаже. Эти недостатки либо слизаны с компонентной модели, либо внесены из-за желания упростить реализацию рантайма.

[...]

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

Вот тут-то и пригодилось бы умени делать индукцию...

VD>>>3. COM замечательно подходит для "построения абстракций уровня реализации".

ГВ>>Нет. Поскольку за COM-интерфейсами есть ещё много чего.

VD>С тачки зрения абстракции COM-интерфейс вещь законченная.

То есть, программы, реализующей его методы уже как бы и нет?

VD>В том же .NET ничего нового не придумали. Мы например все свои разработки планировали как COM-объекты, а специфицировали их до интерфейсов. На самом деле это очень хороший подход. Дисциплинирует и далает четкую границу мжеду частями проекта.

А как ты думаешь, что мешает применять подобный подход, — с чётким разделением на модули и специфицированием интерфейсов, — при программировани на C++?

[...]

VD>Извени. И имел в виду указатль на функцию челен. Причем я не даром сказал указатель на член экземпляра объекта. Т.е. попробуй сделать указатель на фукцию так чтобы в него можно было поместить адрес на фуниции разных классов (но с одинаковым описанием). Псевдокод:
VD>

VD>struct A { void MyFanc1(); };
VD>struct B { void MyFanc2(); };

VD>НекийУсловныйУказательНаМетод pMethod = bCondition ? MyFanc1 : MyFanc2;

VD>...

VD>pMethod();
VD>

VD>Делегаты с таким справляются на ура.

ГВ>> ;) Впрочем, я понимаю, что ты имеешь ввиду — реализовать ту же модель, что реализована делегатами. В принципе, я уже придумал реализацию, запощу чуть позже. Сюда или в "C++". Хотя, повторюсь, что на C++ реализация не столь лаконична, как в C#.

VD>Я уже этим занимался. Как уже говорил получилось не красиво.

Я уже так сделал. Но элегантно это получается только при наличии полноценного C++ — компилятора. Кстати, вот здесь самый важный вопрос: ты пробовал другие компилеры? Например, Intel? Он только в 2001 вышел (5.0) и, ясно, что многие эксперименты не удались бы принципиально.

Признаюсь сразу — на MSVC6 помучился и забросил эту байду после десятого C1001 INTERNAL COMPILER ERROR, а на Intel — вроде получилось.

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

ГВ>>Ну, не так уж он и нужен.

VD>Нужен не нужен... Это из той же оперы. Слова Страуструпа, что сборку мусора можно реализовать как внешнюю библиотеку. Вот тут давича Мишка.Нэт сделал попытку... интересно конечно поичитать, но пользоваться этим нельзя, так как все слишком сложно.

Ну, ещё бы. Придётся прятать все указатели/ссылки и т.п. Тут уж, ИМХО, проще C# сделать ;) Просто без GC обойтись можно. Ну да ладно...

VD>>> Покажи еще как на С++ динамически загрузить объект и вызват его методы. Причем на КОМ не фига пинять.

ГВ>>Есть такой паттерн, называется прокси, если не ошибаюсь... или lazy-object.

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

В принципе, да, особено, если предположить, что объект должен извлечься неизвестно откуда. :) Но решить можно.

VD>>> Там от С++ ничерта не остаются. Ты попробцй срдствами языка. Попробуй вызвать виртуальный метод из коструктора или деструктора.

ГВ>>Если метод абстрактный, то и не попробую из конструктора/деструктора того же класса. Прямое следствие семантики создания/разрушения. ИМХО — очень разумное.

VD>Тогда сделай поиск по форуму С++. Погляди сколько вопросов по этому поводу. Это же ведь подсознательно разумное решение! Язык должен держаться не за спецификацию, а за людей на нем работающих.

ИМХО, язык должен держаться ещё и за концептуальную целостность. А подсознание у всех разное.

[...]

VD>Это без разницы. Были бы "талантливые" руки. Компонентный же подход как раз и становится выходом когда размеры проета становятся невыносимыми.

Примеры! Хочу примеры! Я даже волшеьное слово знаю: пожалуйста.

VD>>>А ты случаем не видел аналога на C++ + SQL? О... забавное зрелище.

ГВ>>Видел. То, как их реализуют мне тоже не понравилось.

VD>Так может дело в людях?

ИМХО — YES!!!

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

VD>>AVK тебе дело говорит. Ты поставь себе новую студию... сделай пару пробных проектов... а потом суди. Отладка в >C# и VB.NET ведется так же как и раньше. И ассемблерный листинг тебе польностью доступен.

A>у меня VC.NET давно стоит. но в основном из-за VC++7.0 :-)

A>>>везет же кому-то на проекты типа мониторинга базовых станций сети GSM в реальном времени
A>>>и вряд ли они делают это на Java :-).

VD>>Вот как раз подобные вещи очень любят клепать на Яве. :)

A>угадайте на каком языке пишут 90% программистов в Microsoft?
A>ответ — не на C# и VB. хотя и это тоже есть.
A>вот когда они полностью перепишут Windows под .NET тогда посмотрим
A>как нам с этим жить дальше :-)

ИМХО, они этого никогда не сделают. Просто навешают .NET-овских интерфейсов на всё NT-шное ядро и привет.
Или сделают "драйвер NT" под .NET или ещё один namespace придумают.

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

VD>> Шарп точно претендует на звание универсального языка. Уровень его конечно выше. Но это не отнимает у него универсальности. В .NET даже VB стал значительно более фуникциональным. По большому счету С++ теперь нужен только тогда когда нужно организавать интерграцию со старым миром, т.е. когда требуется системное программирование.
AVK>Надо заметить что и системное программирование потихонечку мигрирует в компонентную среду.

Коль не секрет, то что это значит? Кроме того, что есть серверы приложений, брокеры и прочее, написанные на Java?

Просто, что-то это очень пессимистично звучит...

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

ГВ>Коль не секрет, то что это значит? Кроме того, что есть серверы приложений, брокеры и прочее, написанные на Java?
Системные сервисы Win часто имеют COM-интерфейс. И если старые это обычно оболочки, то те которые поновее часто именно написаны под COM. К примеру DirectX.

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

ГВ>Коль не секрет, то что это значит? Кроме того, что есть серверы приложений, брокеры и прочее, написанные на Java?

А на чём ты думаешь пишуться серверы приложений под Unix?

ГВ>Просто, что-то это очень пессимистично звучит...

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

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

VD>>Я вот знаю только один класс задачь который пока на Шарпе решать трудно. Это программирование 3D-графики.
AVK>Для справки, на джаве подобное апи есть, Java3D называется. Собственно 3D там естественно нативный, с поддержкой акселераторов. На платформе Win32 есть 2 версии, DX и OGL.

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

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

VD>>AVK тебе дело говорит. Ты поставь себе новую студию... сделай пару пробных проектов... а потом суди. Отладка в >C# и VB.NET ведется так же как и раньше. И ассемблерный листинг тебе польностью доступен.

A>у меня VC.NET давно стоит. но в основном из-за VC++7.0

Тогда остается сделать один небольшой шаг... создать новый проект на C# и поэксперементировать. Вот нужно будет утилитку какую написать... попробуй, не поленись... уверен, что отношение резко изменится.

VD>>Вот как раз подобные вещи очень любят клепать на Яве.

A>угадайте на каком языке пишут 90% программистов в Microsoft?

Сейчас уже неизвестно. Раньше 90% было на С. А что?

A>ответ — не на C# и VB. хотя и это тоже есть.

Сремена меняются.

A>вот когда они полностью перепишут Windows под .NET тогда посмотрим
A>как нам с этим жить дальше

А полностью не будет никогда. Драйверы и ядро все одно на С/С++ с асм-мом писать будут. Ну, а многие прикладные части должны быть переписаны.