[Linuxtrent] Re: Anagrammi in Python
- From: "Mario A. Santini" <alexmario@xxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Tue, 10 Aug 2004 23:15:13 +0200
Matteo Ianeselli wrote:
Casomai: problemi = parti!, dove il numero delle parti non è
necessariamente correlato al numero di righe di codice, anche se
approssimativamente l'uno di solito cresce al crescere dell'altro.
Ma che intendi esattamente per parti?
Dopodiché, meno fatica faccio a leggerlo e a scriverlo, meglio è. Chi ha
fatto manutenzione di codice di altri sa cosa voglio dire.
Ho l'impressione che i due aspetti vadano mediati, nel senso che la facilità di scrivere del codice
spesso è inversamente proporzionale alla capacità di leggerlo sucessivamente.
Forse perchè mentre lo scriviamo abbiamo in testa l'algoritmo e quando lo leggiamo, invece,
cerchiamo di desumerlo dal programma.
Comunque, tutto mi va bene, a parte i commenti. :)
E visto che da tempo non esiste software che non debba essere modificato
in qualche modo da un umano (eccetto il TeX), la difficoltà di leggerne
i sorgenti implica maggiore propensione all'introduzione di errori
nuovi. Il software privo di manutenzione marcisce (e per quanto riguarda
il TeX, scritto in Web, quello che va a marcire è l'attrezzo che traduce
il Web in C).
Non so, forse avete voglia di pulirvi le orecchie con un martello pneumatico?
Non lo so.
Forse vi sfugge il fatto che il Perl è un linguaggio nato per scrivere velocemente
e in breve tempo del codice, spesso da linea di comando, ma nache scriptini purchè piccoli.
In quest'ottica è uno strumento più che riuscito e anche molto funzionale.
Certo non se poi lo si utilizza per implementare un programma complesso e articolato, poi ci si
potrebbe trovare nei guai, ma da quel che so questo non ha mai fermato nessuno, indipendentemente
dal Perl.
Per quanto riguarda il Python non ho grosse esperienze di sviluppo in merito e posso solo dire che è
funzionale nella scrittura e anche in lettura.
L'unico problema è, a mio modo di vedere, l'assenza delle graffe, che facilita la lettura.
In un file molto grande, con migliaia di linee di codice si fa fatica a seguire il flusso.
Certo, potete dirmi che si deve usare un editor decente, va bene, lo uso, ma alla fine l'editor non
interpreta il programma, lo deve fare il tecnico ed il tecnico su file grandi si trova in difficoltà
con una sintassi come il Python.
In questo, Tcl lo reputo più leggibile, almeno.
Per fare un'analogia: un castello di carte si fa con un mazzo di carte,
può stare in piedi se lo si costruisce con pazienza e disciplina, ma al
primo alito casca. Incastrare la disciplina nell'equazione significa
rischiare. Grosso.
Il rischio maggiore sta nella progettazione, più che nella implementazione, sai benissimo che se una
cosa è progettata male puoi pure fare un buncher di cemento armato, ma crollerà comunque, quindi
tanto varrebbe fare il castello di carte, almeno non si fa male nessuno (se non ci credi ti dico che
i giapponei costruivano seguendo questo principio le proprie case fino a metà del 1800, rendendole
antisismiche :) ).
But do not program in COBOL if you can avoid it.
Io penso che tutti dobbiamo morire e che poter scegliere di quale morte sia un progresso civile
indiscutibile. :)
Come dico spesso, ricordate che il linguaggio di programmazione più
usato e diffuso al mondo è... il PostScript.
:)
--
Ciao,
Mario.
"Le persone oneste e intelligenti difficilmente fanno una rivoluzione, perche' sono sempre in
minoranza." Aristotele
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
