Newsgroup: it.comp.lang.perl
Titolo: SFOGO

C'è uno script perl che da mesi è fermo perchè nessuno riesce a togliere dei
bug e a finire altri lavori.
Ma il perl è così complicato?
Con php/mysql non ho avuto problemi così drastici.
Esiste qualche programmatore perl davvero bravo
che non si incasina sul codice scritto da altri?
Bah!


Il perl non è più complicato di altri linguaggi; anzi, usato
professionalmente, semplifica le cose rispetto ad altri. Posso
aggiungere che il perl è un linguaggio con forti peculiarità (che sono
alla base della sua potenza e flessibilità) di cui un professionista
deve essere pienamente consapevole.  Il problema, quando si prende in
mano codice scritto da altri, è la professionalità di chi  ha scritto
il codice in modo che sia manutenibile a costi accettabili.
Il problema del codice "legacy" è uno dei grandi incubi della
disciplina del software engineeering come disciplina. Non c' è alcun
"silver bullet" contro questo problema se non far sviluppare codice ha
chi ha i necessari requisiti di professionalità. Uno di questi
requisiti è che la conoscenza della sintassi del linguaggio è
condizione *necessaria ma non sufficiente* per scrivere codice
corretto.
Ma questo vale per qualunque linguaggi: ci sono gran brutti lavori
(con firme prestigiose...) in Java , C e altri linguaggi.
E non solo per il software
La mia non è una risposta di bandiera: simpatizzo comunque con la tua
necessità di avere un lavoro "done" e con le tue difficoltà
Ciao
Daniele

 (con firme prestigiose...) in Java , C e altri linguaggi.
Con la differenza che alcuni linguaggi, per maggiore "strettezza" di 
sintassi, per maggiore necessita' di formalismo, tendono a generare 
comunque codice intrensecamente piu' lineare e/o semplice da 
capire/mantenere. 
Il Perl *non* e' tra questi linguaggi, e, ovviamente, non lo dico per 
sminuire il Perl, anzi.... ;-)
-- 
Saluti,
Giancarlo

concordo pienamente con quanto hai scritto.
io programmo principalmente in delphi, ma attualmente (purtroppo) sto
mettendo mano a codice VB (oddio!!!) scritto veramente con i piedi. da un
tizio con 5 anni in piu' di me di esperienza e che prendeva almeno il
triplo di quanto danno a me x sistemarlo. nn mi pare bello....
byez
Leo :)

Io sono del parere che programmare è come sistemarsi il cassetto: se si
vuole che chiunque altro ci possa mettere tranquillamente le mani dentro, si
mette tutto in un ordine schematico, altrimenti si mette tutto alla rinfusa.
L'ordine è sempre relativo: quello che puo' essere ordine per me puo' essere
disordine per chiunque altro.
La sintassi di Perl è eccezionale, se la si conosce e la si scrive
ordinatamente, magari con i dovuti commenti, chiunque puo' mettere mano al
codice senza difficoltà, ma quando si trovano programmi disordinati e
confusi e senza commenti, vuol dire che era intenzione dell'autore non
rendere il codice comprensibile ad altri. Basta dare uno sguardo al sorgente
di Ultimate Bulletin Board, qualcuno ci capisce qualcosa? Eppure è un
sorgente :-)

non lo dico per  sminuire il Perl, anzi.... ;-)
Per me potresti coprire di contumelie anche Larry Wall di persona e
non ne farei una questione personale. Ciascuno è libero di esprimersi
e ciascuno è libero di sintonizzarsi o meno sul livello culturale e
professionale della comunicazione altrui.
Ciao 
Daniele

beh magari l'intenzione era proprio quella di non far capire il sorgente...
un po' come avviene con certi script in DHTML, bellissimi ma
incomprensibili.
io invece mi riferivo ad una realta aziendale in cui devi mettere pezze di
rattoppo a software nati male... deprimente....
byez
Leo

 professionale della comunicazione altrui.
E ciascuno e' anche libero di capire o meno una battuta.
-- 
Saluti,
Giancarlo

