Tudo começou antes que o C # existisse
Em 1999, tínhamos o Visual Studio 5/6. Se você era um fornecedor independente de software ou uma empresa usando o Windows e precisava de um aplicativo escrito que pudesse, por exemplo, rastrear o tempo gasto pelos funcionários em projetos, você tinha algumas opções:
- Formulários no Visual Basic.
- MFC, ATL ou Win32 no Visual C ++.
- Formulários no Access 97/2000.
- Site ASP.
- Applet Java.
Naquela época, estávamos um pouco antes do estouro da bolha da Dot-Com, então qualquer um que fosse bom em (4) ou (5) saiu para negociar opções de ações em qualquer ponto-com incrível pela qual se sentisse atraído.
(3) teve problemas com bloqueio e escalabilidade geral, mas vi muitas soluções orientadas a acesso que seriam executadas como shell para executar as funções de suporte conforme necessário.
Então, isso nos deixa com VB e VC ++:
O editor de formulários no VB era, na época, excelente para produtividade. Você pode arrastar e soltar seus componentes - não apenas botões, etiquetas e caixas de texto, mas também a caixa de ferramentas completa 'OLE controls' de componentes reutilizáveis, como grades inteligentes, planilhas do Excel ou instâncias do IE. A conexão foi feita nos bastidores - tudo parecia um objeto e você clicou duas vezes nas coisas para adicionar manipuladores de eventos. Isso foi muito mais difícil no Visual C ++. Como membro da equipe de suporte ao desenvolvedor do Visual Studio na época, lembro como as chamadas de suporte do Visual Basic eram principalmente sobre qual componente era melhor usar ou como otimizar seu aplicativo de determinadas maneiras. Quase nunca foi 'como faço para fazer um aplicativo com os recursos da interface do usuário X, Y e Z'.
Criar uma interface do usuário rica no Visual C ++ era um desafio diferente. Embora houvesse suporte do editor Visual para diálogos e formulários SDI / MDI, ele era bastante limitado. O suporte para incorporar controles OLE (ActiveX) no MFC ou Win32 era uma arte negra, embora um pouco mais fácil no ATL. A instalação de coisas simples, como redimensionar eventos ou desenhar pelo proprietário, foi bastante dolorosa, sem falar nos pontos de conexão necessários para eventos personalizados nos componentes.
Sim, o VC ++ tinha velocidade de execução, capacidade de depuração e estruturas / bibliotecas / opções de interface do usuário flexíveis, mas o suporte ao IDE não podia cobrir todo esse terreno; portanto, abordou as operações mais comuns com coisas como Wizards, hierarquias abrangentes de classes MFC e 90 dias / 2 linhas de suporte para incidentes livres.
O IIRC, o empacotador de aplicativo fornecido com o VB pode empacotar seu aplicativo, o tempo de execução do VB e as DLLs de controles comuns mais recentes e fornecer a você um instalador EXE independente que você pode colocar em um CD e chegar aos clientes. Nada disso ', que msvcrtXX.dll e mfcxx.dll você instalou?', Que atormentou os desenvolvedores do MFC.
Portanto, por motivos de time-to-market e rica interface do usuário, o VB obteve muitos seguidores.
Quando o Visual J ++ e o Visual InterDev chegaram ao VS6, ficou claro que o IDE do Visual Basic havia vencido alguma batalha sobre o Visual C ++, o que era justo no IMHO. Não foi surpresa que o Visual Studio .NET tivesse um editor de formulários do tipo VB para a nova linguagem COOL C #.
A nova linguagem semelhante a Java / C / C ++, juntamente com o designer da interface do usuário apreciado pelo pessoal do VB durante todo esse tempo, deu um novo caminho de migração para o pessoal do C ++ que agora fazia o MFC / ATL / Win32. Para as pessoas VB 3/4/5/6 que não gostaram da falta de 100% de compatibilidade com versões anteriores no VB.net, isso ofereceu a oportunidade de aprender um novo idioma em um ambiente familiar.
Os motivos pelos quais o VB era um produto tão abrangente provavelmente têm algo a ver com as origens da Microsoft, sendo o Basic o principal produto para desenvolvedores, mas não tenho citações no momento.