Aprendizado de Programação e Complexidade

October 16th, 2006 § 2 comments

Esses dias eu andei pensando em um artigo que David Brin escreveu para o Salon, intitulado “Why Can’t Johnny Code?” No artigo, Brin, que é um conhecido escritor de ficção científica, reclama da falta de um ambiente de aprendizado de programação em computadores modernos que seja tão simples quanto o BASIC era.

O artigo suscitou algumas reações interessantes, negativas em sua maioria, mas eu não posso me furtar ao sentimento de que Brin estava parcialmente correto–embora talvez não pelo motivo que ele especifica.

É certo–como alguns responderam–que hoje temos um ambiente relativamente ubíquo de programação presente em quase todos os computadores: o navegador, que pode ser usado para o desenvolvimento de aplicações mesmo sem a necessidade de um servidor, algo demonstrado por aplicações como o TiddlyWiki. Apesar disso, a barreira de entrada é comparativamente alta para aplicações que ultrapassam o mais simples do HTML mais JavaScript e passam para o domínio da necessidade de persistência e continuidade.

Existem dois níveis em que a questão pode ser abordada: o aprendizado infanto-juvenil, ou seja, a exposição à programação como qualquer outra matéria curricular aplicada; e o aprendizado como uma ferramenta de trabalho.

O artigo de Brin tratava exclusivamente do primeiro nível acima, pensando na formação uma nova geração de programadores com conhecimento íntimo dos detalhes internos daquilo que usam. Segundo o argumento de Brin, as linguagens atuais são de um nível tão alto que é difícil para o programador iniciante enxergar dentro da abstração. Eu concordo que as linguagens mais populares realmente podem levar a esse problema. Mas existem ferramentas–como o Squeak, por exemplo, que é uma implementação do Smalltalk voltada primariamente para propósitos educacionais–que permitem que o programador que esteja aprendendo veja o que está fazendo nos mínimos detalhes.

A grande diferença–e o grande problema–talvez esteja na expansão das bibliotecas de apoio. Obviamente, bibliotecas são boas. Bibliotecas são o que tornam a programação eficiente. Mas elas também proporcionam uma barreira ao aprendizado. A curva de aprendizado de uma linguagem como o C# é mais íngreme do que o BASIC porque muitas primitivas estão embutidas diretamente na sintaxe dessa última ao contrário de estarem delegadas a bibliotecas como no caso da anterior.

O Smalltalk, mesmo com uma biblioteca de classes gigantesca, não sofre desse problema porque sua sintaxe é tão simples (cinco palavras chave e uma dúzia de regras sintáticas)  que a biblioteca de classes–desenvolvida em peças pequenas que são montadas quase como blocos Lego–parece parte da linguagem. O resultado é que o programador iniciante aprende a montar suas aplicações de peça em peça, em uma espécie de unit tests mentais que favorece o processo de aquisição de conhecimento.

Em última instância, essa diferença talvez tenha impacto mesmo do segundo nível acima, do aprendizado de programação como ferramenta de trabalho direto. Recentemente, exibindo o funcionamento do Seaside para um colega programador, não consegui que ele entendesse o impacto de continuações do fluxo de construção e execução contextual da aplicação. Esse colega entende o Rails perfeitamente–comparado ao ASP.NET–mas não consegue passar disso para o Seaside, mesmo sendo um programador razoavelmente experimentado. Há um salto de conceitos aqui que a formação dele não consegue ultrapassar no momento.

Isso é resultado–eu acredito–do problema que Brin descreve: programadores que pensam somente em abstrações tão específicas que não conseguem descer até um nível anterior e reconstruir dali quando necessário. E sem linguagens que permitam essa passagem, a f0rmação de novos programadores resulta em pessoas que conseguem juntar ASP, HTML e JavaScript para fazer alguma coisa que funcione, mas nada com a elegância de um Django. Eles podem saber usar, mas não fazer.