>E ciascuno e' anche libero di capire o meno una battuta.
Orpo, non ci siamo capiti. Colpa mia. Non ero polemico ma
effettivamente potevo esprimermi meglio, volevo solo dire che siccome
le tue critiche e le tue osservazioni non sono emozionali e sono
ragionevoli mi vanno benissimo ...
Quando dicevo "porsi a livello" intendo dire che fintanto che le
osservazioni si mantengono razionali e motivate si puņ dire proprio di
tutto.  Le tue osservazioni vanno benissimo.
Mi scuso per l' equivoco.
Ciao


Scusami, non ti seguo perfettamente: come distingui leggibile da
comprensibile?
Ciao

 while (<STDIN) {print if /perl/}
sono leggibili, ma ho la senzazione che un programma, specialmebnte se 
lungo) scritto nel secondo modo sarebbe sicuramente piu' difficile da 
segure nel suo complesso.
La leggibilita' e' solo figlia della buona educazione sintattica di cui 
sopra, la comprensibilta' e' conseguenza soprattutto della 
progettazione globale fatta sul codice e sul programma, ed e' forse la 
seconda, piu' della prima, a discriminare "il software engineer valido 
dallo scappato di casa".
-- 
Saluti,
Giancarlo

dallo scappato di casa".
Potrebbe essere una distinzione meritevole di qualche approfondimento;
la mia opinione è che la prima qualità è proprio legata alla
professionalità intesa come disciplina nella stesura del codice, la
seconda qualità è forse più un prodotto della intima conoscenza che si
ha del linguaggio. Ovvero, la prima è una qualità del fare, il secondo
è una qualità del capire.
Penso al fatto che in Fortran e in C sono pochi i costrutti che ti
fanno scattare delle associazioni di idee, delle forti aspettative:
tutto si basa su statements e tipi di dati e il modo di gestire le
loro relazioni. In perl, linguaggio fortemente idiomatico, ma potrei
citare altri linguaggi, il vedere una closure scatena certe
aspettative. C' è una 'gestalt', se mi passi il termine fuori moda,
associata al costrutto.
Ciao

  anche se sono entrambi ugualmente leggibili
   Perdonate se mi  intrometto esponendo idee un tantino  obsolete: sono un
vecchio  e stanti`o  programmatore a  "riposo", nel  senso che  "sapevo" di
assembler, di basic e  di c, e mia ferma convinzione  era quella di rendere
il  codice sorgente  il piu`  leggibile possibile,  salvo poi  fare qualche
doverosa  deviazione quando  una  sintassi mi  pareva  piu` "elegante".  Un
esempio per tutti: "x += 1" in vece di "x = x + 1".
   Da  vecchio  programmatore  in  ambiente  "ms-dos",  era  naturale  che,
affacciandomi  al mondo  Linux,  sentissi  la mancanza  di  un qualcosa  di
somigliante  al buon  vecchio basic  (l'unico linguaggio  di programmazione
degno di tale nome disponibile "a gratis"). Alla fine mi sono avvicinato al
Perl, e  devo dire che  non ho  trovato grandi difficolta`  ad ambientarmi,
anche perche' avevo familiarita` con il c.
   Anzi, dal momento che la  stragrande maggioranza dei miei... chiamiamoli
"problemi"... ha sempre riguardato la gestione di file di testo, ho trovato
in Perl lo strumento che avevo sempre desiderato di avere...
   Ora,  il mio  dubbio e`:  fra le  due possibilita`  quotate sopra,  c'e`
un  "reale"  vantaggio,  a  livello  di run-time,  o  no?  Perche'  secondo
me  il  problema  e`  questo:  o  la  programmazione  in  perl  "sintetica-
il-piu`-possibile"  ("obfuscated", dico  bene?) ha  dei "reali"  vantaggi a
livello di  esecuzione, oppure resta  confinata negli esercizi  "di stile",
non so se mi  spiego... A suo tempo, scrissi delle  routine in assembler da
linkare con programmi in basic perche'  - oggettivamente - il vantaggio era
notevole (leggi "visibile" e "cronometrabile").
   Personalmente,  ritengo che  la  velocita` di  elaborazione dei  moderni
computer sia tale da minimizzare eventuali ottimizzazioni del codice (salvo
forse iterazioni  ennesimali...), mentre ritengo che  la "leggibilita`" del
codice -  corredata da generosi commenti  - sia di gran  lunga preferibile,
anche in prospettiva dell'open source.
   Dico questo anche perche' recentemente mi  e` capitato di mettere mano a
