в VB нет наследования и полиморфизма.
нет конструкторов (Initialize - это пародия на конструктор)

Но ведь можно создать класс на базе другого. Это не наследование ?

внешне похоже, по сути - нет. Язык(компилятор) ничего не знает о взаимосвязи этих двух КЛАССОВ (не объектов), соответственно ничего не может контролировать - все на твоей совести.

//(Initialize - это пародия на конструктор)
А почему пародия, что такое особенное в конструкторах с++.
При создании объекта VB-шный Initialize вроде может набацать что нужно.
главная особенность - это возможность передать пераметры в этот самый конструктор. Можно конечно, сначала созать объект, а потом вызвать какой-то его метод и передать нужные параметры инициализации. Но опять-же компилятором никак не контролируется выполнил ты второй шаг или нет. Элементарно просто забыть его написать.

Я 6 лет сидел на процедурных принципах программирования , а сейчас вот ООП юзаю. Вообщем то достоинств у ООП хватает,но все говорят ,что его реализация на VB -" подосланная".

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

Полиморфизм это вроде использование одних и тех же определенных методов разными классами (если не путаю). Так уж это важно?

каждый решает для себя. В моих приложениях - не важно.
На мой взгляд, в VB реализован минимальный джентельменский набор OOП, который является вот этим:
По сути дела ООП просто группировка тех же самых процедур и функций.

Твое мнение вызвано тем, что ты идешь к ООП через VB.
На самом деле все намного лучше :-)
Почитай что-то сишное, хоть того-же Стауструпа. Если в синтаксис не вникать, то все идеи ООП можно почерпнуть оттуда.

по поводу .Net не знаю, не пробовал. Но слышал, что действительно
вроде в VB.NET ООП на уровне

а по поводу перехода на vb.Net, то насколько я смог понять рекламу, то это переход не просто с языка на язык, а переход на совершенно другую технологию, причем в ней особо большой разницы между языками нет (что С#, что VB.Net - одинаково, разница только в синтаксисе.)
Но все равно это только понаслышке - ну не ел я этих устриц.
А бросать изученный вдоль и впоперек, и главное востребованный инструмент я считаю глупо - за Microsoft все равно не угонишься, а будешь только тем и заниматься, что изучать ее нововведения и разгребать ошибки и недоработки за свой счет.
Если только начинаешь изучать, и выбираешь куда устремиться, то естественно, надо выбирать самое передовое, что есть на данный момент и рости вместе с ростом выбранной технологии - детство-отрочество-юность-зрелость. А потом по-новой. Как правило за это время сменится две - три новомодных технологии, которые и умирают обычно с такой-же скоростью как и появляются. :-)

там все очень просто. У каждого объекта при его создании VB создает счетчик ссылок на этот объект.
Как только этот счетчик становится равным нулю, объект уничтожается автоматом. Счетчик управляется исключительно самим VB.
Это один из основных источников утечки памяти, и сопровождается зависанием и приложения в памяти даже после закрытия всех окон приложения. Искать такую ошибку ОЧЕНЬ неприятно.
К стати, одно пренеприятнейшее следствие - два взаимноссылающихся друг на друга объекта навсегда зависают в памяти. Никаким способом эту ситуацию не разрешить, кроме как перепроектированием структуры объектов. Внешне это проявляется тем, что приложение из памяти выгружается только через TaskManager, тоесть аварийно и в открытых формах код событий Terminate, Unload не выполняется....
В "Крепком орешке" описан способ как этого избежать, но там можно запросто систему завалить - прямой доступ к памяти в защищенном режиме, да еще и из VB - думаю дальше продолжать не надо? :-)

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

2Александрик:
описанная тобой ситуация как раз не создает взаимной ссылки.

взаимная ссылка получается вот так:
в объекте А есть объектная переменная уровня модуля, которая ссылается на объект В.
А в объекте В есть объектная переменная уровня модуля, которая ссылается на объект А.
Пока хотя-бы одна из этих переменных не станет Nothing, оба объекта будут оставаться в памяти.

Решается это только с помощью перепроектирования объектной модели, либо второй вариант - в одном из классов создается метод, который присваивает объектным переменным уровня модуля значение Nothing. Этот метод надобно вызывать вручную _перед_ выгрузкой объекта. Этот вариант - не более чем заплатка, которую можно применить когда менять что либо уже поздно. Но _изначально_ 100% лучше избегать этих ситуаций.

По идее, эту ситуацию может еще решить оператор END (не проверял), но это все равно, что стопкран на Шатле :-)

2Бобер

Например у нас те кто пишет на VC++ считает тех ,кто пишет на VB юзерами.

у нас таких принято увольнять, будь программист на VB или на C или еще на чем.

Я считаю (но никогда не называю) юзерами тех, кто применяет средства, неадекватные поставленной задаче. Хотя тут тоже есть плюс-минус (например, я в данный период своей трудовой деятельности больше "в теме" VB, поэтому для некоторых задач, где VB не совсем эффективен, иногда все-таки эффективнее применить VB, а не восстанавливать свою квалификацию например, сишника и применять VС++)

По моему опыту, в современном бизнес-программировании важен не инструмент, а связка программист-инструмент.
Причем роль программиста, его опыта и трезвости взгляда на мир - определяющая.

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

Это злобствующие дилетанты. Не обращай внимания - большего они не стоят.