Все началось до появления C #
В 1999 году у нас была Visual Studio 5/6. Если вы были независимым поставщиком программного обеспечения или корпорацией, использующей Windows, и вам нужно было написать приложение, которое могло бы, например, отслеживать время, потраченное сотрудником на проекты, у вас было несколько вариантов:
- Формы в Visual Basic.
- MFC, ATL или Win32 в Visual C ++.
- Формы в Access 97/2000.
- Веб-сайт ASP.
- Java-апплет.
В то время мы были как раз перед тем, как лопнул пузырь Dot-Com, поэтому любой, кто хорошо разбирался в (4) или (5), отправлялся обсуждать опционы на акции в любом удивительном дот-коме, к которому их привлекали.
(3) были проблемы с блокировкой и общей масштабируемостью, но я видел много решений на основе Access, которые могли бы запускать функции поддержки при необходимости.
Это оставляет нас с VB и VC ++:
Редактор форм в VB был в то время превосходным по производительности. Вы можете перетащить свои компоненты - не только кнопки, метки и текстовые поля, но и полный набор инструментов OLE-элементов управления для многократно используемых компонентов, таких как умные таблицы, таблицы Excel или экземпляры IE. Подключение было сделано за кулисами - все было объектно-подобным, и вы просто дважды щелкали мышью, чтобы добавить обработчики событий. Это было намного сложнее в Visual C ++. Как член группы поддержки разработчиков Visual Studio в то время, я помню, как звонки в службу поддержки Visual Basic были в основном о том, какой компонент лучше всего использовать, или как оптимизировать свое приложение определенными способами. Почти никогда не было «как сделать приложение с функциями пользовательского интерфейса X, Y и Z».
Создание богатого пользовательского интерфейса в Visual C ++ было другой проблемой. Хотя визуальные редакторы поддерживали диалоги и формы SDI / MDI, они были довольно ограничены. Поддержка встраивания элементов управления OLE (ActiveX) в MFC или Win32 была черным искусством, хотя и немного проще в ATL. Соединение простых вещей, таких как изменение размера событий или рисование владельца, было довольно болезненным, не говоря уже о точках подключения, необходимых для пользовательских событий в компонентах.
Да, у VC ++ были скорость выполнения, возможность отладки и гибкие параметры каркасов / библиотек / пользовательского интерфейса, но поддержка IDE не могла охватить все это основание, поэтому была решена наиболее распространенные операции с такими вещами, как Wizards, всеобъемлющая иерархия классов MFC и 90-дневный срок. / 2 линии поддержки свободных инцидентов.
IIRC, упаковщик приложений, поставляемый с VB, может упаковать ваше приложение, среду выполнения VB и последние DLL-библиотеки общих элементов управления и предоставить вам автономный установщик EXE, который вы можете положить на компакт-диск и достать для клиентов. Ничего из этого «какие msvcrtXX.dll и mfcxx.dll вы не установили?», Которые мучают разработчиков MFC.
Таким образом, из-за времени выхода на рынок и богатого пользовательского интерфейса у VB очень много последователей.
Когда Visual J ++ и Visual Interdev появились в VS6, стало ясно, что Visual Basic IDE выиграл битву за Visual C ++, что было честно, IMHO. Неудивительно, что в Visual Studio .NET появился VB-подобный редактор форм для нового языка COOL C #.
Новый Java / C / C ++ -подобный язык в сочетании с конструктором пользовательского интерфейса, которым все это время пользовались люди из VB, дал новый путь миграции для людей, написавших на C ++, которые теперь работали с MFC / ATL / Win32. Для людей VB 3/4/5/6, которым не понравилось отсутствие 100% обратной совместимости в VB.net, это дало возможность выучить новый язык в знакомой среде.
Причины, по которым VB был таким всеобъемлющим продуктом, вероятно, имеют какое-то отношение к происхождению Microsoft, причем Basic является их основным продуктом для разработчиков, но у меня пока нет ссылок.