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.
