Que princípios guiam as tecnologias?


Quem é melhor tecnologicamente? .Net ou Java? Ruby? Php? ... Quem?


Sei que estou me metendo num assunto polêmico, mesmo aqui na Microsoft. Mas, como é uma pergunta frequente, vou dar minha visão.


Para este tipo de análise, não uso o estado atual destas tecnologias, mas as forças que as fizeram surgir e as que vão fazê-las se desenvolverem nos próximos anos.


Minha percepção é que .Net nasceu com alguns princípios fortes que ainda estão em curso:



  • Generalidade: É um ambiente que visa à produção de software de missão crítica para cenários que vão do software para workstation convencional à web;

  • Engenharia de Software: Ele foca em uma engenharia de software para programas grandes, daí a opção de usar tipos fortes, maximizando o erro em tempo de compilação, componentização e outros;

  • Simplicidade, sempre que isto não fira os princípios acima: isto é, sempre que possível o .Net oferece facilitadores, como editores drag-drop, intellisense, inferência de tipos (que é uma maneira elegante de tirar o ônus da tipagem forte sem remover seus benefícios), etc.

  • Multi-linguagem, sendo base para uma gama grande de linguagens (F#, Eiffel, etc.).

  • Acesso nativo à plataforma Windows e softwares de terceiros que habitam esta plataforma!

(é claro que existem questões como ser de alguma forma open ou não, custo, empresas por detrás das tecnologias, etc., mas não creio que estes pontos são reais diferenciadores dos caminhos destas tecnologias. Tais fatores impactam muito mais em questões como ecossistema, marketing, acesso, etc. do que com mecanismos linguísticos ou outro aspecto mais técnicos)


Se tivermos isto em mente, fica óbvio perceber que Ruby on Rails (correção - ver comentário) e Php não visam o mesmo cenário do .Net. Eles foram concebidos visando cenários mais focados (Web) e aceitam erros em tempo de execução.


Já no caso de Java, tenho dúvidas se os princípios da simplicidade e multi-linguagem são tão fortes quanto no .Net, mas tenho certeza que o princípio do “Acesso Nativo”não é válido – ele é substituído por “ser multi-plataforma”. Daí a dificuldade para obter o acesso a DLLs, ActiveX, COM+, etc.


São duas estratégias distintas com impactos distintos: Java irá tentar o mínimo múltiplo comum e/ou recriará parte da infra-estrutura com bibliotecas Java, mesmo que isto impacte no desempenho quando comparado a um código nativo. .Net tentará incorporar as novidades da plataforma e dos softwares de mercado tão logo possível, chamando API’s nativas ou utilizando protocolos padrão.


Multi-plataforma é um valor charmoso e atraente, mas nem sempre real. Muitas vezes (não tenho número de mercados) não será necessário mudar de plataforma ao longo da vida do aplicativo. Além disto, a virtualização é outra maneira de mitigar esta questão, o que, para muitos, tira um pouco da sua força.


São muitos os aspectos que fazem a escolha de um produto. Mas, a meu ver, são poucos os princípios de escolha que fazem as tecnologias percorrer caminhos tão diferentes.


Não cabe aqui dizer qual é a melhor, mas sublinhar as diferenças para que vocês façam a suas escolhas de forma consciente.


Em que princípios vocês apostam?


Comments (3)
  1. Olá Otávio,

    Bem interessante esse assunto: considerando o post anterior, onde você comenta que a escolha de uma plataforma envolve sim um certo nível de dependência e acomplamento, vi poucos cenários de migração entre plataformas. Nos casos que acompanhei, a solução por virtualização foi a escolhida, devido o menor impacto para a solução. Assim, soluções que nasciam em Solaris permaneciam em Solaris, soluções em OS/2 eram virtualizadas sobre Windows XP, ou aplicações sobre Linux eram virtualizadas no desktop clientes. O sentido contrário também acontece, claro 🙂

    Uma vez escolhida a plataforma, os recursos presentes para o suporte de funcionalidades do USER EXPERIENCE tornam-se importantes. Em muitos casos, a proximidade com o sistema operacional também é relevante devido questões de desempenho, menor codificação, maior aproveitamento das capacidades gráficas do hardware, ou mesmo interoperabilidade com outros serviços utilitários, como diagnóstico, monitoração, tratamento de exceções, etc.

    Determinar quais princípios são realmente importantes para a aplicação sem dúvida é o primeiro passo.

    []s

    Waldemir.

  2. viniciuscanto says:

    Olá Otávio,

    concordo com boa parte do que você comenta no post. Só uma pequena correção: Ruby != Ruby on Rails, e o primeiro não foi criado pensando em Web. Ruby é de 93 e Rails foi criado somente em 04. Ruby ficou famoso por conta do Rails, mas isso não faz dela uma linguagem pensada para web.

  3. Otavio says:

    Você tem toda razão, Vinicius.

    Ruby é uma linguagem genérica e tem raizes no Smalltalk e Perl.

    Ruby on Rails, por outro lado, é um framework para Ruby que o torna extremamente simples para programação Web. De fato, a linguagem Ruby começou a ficar famosa por causa do sucesso do Ruby on Rails. Creio que dai vem o meu deslize 🙁

    Assim, corrigindo, generalidade também está na raiz do Ruby!

    Obrigado por me chamar a atenção!

    Otavio

Comments are closed.

Skip to main content