[Cascavel-pm] Ensinar Perl na Faculdade [Was: EXPLICAÇÃO SOBRE: PUSH, SPLIT e FOREACH.]

Sexta Junho 22 07:32:48 PDT 2007

On Jun 21, 2007, at 7:40 PM, Adriano Ferreira wrote:
> On 6/21/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
>> On Jun 21, 2007, at 3:31 PM, Adriano Ferreira wrote:
>>> Como o Eden, também não acho que começar a ver programação através
>>> de linguagens como C seja o melhor. Mas:
>>>
>>> * Haskell é muito matemático
>>
>>    Claro, computação == Matemática (cálculo, álgebra) à Jato
>
> I Just Want to Program! Don't Make Me Learn Math!
> by chromatic
> http://www.oreillynet.com/onlamp/blog/2007/05/ 
> i_just_want_to_program_dont_ma.html
>
> é um bom artigo com argumentos sobre quanto de matemática é necessário
> para programar.

   Hum. Vamos estabelecer aqui uma diferença: eu não quero  
"programar". Quero estar entre os 10% melhores engenheiros de  
software do planeta. Eu preciso de mais matemática que a média,  
certamente.

>>> * LISP tem parentêses demais
>>    Você nunca nem olhou para LISP, está na cara... ;-P
>
> Não devemos estar falando da mesma linguagem. Por exemplo, estes  
> trechos
> [lisp code here]
> que vem de uma discussão em comp.lang.lisp
> (http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/ 
> 750d9ff8b3015cdd?hl=en),
> para mim tem parentêses demais.

   Eu vejo apenas os parêntesis necessários para representar a  
estrutura em árvore implícita no código. Não vejo nenhum parêntesis à  
mais...

>  [Prolog e não exibir I/O para iniciantes]
   Tá, tá, você tem razão sobre o I/O. Me convenceu.

>>    Mas se pode aprender bastante sobre lógica e recursividade, e isso
>> é importante.
>
> Backtracking é útil, mas elusivo. Basta dar uma olhada em discussões
> sobre como uma regex com alternações pode ficar ineficiente por causa
> do backtracking realizado pela regex engine.

   Backtracking != Recursividade
   Posso implementar backtracking com pilha explícita, não  
recursivamente. E aí vamos falar de ineficiência.
   Estou falando simplesmente de aprender a enunciar e compreender  
programas recursivos.

> Agora lógica em si, você não encontrará muitos programadores e
> aplicações comerciais em que elas são usadas além de um nível muito
> básico. Cálculo de predicado ou claúsulas de Horn são uma
> excentricidade com que poucos tem de conviver. Pelo menos, eu nunca
> tive de escrever algo parecido com um provador de teoremas em meu
> trabalho de dia-a-dia.

   Se você nunca precisou, sorte sua.
   Eu já tive muitos programas onde estas coisas foram úteis, e  
conheci gente que faz muita análise de grafos antes de mudar uma  
linha de código. ;-)
   É uma questão de escolher para quem você quer trabalhar, basicamente.
   Preprando para atender o nível de exigência mais alto, garantimos  
também qualidade onde as necessidades são menores. Preparação e  
estudo nunca são demais.

> Em muitas das linguagens que usamos, recursividade não é uma idéia tão
> boa assim. Por exemplo, Perl não faz otimização de recursividade de
> cauda, que é uma coisa que pode fazer muitos programas pararem por um
> simples detalhe de implementação. É claro que a solução é usar "goto
> &sub" ou reescrever em Scheme.

   Hum. Agora, se o sujeito não prestar atenção e não compreender o  
que acontece, nem souber que Recursividade de Cauda pode ser  
otimizada (pela linguagem de programação) com o desempilhamento da  
chamada anterior do Call Stack, e arranjanto para que o valor de  
retorno da chamada seguinte seja convenientemente retornado para a  
função de entrada da chamada recursiva, como ele vai saber disso  
antes de travar o programa?

   Dá o braço a torcer, carinha. Você mesmo é muito melhor preparado  
que a média... Eu sei que Java não foi tua primeira linguagem de  
programação, eu sei que você sabe quem é o Tanembaum e o Knuth, e que  
você manja de teoria de grafos e álgebras booleana e relacional... ;-)

> O bom uso de recursividade pode ser um tópico avançado como escrever
> uma função para calcular números de Fibonacci e turbiná-la com
> memorização.

   Engraçado... esta foi a minha segunda aula de introdução à  
programação, na USP. E aposto que você também aprendeu isso mais ou  
menos por esta época, onde quer que você tenha estudado. Você parece  
estar querendo defender uma reserva de mercado, carinha... deixa os  
outros estudarem e aprenderem como você aprendeu. ;-) Seja bonzinho,  
vai...

> [Começar em liguagens de alto nível é criar "Java Monkeys"]
> Quem precisa de brigar com "dangling pointers", quando tem mais o que
> fazer com as regras de negócio de uma aplicação? Quem precisa escrever
> algoritmos para pilhas e filas quando isto tudo é de graça e muito bem
> implementado em uma linguagem como Perl? Agora gerenciar memória não é
> fácil não. Experimente em Perl alguns objetos com referências
> circulares entre eles, situação que causa leaks de memória porque Perl
> usa "reference counting" e não "garbage collection" de verdade. Mas
> por outro lado, pobre do programador Java que com seu "garbage
> collection" nunca sabe quando suas conexões ao banco ou arquivos vão
> se fechar se ele não fizer isto explicitamente -- não há garantia de
> quando os métodos de finalização vão executar ou se vão executar. Isto
> é uma brisa em Perl.

   "Regras de Negócio" é apenas mais um nome bonito para mais um  