sorgenti in  VisualBasic (Excel) da me  scritti nell'ormai lontano -  e non
ridete... ;) -  1995, e di ritrovarmi a benedire  la mia lungimiranza nello
scrivere - oltre a molti "rem" esplicativi - anche codice "leggibile"...
   Scusate... Piu` s'invecchia, piu` ci si parla addosso... :(
-- 
Power down.

anche in prospettiva dell'open source.
Non credo ci sia un reale conflitto tra le due cose. Chi faceva
professionalmente number crunching in Fortran (ostioso come pochi ma
non si è mai visto niente di più veloce salvo l' assembler per fare di
conto) poteva fare un loop unrolling (non proprio leggibilissimo, se
non commentato a dovere) spiegando per filo e per segno il codice in
modo che fosse a prova di scemo portando a casa il piccione della
velocità e il piccione della leggibilità con un solo codice. 
Se posso concludere direi che il conflitto sostanziale è molto più
profondo e radicale: il contrasto tra economia, tempo e qualità rimane
irriducibile o incomprimibile sotto una certa soglia
Ciao

 associata al costrutto.
Dici cosi' solo perche non hai mai visto del mio vecchio codice 
Fortran... :-))))
A parte gli scherzi, hai perfettamente ragione, infondo questa e' una 
delle ragioni che mi fa amare il Perl.
-- 
Saluti,
Giancarlo

    Scusate... Piu` s'invecchia, piu` ci si parla addosso... :(
1995... non supporre di trovarti in mezzo a gente cosi' piu' giovane di 
te... nel '95, per fortuna io ero gia' alle pese col Perl :-)
E, con ancora piu' fortuna, il VB, non l'ho mai frequentato piu' di 
tanto ;-)
-- 
Saluti,
Giancarlo

 veloce del 7,6%, ovvero una media di 2,114 sec. per A e 2,288 per B
Ho provato anche io
Pentium III, 933 Mhz
Linux 2.4.18 (Debian 3.0)
perl v5.6.1
5 tentativi
A) impiega mediamente 1.47 secondi
B) 1.53 secondi
e' comuqnue piu' veloce, ma lòa differenza scende al 3.9% circa la 
meta'... 
-- 
Saluti,
Giancarlo

 è un buon aereo", se capite cosa voglio dire
Uhm. Proviamo ad aggiungere un pezzettino di codice all'interno dei due
cicli. Nel ciclo del frammento A mettiamo:
  for ( 0 .. 0 )   {   }
mentre in quello del frammento B:
  for my $c ( 0 .. 0 )   {  }
Adesso il frammento B è più veloce (12.42 sec contro i 13.33 di A, sulla
mia macchina). C'è un motivo preciso per cui questo accade. In A $_ viene
"localizzata" (scope dinamico, non lessicale) all'ingesso del ciclo
annidato. Questo comporta che il valore di $_ debba essere salvato e
ripristinato ogni volta.
Ora, ripristiniamo il codice iniziale e facciamo una piccola variazione
nel frammento B, spostando fuori dal ciclo la dichiarazione di $line:
  my $line;
  while (defined($line = pop @down))
Anche in questo caso, il frammento B è più veloce, anche se di poco.
Max


Perdona, non ho capito bene com' è il codice risultante: intendi
sostituire o intendi aggiungere? Puoi postare il codice completo?
Ciao

On Fri, 3 May 2002, Daniele wrote:

Aggiungere. Nel caso di A:
 while (defined($_ = pop @down))
 {
        print if  /perl/;
        for ( 0..0 ) { }
 }      
Max

comprensibile?
Mi propongo: un codice Perl è leggibile da un programmatore
Perl, potrebbe essere comprensibile, utilizzando in modo
molto limitato il linguaggio, da programmatori
C/PHP/Java/C++/Delphi.
Insomma, se si decide di fare qualcosa in Perl, significa
che questo linguaggio è adatto allo scopo e lo si deve usare
in tutta la sua potenza. Altrimenti non vedo il motivo di
non usare PHP.
-- 
WEbdOM webmaster di
Metronic.It mobile phone philosophy