Newsgroup: it.comp.lang.perl
Titolo: Migrare a perl

Salve a tutti,
per il mio prossimo impiego mi e' stato chiesto di imparare perl. Non
parto da zero, ho conoscenza avanzata del C, e un livello intermedio
di Java e Python. Secondo voi puo' bastare il tutorial che ho trovato
su 
perl.it
?
Saluti

Lorenzo Mainardi ha scritto:

Io l'ho imparato in 2 settimane. Conoscendo il C sei gia' un pezzo
avanti. Io venivo dal tcl.
-- 
Posted via a free Usenet account from 
http://www.teranews.com


La cosa che mi ha sempre spaventato di Perl, e che mi ha fatto
scegliere Python, e' stata la sintassi...

 ha scritto:

Effettivamente è un macello, ma quando hai imparato a padroneggiarla può 
diventare addirittura un punto a favore.

scegliere Python, e' stata la sintassi...
La maggior parte degli idiotismi perl possono essere evitati o aggirati, e
quelli che restano non sono a mio avviso molto più noiosi di quelli di
qualunque altro linguaggio (l'indentazione in Python[1], le parentesi
infinite in Lisp, la verbosità in Pascal...).
Ma la confortante verità è che non hai scelta, sicché serve a poco
"spaventarsi". Comincia pian piano, cercando di lasciar da parte i
pregiudizi, e vedrai che Perl non è poi così brutto come lo si dipinge.
Se ti riuscisse di trovarla, ti consiglio di leggere la documentazione
originale del primo Perl, quella scritta da Larry Wall per Perl 4 o
precedente. E' divertente, e leggere le motivazioni storiche di tante
scelte (molte certamente discutibili se non proprio sbagliate) sulla
sintassi può aiutare a farsi un po' più amico il "mostro".
Ciao.
[1] Sì, lo so, Python, in realtà, HA dei delimitatori di blocco:
     if foo: #{
         foo1();
         foo2();
         foo3();
     #}

 scegliere Python, e' stata la sintassi...
Io la uso C-style. Non mi vedrai mai fai costrutti strani, tipo
prima il comando e dopo la condizione.


      #}
per la cronaca, questo e' uno *scherzo*: "#{" e "#}" non significano niente,
sono solo commenti... tant'e' che
if foo: #{
    foo1()
  foo2()
   foo3()
#}
(senza ";" che non servono)
da un bell'errore di errore d'indentazione.
OT per OT: la cosa curiosa č che haskell, invece, supporta *davvero*
entrambi i tipi di semantica: il parser dei vari interpreti/compilatori
haskell, infatti, riconoscono l'indentazione come "zucchero sintattico" per
costrutti come {...}
-- 
Under construction

Quale tutorial mi consigliate?
Ho scaricato quello del sito 
perl.it
, mi sembra fatto benino...

sono solo commenti... tant'e' che
Sempre per la cronaca, lo scherzo non è neppur mio:
 
http://www.python.org/doc/Humor.html#parsing
Ciao.

    
http://www.python.org/doc/Humor.html#parsing
io lo so :D
solo che da com'era scritta la nota a pič pagina poteva sembrare una
frase "seria", mentre il thread mostrato nella pagina html č chiaramente
ironico, ecco tutto.
-- 
Under construction


Peccato :)
Sicuramente il fatto di poterli evitare può essere annoverato fra i
punti a favore, però il tipo di costrutto "strano" che citi può essere
linguisticamente molto utile. Immagino che, anche parlando, ti sarà
capitato di dire "passa a trovarci se non fai troppo tardi", o metti
sempre la condizione prima e l'effetto dopo?
Ci sono casi (specialmente quelli "one-shot") in cui secondo me
l'utilizzo del costrutto citato aggiunge leggibilità al codice, perché
ti sembra proprio di poterlo leggere:
   passa_a($visitare, @noi) unless $troppo_tardi;
Solo un paio di eurocent.
Ciao,
   Flavio.

    passa_a($visitare, @noi) unless $troppo_tardi;
E' vero. Il problema e' che per forza di cose, e anche per piacere,
mi diletto con il coding in C e talvolta anche con il php (che non
mi piace per niente), quindi per uniformita' tendo a usare costrutti
simili tra i 3, in modo da fare un context switch veloce e indolore :)


 ti sembra proprio di poterlo leggere:
Trovo molto chiara (e idiomatica in Perl) la maniera in cui si
suggerisce di scrivere le condizioni di uscita dai cicli. Cito da "Perl
Best Practices", che consiglio trall'altro)
  INPUT: 
  for my $attempt (1..$MAX_TRIES) { 
 
     print 'Enter a big integer: '; 
     $int = <>; 
     last INPUT if not defined $int; 
     redo INPUT if $int eq "\n"; 
     next INPUT if $int !~ $INTEGER; 
     chomp $int; 
     last INPUT if $int >= $MIN_BIG_INT; 
  }
Per il momento sospendo il giudizio per gli altri casi: il paragone con
il linguaggio naturale lo trovo un po' debole. A differenza di quanto
avviene con il software, non si passa il tempo a riscrivere, mantenere e
correggere quello che diciamo (mi riferisco alla comunicazione orale e
comunque non alla letteratura). 
Se dunque nel linguaggio naturale il tuo esempio e' perfettamente
sensato, nella pratica dello scrivere codice preferisco usare da subito
un blocco, anche per contenere una singola istruzione, sapendo che in un
secondo tempo potrei voler aggiungere un messaggio di debug, altre
istruzioni, e così via...
S.
-- 
Stefano Rodighiero      |  
http://larsen.perlmonk.org
mailto:
lar...@perl.it
   |  Italian Perl Mongers: 
http://www.perl.it

 istruzioni, e così via...
[snip]
Non capisco bene perché il paragone sia più "debole" negli altri casi,
trattandosi sempre di statement condizionali. Posso capire,
anche se non condividere, il tuo volerti "portare avanti" con un
blocco, ma
immagino che questo ti richieda in media due righe in più per
condizione,
il che ti riduce il "contesto" su cui puoi buttare un occhio in fase
di
rilettura. Va poi osservato, con particolare riferimento
all'inserimento di
messaggi di debug, che il tuo argomento si applica parimenti anche ai
casi da te citati come "buoni".
Quanto poi ad evitare un confronto con la letteratura... mi sembra
pretestuoso,
uno i programmi li scrive e li rilegge, non ci fa conversazione con un
computer.
E nello scritto, pur utilizzando regole più formali, mi viene
perfettamente
naturale scrivere cose tipo "la funzione logaritmo reale non è
definita se il valore
dell'argomento è minore o uguale a zero" o "Domani andremo al mare, a
meno
che non piova". Così come mi viene molto facile leggere
   die 'invalid parameter $foo' unless defined $foo;
Capisco che si sconfina nel gusto personale...