Também interessante é o fato de que isso gera uma outra barreira: contribuições a projetos de código aberto. Projetos de grande aceitação geralmente começam porque alguém resolveu revolucionar uma área específica–conscientemente ou não. Entretanto, essas revoluções implicam em abstrações quase que perpendiculares ao status quo–algo que gera um problema de complexidade inerente. É incrivelmente fácil usar o Rails ou o Django, mas a vasta maioria dos usuários dessas bibliotecas jamais contribuíra com uma linha de código para a base original–não por preguiça, falta de tempo ou falta de gratidão, mas por pura incapacidade de abstrair para os conceitos que levaram à simplicidade de uso em primeiro lugar.

O impacto da linguagem de programação é algo que não pode ser subestimado. Eu me lembro de ter desenvolvido uma biblioteca MVC para aplicações Web quando usava o Delphi, uma linguagem estaticamente tipada, como minha ferramenta primária. A parte de persistência de dados foi baseada em um artigo de Scott Ambler sobre a estratégia Active Record, usada atualmente tanto pelo Rails quanto pelo Django. O desenvolvimento–que ocorreu por volta em 2002–foi relativamente simples e bem sucedido. Eu usei a biblioteca em alguns projetos até ter que abandonar o Delphi quando mudei de emprego sem maiores problemas.

Hoje, porém, mesmo tendo esse código e podendo usá-lo e aperfeiçoá-lo com base no que aprendi, escolho não fazer isso, preferindo o Rails. Isso é resultado do Ruby, em oposição ao Delphi. As possibilidades de abstrações vazarem são menores no Ruby do que no Delphi e isso tem um grande impacto de meu processo de desenvolvimento. E eu entendo muito melhor o que estou fazendo porque já estive dentro da biblioteca em outra instância.

Assim, eu entendo o que Brin diz em seu artigo como uma maneira um pouco mais verbosa de dizer que, em programação, saber usar não é suficiente. E para ir além de saber usar, é necessário esse interesse de pensar no que move o programa, algo facilitado por uma linguagem que permita  um início mais particionado–algo que linguagens de programação com capacidades de meta-programação permitem como uma segunda natureza e linguagens mais simples possuem por necessidade.

Por isso, no final das contas, eu tenho que concordar parcialmente com David Brin. Os programadores de hoje tem muito mais deficiências do que antigamente por causa dessa mudança de foco. Não é uma questão de talento, mas de percepção. E, felizmente, nada que um bom estudo não possa corrigir.

§ 2 Responses to Aprendizado de Programação e Complexidade"

  • Marco Gomes says:

    Tem também a culpa de “quem ensina”, antigamente começava-se sozinho e a especialização vinha em uma instituição respeitada, séria e não-mercenária, normalmente uma universidade federal.

    Hoje os profissionais compram diplomas em FaFiFo’s com graduações de 2 anos que mais parece um curso técnico de uma linguagem específica.

    Conheço uma pessoa que fez uma graduação de 3 anos de “Desenvolvimento de Sistemas para a Web” em uma faculdade peba. Começou o curso com Delphi pra pegar Lógica de Programação e terminou com .Net pra aprender desenvolvimer sistemas para a Web. Pronto, apenas isso, sem JavaScript, sem AJAX, sem Smalltalk, sem C, sem Java, sem Python (o que é Python mesmo?), sem Ruby… SOMENTE C#.Net.

    E o mercado está LOTADO de gente assim. Capitalismo selvagem.

  • Ronaldo says:

    Opa, Marco! Tudo bom? Com certeza o ensino atual está fraquíssimo. Eu tenho visto exemplo de alunos ensinando professores na sala de aula como programar. Essas instituições só estão interessadas em pegar o dinheiro do aluno e dizer depois que ele está formado, se eximindo de qualquer responsabilidade. E ainda tem todo esse papo agora de sindicalização da área, com conselhos, etc. Quero ver o que vai virar.

Leave a Reply

Your email address will not be published. Required fields are marked *

What's this?

You are currently reading Aprendizado de Programação e Complexidade at Superfície Reflexiva.

meta