Tive uma conversa muito boa com um amigo, Victor Benjamin. A atual troca de emprego o deixou motivado, o que serviu de combustível para a convera, parabens pela nova estapa Victor.
Bem, na conversa falamos sobre o que o Java tem de bom, de ruim e o que não queremos nem falar. Como somos pessoas curiosas, temos visto algumas outras linguagens e ambientes, mas acredito particularmente que não exista a linguagem certa para todo o tipo de caso. Como dito em outros blogs, o importante é código funcionando.
Estou com um trabalho pessoal em curso, usando Java, separado em camadas implementando o máximo possível de DDD e uma coisa é certa: escrevemos muito. Para cada camada deve-se ter uma interface que define os métodos, a implementação, os testes unitários, as fabricas, os DTOs, etc. Não estou dizedo que é ruim, estou dizendo que codificamos muito. Apenas contando, um sisteminha de cadastro bem separado para Cliente, Produto e Compras precisa de pelo menos 3 Interfaces de definição para cada serviço, suas respectivas implementações, 3 Repositórios, um para cada classe, e separando a camada física, 3 DAOS, mais as classes de domínio e os DTOS. Somado isso estamos falando de uns 20 arquivo diferentes para 3 cadastros, parece um número um pouco auto.
Outro projeto pessoal que está na pauta, devo voltar a colocar a mão nele tão logo sobre tempo ou o dia passe a ter 36hs, está sendo feito em Ruby on Rails. Não da para comparar pedra com laranja, por isso não vou tentar comparar os dois universos, mas o tempo de codificação é muito pequeno. Praticamente, em um dia todo o cadastro estava pronto, foi ai que parei. A linguagem é ótima, fácil de usar e clara, o Rails tem suas peculiaridades, mas não é de todo mau.
Na empresa estou num projeto em Delphi, não é o ceu, na verdade é perto do purgatório. A linguagem é antiga e não tem muito dos facilitadores que as novas possuem mas, ainda assim, da para se fazer muita coisa legal. Uma das coisa que há em Object Pascal (iach) é o conceito de property, um modificador que permite um nível de get/set. O trecho de código abaixo exemplifica o property, basicamente ele esconde o get e o set que poderá ser definido no futuro, se necessário, sem alterar o código que o chama.
Cliente = class()
private
_nome : String;
_idade : integer;
function getIdade() : Integer;
procedure setIdade(idade : integer);
public
property nome : String read _nome write _nome;
property idade : Integer read getIdade write setIdade;
end;
O objetivo dessa discursão é mostrar que cada linguagem tem o seu "sintax sugar", que um ou outro programador irá gostar, mas o que importa não é isso, o que importa é código funcionando. Uma das premissas do manifesto ágil é essa. Se você está trabahando em um sistema de cadastro para uma campanha publicitária qualquer, não irá precisa se preocupar em fazer o sistema de tal modo que rode até em um palm (modularizando, usando WebServices e EJBS, etc..). A questão é o foco, o que você precisa, em quanto tempo e o que você sabe.
Olá Diego. em primeiro lugar, parabéns pelo blog, como sempre um conteúdo muito interessante. Concordo com você quando diz que nao existe linguagem certa em para todo tipo de caso. Na verdade, quem diz o que lhe é mais apropriado é você mesmo, o próprio desenvolvedor, uma vez que a limitação tecnológica não o atrapalhe, claro. E quando se obtém esse ponto de vista, fica cada mais gostoso e atrativo desenvolver uma aplicação até mesmo para teste sobre uma linguagem ou apenas por fazer mesmo, desenvolver deixa de ser, sob alguns aspectos, uma atividade massante, e passa a ser um bom programa de final de expediente(claro, se você for solteiro,rs). E quanto ao objeto Property do Delphi, o mesmo acontece em VB .NET: temos um property que define gets e sets de para os objetos em questão.
ResponderExcluirAbraços