Tout a commencé avant que C # n'existe
En ~ 1999, nous avions Visual Studio 5/6. Si vous étiez un fournisseur de logiciels indépendant ou une entreprise utilisant Windows et que vous aviez besoin d'une application écrite qui pourrait, par exemple, suivre le temps passé par un employé sur des projets, vous aviez quelques options:
- Formulaires en Visual Basic.
- MFC, ATL ou Win32 dans Visual C ++.
- Formulaires dans Access 97/2000.
- Site Web ASP.
- Applet Java.
À l'époque, nous étions juste avant l'éclatement de la bulle Dot-Com, donc tous ceux qui étaient bons avec (4) ou (5) sont partis négocier des options d'achat d'actions à n'importe quel incroyable dot-com qui les attirait.
(3) avait des problèmes avec le verrouillage et l'évolutivité globale, mais j'ai vu beaucoup de solutions pilotées par Access qui permettraient d'exécuter des fonctions de support selon les besoins.
Cela nous laisse donc avec VB et VC ++:
L'éditeur de formulaires dans VB était, à l'époque, excellent pour la productivité. Vous pouvez glisser-déposer vos composants - pas seulement des boutons, des étiquettes et des zones de texte, mais la boîte à outils complète des «contrôles OLE» de composants réutilisables comme des grilles intelligentes, des feuilles Excel ou des instances IE. Le câblage a été fait dans les coulisses - tout ressemblait à un objet et vous venez de double-cliquer sur des choses pour ajouter des gestionnaires d'événements. Cela a été beaucoup plus difficile dans Visual C ++. En tant que membre de l'équipe de support de développeur Visual Studio à l'époque, je me souviens comment les appels de support Visual Basic étaient principalement sur le composant qui était le mieux à utiliser ou comment optimiser leur application de certaines manières. Ce n'était presque jamais «comment créer une application avec les fonctionnalités d'interface utilisateur X, Y et Z».
La création d'une interface utilisateur riche en Visual C ++ était un défi différent. Bien que Visual Editor prenne en charge les boîtes de dialogue et les formulaires SDI / MDI, il était assez limité. La prise en charge de l'intégration de contrôles OLE (ActiveX) dans MFC ou Win32 était un art noir, bien qu'un peu plus facile dans ATL. Le câblage de choses simples comme redimensionner des événements ou dessiner par le propriétaire était assez pénible, sans parler des points de connexion requis pour les événements personnalisés dans les composants.
Oui, VC ++ avait la vitesse d'exécution, la capacité de débogage et les options de frameworks / bibliothèques / UI flexibles, mais le support IDE ne pouvait pas couvrir tout ce terrain, donc a abordé les opérations les plus courantes avec des choses comme des assistants, des hiérarchies de classes MFC complètes et 90 jours / 2 lignes d'assistance gratuites.
IIRC, le packager d'application fourni avec VB, peut emballer votre application, le runtime VB et les dernières DLL de contrôles communs et vous fournir un programme d'installation EXE autonome que vous pouvez mettre sur un CD et remettre aux clients. Rien de tout cela "quels msvcrtXX.dll et mfcxx.dll avez-vous installé?", Ce qui a tourmenté les développeurs MFC.
Ainsi, pour des raisons de temps de mise sur le marché et d'interface utilisateur riche, VB a obtenu un très grand succès.
Lorsque Visual J ++ et Visual Interdev ont frappé dans VS6, il était clair que l'IDE Visual Basic avait remporté une bataille contre celui de Visual C ++, qui était juste à mon humble avis. Il n'était pas du tout surprenant que Visual Studio .NET disposait d'un éditeur de formulaires de type VB pour le nouveau langage COOL C #.
Le nouveau langage de type Java / C / C ++ couplé avec le concepteur d'interface utilisateur apprécié par les personnes VB pendant tout ce temps a donné un nouveau chemin de migration pour les personnes C ++ qui ont maintenant terminé avec MFC / ATL / Win32. Pour les personnes VB 3/4/5/6 qui n'aimaient pas le manque de compatibilité à 100% en arrière dans VB.net, cela a offert l'occasion d'apprendre une nouvelle langue dans un environnement familier.
Les raisons pour lesquelles VB était un produit si complet ont probablement quelque chose à voir avec les origines de Microsoft, Basic étant leur produit phare pour les développeurs, mais je n'ai pas de citations pour le moment.