O que é preciso para DSLs?

(Se vc não sabe o que é DSL, Akita explica... se quiser uma discussão aprumada e ajeitada sobre o assunto, dá uma olhada no que diz o tio Ronaldo) Alguns dizem que Smalltalk, Ruby e Lisp são boas linguagens para criar DSLs. Mas Java, C# e afins não são tão boas? Por quê? Depois de ler um tanto e experimentar mais outro tanto, acredito que para criar DSLs internas (veja o que diz Martin Fowler sobre DSLs internas e externas), uma linguagem precisaria dos seguintes items:

1. Reflexão(de verdade), ou seja, capacidade de inspecionar e alterar suas próprias definições em tempo de execução - DSL normalmente envolve criar e inspecionar código, e sem reflexão decente não dá pra fazer metaprogramação
2. Metaprogramação, ou seja, código que gera código - Muito da DSL na verdade é fazer com que pouco código faça muita coisa, às vezes de maneiras pouco convencionais. Para isso sua linguagem precisa conseguir criar código "on the fly" sem grandes maracutaias, porque afinal, você já vai estar fazendo maracutaias, aí a metaprogramação fica maracutaia ao quadrado :p
3. Closures (ou lambdas) - Permitir passar blocos de código pra cima e pra baixo são essencias para você codificar em um ponto e poder executar em outro, normalmente após preparar o terreno para a execução da closure
4. Sintaxe flexível - Não é essencial, mas ajuda a vc criar uma DSL simples. Sintaxes rígidas limitam a maneira com a qual você pode se expressar nas DSLs e elas acabam ficando mais complicadas sem necessidade. Um exemplo desse princípio é a tal da "interface fluente". Sem um sintaxe flexível, ela fica meio canhestra.
5. Classes abertas - Isso é uma extensão da "Reflexão", na verdade é permitir que você possa redefinir tipos básicos como String, Integer e outros. Se você olhar a tal da "interface fluente" vai ver que com classes abertas ficaria bem mais fácil criá-las

Tem gente que acha que uma linguagem de programação que permita essas coisas deveria ser queimada, triturada, empalada e que todos que programam nela são hereges que deveriam queimar no Inferno de Knuth. No final, tenho uma teoria (grandes coisa minhas teorias, mas como o blog é meu, vou postar). Tenho a teoria que, na verdade, Orientação a Objeto é uma maneira de criar DSLs internas, mas sem que pensemos em termos de linguagem. Toda boa API OO me lembra muito DSLs. Acho que nosso trabalho é puramente criar abstrações, quanto melhores, mais somos produtivos e menos dores de cabeça temos. Em um texto, as abstrações são tão maiores quanto mais técnico é o texto, onde uma única palavra (por exemplo: "Façade") abstrai uma idéia um bocado complexa. Do nosso lado, criar classe, métodos e refatorar código é basicamente melhorar as abstrações. Estou certo? Estou errado? Não importa muito, isso é mais retórico do que prático, no final. Mas esse tipo de pensamento muda um pouco minha maneira de encarar o que eu aprendo de novo... Editado: um "PS" aqui... esse artigo estava rascunhado no meu blog faz quase um ano... tou ficando velho e preguiçoso, e talvez um pouco lelé...

Desgaste de informação

Hoje me deparei com uma situação que todo mundo passa, conhece, mas parece que ninguém toma medidas para conter o problema: quanto mais gente no meio entre a fonte de informação e o utilizador (EU!), pior a informação vai ficando. Cliente pede uma feature -> Relacionamento com cliente repassa para Gerente de projeto -> Gerente de projeto passa para Analista -> Analista passa para desenvolvedor. Nesse caminho, o que o cliente pediu já foi interpretado de maneiras diferente QUATRO vezes (Relacionamento, Gerente, Analista e Desenvolvedor). Em cada interpretação a informação sofreu um certo desgaste, detalhes se perderam e o pior: detalhes que podem ser irrelevantes foram adicionados. Esse é de longe o maior problema da informática, depois da comunicação falha (que é relacionada, mas não é a mesma coisa). Alguém sabe se existe alguma área que estuda o que acontece com a informação?