Rodrigo Strauss :: Blog

Não sou o único na contra mão do MsMarketing

Pérola que eu li em um newsgroup um dia desses: "Não sei como, nos dias de hoje, ainda existem pessoas que escrevem uma nova aplicação Windows usando Win32 ou MFC ao invés de usar Windows Forms". Como eu sei que existe uma imensa massa de programadores que definitivamente não sabem o que falam, eu resolvi não discutir. Já ouvi tantas pessoas que acreditam que qualquer coisa pode ser feita em .NET, que hoje em dia eu prefiro não discutir e continuar com o meu Visual C++.

O primeiro problema disso é a definição de conceito e o entendimento da arquitetura das coisas. Falar que não usar Windows Forms não faz sentido é completamente sem sentido, já que o Windows Forms não passa de um wrapper sobre a Win32 API. Além disso, a MFC não passa de outro wrapper para a Win32 API, só que com mais de 10 anos de mercado e MUITO mais maduro do que o Windows Forms (que ainda tem vários bugs). Eu sempre achei o Windows Forms aquém das minhas expectativas para desenvolvimento de aplicativos Win32, mas acredito que a escolha da ferramenta sempre deve ser feita com calma e pesando todos os fatores, como experiência, tempo para desenvolvimento e alcance do aplicativo. É inviável fazer um aplicativo para download em .NET, já que só a runtime dá uns 25 MBs. (Não me venha com esse papo de que isso está melhorando, que mais pessoas tem o Framework instalado, etc. A grande maioria da base instalada não tem Framework e nem sabe o que é isso).

Semana passada encontrei mais algumas pessoas que compartilham da minha opinião. A primeira é a equipe que desenvolveu o newsreader Sauce. Ele foi totalmente desenvolvido em .NET, como muitos dos leitores RSS que existem hoje. Depois de não conseguir fazer o aplicativo ficar mais rápido e consumir menos memória, eles decidiram abandonar o .NET e refazer em "old unmanaged code". A nova versão ainda está em beta, mas é bem mais rápida do que a versão .NET e consome metade da memória. Fiz algumas medições entre a versão .NET e nativa (feita em C++ Builder, Delphi ou Kylix), e como dados concretos valem mais do que c palavras, vamos a eles:

Tempo de inicialização
.NET	Nativo
36	6
25	2
12	1
16	5
Consumo de memória (Private Bytes)
.NET	Nativo
45.492 KB	24.144 KB

O argumento que todos os .NETers sacam assim que são "atacados" é que a aplicação usada não foi bem escrita, que não segue os best practices de alocação de memória, não usa corretamente IDisposable, bla, bla, bla. Se é tão difícil assim fazer uma aplicação com boa performance e consumo de memória razoável em .NET, é melhor continuar usando C++. Pelo menos em C++ a regra de alocação/desalocação de memória é clara, e não depende de saber quem precisa ou não de Dispose(). Além disso, tem o argumento barato de que as máquinas vão ficar mais rápidas, que a memória vai ficar barata, que o Bush vai recobrar a sanidade algum dia e que em um futuro não muito distante todos os micros terão Framework instalado. Eu desenvolvo aplicativos hoje, para clientes de hoje, que têm máquinas de hoje. Eu acho que o Windows Forms vai ficar muito melhor no futuro (Avalon), mas não posso viver lidando com coisas em fase experimental e SOs que ainda estão em alpha. Quem já tem experiência no mercado sabe que a migração para o Longhorn - ou a instalação da runtime do Avalon em todas as máquinas - deve demorar alguns anos.

Outra pessoa que compartilha da minha opinião chama-se Mark Russinovich. Para quem vive em outro mundo e não o conhece, ele além de escrever os programas do site SysInternals é o escritor do livro Windows Internals, a bíblia sagrada da arquitetura Windows. Ele escreveu um post sobre isso, e como esperado, foi impiedosamente atacado pelo cardume de Piranhas.NET. Devido ao grande número de comentários negativos, ele explicou novamente o que já tinha explicado e as Piranhas.NET não tinham lido. Compartilho da mesma opinião: .NET é bom para componentes e maravilhoso para Web (ASP.NET é muito bom). Mas Windows Forms aumenta muito o consumo de CPU e memória sem trazer grandes vantagens (traz até alguns problemas). E wrapper por wrapper eu prefiro meu WTL. :-)

Em 23/05/2005 19:31, por Rodrigo Strauss

Comentários