Essa experiência de acender a lâmpada é sempre a mais prazerosa em qualquer campo e acho que ficar limitado em uma linguagem acaba coibindo isso. E é sempre bom poder ver o outro lado para ver se sua forma é vantajosa e como ela pode melhorar.

—

Akita, boa indicação. Aliás, alguém precisa urgentemente começar a traduzir esses títulos para o português. Acho que o mercado está pronto.

—

Witaro, sim! Eu comecei a escrever um comentário meio nessa linha e acabei arquivando aqui para completar em outra hora.

Eu sou meio que um defensor da hipótese Sapir-Whorf em sua forma mais plena embora tenha consciência de que ela não é completamente válida como uma lei geral. Para linguagens de programação, principalmente, acho que ela é essencialmente válida (os programadores Ruby é que estão se deleitando com isso ultimamente). Essa analogia de mágica acaba então fazendo um sentido enorme para descrever o processo. Depois tenho que pensar mais nisso.

—

Luiz, isso! O pessoal do Ruby está até abusando disso ultimamente mas eu acho bem válida dentro dos contextos corretos. Só não defendo completamente porque linguagens naturais são um pouco menos “analisáveis” nesse sentido. Mas, de certa forma, seu jeito de programador é intrinsecamente ligado com a linguagem. Daí a tendência de se fixar em um paradigma e não conseguir pular sem esforço.

—

Silfar, não é muito complicado.

O maior problema é que quando você estudo só um paradigma, você fica preso no mesmo em todas as suas soluções. Daí eu acho que não adianta muito ficar em Perl, Python, Ruby, PHP. São todas linguagens parecidas que não acrescentam muito à sua caixa de ferramentas.

O interessante, nesse sentido, seria partir para um estudo sério de uma linguagem bem fora do que você conhece como Lisp, Haskell ou Smalltalk. Essa última é imperativa mas suficientemente diferente das usuais para valer um estudo melhor.

Pensar e implementar o CodeKata[1] em uma dessas linguagens já daria um impulso a essa mudança. E depois disso é só uma questão de evoluir gradualmente.

[1]: http://codekata.pragprog.com/

Mas a questão é que não fui sempre assim, quando tive o meu primeiro contato com programação em cobol, dbase e depois clipper, eu conseguia resolver problemas de formas que surpreendiam até aos professores.

Mas em algum ponto eu estagnei, parei no tempo, e hoje tenho uma dificuldade enorme de compreender certas coisas que não sejam com exemplos.

Mas a questão mais importante é, já que o problema foi exposto, como resolver ?

Será que tem como, sair da estagnação e voltar a ser “criativo” ?

Se alguem souber, me diga.

Eu também defendo essa idéia. Acredito que conhecer diversas linguagens, mesmo que parecidas, abre a cabeça. Permite enxergar soluções diferentes para um mesmo problema e isso é bem estimulante (ou pelo menos, deveria ser).

Outra leitura recomendada sobre um tema relacionado (mas não o mesmo) é o “Software Craftsmanship” do McBreen.

Excelente texto! Parabéns!

Lendo seu texto me vem à mente a época que eu estava aprendendo a progrmar (com Delphi em Object Pascal) e que cada nova descoberta da forma de resolver um problema “acendia uma lâmpada” e uma nova abordagem para um problema seguinte era pensada.

Aprender com o erro, e com o trabalho de outros também é uma boa forma de “ter estalos” para soluções, mas têm-se que tomar cuidado para não tornar a solução uma mera cópia.