[Recife-pm] Digest Recife-pm, volume 12, assunto 1

[Ulisses Montenegro]

Cleber e demais,

Gostaria de fazer alguns comentários sobre os pontos discutidos --
enquanto um nível mínimo de civilidade for mantido na discussão,
acredito que as diferenças de opinião só tem a agregar.

DISCLAIMER: Cortei os emails originais e as partes que não vou
comentar, porque os emails já estavam ficando enormes devido à
quantidade de lixo residual incluído.

2010/6/9 Cleber Morais <cmorais em gmail.com>:

> Mas o ponto que levanto é: é mais fácil aprender Perl programando ou
> aprender Perl aplicando restrições?(Antes de mais nada, aprenda boas
> práticas; leia o perldocs -- preferencialmente todo--, levante bom
> requisitos, documente corretamente, use a metodologia adequada, passe
> pelos momentos de iteração... para fazer sua calcuradora).
>
>
> Acho que o mais importante é, desculpem a lista, é aprender a
> programar. Qualquer coisa, de qualquer jeito. Por sorte nossa, usamos
> Perl, que possui um monte de coisas que facilitam a aprendizagem e o
> modelo mental de cada um. Algumas linguagens não são tão fáceis assim,
> tão mnemónicas (toda vez que uso C tenho que ficar xingando o fato de
> não poder atribuir simplesmente um valor a um array). Mas o objetivo é
> PROGRAMAR, não aprender Perl. E eu venho de uma "linhagem" de caras
> que aprendem fazendo. Teorizar é ótimo, mas nem sempre aprende-se onde
> coloca isso no mundo. Prática é legal, mas esvazia o conhecimento. Por
> isso acredito que começamos com a prática e depois vamos para o estudo
> para melhorar a prática...e entra em loop.

Você tocou em um ponto importantíssimo, mas que talvez seja polêmico
devido ao público da lista -- Perl é uma boa linguagem para se
aprender a programar? Eu acredito que restrições são essenciais
durante o processo de aprendizado, uma vez que diminuem o escopo de
possibilidades a serem validadas. Os usuários de Linux (eu me incluo
na categoria, uso o sistema operacional de Linus Torvalds desde 1995)
já viram essa história várias vezes -- algum amigo ou conhecido decide
tentar a plataforma, e já de cara precisa escolher uma distribuição.
Logo depois, o desktop environment -- KDE, Gnome ou aldo diferente?
Qual browser, Firefox ou Chrome? Qual editor de texto, vim ou emacs? O
usuário tipicamente vai utilizar aquilo que os mais experientes (i.e.,
aqueles que poderão tirar suas dúvidas quando surgirem) sugerirem, mas
será que esse critério é realmente o mais adequado para garantir que o
usuário tem suas demandas devidamente atendidas?

Eu, particularmente, considero Perl uma escolha ruim para uma primeira
linguagem, justamente por oferecer opções em excesso. Devido ao
excesso de possíveis abordagens de implementação, fica difícil para um
desenvolvedor iniciante decidir qual a mais adequada. Excesso de
opções também dificulta diferenciar implementações bem feitas de
gambiarras. Isso pode ser observado facilmente na quantidade enorme de
módulos no CPAN para resolver problemas mais comuns, e na gritante
diferença de qualidade que existe entre muitos deles. Dêem uma olhada
em http://www.shlomifish.org/lecture/Perl/Lightning/Too-Many-Ways/slides/index.html
e vejam que não sou apenas eu quem acredita nisso.

Isso não quer dizer que escolha seja algo ruim, mas no contexto de
alguém que está aprendendo algo novo, eu acredito trazer mais
malefícios do que benefícios.


> Meu objetivo quando falei era fazer o Bruno programar, numa abordagem
> top-down. Todo mundo na lista estava falando bottom-up (leia o
> perldocs, veja o CPAN...). Mas isso não é a parte mais legal (pelo
> menos para mim) do Perl. A parte mais legal é funcionar.

É legal quando você entende *porque* funciona. Óbvio que funcionar é
divertido, mas programação é um processo construtivo, e construir algo
que não entendemos não é tão divertido assim.

> É fácil dizer que o código é uma desgraça. E é mesmo. Não é uma obra
> de arte e nem pretende ser. Mas eu asseguro que funciona. Asseguro que
> pode ser melhorado e asseguro que foi o único (e até agora, quando
> mandei essa mensagem) que mandou código para a lista. Espera, é uma
> lista de boas práticas e leitura comentada ou de programação? Ou
> existe uma metodologia para falar disso? Primeiro manda o cara ler
> tudo que vier pela frente... Se ele continuar na lista, manda ele ler
> mais outras coisas, se realmente o cara for chato suficiente para
> continar, mandamos algum código para ele calar a boca </trolling>.
> [Não resisti a essa provocação...]

Na verdade, se ele ler um pouco mais, tentar implementar algo e
falhar, e mostrar o código que escreveu, os erros que está
enfrentando, nós provavelmente vamos tentar ajudá-lo da melhor forma
possível. No entanto, a resposta dele deu a entender que ele não está
conseguindo entender como a coisa funciona. Código não vai ajudá-lo a
resolver o problema do entendimento, leitura talvez também não, mas
com certeza vai deixá-lo mais próximo de conseguir resolver a situação
por conta própria.

> Cleber M

Ulisses

-- 
“If debugging is the process of removing software bugs, then
programming must be the process of putting them in.” - Edsger Dijkstra