Convention over Configuration é uma filosofia que Rails tornou famoso, mas infelizmente nem sempre podemos nos dar ao luxo de usar convenções para tudo. Usar XML como grude está fora de questão. Precisamos de uma mini-linguagem. Precisamos de um compilador. Não, mas isso também é complicado. Em Ruby a saída para isso é usar sua capacidade de linguagem dinâmica e capaz de criar DSLs.
Para dar outra perspectiva, traduzi um artigo da SDTimes de Allen Holub, um arquiteto, consultor e instrutor de C/C++, Java e Design OO. Ele faz um pouco de marketing-pessoal no fim, mas seus argumentos são os mesmos que digo às pessoas há tempos. Ele traduz alguns dos pontos que considero que todo bom programador deve ter. Segue a tradução:
XML é talvez a pior linguagem de programação já concebida. Não estou falando de XML como uma linguagem de descrição de dados, que era seu design original. Estou falando de perverter XML para programar aplicações. É inapropriado usar XML como uma linguagem de script (ex. ANT), uma linguagem de descrição de testes (ex. TestNG), uma linguagem de mapeamento objeto-relacional (ex. Hibernate, JDO), uma linguagem de controle de fluxo (ex. JSF), e assim por diante. Esses tipos de “programas” em XML são ilegíveis, impossível de dar manutenção, ordens de magnitude maiores do que o necessário e audaciosamente ineficientes em tempo de execução.
Então, porque alguém usaria XML nessa maneira bizarra? Até onde posso ver, é porque muitos dos chamados programadores simplesmente não sabem como construir um compilador. Realmente não tenho muita paciência para esse tipo de coisa. Na minha mente existe um conjunto mínimo de tópicos que você precisa ser fluente para se chamar um programador profissional. Se não sabe essas coisas, você é um diletante. Essa lista inclui conhecimento profundo de estrutura de dados e algoritmos chaves, um pouco de matemática (teoria dos conjuntos, um pouco de estatística), ser mestre em técnicas de análise-e-design, ambos processo (ex. RUP ou XP) e estrutura (ex. design patterns), e estrutura e uso de banco de dados (ex. SQL). Você também precisa saber como o hardware funciona.
Você precisa dessas coisas mesmo que não esteja usando realmente em seu trabalho, porque não importa o que está fazendo, saber esse material tornará seu trabalho melhor. Como você pode decidir qual das classes Collection do Java usar em uma certa situação se não souber como cada classe trabalha por baixo dos panos, por exemplo?
Saber como se constrói um compilador é certamente uma das habilidades nessa lista. Compiladores são fundamentais para o que fazemos todos os dias como programadores. Saber como o compilador trabalha o fará tomar decisões inteligentes sobre a estrutura do programa, decisões que tem impacto real na qualidade de seus programas. Mais ao ponto, a maioria dos programas tem que quebrar dados de entrada (input parsing — tanto para um ser humano quanto para um máquina) e dar sentido a isso. Para fazer isso, você tem que construir um pequeno compilador. Corromper XML para esse propósito, simplesmente porque acontece de você ter um parser XML ao redor, é inapropriado, para dizer o mínimo.
Basicamente você está egoistamente fazendo sua vida mais fácil ao enorme custo de outra pessoa. Para cada hora que você salva, está submetendo cada um dos seus usuários a muitas horas desperdiçadas com uma coisa de complexidade excessiva, difícil de aprender, difícil de dar manutenção, impossível de ler, chamada lixo-baseado-em-XML. Essa não é a melhor maneira de fazer amigos e influenciar as pessoas.
Aprender como construir compiladores é, infelizmente, muito difícil. O livro mais usado, de Acho, Sethi e Ullmans, “Compilers, Principles, Techniques and Tools”, é um exemplo clássico de tudo que é errado com literatura acadêmica. Sua completa, mas impenetrável, cobertura do assunto oferece virtualmente nenhuma informação prática. Os acadêmicos adoram, mas eu recomendaria evitar esse livro a menos que você tenha um forte background matemático e está mais interessado na matemática por baixo do que na aplicação prática.
Em contraste, “Programming Language Processors in Java: Compilers and Interpreters”, de Watt e Brown, é uma ótima introdução prática ao assunto. Os autores usam um estilo de aprenda-fazendo, apresentando códigos-fonte completos para um compilador e interpretador em Java. Embora esse livro seja provavelmente a melhor introdução a compiladores para programadores Java, o Java em si não é particularmente bem feito.
Java é muito procedural (usando muitos campos públicos, por exemplo), não usa polimorfismo particularmente bem, usa excessivamente variáveis com nomes de um caracter apenas e outra coisas ruins. Enquanto você mentalmente separar os tópicos de compilador com as coisas de Java e não usar Java como um modelo de uma boa prática de programação, então o livro é ótimo.
“Constructing Language Processors for Little Languages”, de Kaplan, é outra boa introdução com muito código nele (infelizmente em C++).Falando nisso, meu próprio “Compiler Design in C” também tem muito código, mas obviamente tudo em C, não Java. Meu livro mostra não somente como construir um compilador, mas também como construir as ferramentas que precisará para construir um compilador (eu dou implementações completas de lex e yacc). Quando acabar de aprender e mudar para a mão na massa, existem algumas ferramentas disponíveis para ajudá-lo a construir compiladores, a maioria software livre.
The Catalog of Compiler-Construction Tools é um grande compêndio de todas as ferramentas que conheço. Não há muita razão para olhar esse site a menos que já tenha lido um livro sobre o assunto antes, mas quando tiver lido, será um grande recurso.