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

Quinta Junho 21 10:40:11 PDT 2007

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.

> > * 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

(defun series-example ()
    (let ((elements (scan '(3 -1 4 -1 5 -9 2 -6 5 -3))))
      (/ (collect-max (#m abs elements))
         (collect-sum elements))))

(defun pythagorean-triples (n)
 (all-values
  (let ((a (an-integer-between 1 n))
        (b (an-integer-between 1 n))
        (c (an-integer-between 1 n)))
   (unless (= (+ (* a a) (* b b)) (* c c)) (fail))
   (list a b c))))

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.

> > * Prolog é extremamente difícil de se usar na prática - acho que
> > pode até ser uma boa embutido em uma aplicação maior - mas de
> > resto, algumas coisas práticas como IO e outras deixam muito a desejar
>
>    "Coisas práticas" que não precisam ser exibidas a um iniciante.

IO não precisa ser exibido a um iniciante? Realmente, eles costumam
ficar muito felizes de não poder visualizar com que estão mexendo e
nem fazer o programa mais bocó em que eles podem pensar, porque fazer
IO na linguagem em que eles estão escrevendo é um pé no saco.

Tem uma história boa sobre isto no PerlMonks onde o BrowserUk explica
a necessidade de mônadas (que servem para fazer IO e representar
efeitos colaterais) em linguagens funcionais (como Haskell) que
pretendem ser úteis.

http://www.perlmonks.org/?node_id=620424

>    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.

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.

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.

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.

> > Acho que é uma boa idéia começar com uma linguagem de alto nível
> > que esconda as baboseiras do iniciante. Entre as baboseiras, temos
> > 'memory management', estruturas de dados básicas, etc.
>
>   Sim, claro. E aí a gente cria "Java Monkeys" como montes que
> existem por aí, que simplesmente não conseguem enunciar um problema
> recursivo claramente, e não são capazes de gerir a memória das suas
> aplicações, quem dirá projetar aplicações.

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.

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.

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?

>
> > Eu disse que Perl pode ser uma opção -- mas isto depende muito da
> > gentileza do professor -- se for um ogro como os nossos de plantão,
> > eles vão fazer este pessoal correr sem olhar para trás, com os
> > olhos sangrando com referências, globs, stashes, detalhes de
> > implementação de objetos, e outras coisas escabrosas. Se 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? O ambiente "macio" não serve como
> preparação para a vida profissional. Ainda mais num ramo competitivo
> como IT.

Quem é o senhor que vai separar o joio do trigo? De quem são as
regras? Quem vai aceitá-las? Pessoas diferentes pensam diferente,
aprendem diferente, e ainda conseguem fazer muitas coisas. There is
more than one way to do it.

> > Com uma linguagem de alto nível, o iniciante pode fazer mais e
> > continuar motivado por mais tempo. Ele pode apanhar menos ou pelo
> > menos apanhar de coisas que façam sentido para ele, diferente de
> > segfaults e bichos parecidos. É mais produtivo, mais divertido e
> > recompensador.
>
>    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.

> mas os caras tem 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.

>Os caras que
> não sabem isso, ou estudam muito por fora (e vão aprender), ou vão
> viver de construir programas Java diagramados em UML (por que os
> caras não conseguem entender nada que não estiver desenhado).

Até que tem uns diagramas bonitinhos ;-)

>    Eu gosto de bater em Java, mas você pode substituir por
> VisualBasic, Delphi, ou qualquer outra merda da M$, que dá o mesmo
> resultado.
>
>    Aí tem os meus 0.02 ;-)
>    Putamplexos!
> --
> Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
> Perl fanatic evangelist, and amateur {cook, photographer}
>
>
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
>