Embora, no geral, a série The Sword of Truth seja uma boa leitura, a qualidade dos livros individuais varia enormemente. Particularmente, eu considero o quinto livro, Soul of the Fire, um dos piores da coleção. O final deus ex machina não ajuda em absolutamente nada uma estória que já é desapontadora em si mesmo. O que torna o fato de que o sexto livro da série é melhor ainda mais incompreensível. Mas eu estou me desviando do assunto.
No final desse livre, Richard, o herói, descobre que para resolver uma determinada situação ele precisa não somente aplicar o seu conhecimento de mágica, mas criar uma nova forma de mágica.
Mágica e programação (ou tecnologia) sempre foram um ponto de comparação. Da terceira lei de Clarke–”qualquer tecnologia suficientemente avançada é indistinguível de mágica”–a livros onde o personagem principal é um programador manipulando não código mas feitiços, a comparação permeia a indústria.
O Jargon File, o conhecido dicionário de termos da cultura geek compara a programação à mágica, ou termos similares, pelo menos 50 vezes em suas páginas–algo sobre o qual eu, inclusive, escrevi um pouco aqui alguns anos atrás.
O que me leva a pensar que o exemplo de criação versus aplicação de mágica é particularmente apto para a programação. Um bom programador não é somente capaz de aplicar o conhecimento que possui, adquirido pela experiência, mas ele também é capaz de criar novas formas de resolver problemas.
Com isto, é claro, eu não estou falando que cada programador precisa ser um Donald Knuth ou um Edsger Dijkstra que, em cada artigo publicado desbravam ou desbravavam novos campos de teoria e prática da ciência da programação. Mas, em uma certa medida, um programador só pode ser considerado um excelente programador se ele é capaz de extrapolar além de seu conhecimento básico e pensar em novas soluções para os seus problemas.
Algumas vezes, isso implica em descobrir algo que já foi inventado. Mas o processo de raciocínio por trás da descoberta é suficiente, muitas vezes, para abrir uma série de novas perspectivas.
Infelizmente, isso é algo que poucas vezes se vê no campo. Eu meus quase 15 anos de experiência na área, eu já vi dezenas de programadores que são incapazes de programar alguma coisa a menos que um exemplo lhes seja fornecido. Eles são excelentes em copiar e utilizar o que outros programadores fornecem, mas se a solução necessária estiver fora do âmbito de suas experiências, nada no mundo os fará conseguir a solução.
Um dos sinais típicos desse tipo de programador é o programador de uma linguagem só–aquele programador que pode até saber um pouco de outras linguagens mas só tem um conhecimento razoavelmente sólido em uma única linguagem.
Atualmente, com o enorme hype em cima do Ruby, uma nova geração desse tipo de programador está nascendo. Programadores que só conseguem pensar em termo de Ruby–ou pior, em termos de Rails–e se confrontados com outro tipo de escopo de problema, se escondem por trás das características mais básicas da linguagem. Não que isso não tenha acontecido com Java ou C# ou qualquer outra linguagem de massa. Ruby só calha de ser a linguagem da hora.
O fato é que se você só conhece Ruby–ou Java, ou C#–você não pode ser considerado um programador completo. A programação plena requer uma comparação de paradigmas que é impossível de obter em uma linguagem só.
O mesmo vale para a criatividade. Programadores que se restrigem–por opção–a uma única linguagem não tem recursos para comparar soluções em outras linguagens e isso os torna menos eficientes.
Um exemplo notório disso foi o recente interesse despertado por Tim Bray em cima de um simples problema de análise de logs que ele intitulou Wide Finder. Basta analisar as soluções e verificar que as melhores implementações foram feitas por aqueles programadores capazes de trabalhar amplamente com várias linguagens substancialmente diferentes.
Criatividade é o que distingüe um bom programador de um programador medíocre. E isso só é conseguido com uma espécie de generalização no campo. Se limitar a uma única linguagem ou tecnologia, por mais interessante que ela seja, não vai lhe dar qualquer ponto novo de apoio. Inovação real depende de criatividade e qualquer projeto cujo alvo seja inovar precisa desse tipo de generalização.
Sendo assim, escolha sua estratégia e seja criativo. Eu vou evitar o clichê e não dizer nada do tipo, “do contrário você, etc”. Você sabe muito bem o que vai acontecer.
Fala Ronaldo,
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.
Muito bom, é exatamente isso que eu canso de dizer o tempo todo. É como um pintor que só sabe usar um pincel. Ou um músico que só conhece uma nota.
Outra leitura recomendada sobre um tema relacionado (mas não o mesmo) é o “Software Craftsmanship” do McBreen.
Falando não apenas de programação, mas também… Linguagem é Magia. Magia é linguagem. E uma Realidade nada mais é do que uma malha (possivelmente de várias camadas) de um sem número de linguagens se relacionando. Para saber transformar uma realidade é preciso saber dialogar com ela. Criativos são aqueles que conseguem assumir um papel de co-criação dessa malha. Então, quanto mais linguagens pertinentes a uma realidade alguém souber (ou descobrir), maior seu potencial criativo nela… Exemplos dessas “linguagens”? É só imaginar domínios e/ou meta-domínios das mais diferentes áreas de nossas vidas e lembrar que seus “tokens/símbolos” podem ser constituídos dos mais diferentes materiais…
E a gente volta para a hipótese de Sapir Whorf.
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).
Concordo plenamente, tanto que até me reconheci como um desses “maus programadores”.
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.
Opa, Rafael, obrigado pelo elogio.
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/