Rico Mariani, Arquiteto Chefe do Visual Studio, fala sobre os planos de longo prazo do Visual Studio 2010. Antes de começarmos, Rico tem um aviso,
Eu sou o Artiteto Chefe mas eu também sou *apenas* o Arquiteto Chefe. Eu não tomo a decisão final sobre o que é incluido no produto, nem mesmo combinado com os outros arquitetos. Juntos, nós criamos um roteiro de tecnologia de longo prazo, que indica problemas chaves que precisam ser resolvidos a longo prazo sobre o andamento do produto entre outras coisas, mas estas coisas não podem normalmente ser mapeadas diretamente para as funcionalidade de uma determinada versão.
O primeiro tópico a surgir é extensibilidade. Enquanto o core do Visual Studio é extensível, muitos dos componentes de alto nível que as pessoas realmente querem extender estão na sua maioria fora dos limites. Além disso, os pontos de extensibilidade estão baseados no COM.
Portanto, para atender a essas necessidades, nós focamos no que se tornou conhecido como Managed Extensibility Framework (MEF) e duas grandes áreas de extensibilidade do Visual Studio 2010 importam e exportam de acordo com esse padrão. Agora é claro que o MEF era apenas um brilho em nossos olhos quando começamos, mas como você pode ver pelo que fomos capazes de mostrar no PDC, temos um longo caminho a percorrer. Nós temos pêgo as principais dependências do MEF em nosso novo editor de textos (mais sobre isso abaixo) e no novo sistema de projetos C++.
No futuro, o Visual Studio será altamente dependente do Windows Presentation Foundation. Isso tem gerado opiniões variadas do público.
Isso pode soar um pouco estranho mas sempre há resistência. Deixe-me escolher o meu tema favorito para VS2010 -- usando o WPF amplamente. Vários usuários, pelo menos inicialmente, pensam que eu estou louco por defender essa dependência. "Você aguenta isso? E quanto ao cenário
Eu ouvi que WPF não está bom no cenário ." Fui bem discreto com a seguinte observação: "Você realmente pensa que GDI é a última palavra em computação gráfica para os próximos 10 anos?"
Ele continua,
Eu sei que nos estamos tendo alguns prováveis problemas com WPF. Temos que resolvê-los, e quem melhor do que nós? Nós fizemos aplicações de tamanho médio no WPF (e.g. Blend), e agora vamos conduzir uma aplicação substancial, talves a 3ª maior suite do mundo e nós vamos fazer funcionar. Vai ser ótimo para nós e para o proprio WPF, e então outros podem seguir com confiança. Não há uma verdadeira alternativa porque nós não podemos ficar parados no nossa UI antiga e depois esperar um visual moderno depois de 10 anos. E nossos amigos da terra do WPF estão tão animados quanto eu... mas não é certeza que isso seja possível.
Durante todo o artigo, um tema comum foi comparar o VS 2008 com VS 98.
Fiz uma breve demonstração para meu VP ano passado quando eu mostrei uma aplicação MFC simples para os cenários entre VC98 e o VS2008 -- e não me interpretem mal, eu acho que o VS2008 fez grandes progressos e penso que é um ótimo produto, mas --- basta dizer que o VS2008 utilizou muita memória para fazer o mesmo trabalho que o VC98.
Sim, é claro que o VS2008 pode fazer mais que o VC98, mas seriamente, eu acho que pode ser melhorado. Lembrar que eu estava cercado pelo C6.0, eu tenho uma boa memória :)
Quando questionado sobre o desenvolvimento do Visual Studio 64-bit, Rico respondeu:
Às vezes as pessoas dizem que devíamos ir para solução de 64 bit para obter a escala que precisamos. Eu acho que isso é errado, acho que precisamos é usar menos memória e não mais memória, acho que nos temos algoritimos non-lazy dentro de alguns lugares principais e precisamos tratar deles. Estou pressionando para isso. Eu não quero agir como se nós tivessemos mais memória -- se fizermos issos poderemos estar avançando na direção errada. Mas nós precisamos fazer um plano para o 64 bit e isso é algo para um outro posting.