Ambientes de desenvolvimento rápido suprimem os sintomas de impotência ao criar a ilusão de poder.
Corolário Weissmann sobre desenvolvimento
Aquela infindável discussão “minha linguagem de programação é melhor que a sua”, que nada mais é do que um reflexo de nossa infância “meu brinquedo é melhor que o seu”, devo confessar, sempre chamou minha atenção. Fico horas e horas me divertindo com estes tópicos. É quando me pergunto: uma linguagem de programação pode emburrecer um indivíduo? Cheguei a conclusão de que sim. E muito.
Quando fiz o curso de Filosofia, fiquei muito impressionado com o conceito de determinismo linguistico, ou seja, o fato de que a linguagem que usamos modela nosso pensamento. Alguns filósofos vão além. Wittgenstein, por exemplo, chega a afirmar (e eu concordo plenamente) que os limites do mundo (pode ser entendida aqui a percepção do mesmo) de um indivíduo correspondem aos limites de sua linguagem. Realmente, trata-se de um ponto válido visto que o mundo só recebe o nosso feedback a partir da nossa linguagem e vice-versa. Transmitimos ao mundo aquilo que captamos a seu respeito e em seguida processamos a partir de nossa linguagem.
E de onde vêm a nossa linguagem? Bem, esta é fruto do ambiente no qual estamos (ou seria algo intrínseco?). O ambiente influencia nossa linguagem. Há alguns exemplos hoje considerados banais, como o esquimó que consegue perceber n variações distintas do branco, que são refletidas em sua própria linguagem (há um nome para cada variação). Outro bom exemplo é o brasileiro: nós conhecemos diversos tipos de banana. Curiosamente, para um estrangeiro, todas as bananas são iguais. E nosso vocabulário expõe esta riqueza: banana nanica, caturra, etc.
O que me faz pensar na seguinte citação de Dijkstra: “the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery.“. No caso, esta frase foi dita na palestra “The threats to Computer Science”, que tratava do modo como a ciência da computação é ensinada nas faculdades. Aliás, atualmente há inclusive gente que usa um argumento bastante similar no que diz respeito ao Java.
A pergunta que se faz portanto é: pode uma linguagem de programação “mutilar” a mente de um desenvolvedor? Na minha opinião, sim. Em minha experiência, já vi diversos casos de desenvolvedores que criam coisas incrívelmente interessantes em Visual Basic mas não conseguem de modo algum sair desta linguagem. Até tentam aprender outras, mas sempre acabam voltando ao Visual Basic, o que justifica-se pelo fato de que trabalhar com algo com o qual já se está confortável é mais seguro.
Algo muito similar observo com Java. Visto a sua aplicação com sucesso em diversos ambientes distintos (móvel, desktop, web, etc.), muitas vezes o desenvolvedor fixa-se no Java e dele não sairá jamais. Assim como no caso do Visual Basic, trata-se novamente da mesma justificativa: “se já sei Java tão bem, por que me arriscar com outras linguagens ou ambientes?”. No caso do Visual Basic, a deficiência fica mais nítida pelo fato de ser uma linguagem ultrapassada. Neste sentido, quem programa em VB possui uma vantagem em relação a quem programa em Java. Há menos arrogância (“por que aprender outra coisa se Java já é uma linguagem de ‘ponta’?”), e portanto a necessidade de se aprender algo novo se torna mais nítido. Mas em ambos os casos, ambas as linhas de raciocínio levam em consideração apenas o medo de se tornar obsoletos tecnologicamente (mais especificamente, para o mercado), ignorando um problema que é ordens de magnitude mais sério: o determinismo linguistico.
O que nos leva a pensar no papel do desenvolvedor: espelhar/reproduzir/criar no ambiente computacional uma solução necessária no ambiente real. Ora, dado que, como já mencionei anteriormente, nosso mundo (percepção) é resultado de nossa linguagem, e as linguagens de programação são a nossa percepção do ambiente digital em que atuamos, o fato de conhecermos apenas uma linguagem de programação contribui para que nosso raciocínio criativo torne-se também limitado. Pior ainda se a única linguagem que conhecermos nos apresentar uma descrição limitada deste ambiente.
Focar-se em uma única linguagem consiste em ignorar o porquê de sua criação: resolver problemas presentes na época de sua introdução. São linguagens de uso geral? Sim, com certeza. Neste caso, não deveriam nos dar uma visão ampla? Com certeza, porém foi criada visando também superar algumas das limitações presentes em sua época de desenvolvimento. Se não fosse assim, existiria hoje provávelmente uma (no máximo duas) linguagem de programação. Logo, o argumento de que “aprender outra linguagem é trivial, pois só muda a sintaxe” mostra-se como falacioso.
Para ilustrar o raciocínio, irei expor de modo fenomenologico o desenvolvimento de um profissional fictício. Este profissional começará sua carreira com o Visual Basic 6, o que ilustra muito bem o comportamento que já observei com alguns profissionais. Escolhi o Visual Basic 6 só por se tratar de um ambiente de desenvolvimento rápido (outros poderiam entrar em seu lugar portanto).
Num primeiro estágio, todo software é composto por uma série de formulários a partir dos quais o usuário envia seus dados e então, através de uma série de eventos, faz o que deve fazer. Não há muita preocupação com módulos ou algo similar. Apenas com os eventos. O trabalho consiste basicamente em agrupar componentes em uma janela, incluir os eventos necessários, compilar a aplicação, entrega-la ao cliente e, conforme o tempo for passando, ir dando manutenção no produto final.Com o passar do tempo, a complexidade do software aumenta. Isto fica nítido a este profissional pelo número de formulários criados. São diversos, e em diversos momentos, ocorre a necessidade de se copiar código de um formulário para outro. Quando o uso do famigerado Control-C/Control-V começa a dar muito trabalho a este desenvolvedor, ele começa a perceber que programar realmente é algo “difícil”.
É quando o usuário passa para o segundo estágio. Surgem os famosos módulos. Neles é possível incluir todo aquele código que até então era copiado de um formulário para outro. Fantástico! Agora basta referenciar estes métodos nos formulários e pronto. O trabalho diminuiu.
O tempo passa e a aplicação continua crescendo. Desta vez, o cliente quer que o sistema se comunique com clientes externos. Já tenho módulos, o que facilita, no entanto, um novo paradigma surge. A web. Como a web funciona? O que devo fazer?
Neste exato momento, o profissional trava. Gastou tanto tempo pensando no desktop que ao se deparar com a web, pelo fato de sua linguagem favorita não lhe oferecer suporte fácil a este novo paradigma, simplesmente não sabe nem por onde começar. “Engenharia de software? Coisa pra gente besta. Há até alguns recursos no Visual Studio. Um tal de ASP… Lembra muito o VB. Será que eu uso ele? HTTP? Que é isto? Eu poderia também procurar algum componente que resolva meu problema…”
Chega-se a seguinte solução: “vou disponibilizar o banco de dados para eles. Assim, eles enviam seus dados aqui pra dentro de acordo com as regras que eu venha a definir e pronto. Problema solucionado. Sou um gênio!”
Lógicamente, a solução irá se mostrar um fracasso. É quando este profissional é expulso do segundo estágio de evolução e aprende outra linguagem de programação. No caso, Java.
Terceiro estágio: aprendendo Java. “Aprender Java é fácil, porque todas as linguagens são iguais. Só muda a sintaxe” pensa nosso pobre profissional. Ao iniciar seu trabalho com Java, a primeira coisa que procura saber é como são criados os formulários, e começa a achar a plataforma um lixo enquanto não encontrar um editor visual que lhe permita trabalhar assim como fazia no caso do Visual Basic. Quando finalmente o encontra, aí sim começa a trabalhar. Cria então algumas classes, lotadas de métodos estáticos. Estas classes “utilitárias” corresponderão para este usuário aos módulos com os quais estava habituado ao trabalhar com Visual Basic.
Algumas aplicações desktop são criadas, já é possível escrever no banco de dados, e tudo anda bem, até que o mesmo profissional percebe a necessidade de criar uma aplicação web. E é neste ponto que dá de cara com a parede de novo. Como não aprendeu orientação a objetos direito (no VB não havia isto. Haviam classes e tal, mas nunca entendeu ao certo para que serviam), não consegue entender como um servlet funciona. Consequentemente, não consegue aprender a trabalhar com outros frameworks. Diz que o Java é um lixo, que o bom mesmo era o VB, aonde conseguia fazer tudo de forma fácil, sem estas “frescuras”.
Repare na constante: como aprendeu a programar usando apenas um ambiente de desenvolvimento, sempre que ocorrer uma mudança, irá tentar trabalhar assim como fazia no ambiente inicial. Se o mesmo profissional, ao iniciar o seu trabalho, tivesse começado com duas ou mais linguagens, vamos supor: Visual Basic e C, ou qualquer outra, o mesmo não teria ocorrido.
Ao se acostumar com o ambiente visual, o programador passa a ignorar que por trás dos seus lindos formulários, há uma estrutura complexa que é preciso conhecer para que se possa progredir. Ambientes de desenvolvimento rápido como Visual Basic ou Delphi banalisam a nossa tarefa.
Curiosamente, se o profissional fictício acima tivesse começado sua carreira aprendendo apenas C, possuiria uma visão mais abrangente? Com certeza. Isto porque linguagens como o Visual Basic ou qualquer ambiente visual apenas suprimem os sintomas de impotência incluindo a ilusão de poder. Nosso programador fictício ao criar seus formulários se sentia incrívelmente podroso. Afinal de contas, estava criando algo realmente útil com apenas alguns cliques do mouse. No entanto, esta ilusão desaparece a partir do momento em que precisa interagir com algo mais complexo. No caso de quem começou usando C/C++ ou outra linguagem que não ofereça este tipo de ambiente, as coisas são mais difíceis no começo.
Este outro desenvolvedor possuirá a visão de baixo pra cima, ao contrário do primeiro. Consequentemente, ao evoluir, ficará mais simples para este compreender as camadas posteriores. Afinal de contas, são desenvolvidas com base naquela da qual está partindo, e não o contrário. Este outro desenvolvedor vê a sua percepção do ambiente digital evoluir conforme vai conhecendo estes novos frameworks ou bibliotecas.
Qual seria a solução portanto? Começar pelo assembler? Claro que não, mas pelo menos fugir dos ambientes de desenvolvimento rápido o máximo possível e, se possível, sempre conhecer pelo menos duas linguagens de programação distintas (melhor ainda: ao menos dois paradigmas). Isto quer dizer também que todos os ambientes de desenvolvimento rápido são um veneno terrível? Não! Só que devemos utilizá-los apenas após possuir uma base teórica/prática sólida sobre os fundamentos da computação.
(não vou chover no molhado e dizer “quanto mais linguagens aprendermos, melhor”, pois é óbvio demais)
No final das contas, não é a popularidade de uma linguagem que torna um profissional competente (COBOL tá aí pra provar isto), mas o modo como lida com o determinismo linguistico.
PS: outro bom exemplo de determinismo linguistico. Windows!
Aqueles que só usam Windows, acham comum os erros que o sistema apresentam, e jamais reclamam. No entanto, no dia em que passam a usar outro sistema, como o Linux ou Mac OS, nunca mais retornam ao mesmo. Isto porque sua linguagem cresceu (ele conhece mais de um sistema operacional) e, consequentemente, possui uma visão mais ampla do mundo.
Deixe uma resposta