O padrão "Idiota Útil"

Ontem eu estava em casa mexendo em um projeto pra fazer um Wiki. Aí tive um problema qdo estava tentando renderizar uns links. Fiquei ontem o tempo todo olhando para o código e imaginando soluções, fui dormir pensando no problema, acordei e vim trabalhar caminhando e pensando no problema. Foi então que me veio o estalo e a solução apareceu, de maneira óbvia e elegante. Qdo cheguei no trabalho, todo feliz, expliquei pra um colega o problema em linhas gerais. Qdo terminei a explicação ele me veio exatamente com a mesma solução que eu passei horas e horas pensando... :p Frustrante! Aí fiquei imaginando: 1 - Ou eu sou muito estúpido e o cara é muito inteligente (ele é, de fato, por consequência, devo ser um estúpido :p ) 2 - Ou qdo eu expliquei o problema já induzi a solução que eu tinha pensado (provável) 3 - Ou qdo o problema é visto de fora, fica mais simples. A opção 3 ficou martelando na minha cabeça, pq eu lembro que ontem passei boa parte do tempo só pra decidir em qual parte do código deveria modificar. Acho que qdo expliquei o problema sem entrar em detalhes de código, a solução ficou mais óbvia. Então eu senti, na prática e na pele, porque o padrão "Idiota Útil"* é tão bom pra resolver problemas. Vou fazer mais uns testes, mas acho que vou adotar o "Idiota Útil"* sistematicamente daqui pra frente.

---

* "Idiota Útil" (batizado pelo grande desenvolvedor e "cara de curtição" Cláudio Teixeira) - pra quem não sabe, é quando vc está com um problema e explica pra alguém, aí o cara pra quem vc está explicando nem sequer abre a boca e vc pára: "Pode deixar, valeu! Já achei a resposta".

Wish List para a linguagem ideal (revisada)

Wish List atualizada, novos itens em negrito Será que Python atende tudo isso?

   
1. Closures.
   
2. OPCIONALMENTE tipada. Isso mesmo, nem dinâmicamente tipada nem estaticamente tipada, quero usar tipo qdo eu quiser. E mais, por conta disso tem que aceitar polimorfismo local.
   
3. Biblioteca decente para Coleções com suporte a Closures e uniformidade de métodos entre as coleções.
   
4. Suporte a slice nas coleções (subcoleções) e em arrays e similares.
   
5. Reflexão simples e funcional.
   
6. Puramente Orientada a Objeto. Classes tb tem que ser objetos.
   
7. Suporte a Expressões Regulares no padrão PERL, de preferência com muito açúcar sintático.
   
8. Suporte a slice em Strings, aliás, melhor, Strings com mesma interface que Array.
   
9. Biblioteca para Arquivos simples e funcional, PRINCIPALMENTE com facilidades para trabalhar arquivos texto. Nada de open - close, deve trabalhar com closures (padrão "during" do Smalltalk). Serialização opcional em CSV e XML tb ia ser legal.
   
10. Biblioteca para Banco de Dados simples e funcional. Também que ser capaz de trabalhar com closures naturalmente. Nada de open - close tosco, usar novamente o padrão "during" do Smalltalk.
   
11. Biblioteca para Rede simples e funcional. Suporte a closure, serialização e desserialização automática de qualquer objeto. Sockets do Java são um bom começo.
   
12. Suporte descente a Threads. A nova biblioteca do Java 1.5 parece boa, mas, adicionalmente, deveria ter uma estrutura especial de linguagem para indicar instruções que eu posso executar em paralelo daquelas que eu sou obrigado a executar sequencialmente. O trecho em paralelo tem que terminar todo antes de prosseguir para a próxima instrução sequencial. A JVM ou equivalente deveria aceitar um parâmetro de quantas paralelizações no máximo ela aceita e qdo esse limite chegar, executar sequencialmente as instruções que estão marcadas como "executáveis em paralelo". Se quiser ter uma boa idéia do que estou falando, veja as tags "sequential" e "parallel" do ANT.
   
13. Suporte MUITO simples e funcional a XML e processamento XSLT.

Wish List - A Linguagem Ideal

Aqui vai minha lista de características para uma linguagem de programação ideal, por ordem de importância.

   
1. Closures.
   
2. OPCIONALMENTE tipada. Isso mesmo, nem dinâmicamente tipada nem estaticamente tipada, quero usar tipo qdo eu quiser. E mais, por conta disso tem que aceitar polimorfismo local.
   
3. Biblioteca decente para Coleções com suporte a Closures e uniformidade de métodos entre as coleções.
   
4. Reflexão simples e funcional.
   
5. Puramente Orientada a Objeto. Classes tb tem que ser objetos.
   
6. Suporte a Expressões Regulares no padrão PERL, de preferência com muito açúcar sintático.
   
7. Biblioteca para Arquivos simples e funcional, PRINCIPALMENTE com facilidades para trabalhar arquivos texto. Nada de open - close, deve trabalhar com closures (padrão "during" do Smalltalk). Serialização opcional em CSV e XML tb ia ser legal.
   
8. Biblioteca para Banco de Dados simples e funcional. Também que ser capaz de trabalhar com closures naturalmente. Nada de open - close tosco, usar novamente o padrão "during" do Smalltalk.
   
9. Biblioteca para Rede simples e funcional. Suporte a closure, serialização e desserialização automática de qualquer objeto. Sockets do Java são um bom começo.
   
10. Suporte descente a Threads. A nova biblioteca do Java 1.5 parece boa, mas, adicionalmente, deveria ter uma estrutura especial de linguagem para indicar instruções que eu posso executar em paralelo daquelas que eu sou obrigado a executar sequencialmente. O trecho em paralelo tem que terminar todo antes de prosseguir para a próxima instrução sequencial. A JVM ou equivalente deveria aceitar um parâmetro de quantas paralelizações no máximo ela aceita e qdo esse limite chegar, executar sequencialmente as instruções que estão marcadas como "executáveis em paralelo". Se quiser ter uma boa idéia do que estou falando, veja as tags "sequential" e "parallel" do ANT.
   
11. Suporte MUITO simples e funcional a XML e processamento XSLT.

Obs: Qdo digo SIMPLES, quero dizer SIMPLES DE USAR, não que o suporte seja limitado. SIMPLES DE USAR é conseguir executar 80% das operações mais comum em apenas uma linha. É isso aí, aparentemente as linguagens de script que estão crescendo por aí atendem boa parte da minha lista de desejos. Preciso ver em especial Python e Ruby. O Groovy já atende muitos dos requisitos, mas ainda tem uns bugs. Smalltalk atende a maior parte da lista, mas peca um pouco por falta de bibliotecas.

RUP e outros bichos

Estava lendo uns artigos e comecei a pensar novamente sobre RUP (ou UP pra quem gosta, mas pra mim sempre vai ser coisa da Rational). Sabe, depois de um tempo, comecei a achar que RUP não estava ajudando muito, mas não sabia exatamento o porquê. Hoje eu tive uma boa idéia do motivo. Acredito que RUP erra o alvo duas vezes: 1 - Ele não trata absolutamente nada sobre código, mas é o código que, de fato, constrói o programa. 2 - Ele não trata nada sobre estimativas e prazos, delegando isso para outros. E prazo é essencial para qualquer projeto de qualquer coisa, não somente software. Caricaturando: "RUP é tudo sobre nada que importa".