conjunto (importante, por sinal) de coisas para implementar. De  
qualquer forma, se na faculdade você não aprendeu nada implementando  
e entendendo os outros conjuntos de coisas que te deram (filas,  
pilhas, dangling pointers, abrir e fechar arquivos) você vai  
implementar as tuas regras de negócio da mesma forma: porcamente.

> Há problemas difíceis e dignos sem precisar de descer às tais das
> baboseiras que citei. Eu disse baboseiras não porque elas não são
> importantes, mas porque elas são difíceis e tendem a tomar um tempo
> infinito do programador que sonhava em estar avançando a
> funcionalidade da sua aplicação enquanto cuida de coisas que
> linguagens mais fortes lhe trazem como garantidas.

   Você não entendeu ainda que não interessa o que a linguagem traz  
como "garantido", você sempre vai ter de implementar alguma coisa? Se  
você não compreende as "Regras de Negócio" de uma fila ou pilha, como  
vai compreender e implementar corretamente as "Regras de Negócio" de  
uma aplicação bancária?

> Um dos mais prolíficos autores do CPAN, Adam Kennedy
> (http://search.cpan.org/~adamk/), coloca-se como um programador Perl
> com uma experiência muito pequena em C. Acha que isto faz muita
> diferença no currículo dele?

   Me desculpe, mas quantidade não tem nada a ver com qualidade.  
Basta ver quanto você escreveu para se justificar e quanto eu escrevi  
para rebater e você vai ver que a relação não é uniforme - produzir  
muito ou pouco não tem nada a ver com fazer direito.

>>> [Se (os alunos) não tiverem espírito combativo, provavelmente  
>>> nunca vão voltar.
>> [A idéia básica é "separar o Joio do Trigo": a gente bate em todo  
>> mundo, e quem bater de volta, é bom.]
>> [Se a gente não espremer os alunos no começo, como vamos ter bons  
>> profissionais no final da linha?]
>
> Quem é o senhor que vai separar o joio do trigo? De quem são as
> regras? Quem vai aceitá-las?

   O "senhor" que vai separar o joio do trigo chama-se "Mercado de  
Trabalho Capitalista".
   As regras, como você já deve ter percebido, são as dele, e ninguém  
tasca.
   Como você pode ver também, eu aceitei as regras, e, até o presente  
momento, não vejo por que a gente deva mudá-las.

> Pessoas diferentes pensam diferente, aprendem diferente, e ainda  
> conseguem fazer muitas coisas. There is more than one way to do it.

   Sim, sim, claro que existe mais de uma forma de fazer. Eu estou  
apenas defendendo que a gente não aceite formas erradas ou que não  
produzem resultados muito bons, ou os trabalhos de IT do Brazil vão  
migrar para a Índia, onde o pessoal estuda matemática e aprende a  
programar em C ANSI...

>>> [Com uma linguagem de alto nível, o iniciante pode fazer mais e  
>>> continuar motivado por mais tempo.]
>> [Não vai ser divertido no começo,]
>
> Se não for divertido, ninguém quer fazer. Já dizia Joãosinho Trinta:
> "Quem gosta de miséria  é intelectual, pobre gosta é de luxo." Mude o
> intelectual pelo nerd de carteirinha que acha que é preciso sofrer
> para chegar lá e troque o pobre pelo homem comum que quer trabalhar
> mas espera ter tempo para viver.

   O que eu faço, muita gente acha horrível, torturante, insuportável.
   Mas eu gosto.
   Com isso, quero dizer que as pessoas que realmente tem vocação  
para a coisa não vão achar programar em binário nas 9 únicas teclas  
do painel frontal de um computador dos anos 60 "horrível". Elas vão  
se divertir fazendo isso. TIMTOWTDI. E também tem mais de uma maneira  
de ENXERGAR "diversão".

>> [(Os alunos) têm de aprender depressa a enunciar problemas  
>> recursivamente, a gerir threads e
>> processos, a fazer manipulações de ponteiros e a compreender como  
>> funciona a estrutura interna de um computador moderno]
>
> A última vez que tentei passar isto em curso de arquitetura de  
> computadores, descobri uma certa incompatibilidade entre estes  
> princípios e as esperanças dos alunos e do corpo dirigente da  
> faculdade. Isto só tem se agravado desde então.

   Certo. É contra isso que eu estou lutando.
   Não quero faculdades de computação formando Java Monkeys.
   Não quero cursos de computação (ou do que quer que você os chame)  
aceitando alunos que não tem vocação: é desperdício de tempo e  
talento de todo mundo, principalmente o dos alunos.
   Não quero corpos diretores de faculdade mais preocupados com a  
quantidade de desistências do que com a qualidade do ensino.
   A falta de qualidade do ensino nos níveis inferiores está  
começando a cobrar uma taxa muito alta, IMHO, sobre a qualidade do  
ensino superior. Como as faculdades particulares são vistas e  
administradas como uma empresa, ninguém mais se importa em "vender  
diplomas" em 60 "suaves" prestações aos alunos.
   O problema é que todo mundo que sai destas faculdades tem diplomas  
que não valem o papel onde estão impressos, e disputam o mercado com  
as pessoas que se esforçaram e se prepararam. A conseqüência é que os  
melhores preparados acabam "engolidos" pela massa, e se tornam apenas  
"mais um". Ou vão para fora do país.

   Putamplexos!
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
Perl fanatic evangelist, and amateur {cook, photographer}