Newsgroup: it.comp.programmare
Titolo: riflessioni sull'apprendimento della programmazione

in questi giorni mi sto cimentando nell'apprendimento di quest'"arte", ma mi 
sono sorti diversi dubbi..
ho 18 anni, frequento il liceo scientifico e non vado molto bene in 
matematica, l'anno prossimo vorrei iscrivermi ad 'informatica'.
il problema è che ho paura di non essere 'portato'.
grazie ai vostri consigli ho scelto di iniziare con "python", in effetti la 
sintassi del linguaggio è intuitiva e semplice, però, è normale che dopo 
aver letto la guida 'istant hacking' (tradotta in italiano da Alex 
Martelli), mi blocco *piu di 2 ore* per risolvere un esercizio che mi 
sembrava banalissimo? (scrivere un programma che legge numeri scritti 
dall'utente e li somma finchè la somma arriva a 100)
ecco cosa ho prodotto dopo enormi fatiche:
#!/usr/bin/env python2
numero_da_raggiungere=100
addendo = input("inserisci numero: ")
while addendo < numero_da_raggiungere:
        addendo2=input("inserisci numero: ")
        addendo=addendo2+addendo
        print addendo
print "ok"
ho fatto non so quanti tentativi prima di arrivarci, e non so nemmeno se è 
il modo migliore per farlo...
il problema è che finchè vedo degli esempi se ci penso un pò capisco come 
funzionano, ma se sono lasciato 'al mio destino' a risolvere un problema 
che non ho mai 'letto/studiato' mi perdo...parlo del 'ragionamento', quindi 
è un discorso indipendente dal linguaggio...(la sintassi ce l'ho)
sono normali queste frustrazioni iniziali o proprio non fa per me?
grazie :)
P.S.
sono ancora in tempo per iscrivermi a filosofia :P

grazie :)
Facendo esercizi tutto ti semrerà più facile.
-- 
Marco Barisione (ICQ 84277092)

 sono ancora in tempo per iscrivermi a filosofia :P
Facolta` rispettabilissima, se e` il lavoro del filosofo quello che
ti attira.  Ma ricorda che Platone si rifiutava di insegnare
filosofia a chi non si dimostrasse anzitutto disposto alla fatica
di studiare la geometria, che all'epoca era praticamente tutta la
matematica "rigorosa" -- e` una palestra di disciplina del tutto
indispensabile per chi vuole poi affrontare i problemi assai piu`
difficili di cui un filosofo dovrebbe occuparsi.
Alex

 print "OK, fatto"
Scusa, ma Phyton come si 'accorge' della fine del costrutto while? 
-- 
Luc.

Luc wrote:

Quando l'indentazione rientra al livello dell'istruzione while (o
piu` a sinistra ancora), l'istruzione while e` terminata.
In pratica, quell'indentazione uniforme dei blocchi che si usa per
convenzione in tutti i linguaggi (assieme a begin/end, graffe, o
altro), in Python si usa _invece_ di avere bisogno di begin/end ecc.
Il risultato e` codice molto pulito _e_ nessun rischio di errori
come quello classico in C:
    if(uno)
        if(due)
            unoedue();
    else
        nonuno();
dove qualunque lettore umano rischia di pensare che nonuno() viene
chiamata tutte e sole le volte che 'uno' e` 0, e se 'uno` e` != 0
e 'due' e` 0 non succede niente (perche` questo suggerisce
l'indentazione, che un lettore umano "vede" a colpo d'occhio!)
mentre in realta` nonuno() viene chiamata se 'uno` e` != 0
e 'due' e` 0, mentre se 'uno' e` 0 non succede niente (perche` il
C ignora l'indentazione e associa ogni else con l'if precedente
piu` vicino cui puo` associarlo in caso di ambiguita`).  E` il
tipo di sciocchi bachi che possono fare sprecare tempo: l'uso
dell'indentazione come indicazione della struttura dei blocchi
elimina la possibilita` di questo tipo di bachi in Python.
Altri linguaggi che usano regole simili sono Occam (programmazione
concorrente, soprattutto sui Transputer) e Haskell (programmazione
funzionale).
Alex

dall'utente e li somma finchè la somma arriva a 100)
Io ti darei questi consigli:
1) Non usare il PC per cercare una soluzione: usa il PC solo per
verificare che la soluzione che hai trovato funziona veramente. Se
funziona hai vinto. Se non funziona allontanati dal PC e prova a
scoprire il motivo. (in questo modo si impara a trovare la soluzione
ragionando e non andando per tentativi a scrivere istruzioni sul PC)
2) Il ragionamento e' importante. Deve essere semplice, spontaneo e
lineare. Tanto piu' e lineare, e tanto piu' e' facile che il risultato
sia quello cercato. Prova anche cosi'. Se qualcuno viene da me e mi
chiede: "leggi i numeri fino a quando la loro somma e' 100 " . 
Io faccio questo (PASSO A):
-leggo un numero
-se la somma di tutti i numeri letti e' >100 : ho finito
-leggo un numero
-se la somma di tutti i numeri letti e' >100 : ho finito
-leggo un numero
-se la somma di tutti i numeri letti e' >100 : ho finito
...
Facile no! Con due sole istruzioni ho risolto il problema. E questo e'
esattamente quello che farei se fossi un PC che deve risolvere quel
problema. Ora pero' dobbiamo formalizzarlo: un programma non puo'
avere codice di lunghezza infinita.
Usando i cicli diventa cosi' (PASSO B):
leggo un numero
se la somma di tutti i numeri letti e' < 100
   leggo un (altro) numero
E la soluzione scritta in linguaggio italiano e' (PASSO C):
leggo numero
somma=numero
mentre somma < 100 fai
   leggo numero
   somma=somma+numero
Questa soluzione si comporta come la tua, pero' e' piu' leggibile
perche' alle variabili ho associato nomi che fanno capire a cosa
servono e cosa rappresentano.
A questo punto, implementare il codice in un linguaggio qualunque
(Python) e' molto semplice (PASSO D): basta tradurlo.
In sintesi per risolvere questo problemino ho fatto questo:
PASSO A 
Ho scritto la sequenza di cose che io farei se fossi il PC.
PASSO B
Ho sostituito la sequenza infinita di istruzioni con un ciclo while
PASSO C
Ho scritto l'algoritmo in italiano (ossia il nostro linguaggio
naturale)
PASSO D 
L'ho tradotto in un altro linguaggio.
Poniti come obiettivo quello di fare direttamente il passo C: senza
fretta e con il massimo della tranquillita', se ti innervosisci la
soluzione diventa caotica (altro che lineare!) e non funziona.
Ed usa il PC solo per scoprire se l'algoritmo sviluppato e' corretto.

 Scusa, ma Phyton come si 'accorge' della fine del costrutto while?
Quando l'indentazione rientra piu' a sinistra.
Questo fara' finalmente in modo che la gente indenti in modo corretto ;)
--------------------------------
Inviato via 
http://usenet.libero.it

 Questo fara' finalmente in modo che la gente indenti in modo corretto ;)
Questo è vero....
-- 
Luc.

 ROTFL!!!!!!!!!!!!
Che ci trovi di tanto divertente ?


 Che ci trovi di tanto divertente ?
Un linguaggio che basa la sua struttura sugli "spazi" nel codice... 
Dai... ;(
 
-- 
Luc.

 Questo fara' finalmente in modo che la gente indenti in modo corretto ;)
Oddio... le risate se uno deve trascrivere un algoritmo proveniente da
qualche parte, se quella fonte smangiucchia o comunque altera l'indentazione
di quello che e' stato scritto... :)
*** Azimuth ***

Azimuth wrote:

Piu` o meno come dover trascrivere un programma C o Java da una
fonte che smangiucchia o altera le parentesi graffe o la
distinzione fra minuscole e maiuscole.  Fortunatamente non occorre
progettare i linguaggi di programmazione in modo che i programmi
restino corretti dopo trasmissione su di un canale disturbato.
Alex

 restino corretti dopo trasmissione su di un canale disturbato.
Software (di qualunque tipo) che lavora su file ASCII mangiandosi 
parentesi è moooolto più difficile da trovare che uno che si mangi gli 
spazi...
Python??? MMMMMaPPPPPerpiacere!!!!!!! ;-PPPPP
-- 
Luc.

 Python??? MMMMMaPPPPPerpiacere!!!!!!! ;-PPPPP
Non mi pare che tu sia minimamente qualificato per i giudizi
che stai esprimendo, ne`, peraltro, che tu stia portando la
benche` minima argomentazione, o esempi concreti, per
sostenerli: forse perche` non hai nessun esempio concreto
e nessuna argomentazione appena appena sostenibile?
Quando non si ha nulla di valido da dire su di un argomento,
basterebbe un minimo di senso comune per scegliere di stare
zitti.  C'e` invece chi preferisce fare figuracce...
Alex

Python??? MMMMMaPPPPPerpiacere!!!!!!! ;-PPPPP
io nn ci trovo nulla di divertente
--
Rhymes (rhy...@NOSPAMmyself.com)
http://www26.brinkster.com/rhymes
" ride or die "

 Dai... ;(
"Dai" cosa ? A mio avviso, e' un grosso vantaggio.
O forse tu ami leggere codice del tipo:
#include<stdio.h>
int main()
{
int i,j;
for(i=0;i<10;i++)
{
for(j=0;j<20;j++)
{
printf("%d\n", i*j);
}
}
}
Perlomeno Python ti *obbliga* a scrivere codice leggibile.


 di quello che e' stato scritto... :)
No, aspetta, fammi capire: se io devo trascrivere del codice C corretto
(dove, quindi, non manchino elementi lessicali) non vedo dov'e' il problema:
in C, anche alterando l'indentazione, non si altera il funzionamento del
programma e quindi anche il codice Python risulta corretto. Se devo
trascrivere del codice Python, l'indentazione non puo' essere stata alterata
alla fonte, perche' sarebbe, alla fonte, un programma non funzionante. Se
poi parli di alterazioni che avvengono lungo il percorso (ma dubito che
stessi parlando di questo) nessuno puo' prevedere che cosa succeda anche a
del codice scritto in un altro linguaggio, quindi il problema non si pone.



<espressione_tra_il_sorpreso_e_il_disgustato>
Alt123, Alt125, che problema c'e`??
</espressione_tra_il_sorpreso_e_il_disgustato>
Ahhhhhhhh! Adesso mi sento meglio.
Scusami ma erano anni che aspettavo il momento per poterlo dire 
anch'io a qualcuno!
Alt99Alt105Alt97Alt111 
Andrea Vinzoni

 Python??? MMMMMaPPPPPerpiacere!!!!!!! ;-PPPPP
Luc, attento, l'ultima volta che abbiamo discusso di argomenti del genere
hai preso sonore bacchettate sulle orecchie, evita di fare brutte figure ;))
Comunque, tanto per fare due chiacchiere, ti informo che Python sta avendo
una progressiva diffusione nell'ambito della programmazione cosiddetta
"seria". Per esempio Blender 3D, ottimo programma di grafica
tridimensionale, utilizzato per la realizzazione di qualche film di ultima
generazione, ne fa largo uso al suo interno, cosi' come Poser, uno dei
migliori programma di rendering 3D.


 corso introduttivo di A. Gauld tradotto in italiano da Fini).
grazie a tutti dei suggerimenti!
per quanto riguarda quel sito, diverse pagine della guida non sono 
raggiungibili! (error 404..), sai posso trovarle a qualche altro indirizzo?
grazie!

 Intendi ingegneria informatica, o scienze dell'informazione?
non ingegneria, è il dipertimaneto di informatica a torino (centro piero 
della francesca).
a proposito, qualcuno frequenta/conosce questa scuola?
sul sito 
www.unito.it
 si presenta bene...che ne dite?
grazie mille di tutti i consigli!

migliori programma di rendering 3D.
Non dimentichiamoci google, il motore di ricerca piů potente che abbia
mai trovato.
Comunque qui ci sono un po' di aziende che lo usano:
http://www.python.org/psa/Users.html


Alt123, Alt125, che problema c'e`??
Scusate l'intromissione, ma...
ALTGR + SHIFT + [
ALTGR + SHIFT + ]
non piace a nessuno?
Ritorno nell'ombra.
-- 
Ciao
	Fabrizio C.

 Alt123, Alt125, che problema c'e`??
Devi premere TRE tasti per la funzione di UNO (piu` shift o alt in ambo
i casi) e chiedi che problema c'e`...?!  Senti, se la tua splendida tastiera
ti chiedesse di usare questo metodo per comporre TUTTI i caratteri,
lo capiresti, "che problema c'e`", o no...?
Alex

 zitti.  C'e` invece chi preferisce fare figuracce...
Ti ripeto, mi manca solo il tempo. NON temo figuracce quando DECIDO di 
partecipare ad un thread.
Sorry, NO BONUS! 8-PPPPP 
-- 
Luc.

 Perlomeno Python ti *obbliga* a scrivere codice leggibile.
L'unica entità che mi può obbilagare a fare qualcosa... è mia moglie!?!? 
;)
-- 
Luc.

 lo capiresti, "che problema c'e`", o no...?
[CTRL]+[SHIFT]+[ALT]+'[', comodissima e rapida.
E non diciamo CAZZATE sulla tastiera per giustificare Phyton, linguaggio 
che conosco poco ma che già 'inquadro' dalle parti del VisualBasic....
Attendo smentite, comunque.
-- 
Luc.

 "seria".
Si... Quando la smetteranno di scrivere nuovi linguaggi??? Non se ne può 
più!
Ho appena letto l'instant-hacking...
E' (sembra) un linguaggio scopiazzato, senza infamia e senza lode.... 
Ovviamente escludendo l'indent... ;-))))
-- 
Luc.

 che conosco poco ma che già 'inquadro' dalle parti del VisualBasic....
Visto il resto della discussione, e` normale: trovi Python "risibile"
perche` usa gli spazi per indicare la struttura dei blocchi (che pare
sia l'unica cosa che sai di Python: e la sai perche` l'hai chiesta e
ti e` stato risposto) quindi "lo inquadri" assieme ad un linguaggio
che NON fa assolutamente nulla del genere.  Tipico.
Alex

 partecipare ad un thread.
Si vede che non le temi: devi esserci proprio molto abituato.
Alex

 perche` usa gli spazi per indicare la struttura dei blocchi
Confermo al 100%, mi dispiace.
Ed ora torno alle mie {{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}} del C++.
-- 
Luc.

 Ovviamente escludendo l'indent... ;-))))
Ah certo, con tutti i virus divoraspazi che infestano il
ciberspazio, bisogna proprio starci attenti...!
Alex

 Si vede che non le temi: devi esserci proprio molto abituato.
Torna a consulire... 8-PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
-- 
Luc.

 
La mia non pretende di essere una smentita, solo un parere diverso.
E adesso chiudo qui perchè, come diceva mia nonna, a esprimere pareri 
su cose che non si conoscono bene si richia solo di fare figuracce...
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 Torna a consulire... 8-PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
E` certamente piu` lucroso che non fare a pezzi i piu`
sconsiderati sbruffoni della rete, ma come divertimento
e varieta` entrambe le cose hanno dei punti di forza.
Comunque ho sempre dedicato parte del mio tempo ad aiutare
la gente sui newsgroups (per questo sono stato nominato
per uno dei premi "Programmers' Choice" di ActiveState di
quest'anno -- ho vinto pero` solo l'"Activators' Award",
grosso mood l'equivalente in questo campo di una "menzione
speciale della giuria":-), mentre il piu` prestigioso 
"Programmers' Award" e` andato, meritatamente, a Robin Dunn).
Purtroppo in certi casi il massimo aiuto che si puo` dare
e` il sincero consiglio "ma vatti a nascondere" (perche`
certe persone, nascondendosi, eviterebbero almeno le
peggiori figuracce), e in questi casi non evito di farlo.
Alex

 Dipendente per oltre vent'anni
Ok, guarda che ti leggo spesso. Sicuramente tu sei "più" di me, non lo 
metto in dubbio. Mi dispiaceva solo che fossi caduto su un linguaggio 
come il python che "conosco" da ieri e si presenta come adatto 
specialmente ai principianti.
Ricordi il primo post del thread?
Per il resto, le offese "professionali" su di me scivolano via come 
l'olio, credimi.
-- 
Luc.

 Ed ora torno alle mie {{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}} del C++.
Certo non quanto i luminari di C++ che ti ho gia` elencato fra i
patiti di Python, ma anch'io (MVP di Brainbench per il C++, tra
l'altro) dubito di avere gran che da imparare da te sul C++ -- penso
che alcuni dei "veci" di it.comp.lang.c++ si ricordino ancora di me,
anche se e` un pezzo che non lo bazzico.  Fatti tutte le graffe che
vuoi, e buon pro ti facciano.
Alex

 Dai... ;(
Non vorrei mai che tu tralasciassi questo ottimo linguaggio solo perche` 
non si usano delimitatori per i blocchi:
#!/usr/bin/python
begin = '#begin'
end = '#end'
indent_size = 4
def blockify(input, out):
    indent = 0
    for line in input:
        s = line.strip()
        if s == begin:
            indent += indent_size
        elif s == end:
            indent -= indent_size
        else:
            out.write(' '*indent + s + '\n')
if __name__ == "__main__":
    import sys
    input, output = sys.stdin, sys.stdout
    try:
        input = open(sys.argv[1])
        output = open(sys.argv[2], 'w')
    except:
        pass
    blockify(input, output)
Questa e` una prova del funzionamento:
[anto@anto blockify]$ cat prova.py
def prova():
#begin
print 'ciao'
if 1:
#begin
print 'buongiorno'
#end
#end
[anto@anto blockify]$ ./blockify.py prova.py
def prova():
    print 'ciao'
    if 1:
        print 'buongiorno'
Ovviamente non e` completo (ad esempio non gestisce bene le triple-quoted 
string) ma magari ti puo` essere d'aiuto :-))
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 ha scritto nel messaggio
news:MPG.18060c94c...@tornado.fastwebnet.it...

[ALT GR]+[SHIFT]+'[' con una sola mano... ;)
Martino

 tua presenza nella comunita`
Stai parlando di una cosa (la mia professionalità) che non conosci, ma ti 
perdono. 
-- 
Luc.

 l'olio, credimi.
Gia`, immagino, ci sarai cosi` abituato da non farci piu` caso.
Buon per te, visto il tuo comportamento sui newsgroup.
Alex

 E' (sembra) un linguaggio scopiazzato, senza infamia e senza lode....
Sei libero di non usarlo. Essendo un vero uomo userai il C++ ;)
In ogni caso, se tu avessi conosciuto l'Algol68 o il PL/I avresti giudicato
una loro scopiazzatura tutti i moderni linguaggi (dal Pascal, al C, al C++).


 perdono.
La professionalita' si dimostra anche nelle cose che si scrivono e tu, senza
offesa, non la dimostri. Non puoi, poi, pretendere che gli altri usino le
buone maniere, se cominci a parlare a vanvera. Diciamoci la verita', ti
piace denigrare cose che non conosci e questo e' uno dei difetti peggiori.
Non e' la prima volta che lo fai, l'hai gia' fatto con Delphi e lo stai
facendo con Python. Non so il perche', ma chi si comporta cosi' non e'
etichettabile con null'altro che la parola "troll".


 l'olio, credimi.
Ci hai fatto il callo, eh ? :)


 ciberspazio, bisogna proprio starci attenti...!
AHAHAH...


 etichettabile con null'altro che la parola "troll".
Ciumbia!!! E poi???
-- 
Luc.

 linguaggio (e programmo dal 1985).
A parte che non capisco cosa c'entri questa risposta con quanto ti e' stato
detto.
Che tu non sia qualificato per esprimere giudizi su Python mi sembra
evidente.
Imparalo, programmaci e poi ne riparliamo. Se ribatti, pero', fallo per
cortesia con argomenti seri, non con baggianate farcite di faccine senza
senso.
Non spaventi nessuno dicendo che "programmi" dal 1985.


 Forse, ma mai completamente alla 'ca**o'. ;)
Io mi preoccuperei anche di quel "forse".


 Allora sul lavoro devi essere proprio una persona diversa.
Si, il 100% lo do sul lavoro (con risultati ottimi, a quanto so), il 
restante 5% è per i NG. ;-)
-- 
Luc.

 
Luc, uomo al 105% :)
Forse č il caso di chiudere questo thread...


 Per tornare ad un esempio "pratico": HTML.
Cioe' ? spiega.


 del codice scritto in un altro linguaggio, quindi il problema non si pone.
Il problema accade quando un sorgente viene passato attraverso un meccanismo
che altera il significato di alcuni caratteri, prima di giungere a
destinazione.
Il carattere spazio e' un carattere che ha un significato diverso se scrivi
qualcosa per un compilatore o per un impaginatore di testi.
Il numero di spazi contigui, ad esempio, puo' o no essere mantenuto, a
seconda della "convenienza", durante un fenomeno di giustificazione.
Per tornare ad un esempio "pratico": HTML.
Altro esempio pratico: PERL con alcune sequenze di pattern matching.
I caratteri '{' e '}' non soffrono di questi problemi, essendo il loro
significato il medesimo con entrambi i tipi di programmi (e con l'HTML!).
*** Azimuth ***

 Forse è il caso di chiudere questo thread...
Anche perche' gia' quel 5% e' nauseante, figuriamoci il resto ;))


 Anche perche' gia' quel 5% e' nauseante, figuriamoci il resto ;))
Please, shut up! ^__^
-- 
Luc.

 
http://www.python.org/psa/Users.html
Hai ragione, ma sono tutte aziende piccole, comunque, vedi la NASA,
L'Industrial Light & Magic (gli autori degli effetti speciali di Star Wars,
per intenderci), l'IBM, la Walt Disney, l'Universita' della California, Red
Hat, Yahoo (etc... etc...).
Sai, quando Luc ha lavorato per tutte queste aziende si usava ancora il
Basic del C64, pensa che dovette modificare il parser per fargli supportare
l'indentazione !...
Pensa che l'Ariane V l'ha programmato lui !
ROTFL ;)


 Pensa che l'Ariane V l'ha programmato lui !
Sai che mi sai di sfigato??? Tua moglie che dice di te?
-- 
Luc.

 Cioe' ? spiega.
Prova a scrivere questo file:
=== CUT HERE, FILE: prova.html ===
<HTML>
<HEAD></HEAD>
<BODY>
Prova
Riga 1    AAAA
Riga 2    BBBB
   Riga 3     CCCCC
</BODY>
</HTML>
=== CUT HERE, FILE: prova.html ===
Ora prova a caricare questo file con un browser qualsiasi e a contare gli
spazi fra le parole (con un cut'n'paste su Notepad, ad esempio). Quanti
spazi conti? Soprattutto QUANTE RIGHE CONTI?
Ciao!
*** Azimuth ***
[1] Sia chiaro, non amo assolutamente XML!
[2] Per esempio, cosa segnala la fine di una riga? Sei sicuro che una riga
che finisce per me finisca per te o per chiunque altro?

 e' inutile che continuiamo
Lascia perdere, Laforge & Martello non lo ammetteranno mai.
PS: ovviamente sono 100% in accordo con te, Azimuth. Tu ti sei spiegato 
più prolissamente.
-- 
Luc.

 un'altra.
Nei romanzi, non nei linguaggi di programmazione.


 Tua moglie che dice di te?
Non ho moglie (non ancora), e nel tuo caso mi sa che la sfigata vera e' lei


 più prolissamente.
Be', tu non ti sei spiegato proprio (al solito, tiri il sasso e ritiri la
mano), quindi immagino per te sia un bel risultato ;) peccato che
l'argomentazione di Azimuth sia un po' fallace ;)


 Cominci a storpiare i nomi...
Io avrň pure parlato male di python, voi avete incominciato a farlo di 
me.
Siete delle 'CACCHE', per favore, killatemi!
E basta con le faccine da ebete... CRIBBIO.
-- 
Luc.

 Siete delle 'CACCHE', per favore, killatemi!
E tu sei un puzzone ! e se non la smetti chiamo la suora ! :)
Oh, no, non ti killero' mai, quello che scrivi e' troppo divertente ;)


 Personalmente, non ho mai parlato male di te
Mah...
-- 
Luc.

si presenta come adatto specialmente ai principianti.
Io in quanto principiante mi sento offeso. E' da qualche tempo che
frequento (per modo di dire) la comunità Python (anche se non ho più
tempo per seguire il NG di Python) ma di una cosa sono completamente
sicuro: Python è un ottimo linguaggio ed è adatto ai principianti
TANTO QUANTO ai professionisti. 
Non hai le basi? Parti col Python
Vuoi un linguaggio facile e potente? Usa il Python
Vuoi fare cose "avanzate"? il Python è li apposta per te
Proprio in questi giorni ho indirizzato un paio di amici programmatori
(hobbysti) su IRC ad utilizzare Python come linguaggio di scripting
nel motore 3D che stanno sviluppando... appena si sono letti il
tutorial e un paio di docs sulla rete sull'argomento mi hanno
ringraziato...non immagini quanto...nemmeno avessi salvato loro la
vita.
Questo banale esempio per dire: Python può ed è l'alternativa a
parecchie cose anzi è la scelta primaria per molte di esse. 
Il grosso problema di Python (ma che di qui a poco tempo credo si
risolverà) è l'ignoranza delle persone (anche io all'inizio ero
titubante - vero Alex?), l'ottusità di alcuni accademici e la
diffidenza di alcune aziende.
Luc, senz'offesa, so che sei un programmatore migliore di me (senonchè
perchè conosci il C++ - che io tento di studiare a tempo perso :(( ma
questa sparata te la potevi evitare perchè ti sei tirato addosso
parecchia gente :(
saluti!
un Rhymes che tenta di propagare il Python-verbo ai suoi amici
(peccato che loro codino tutti in 3D e di Python non ne vogliano
sapere :( e che allo stesso modo tenta di imparare il C++ e non il C
with objects
--
Rhymes (rhy...@NOSPAMmyself.com)
http://www26.brinkster.com/rhymes
" ride or die "

 Ma che ca..volo **c'entra** questo con la bonta' o meno di Python ???
Vedi sopra.
*** Azimuth ***

Hat, Yahoo (etc... etc...).
eheh Andrea ti giuro che a colpo d'occhio ho letto "industrie piccole"
e "Industrial L&M" e mi sono detto: ma Lafogia sta dando i numeri ?
:PP


E' (sembra) un linguaggio scopiazzato, senza infamia e senza lode.... 
LOL!! Scopiazzato da che??


ma Lafogia 
ovviamente Laforgia


 (peccato che loro codino tutti in 3D e di Python non ne vogliano
Mah, fagli visitare 
vpython.org
, o 
http://alice.cs.cmu.edu/
 , oppure
http://www.3dartist.com/3dao/r/allenbil/python/
 (che nomina
Blender, trueSpace, e altre app commerciali 3D che usano Python), 
http://pyopengl.sourceforge.net/
 se amano OpenGL, 
http://starship.python.net/crew/jriehl/pycdx/
 se vogliono
invece usare DirectX, http:/
threedom.sourceforge.net/
 se
vogliono un solid modeler indipendente dalla parte di rendering,
oppure 
http://prettypoly.sourceforge.net/
 , o magari
http://dmoz.org/Computers/Programming/Languages/Python/Modules/Scientific/
se quello che vogliono fare in 3D sono modelli di molecole,
ecc ecc.  Di "3D" ce ne sono tanti, mi sembra che Python brilli
in svariate nicchie di questo enorme, sfaccettatissimo settore.
Alex

 Ritengo che il linguaggio vada esaminato fin dalle basi.
I problemi di impaginazione e pubblicazione del codice sorgente di un
linguaggio non sono AFFATTO problemi del linguaggio.


in svariate nicchie di questo enorme, sfaccettatissimo settore.
mmm principalmente modellazione e animazione 3D per terrain,
personaggi ecc ecc per videogiochi comunque passerò loro sti links :)


 se aprissi il file creato sotto UNIX con Wordpad e non con Notepad.
Peccato pero' che tale traduzione sia NECESSARIA con uno (PYTHON) e
ININFLUENTE con l'altro (C/C++ e compagnia cantante).
*** Azimuth ***

</HTML>
Il problema è che lo spazio in HTML è codificato con una sequenza 
particolare &nbsp (se la memoria non mi tradisce), così come sono 
codificati in modo diverso anche altri caratteri, tanto che nemmeno 
un listato in C/C++ che utilizzi un maggiore o un minore può essere 
inserito "impunemente" nel tuo HTML (per la fasciatura al piede passa 
in infermeria).
Se un "formattatore" converte il testo in HTML senza convertire 
correttamente gli spazi, il problema è del convertitore, non di chi 
ha scritto il testo.
Credo che l'indentazione obbligatoria di python sia una delle 
caratteristiche che contribuiscono a rendere questo linguaggio 
particolarmente chiaro e comprensibile, "obbligando" a scrivere 
codice chiaro e comprensibile (cosa che con le graffe di C/C++ non 
sempre avviene, visto che ci sono diverse "convenzioni" stilistiche e 
che i sostenitori di una convenzione sono generalmente "allergici" 
alle altre).


 
Direi al 105% :P


 uso di questa tecnica, e per ovvi motivi[2].
In XML, la distinzione fra maiuscole e minuscole e` sempre
significativa (forse la singola differenza piu` clamorosa fra
il buon vecchio HTML e il nuovo XHTML).  Inoltre sono significativi
la maggior parte degli spazi e dei fine-riga (lo standard XML
definisce specificamente una categoria di "ignorable whitespace"
ma in essa NOn rientra tutto il normale whitespace che risulta
invece parte del contenuto testuale degli elementi): se un parser
XML consuma o trasforma in qualsiasi modo questi caratteri e` in
grave violazione dello standard, ne` piu` ne` meno di quanto lo
sarebbe consumando o trasformando lettere, cifre, punteggiatura.
In un altro post porti un esempio di un programma in cui sono
stati ignorati/trasformati (oltre agli spazi) anche i fine-riga.
Questo tipo di trasformazione puo` facilmente alterare (o, se
preferisci, creare ambiguita`) anche in programmi C++,Java, C#
(e C a standard 1999) -- una cosa e`, ad esempio:
    blahBlah();  // blah blah
    blohBloh();  // ecc ecc
e tutt'altra, ben diversa, e` invece:
    blahBlah();  // blah blah  blohBloh();  
    // ecc ecc
Eppure l'introduzione della possibilita` di commentare con //
(in alternativa al + goffo /* ... */) e` universalmente accettata
come una GRANDE MIGLIORIA di C++, tanto e` vero che l'hanno poi
adottata anche i peggiori avversari di C++, come appunto Java, C#,
e persino C stesso (nello standard del 1999).  O com'e`?  Non e`
appunto il // che rende tanto PIU` significative le fine-riga (lo
erano gia` anche in C per direttive come "#include", necessita`
di chiudere le virgolette entro fine riga, ecc, ma con quell e`
piu` difficile costruire due programmi validi e diversi che si
trasformano l'uno nell'altro inserendo/togliendo fine-riga) e
quindi secondo te "rende decisamente piu' fragile" il C++, il
Java, il C#, il C secondo il nuovo standard, rispetto al C che
si poteva scrivere nello standard vecchio...?
La soluzione e` evidente: *NON INTERESSA MINIMAMENTE* se un
programma possa sopravvivere intatto o ricostruibile ad un
generico filtro testuale che ne altera il whitespace in modi
arbitrari, particolarmente distruggendo i fine-riga come nel
tuo esempio.  L'uso di // permette di commentare in modo piu`
agevole e leggibile, e tanto basta (addirittura tanti
compilatori C l'hanno introdotta come estensione, mutuandola
dal C++, quando ancora lo standard [dell'89/90] lo proibiva...).
La situazione non e` molto diversa per quanto riguarda il
trasformare qualsiasi sequenza di spazi in uno spazio solo.
E` facilissimo scrivere programmi in qualsiasi linguaggio
la cui "ricostruibilita`" e` annientata da un massacro del
genere, basta che abbiano dentro qualche literal stringa
come "   " o "  " e la distinzione fra di esse abbia una
qualche importanza.
La differenza E` invece pragmaticamente importante quando
si parla di caratteri di controllo diversi dal fine-riga: li`
si` che rischi grosso se speri che tutto il software che
_normalmente_ si usa con i programmi lasci in pace i tuoi
caratteri di controllo!  Appunto per questo il C (e tanti
altri linguaggi, come Python) permettono di usare notazioni
come \03 per indicare (ad es entro una stringa) un certo
carattere di controllo, o anche notazioni piu` leggibili
come \t per un tab (piu` leggibile di \09).  Che io sappia,
solo Perl (e Ruby, il cui autore copio` la caratteristica
dal Perl e ha pubblicamente dichiarato di essersene tosto
pentito) permettono di usare caratteri di controllo come
*nomi di variabili* -- non certo Python.  Se vuoi sostenere
che Perl (e forse Ruby) "non possono essere validi" per
questa sola ragione, accomodati, litigherai coi patiti dei
linguaggi stessi:-).
L'unico carattere di controllo (a parte il fine-riga) che
si trova abbastanza spesso nel corpo dei programmi e` il
tab, e a mio parere sarebbe meglio non usarlo proprio,
appunto per evitare problemi.  Che io sappia, l'unico
"linguaggio" che *vuole* a ogni costo dei tab (e non
accetta equivalenti sequenze di spazi bianchi) e` quello
di "make", nota utility di programmazione (tipico sintomo
dell'aver usato spazio invece di tab, il messaggio di
errore "must be a separator on line ...").  [Esiste anche
un formato-dati analogo al CSV che usa tab come separatori,
invece delle virgole.]  Qui si` che siamo sul fragile, e
nel caso di "make" a mio parere anche sulla scarsa
usabilita` per esseri umani tipici.  Ma in Python puoi
benissimo usare spazi (e fine-riga come unico carattere
di controllo) evitando sempre i tab (e questo appunto
prevede la guida allo stile standard, anche se il compilatore
accetta anche i tab; puoi usare lo switch -t per avere
warning, o -tt per avere errori di compilazione, in caso 
di problemi di uso congiunto di tab e spazi).
Alex

 codice chiaro e comprensibile
Delle linee guida di stile potrebbero bastare. :)
*** Azimuth ***

 qualche importanza.
Scusa, ma chi e' che programma cosi'? Hai dei casi reali?
Ciao!
*** Azimuth ***
[1] "Mie" nel senso "della mia azienda". <g>

 fissa, non vedo proprio dove sia il problema.
Tanto per precisione, mi sembra che queste tue specifiche siano
piu` rigorose del necessario, e, di conseguenza, che la soluzione
che proponi sia piu` restrittiva di quanto strettamente occorra.
Non e` necessario usare un font a spaziatura fissa, perche` non e`
necessario far vedere a video *esattamente* quanti spazi ci sono
nel codice.
E` sufficiente che si distingua in modo visivamente agevole se due 
linee hanno al margine sinistro la stessa spaziatura, ovvero quale
l'abbia minore o maggiore dell'altra.
Questo requisito e` soddisfatto da tutti i font a spaziatura
proporzionale che abbiano una larghezza (abbastanza) maggiore di 0
per lo spazio (e se non ce l'hanno, leggituttiitesticosi`...:-).
Se poi abbia mai SENSO presentare un programma in spaziatura
proporzionale, e` un altro discorso.  Ma non e` un problema in
Python piu` di quanto possa esserlo in qualsiasi altro linguaggio.
Alex

 ININFLUENTE con l'altro (C/C++ e compagnia cantante).
Non e' affatto vero, e' NECESSARIA per l'uno e per l'altro.
Il contenuto dei file di testo NON CAMBIA, la struttura del file di testo
CAMBIA, ma la struttura, convertita, ti consente di leggere la STESSA
identica informazione e questo a prescindere da cosa sia CONTENUTO nel file.


 Scusa, ma chi e' che programma cosi'? Hai dei casi reali?
"Chi e` che" include nei suoi programmi letterali-stringa con
due o piu` spazi bianchi adiacenti?  Ma scherzi?!  Greppa un
po' qualsiasi bella massa di sorgenti poi mi sai dire.  Non
ho nessun "caso reale" in cui nessun programma del genere sia
mai stato massacrato dal temibile virus magnaspazi, ma se e`
per questo non ne ho neppure per Python:-).  [I virus
magnatab invece si`, compreso un paio di dannati casi in cui
l'autore aveva usato virgolette - tab - virgolette e simili
invece di '\t' e simili -- e, apriti cielo -- ma come gia` detto 
l'uso dei tab nei sorgenti e` una pessima prassi).
Alex

 Questo aiuta molto a rendere comprensibili i sorgenti.
Cazzata. Se mi sbaglio (siamo umani, succede) e al posto di usare "PIPPO"
uso "pippo", che cosa succede ? il razzo esplode ?


"Azimuth" ha scritto  
Prova ad usare <PRE> code </PRE>; per l'include devi usare
&gt; e &lt;
 
<HTML>
<HEAD> </HEAD>
<BODY>
<PRE>
#include &lt;stdio.h&gt;
int main( int _argc, char * _argv[] ) {
 
  if ( _argc < 1 )
   printf( "Argh!" );
  else
   printf( "Ouch!" );
 
  return 0;
 
};
</PRE>
</BODY>
</HTML>
HTH Massimo

portatile -- argh!
E se gli vuoi spedire un file binario? E se gli vuoi spedire un
Makefile?
-- 
Marco Barisione (ICQ 84277092)

 
In questo modo il linguaggio č molto chiaro e i listati piů corti. 
E' una scelta discutibile, come ce ne sono in tutti i linguaggi, ma ha 
le sue motivazioni. Le linee guida non avrebbero avuto la stessa 
efficacia e avrebbero comunque resa necessaria l'introduzione di dei 
marcatori di inizio/fine blocco.


 E in base a *quale* principio, di grazia ?
Il word wrap automatico.
[snip per diminuire l'impatto sulla banda di tutti]
*** Azimuth ***
[1] Vedo che tu, invece, sei bell'allenato alla mossa.
[2] Ripeto, modifico l'aspetto non il contenuto!
[3] Ovviamente, puo' non essere leggibile, pero' e' ricostruibile -- e
questo e' il punto di partenza per scrivere un codice bello!


Ehhmmmm, ho toppato, dovevo aggiungere qualche faccina, mea culpa.
Chiarisco: la frase "Alt123, Alt125, che problema c'e`??" e` la frase
standard che mi devo sorbire (condita dell'espressione di cui sopra e
dell'immancabile "demo") tutte le volte che mi lamento del fatto
che ovunque mi giro mi ritrovo con tastiere da "segretarie", oppure
per il fatto che ho dovuto passare due pomeriggi su internet prima
di trovare un negozio a milano che vendesse tastiere con graffe, tildi
e compagnia.
Credendo ormai di essere l'unico in Italia ad avere questa 
idioscincrasia per le tastiere con le lettere accentate quando ho visto 
il tuo post ho voluto provare l'emozione per una volta di mettermi dalla 
parte dei piu` ;-)
Chiedo scusa per il qui pro quo e l'irritazione inevitabilente provocata.
ciao (stavolta "in chiaro")
	Andrea Vinzoni

 che conosco poco ma che già 'inquadro' dalle parti del VisualBasic....
ERESIA! :-) Se Python fosse come VB, credi che avrebbe tutti questi 
seguaci? Ti pare per caso che VB supporti la programmazione ad oggetti, 
l'overload di operatori, il caricamento dinamico di moduli? O magari hai 
solo visto le variabili che sembrano simili alle Variant di VB...
Prima di giudicare qualcosa, cerca di conoscerla bene. La prima 
impressione è spesso sbagliata...
-- 
Andrea Bergia - studente
Linux Registred User #281550

parte dei piu` ;-)
Non sei l'unico, poi con ona tastiera impostata con layout americano
internazionale fare gli accenti è semplicissimo.


implicita impedisce cio'.
E perché?


 L'ALT non è necessario. E funziona solo su qualche win.
Piccolissima correzione: è il CTRL a non essere necessario.
Kiuhnm


Ops.


 linguaggio (e programmo dal 1985).
considerando che conosci il C++ e che per quest'ultimo ci vuole come 
minimo qualche mese direi che gli altri li hai imparati in fretta... 
:-))
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 E perché?
La dichiarazione implicita non impedisce nessuna diagnostica di errore, 
come e` ovvio a chiunque conosca i migliori linguaggi (basta vedere
Haskell, Standard ML, eccetera).  Ma e` errata l'implicazione che "la
maggior parte degli errori" POSSA "essere rilevata al tempo della
compilazione": gli "errori di tipo" sono comunque una parte minuscola
degli errori di programmazione, che vanno dagli errori di analisi (il
problema che si risolve non e` quello che serve risolvere) giu` giu`
sino allo scrivere "a+b" come errore di battitura per "a-b".
In pratica, e in qualsiasi linguaggio, la maggior parte degli errori si
trova con il *TESTING* -- dallo "unit testing" su fino al "system
testing" o "acceptance testing" o "functional testing" che dir si
voglia.  Per questo, le buone metodologie moderne di programmazione
enfatizzano questa attivita`.  Highsmith, "Agile Software Development
Ecosystems", Addison-Wesley 2002, e` un buon survey delle varie
metodologie moderne in questione.  Attenzione al rischio di restare
a quel che si insegna (o magari si insegnava pochi anni fa...) nelle
universita` italiane: il mondo va avanti!
Dijkstra, da buon matematico, ha messo sul piede sbagliato un'intera
generazione di programmatori con il suo detto "Il testing puo` essere
usato per dimostrare la presenza di bug, ma non la loro assenza".
Vero, ma e` cosi` che funziona la scienza (come Popper ha mostrato
assai prima: una teoria e` scientifica se anzitutto e` FALSIFICABILE,
cioe` se posso eseguire esperimenti che, se falliti, la dimostrino falsa;
non posso mai aspettare che sia DIMOSTRABILE vera -- questo
succede solo in matematica, non nella scienza).  L'ingegneria si basa
sulla scienza, e la programmazione e` piu` ingegneria di quanto non
sia matematica.  Se i miei test sono abbastanza buoni, non posso
essere sicuro della correttezza del mio programma quanto lo sono
di quella, che so, del teorema di Pitagora; ma POSSO esserne sicuro
quanto della correttezza, che so, della teoria dell'evoluzione.
Naturalmente, qualsiasi suite di test non dico buona, ma appena
appena ai limiti della risicata sufficienza, mostra e permette facilmente
di correggere qualsiasi errore che potrebbe essere rilevato da un
buon compilatore (con inferenza di tipi) o da un compilatore anche
mediocre in un linguaggio che obbliga alle dichiarazioni di tipo.  Dunque
la differenza non e` in termini di solidita` del software risultante: se la
suite di test e` cosi` scarsa da non mostrare neppure simili banali errori,
chissa` quanti altri (+ invece di - ecc ecc) ne nasconde il programma,
probabilmente e` un colabrodo.  L'UNICA problematica rilevante e` 
invece quella della produttivita` dei programmatori: se un linguaggio piu`
oneroso che obbliga alle dichiarazioni, uno piu` rigido e preciso che non
vi obbliga ma esegue type-inferencing (Haskell &c), o uno piu`
flessibile (Smalltalk, Python, Scheme, Erlang, Ruby...) risulti piu` 
produttivo.  Il primo mi lascia trovare gli errori banali qualche minuto 
prima del terzo, il secondo batte gli altri due di qualche altro minuto 
ancora, ma richiede rigore matematico nell'impostazione e vera mentalita` 
matematica sin dal momento del progetto; il terzo e` il piu` flessibile di 
tutti, ma i piu` banali tipi d'errore richiedono 2-3 minuti di piu` per 
saltar fuori.
Le misurazioni confermano l'intuizione: per pochi brillanti soggetti di
spiccata attitudine matematica, Haskell, O'Caml, SML, e simili, hanno
una produttivita` eccellente; Smalltalk, ecc, sono anche migliori da
questo punto di vista per un'amplissima parte della popolazione; i
linguaggi con obbligo di dichiarazione soffrono rispetto ad entrambi.
Totalmente diverso e` il problema delle prestazioni del codice che
puo` essere generato.  Il migliore viene dai linguaggi rigorosi: O'Caml
ad esempio batte quasi inevitabilmente Java (confrontando linguaggi
di livello _quasi_ eguale -- O'Caml e` superiore, ma e` inutile mettere
nel confronto linguaggi-macchina, C, ecc), SML e Haskell non sono
lontani.  Per Smalltalk, ecc, occorrono compilatori MOLTO ben fatti
per raggiungere prestazioni paragonabili, e ben pochi curano cosi`
strettamente l'ottimizzazione ("stalin", compilatore per Scheme, e` un
controesempio: ma sono davvero pochi).  Si evidenzia dunque l'unico
vero vantaggio delle dichiarazioni: aiutano un compilatore non eccelso
a produrre codice migliore.  Il linguaggio Dylan si impernia su questo:
le dichiarazioni sono facoltative, ma se ci sono il compilatore le usa
per guidare l'ottimizzazione.
Per vedere questo concetto applicato a Python, basta esaminare il
dialetto Pyrex, che permette di scrivere "estensioni Python" (che di
solito si scrivono in C o C++): praticamente e` Python piu` una nuova
istruzione cdecl usabile per dichiarare tipi elementari a livello C (e
alcune comodita` come la possibilita` di leggere e studiare un file
d'include del C per guidare l'interfaccia a librerie C esistenti).  Con
questo piccolo aiuto, il compilatore puo` generare codice macchina
che ottiene prestazioni migliori.  Per quel 5-10% circa del codice che
richiede ottime prestazioni, Pyrex e` una buona scelta.
Per vedere invece la type inference al lavoro (alla "stalin"), il progetto
da seguire e` pyro, non pero` cosi` maturo come Pyrex (la type
inference su di un type system non progettato apposta e` ancora
un concetto abbastanza avanzato al giorno d'oggi: fattibile si`, banale
decisamente no).
Il bello e` naturalmente che il 90% o piu` del codice si continua a
sviluppare in Python normalissimo: e` solo alla domanda "che fare
per questa minuscola frazione che deve interagire con la data
libreria esistente o comunque produrre prestazioni massime" che
pyrex o pyro offrono un'alternativa alla panoplia di possibilita` gia`
esistenti (Python-C API, Boost Python, SWIG, pyfort, CXX e SCXX,
Blitz Python, weave, weave.blitz, ...).
Alex

 parte dei piu` ;-)
Ah, si`, siamo almeno in due.  Con le tastiere ce la si cava ancora,
quelle a layout US con un po' di sforzo le si trova -- sono i laptop 
che mi fanno alzare veramente il tasso di bile... (li`, Dell a parte, il
disastro...).
Alex

 Il word wrap automatico.
Quindi il codice C++:
    questasi();  // abakuk snodobas avala questano();
(il commento significa, in dialetto dello Zanzibar, "soprattutto e`
importante non chiamare questano();") potrebbe diventare:
    questasi();  // abakuk snodobas avala 
    questano();
e tu dici che "funziona a meraviglia"?  Il tuo concetto di
meraviglia davvero mi meraviglia.
Alex

 no...? 
quando serve, puoi sempre cambiare layout di tastiera. Con l'"Americano 
Internazionale" di Windows si scrivono, oltre a tutti i caratteri della 
tastiera americana, praticamente tutti i caratteri estesi europei, con 
la tecnica dei "dead key": scrivi il carattere di decorazione - ad 
esempio doppie virgolette per l'umlaut, virgoletta dritta per l'accento 
acuto, virgoletta all'indietro per quello grave, tilde per la en-tilde 
spagnola, ecc - seguito dal carattere da decorare (o uno spazio per 
scrivere un carattere di decorazione letteralmente). Inoltre in Windows 
puoi configurare più layout e cambiarli al volo quando serve
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 commenti)
in Pascal c'erano dei digraph per le tastiere o stampanti senza certi 
caratteri. Ne ricordo solo due, ma sono quelli che contano adesso: (* 
che equivale a {, e *) che equivale a }


 appaiono di gran lunga troppo simili.
got Andale Mono?


 alla gianni morandi) si è adeguato.
AltGr+Shift+[ :-) (che da me a volte non funziona, causa logorio dei 
meta-tasti - tutti, nessuno escluso, anche quelli con il logo Windows, 
che uso moltissimo)


 scampo.
già. Però questo problema è stato affrontato anni fa e risolto in una 
decina di modi diversi. Mai sentito parlare di UUEncode? Base64? MIME? 
testo flowed? (il *tuo* programma idiota forse spezzerà bovinamente le 
righe alla colonna 78, distruggendo URL lunghi, codice, output del 
compilatore copiaincollato, eccetera - il mio invece si segna quali 
righe sono state spezzate automaticamente, e mostrando il messaggio su 
schermo le ricostruisce intere)
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 PYTHON, ma con il C/C++/PERL funziona a meraviglia.
e va bene, usa pure editor dimmerda e dai la colpa al linguaggio. Per 
caso manda a capo anche tra punteggiatura e testo? perchč se cosě fosse 
non ci puoi scrivere neanche PHP, che *richiede* un simbolo di dollaro 
prima dei nomi di variabile
L'editor che uso io per *ottime* ragioni ha configurazioni diverse per 
ogni linguaggio. Perchč se in Pascal voglio che il Tab mi faccia tre 
spazi (standard Borland), e in C voglio che me ne faccia uno solo 
(preferenza personale), quando scrivo un Makefile, caro mio, *devo* 
usare caratteri di tabulazione, che mi piacciano o no, altrimenti č un 
*errore di sintassi*, e se l'editor insiste a scrivermi otto spazi al 
posto di una tabulazione, č un *bug dell'editor*


 giustificazione. 
[...]
stai scherzando... vero? non puoi stare parlando sul serio. Che gli 
spazi ad inizio riga in Python siano whitespace, prima di tutto, lo 
dici *tu*, che forse non hai ben presente come opera un lexer, o - più 
che altro - non riesci ad astrarre abbastanza e rimani invischiato in 
pochi degli infiniti casi possibili
Eppoi, tutti i mezzi che potenzialmente alterano contenuti (esempio: le 
e-mail, che non possono contenere certi caratteri) prevedono codifiche 
che traducono - reversibilmente - stringhe illegali in stringhe legali 
(Base64, UUEncode, ecc.). Altro esempio: certi caratteri non possono 
essere inseriti letteralmente in espressioni stringa del C, per cui 
vanno codificati con le apposite sequenze di escape. Ancora un altro 
esempio: l'HTML prima di tutto non si mangia gli spazi, è semplicemente 
una questione di rendering su schermo, e come tale c'è apposito stile 
per conservare spazi e a-capo a display; in secondo luogo, il problema 
è stato risolto definitivamente (l'HTML è troppo ambiguo a riguardo - e 
qui parliamo di binary-safe) in XML, con i nodi CDATA. Ultimo esempio: 
per alcuni impaginatori (mi viene in mente RTF), le parentesi graffe 
sono caratteri speciali e spariscono inghiottiti dalla prima passata 
del lexer, e su questo ti invito a riflettere


 Scusa, ma chi e' che programma cosi'? Hai dei casi reali?
l'help delle utility a riga di comando. In genere fanno così, un sacco 
di spazi per allineare le linee. Si potrebbe fare a runtime con printf, 
ma quelle schermate di help (e in genere le opzioni di certe utility) a 
volte sono molto difficili da formalizzare


  if ( _argc < 1 )
qui ti salvi perchč IE deve ingurgitare spaghetti-HTML tutto il giorno 
senza vomitare. Prova a scriverlo in XHTML, e vedi se il documento *si 
vede*, almeno. Ah, ti ricordo, per futuri raptus di follia masochistica 
verso i tuoi arti inferiori, che anche & č un carattere riservato in 
HTML


 problemi[3].
quali problemi? il sapere esattamente un else/elseif a che if è 
associato sarebbe un problema?


 o meno solo ADA, il linguaggio tanto amato dal DOD USA.
<nota a margine>
e con buone ragioni
E' l'unico linguaggio (che io sappia) con task, memoria condivisa e 
sincronizzazione nativi - per cui l'unico linguaggio che permette di 
individuare la maggior parte dei bug relativi a, e di ottimizzare 
codice che fa uso di questi meccanismi già in fase di compilazione
Pensiamo al C, che il massimo che ha in tal senso è la possibilità di 
disattivare l'ottimizzazione di certe variabili o campi di strutture 
dichiarandole come "volatili" - cioè dici al compilatore: "QUALCUNO 
potrebbe scriverci dentro senza che tu lo possa capire da quello che 
stai compilando, tu per sicurezza non fare presupposizioni". In Ada non 
esiste questo generico "qualcuno" esterno, idealmente ogni programma è 
il sistema operativo di se stesso
</nota a margine>


 :-))
Conoscendo C++ è facile apprendere gli altri linguaggi. Comunque se c'è 
qualche vena ironica sulle mie capacità, mi dispiace ma caschi male...
;-PPP
-- 
Luc.

 confinata al TG4...
NO!!! Fede è un grande!!!
:-)))))
-- 
Luc.

 E perché?
Semplice: la dichiarazione implicita non da informazioni sul tipo e non
fornisce indicazioni sulla volonta' o meno che quella variabile esista.
Alex Martelli ha dato una spiegazione soddisfacente, ma manca un punto
fondamentale: la programmazione non e' solo ingegneria bensi' anche
creativita'.
Il problema della creativita' e' che, per definizione, non e'
schematizzabile. Quando crei un nuovo algoritmo[1] e lo codifichi, potrebbe
essere difficile capire, in caso di comportamento erratico da parte
dell'implementazione durante la fase di test, se il problema si trova
nell'algoritmo o nel codice che lo implementa (o nel compilatore,
ovviamente). In questo caso, evidenziare gli errori durante la fase di
compilazione significa evitare una classe di errori che possono mettere
sulla strada sbagliata chi analizza l'algoritmo per vedere se c'e' qualcosa
che non va.
Certo, ci sono alcune classi di errori difficilmente evidenziabili, ma
dovrebbero ricadere nel novero degli "errori semantici" e non nella classe
degli "errori sintattici".
*** Azimuth ***
[1] I vecchi algoritmi (es. quick sort, merge di liste, ecc..) non
dovrebbero essere mai ricodificati.

 meraviglia davvero mi meraviglia.
Ho semplicemente detto che se ho una riga lunga cosi':
    questa_e_una_funzione_molto_lunga( con_dei_parametri, numerosi, come, i,
granelli, del, fiume, gange );
con il wordwrap me la ritrovo cosi':
    questa_e_una_funzione_molto_lunga( con_dei_parametri,
numerosi, come, i, granelli, del, fiume, gange );
Ora, se voglio renderla leggibile basta spostare "numerosi..." fino ad
allinearla, MA NON E' INDISPENSABILE. Il codice funziona lo stesso.
*** Azimuth ***
[1] La maggior parte dei tuoi interlocutori avranno un limite di circa 1 MB
per la loro casella, quindi o non arriva o arriva smangiucchiato. Una
piccola parte della popolazione internet si trova a valle di diversi MTA che
possono avere limiti diversi ed effettuare uno splitting della posta, che
qualche volta puo' rendere piu' difficile ricostruire l'allegato.
[2] Brrr... a me mette i brividi che anche una sola vita (umana o non) venga
sacrificata per rilevare la tossicita' delle medicine!

 uso "pippo", che cosa succede ? il razzo esplode ?
E' un errore di programmazione, e la revisione del codice lo individua
velocemente (perche' cavolo il programmatore possa aver usato una costante
quando qui ci vuole sicuramente la variabile locale, COME DA COMMENTO?).
*** Azimuth ***

 Piantala di offendere, per favore.
Guarda che lui può farlo, ha lavorato in tantissimi posti importanti!!!
(Forse perchè lo mandavano via dopo poco tempo...)
^________^
-- 
Luc.

 conosca tutti gli step che passano tra me ed il mio interlocutore.
quindi tu non utilizzi *nessun* mezzo di comunicazione digitale? In 
*nessun* caso sei a conoscenza di tutti gli step che ci sono tra te e il 
tuo interlocutore; in teoria potrebbe capitare di spedire una e-mail che 
malauguratamente passa per un server che trasforma tutte le "a" in "e", 
ma questo che c'entra? Forse le email sono uno strumento inutile perche` 
non sappiamo quali sono gli step per cui passano?
Se vuoi spedire un sorgente python devi trovare un modo per non perdere 
l'informazione: MIME, ad esempio.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 quando qui ci vuole sicuramente la variabile locale, COME DA COMMENTO?).
Perche' si e' sbagliato. I programmatori, per tua norma e regola, si
sbagliano frequentemente e i linguaggi di programmazione devono tendere a
non farli sbagliare, non devono consentirti di "fare" comunque, tanto poi
c'e' il revisore...
--------------------------------
Inviato via 
http://usenet.libero.it

 sacrificata per rilevare la tossicita' delle medicine!
Purtroppo la complessita` dell'organismo umano e` tale che a oggi
non abbiamo vere alternative: o si evita di introdurre medicine
(non solo quelle nuove: a me mi porto` a un millimetro dalla morte
una banale aspirina, e uccide decine di persone ogni anno...), e
si lascia che la gente muoia, oppure con tutte le cautele del caso
si fanno tutte le prove che si puo` fare e poi, inevitabilmente,
si prova sul campo, in test clinici.  Naturalmente e` sacrosanto
(oltre che economicamente conveniente) fare tutti i test software
possibili e immaginabili (oggi che la tecnologia HW e SW, con
Python peraltro in ruolo critico in quest'ultima, lo consente in
modi tra l'altro assai economici), ma non bisogna illudersi che
questo risolva tutti i problemi -- 10% e` gia` un grande risultato,
e sicuramente migliorera` con gli anni man mano che i chimici e
vari altri specialisti capiscono meglio i meccanismi vari, ma
dubito che la vedremo arrivare al 100%... in biologia, quasi NULLA
e` mai al 100%, comunque...
Alex

 
E' quella che uso abitualmente anche io (tranne su un vecchio portatile 
Texas che si blocca inspiegabilmente ogni volta che si usa quella 
combinazione...), è comunque una posizione "innaturale" che ti 
costringe a spostare le dita dalla posizione abituale.
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 c'e' il revisore...
Insomma, ho capito: ti serve la tata per programmare.
*** Azimuth ***
[1]  Brr.... ovviamente, le variabili globali andrebbero bandite...

 parliaffa`...?
Oddio... vabbeh, hai ragione tu, contento?
*** Azimuth ***
[1] Scusami, non voglio discutere su questo punto, perche' mi sembra
quantomeno OT qui.
[2] Lo sai che e' stata proprio la Ericsson a spendere diversi milioni di
euro nel rifacimento dei propri laboratori perche' sono spese detraibili?

 dovrebbero essere mai ricodificati.
Dillo a Tim Peters, che continua a rielaborare il metodo sort delle
liste Python, originalmente un banale quicksort, e ne estrae delle
prestazioni assolutamente sbalorditive.
Il vero messaggio e`: bisogna sempre riutilizzare il codice che ci
mette a disposizione la libreria standard del linguaggio, tutte le
volte che sia possibile, E la libreria stessa deve offrire le cose
piu` fondamentali in modo facile da riutilizzare.  Ma chi scrive
quella libreria *sara` meglio* che abbia invece verso di essa un
atteggiamento critico e sia sempre pronto a studiare miglioramenti
di prestazioni, altrimenti il riuso viene a costare troppo...!
Facciamo un esempio?  Prendiamo un programmino C...:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#define TANTI 1000000
int paragona(const void* a, const void* b)
{
    return strcmp(*(const char**)a, *(const char**)b);
}
int main()
{
    char* arrayone[TANTI];
    int i;
    clock_t before, after;
    for(i=0; i<TANTI; i++) {
        arrayone[i] = malloc(8);
        sprintf(arrayone[i], "%d", i);
    }
    before = clock();
    qsort(arrayone, TANTI, sizeof(char*), paragona);
    after = clock();
    printf("Sorting took %f seconds\n", 
            ((double)(after-before))/CLOCKS_PER_SEC);
    return 0;
}
lo compiliamo ottimizzato, e lo facciamo girare un po' di volte:
[alex@lancelot ba]$ gcc -O esa.c
[alex@lancelot ba]$ ./a.out
Sorting took 0.890000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.910000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.910000 seconds
[alex@lancelot ba]$
Che bello, abbiamo messo meno di un secondo per sortare un
milione di stringhine, i PC da poco di oggi sono proprio belli
potenti.  Vale proprio la pena di programmare a bassissimo
livello, in C, con complicazioni come quelle che vedi nel
corpo della funzione "paragona" o anche nella printf per
ottenere prestazioni del genere, vero?
Falso.  L'equivalente Python:
import time
arrayone = map(str, range(100000))
before = time.clock()
arrayone.sort()
after = time.clock()
print "Sorting took %f seconds" % (after-before)
e i risultati:
[alex@lancelot ba]$ python -O esa.py
Sorting took 0.260000 seconds
[alex@lancelot ba]$ python -O esa.py
Sorting took 0.260000 seconds
[alex@lancelot ba]$ python -O esa.py
Sorting took 0.250000 seconds
il sort non e` proprio 4 volte piu` veloce di quel che puo`
fare il qsort del C, ma non ne e` lontano da questo.  Ah,
ma questo e` Python 2.2, con il migliore samplesort che
abbia mai visto, un gioiello.  Certo ottenuti risultati del
genere il grande Tim Peters un sonnellino sugli allori se
lo sara` ben meritato, giusto?
Sbagliato.  Con Python 2.3, Tim Peters ha riscritto da
capo l'implementazione del metodo sort, usando una variante
del "natural mergesort" che un tempo ha fatto capolino in
letteratura.  Con uno snapshot di 2.3 dal CVS (attuale
versione pre-alpha)...:
[alex@lancelot ba]$ python2.3 esa.py
Sorting took 0.050000 seconds
[alex@lancelot ba]$ python2.3 esa.py
Sorting took 0.040000 seconds
[alex@lancelot ba]$ python2.3 esa.py
Sorting took 0.040000 seconds
[alex@lancelot ba]$
senza neppure il -O (praticamente non serve piu` nella
nuova versione: hanno trovato un modo rapido di ottimizzare
il codice quasi appieno SENZA perdere nessuna informazione
utile per debugging, tracing, e simili...!), abbiamo un
ULTERIORE guadagno di 5-6 volte, per un'accelerazione, in
totale, di ben oltre le 20 volte rispetto al qsort del C.
Quando penso che c'e` gente che non vuole provare Python,
perche` pensa che "interpretato" significhi "lento", non
so mai se mettermi a ridere, o a piangere...
Alex

 Insomma, ho capito: ti serve la tata per programmare.
Tutt'altro (indice del fatto che non hai capito *NULLA* di quanto ho
scritto), io sto affermando esattamente il contrario e cioe' che bisogna che
il programmatore prenda in carico i problemi alla fonte e lasci il minor
numero di carichi pendenti all'eventuale revisore.


Aggiungo: hai la brutta abitudine di cambiare i subject dei thread.
Evita (specie se usi subject idioti), molti newsreader rompono la sequenza
dei messaggi.


 so mai se mettermi a ridere, o a piangere...
Sicuramente se li stai a sentire potresti persino capire perche'.
*** Azimuth ***
[1] Anche se sai, meglio di me, che "quick sort" non e' il miglior metodo di
sorting.

 Seguendo i tuoi consigli, caro Azimuth, una persona e' appena morta:
La nostra fortuna, caro Andrea, e' che sei lontano da tali problematiche.
Saluti.
*** Azimuth ***

 La nostra fortuna, caro Andrea, e' che sei lontano da tali problematiche.
Non continuero' a discutere con chi si ostina a dire idiozie, in virtu' del
fatto che, probabilmente, non ha mai programmato seriamente (o si e' illuso
d'averlo fatto).


 d'averlo fatto).
Fai come ti pare.
Al massimo, la rete risparmiera' banda per la mancanza dei tuoi realistici
esempi medici (!!!). <g>
*** Azimuth ***
[1] Ovviamente, non escludo che abbia un qualche ruolo da qualche parte
dell'universo informatico.
[2] Se non e' questo il caso, beh, allora non c'e' linguaggio che tenga.

"Alex Martelli" ha scritto 
: #include <time.h>
: 
: #define TANTI 1000000
: 
                0123456
: 
: arrayone = map(str, range(100000))
                            012345 
: 
: 
: Alex
: 
Sono io che conto male o qualcosa non torna?
ciao
Massimo

 esempi medici (!!!). <g>
La tua "teoria" e' talmente fragile che la si ribalta con *qualunque*
esempio, a occhi chiusi e con una mano legata dietro.


 linguaggi inefficienti su piattaforme inefficienti.
Balle spaziali.  Cosa sai di modellazione molecolare?!  CERTO
che ci vogliono i megaflop, scherziamo?  Ci volevano sui Cray
e altri supercomputer che programmavamo in Fortran accuratamente
ottimizzato negli anni '80, ci vogliono oggi su macchine 100
volte + economiche eppure + potenti e con linguaggi comodi o
comodissimi.  Python, con Numeric, weave.blitz, e soci, FA I
CERCHI ATTORNO ai programmi C, per le tipiche applicazioni di
quel che una volta si chiamava "supercalcolo".  
Ovviamente non posso mostrarti i programmi proprierari di
Astra-Zeneca (anzi non li ho visti neanch'io, e` Andrew
Dalke che e` il mago della modellazione molecolare, non
io:-), ma dai un occhio a 
biopython.org
, oppure ad esempio
http://conferences.oreillynet.com/cs/bio2002/view/e_sess/2229
o meglio ancora (piu` grafico:-) all'MGL dello Scripps RI,
http://www.scripps.edu/~sanner/python/index.html
 , scaricati
ViPEr e rifatti gli occhi ...
Alex

 e base (che e' una costante, ovviamente!).
Chiamarle ALTEZZA_MASSIMA e BASE_MASSIMA renderebbe il codice *MOLTO*
piu` chiaro (forse meglio MAX_ALTEZZA e MAX_BASE, dipende dalle
convenzioni che si usano).  Quando possibile, usa nomi che rendono
IMMEDIATAMENTE comprensibile il ruolo di una variabile, o costante;
questo migliora leggibilita` e manutenibilita` del codice.  Sapere
che un valore e` "una costante che ha a che vedere con l'altezza"
serve meno (potrebbe essere un default, o un minimo...?), sapere
subito che definisce specificamente l'altezza *massima* e` piu` utile.
Alex

 c'e' il revisore...
"E` impossibile costruire un sistema a prova d'idiota, perche` gli
idioti sono troppo ingegnosi".  Le scelte di progetto di un sistema
(compreso un linguaggio di programmazione) che costituiscono tradeoff
fra "aiutare l'utente a non sbagliare" e quelle che aumentano invece
la produttivita` dell'utente stesso sono le piu` difficili.  Nessuna
difficolta` quando ENTRAMBI gli obbiettivi sono raggiunti nello stesso
modo (ad esempio, la semplicita`!), tanta difficolta` quando, o e` una
cosa, o l'altra.
Ad esempio, che succede se un programmatore CREDE erroneamente che
Pippo e pippo siano due nomi diversi in un linguaggio in cui invece
sono eguali?  Risposta: succedono degli errori.
La scelta che minimizza il rischio di errore e`: ogni nome si deve
presentare in UNA SOLA combinazione di minuscole e maiuscole in
tutto il programma.  Sarebbe un po' una palla, pero` minimizzare
minimizza.  Ma non conosco alcun linguaggio che la usi.
Prendi un altro esempio, blocchi annidati con dichiarazione, ad
es. (ma non importa) in sintassi C-osa...:
     int x = 23;
     {
         int x = 45;
         x = x + 93;
     }
visto cosi` in piccolo sembra comodo e QUASI tutti i linguaggi
che supportano blocchi o funzioni annidate supportano anche
questo tipo di uso, in cui la variabile piu` interna nasconde
localmente quella omonima piu` esterna.
Ma quando i blocchi sono grossi e le dichiarazioni lontane, il
costrutto e` prono ad errori: il programmatore scrive x = 77
PENSANDO di avere effetto sull'x del blocco esterno, invece
lo ha su quello del blocco piu` interno che nasconde l'altro.
E infatti Java proibisce questo uso: il compilatore riconosce
questo costrutto e ti smacca un errore "x is already defined".
E` giusto?  E` sbagliato?  Mah.  Forse.  Non sono decisioni
facili.
Alex

 che ci vogliono i megaflop, scherziamo?
Scherzi tu!
Io posso anche non sapere cosa sia la modellazione molecolare, ma una cosa
la so: ho implementato algoritmi molto smart per la risoluzione di
problematche CAZZUTE che riducono di 10000 volte il tempo di esecuzione a
fare le stesse cose a parita' di problema. Tanto che posso VERAMENTE usare
un PC invece di un Cray[1]
E non le ho fatte in python perche *NON*SI*PUO'*FARE*
(CON*QUESTE*PRESTAZIONI).
Per il resto, direi di finirla qui.
*** Azimuth ***
[1] Un esempio per tutti: hai presente tutta la manfrina per estrarre le
cartelle vincenti del superenalotto? Ci vogliono 45 minuti di elaborazione
di un MAINFRAME da 20 GB di RAM piu' 90 terminali PC ognuno con 128 Mb per
trovare le cartelle che hanno i sei numeri fortunati (beh, 6 + 1, c'e' anche
il jolly). L'implementazione piu' stupida del mio algoritmo scritta in C
impiega 30 secondi con un PC Pentium II 400 Mhz e 128 Mb di RAM per trovare
TUTTE le cartelle vincenti, cioe' i 6, i 5 + 1, i 4, ed i 3, con tanto di
localita' di giocata, PRELEVANDOLE da un CD-ROM. Se l'avessi fatta in
PYTHON, per quanto ottimizzata, avrebbe avuto i tempi che vedi.

 esempio, a occhi chiusi e con una mano legata dietro.
Visto che ci sei, puoi legartele entrambe, cosi' veramente il mondo ti sara'
grato?[1]
*** Azimuth ***
[1] Scusa, non ho resistito. Ad inserire la nota, ovviamente.

 convenzioni che si usano).  Quando possibile, usa nomi che rendono
Ammetto che in questo caso andrebbe meglio.
Per il resto, non vedo problemi con il caseing.
*** Azimuth ***

 (Forse perchè lo mandavano via dopo poco tempo...)
Eh si`, dimissionario dopo solo 13 anni, praticamente un entra ed
esci... certo che Luc e Azimuth si meritano (quasi) a vicenda...
Alex

 individuare la maggior parte dei bug relativi a, e di ottimizzare
Erlang EVITA la memoria condivisa (come Occam, usa solo passaggio
di messaggi), quindi e` una tacca sopra: invece di individuare i bug
ed ottimizzare le inefficienze, evita gli uni e le altre:-)
[Fuor di scherzo: su certe architetture HW non c'e` alternativa alla
memoria condivisa, per certe applicazioni e con certi stretti vincoli
di prestazioni: ma sono casi rari, normalmente il paradigma a
messaggi e` preferibile].
Alex

 puoi configurare più layout e cambiarli al volo quando serve
Si`, anche con Linux (e KDE), infatti quando mi servono caratteri
accentati (sulle tastiere a layout USA che preferisco) commuto un
attimo a "US-International" per quel compito, sia che stia usando
Linux oppure Windows (quando non mi e` indispensabile, preferisco
evitare le dead-key).  [L'unica cosa che non ricordo mai e` come
si fa con US-international "il pallino sopra", che ogni tanto mi
servirebbe per scrivere un nome svedese, ma tanto sulla tastiera
a layout IT non lo avrei comunque].  Ma la tastiere dei laptop sono
a volte distorte, ad esempio quella dell'Acer 345T non ha nessun
tasto a sinistra dell'1 in alto a sinistra, dove andrebbero tilde
e back-quote: se lavoro con un layout logico diverso da quello
fisicamente stampato sulla tastiera e` un casino.  Possibile che
ad Acer e soci costi tanto distribuire layout di tastiera diversi
se il cliente vuole quelli?  Oh com'e` che Dell lo fa senza
problemi, sara` mica anche per questa filosofia di SERVIRE il
cliente che sono diventati il numero uno...?
Alex

 che equivale a {, e *) che equivale a }
Si`, ma non parte dello standard, benche` popolare estensione.  Non
ricordo quale dei vari dialetti (UCSD, Turbo Pascal 1.0, o Pascal/VS 
sui mainframe IBM) non supportava questa estensione, quindi a passare
(come allora facevo) continuamente programmi dall'uno all'altro mi
toccava (oltre alle altre) la pizza di trasformarli in graffe... da
cui, l'odio per chi le graffe non le aveva messe...!-)
Alex

 certo che Luc...
Un altro alla frutta... ;-PPPP
-- 
Luc.

Azimuth wrote:

Questione di gusti.  Come e` evidente, non e` per me una questione
di vita o di morte, se no non potrei usare C, C++, Java, Haskell,
Python, tutti case-sensitive -- anche fuori dall'ambito della
programmazione, _preferisco_ Linux, BSD e altri simil-Unix, a
Windows vari, BENCHE` il filesystem sia case-sensitive in un
caso e insensitive-ma-preserving (l'ideale!) nell'altro.
Cio` detto, *preferirei* (se per ipotesi si potesse avere a
parita` di tutti gli altri fattori) un linguaggio che NON
incoraggia i programmatori a usare Bla, bla e BLA con vari
significati diversi.  Mai discusso un programma al telefono
(o altro equivalente mezzo audio-only, al giorno d'oggi ad
esempio voice-su-IP)?  Io si`, spesso, e non ti dico le
ambiguita` dannate prodotte dai linguaggi case-sensitive
(cosi` dannatamente popolari!-) o meglio dall'uso che essi
supportano ed incoraggiano di AFFIDARSI solo alla case
distinction per distinguere identificatori distinti.  Piu`
in generale, il mio ragionamento tende ad essere "verbale",
non "visuale", per cui distinzioni puramente visuali non
agevolmente colte "verbalmente" non mi fanno piacere (mi
rendo conto che la maggior parte della gente preferisce
una maggior componente visuale, forse e ` anche per questo 
che i linguaggi case-sensitive sono oggi piu` popolari...).
Il mio linguaggio di sogno ammetterebbe minuscole o
maiuscole in identico ruolo *E* spazi (o sottolineature)
supplementari, privi di ruolo lessicale, per permettermi
di scrivere ad esempio 10_000_000, assai piu` leggibile
di 10000000 dove uno deve contare gli zeri con molta
ma molta attenzione (se non sbaglio Ada supporta questo
specifico uso, solo entro i numeri).  In altri termini
forse quello che mi manca non e` Pascal (che e` si case
insensitive, ma NOn permete di aggiungere spazi ne`
sottolineature extra), ma il Fortran, che ha entrambe
le caratteristiche (spazi sempre ammessi e facoltativi,
puoi scrivere se vuoi 10 000 000 ed e` esattamente
equivalente a 10000000).  Ci sarebbe anche la sua logica,
visto che il Fortran fu il primo linguaggio che mi
trovai ad imparare (1974).  _Coscientemente_ non mi
manca per nulla, ma il subcosciente gioca scherzi...
Alex

 
Questo esempio, tradotto in termini non-informatici, č come dire che un 
trapano č un utensile inutile perchč non ci puoi piantare i chiodi (o, 
meglio, perchč i chiodi li puoi piantare molto piů in fretta con il 
super-martello che tu ti sei appena costruito).
In un ipotetico sistema di gestione del super-enalotto quanta 
percentuale di codice si occupa della ricerca dei vincitori e quanta di 
altro? Sei obbligato a scrivere tutto con lo stesso linguaggio?
Casa tua l'hanno costruita tutta con usando solo un cacciavite?
E' importante saper scegliere i tool giusti per il lavoro che si deve 
fare (e nota bene che ho usato il plurale!).
E comunque il tuo algoritmo č lento:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=
3643e70c.439899508%
40news2.tin.it


 Alex
Gli infervori cerchiamo di lasciarli a Ezio Greggio....
Ciao
P.S. Ovvia considerazione generale, rispondo a te solo per via 
dell'esempio anche gli altri sono invitati alla moderazione.
-- 
Molebio

 3643e70c.439899508%
40news2.tin.it
Puo' darsi. Comunque lui ne parla, io l'ho implementato. Considera che non
ho fatto alcuna ottimizzazione (nulla e' scritto in assembly, ad esempio).
Ciao.
*** Azimuth ***

 errate, e` una MENZOGNA per DEFINIZIONE di menzogna.  Punto.
Ti cito, solo a termine di completezza, cio' che ALTRI da me hanno portato
come risposta al tuo esempio:
<CITE Message-Id: 
Xns929DAA45F130...@195.31.190.132
 >
[...]
Compilato in Debug (nessun ottimizzazione)
5.711000
5.127000
Compilato in release (ottimizzato per la velocità)
1.652000
1.632000
Con lo script Python interpretato (versione 2.2.1)
Sorting took 3.588697 seconds
Sorting took 3.498557 seconds
Sorting took 3.465475 seconds
[...]
</CITE>
Direi a questo punto che chi mente sei tu, mio caro.
Thread chiuso.
*** Azimuth ***

 fatta in PYTHON, per quanto ottimizzata, avrebbe avuto i tempi che vedi.
Quali "tempi che vedi"?  I 45 minuti?  Perche` mai dovresti
pensare ad un rallentamento del genere, implementando un buon
algoritmo?
Alex

Andale Mono
Stupendo!
-- 
Marco Barisione (ICQ 84277092)

 3643e70c.439899508%
40news2.tin.it
Aspe'... tra l'altro lui sostiene di trovare il 6 (1 o 2 giocate al max)...
mentre io trovo TUTTE le combinazioni di 6, 5, 4 e 3 (piu' di 350.000
giocate)!
Inoltre, io parlo di un algoritmo che ho implementato nel 1998...
*** Azimuth ***

Massimo Valentini wrote:

No, no, hai ragione tu -- ho sbagliato il numero di
zeri!  Dann, avrei dovuto scrivere (1000*1000) (visto
perche` vorrei poter usare liberamente underscore nei
numeri, scrivendo 1_000_000 ...?-).
Con un milione di numeri per entrambi il rapporto e` meno
assurdo...:
[alex@lancelot ba]$ python2.3 -O esa.py
Sorting took 0.410000 seconds
[alex@lancelot ba]$ python2.3 -O esa.py
Sorting took 0.410000 seconds
[alex@lancelot ba]$ python2.3 -O esa.py
Sorting took 0.410000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.930000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.930000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.930000 seconds
[alex@lancelot ba]$
quindi, il qsort di C e` solo 2.27 volte piu` lento
del sort di Python 2.3 -- numeri piu` sensati:-).
Per farmi perdonare propongo una piccola variante: e
se il formato delle stringhe fosse un po' diverso...?
Cambiamo la sprintf nella versione C in:
        sprintf(arrayone[i], "%7d", i);
e abbiamo un piccolo miglioramento (penso per la minor
frammentazione di memoria in gioco):
[alex@lancelot ba]$ gcc -O esa.c
[alex@lancelot ba]$ ./a.out
Sorting took 0.850000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.870000 seconds
[alex@lancelot ba]$ ./a.out
Sorting took 0.840000 seconds
[alex@lancelot ba]$
La versione Python diventa:
import time
TANTI = 1000*1000
arrayone = [ "%7d" % i  for i in xrange(TANTI) ]
before = time.clock()
arrayone.sort()
after = time.clock()
print "Sorting took %f seconds" % (after-before)
ma i tempi con Python 2.3...:
[alex@lancelot ba]$ python2.3 -O esa.py
Sorting took 0.180000 seconds
[alex@lancelot ba]$ python2.3 -O esa.py
Sorting took 0.190000 seconds
[alex@lancelot ba]$ python2.3 -O esa.py
Sorting took 0.180000 seconds
[alex@lancelot ba]$
*dimezzano*!  Il "natural mergesort" trae (in modo,
appunto, naturale) pieno vantaggio dall'ordinamento
che possa essere gia` presente (in tutto o in parte)
nei dati da ordinare, come spesso accade (anche se
non in misura cosi` clamorosa:-) nei casi pratici.
Alex

 algoritmo?
Perche' usare un linguaggio troppo astratto debilita il programmatore.
*** Azimuth ***

 [di sorting.
Certo.  Infatti la funzione qsort della libreria standard C
(e l'algoritmo sort di quella C++) possono liberamente usare
quel che vogliono (proprio come il metodo sort delle liste
di Python) -- samplesort, natural mergesort, o che altro (il
'q' davanti al nome e` dunque magari sbagliato -- tra l'altro
di solito sta per quickersort, che almeno ha la stessa
iniziale ed e` un po' meglio del quicksort classico -- ma
non vi e` nessun vincolo del genere sull'implementazione).
Alex

 Perche' usare un linguaggio troppo astratto debilita il programmatore.
Forse, per definizione della parola "troppo", ma se cosi` dovesse
essere il discorso non si applica certamente a Python, che, SE VUOI,
ti permette di smanazzarti i bit e i byte ad uzzo tuo.  DI SOLITO
non e` l'approccio piu` produttivo, ma per quei rari casi in cui
puo` esserlo, il linguaggio offre tutte le risorse necessarie.
Alex

 
Il punto del discorso non era l'algoritmo dell'enalotto (il link l'ho 
postato solo per far notare che non c'č nulla di mostruoso nella tua 
soluzione, anche se l'autore del post originale č una delle persone 
piů competenti che conosca, seppur solo attraverso i suoi post), era 
il tuo esempio sballato e vedo che quel punto č stato eliminato dalla 
tua risposta.


 dell'esempio anche gli altri sono invitati alla moderazione.
Ci sono gruppi che hanno la moderazione, ma non questo:-).
Alex

del lexer, e su questo ti invito a riflettere
TeX e simili idem, e scrivere direttamente in LaTeX è molto più
diffuso di scrivere direttamente in rtf.


 Thread chiuso.
Lo hai gia` detto, con parole un po' diverse, e continui a
postare.  Fai pure: continua pure a sbugiardarti da solo...
Alex

"Alex Martelli" ha scritto 
: 
: *dimezzano*!  Il "natural mergesort" trae (in modo,
: appunto, naturale) pieno vantaggio dall'ordinamento
: che possa essere gia` presente (in tutto o in parte)
: nei dati da ordinare, come spesso accade (anche se
: non in misura cosi` clamorosa:-) nei casi pratici.
: 
: 
Non dubitavo che l'interprete potesse battere il programmino
C, e` evidente che in un caso del genere non fa che da passacarte
alla funzione superottimizzata, probabilmente scritta in C ;-)
Soprattutto su un esempio proposto da te, che, conoscendo l'algoritmo,
non lo avresti certamente creato sfavorevole alla versione .py, e del
resto il quicksort ha casi pessimi. 
Oltretutto la qsort, nel tuo esempio, riceve il puntatore ad una 
funzione che non fa altro che chiamare un'altra funzione di libreria. 
Volendo si puo` implementare il confronto direttamente nella paragona, 
probabilmente ci si perde qualcosa meno, ma se l'algoritmo non e` il 
migliore di sicuro non basta.
Comunque ammetto che l'effetto e` notevole. Complimenti a Tim Peters
ciao
Massimo

 Comunque ammetto che l'effetto e` notevole. Complimenti a Tim Peters
Li merita tutti.  E` tutto ben visibile e chiaramente documentato a
http://py-stablesort.sourceforge.net/
 comunque -- la pagina linka
sia ai sorgenti, sia ad un'approfondita discussione tecnica.
Alex

"Alex Martelli" ha scritto
:
: Temo di no, perche` gcc su architettura Intel ha strcmp come funzione
: built-in, implementata in assembler assai ottimizzato; non credo che ci
sia
: molto da guadagnare riscrivendola invece in C.  Comunque, l'unica e`
: provare.
:
:
Allora meglio che niente si puo` disordinare l'array prima di darlo
in pasto alla qsort. Contando anche quel tempo ovviamente.
BTW ho notato che nel secondo esempio (quello del 7d) la lista e`
gia` ordinata:-)
ciao
Massimo


Per il portatile mi sono messo subito il cuore in pace, non ci ho
nemmeno provato (interessante la dritta sui Dell, comunque).
Per fortuna lo uso prevalentemente a casa, collegato con una tastiera
"vera".
Andrea

 Alex
Ciao
-- 
Molebio

 La prendo come battuta :-)
Fai, fai (apposta ho messo lo smilie).  Ma fuor di scherzo, se il
gruppo fosse moderato e permettesse a qualcuno di usare un
linguaggio da trivio ma NON ad un altro di replicare a tono, non
sarebbe certo un gruppo che meriterebbe frequentare...
Alex

 gia` ordinata:-)
Certo, avrai notato che anche la versione C se ne avvantaggia (di
poco) -- il qsort della GNU usa i classici acceleratori Bentley /
McIlroy, per cui ha il suo vantaggio (piccolo) ad esempio da un
array gia` ordinato (si trova rapidamente a scegliere sempre come
pivot la mediana e quindi a partizionarlo assai bene, regolarmente).
Alex


"[...]
6.1.10 Token separators
Where a commentary shall be any sequence of characters and separations of
lines, containing neither } nor *), the construct
        ( '{' | '(*' ) commentary ( '*)' | '}' )
shall be a comment if neither the { nor the (* occurs within a
character-string or within a commentary.
NOTES
1 A comment may thus commence with { and end with *), or commence with (*
  and end with }.
[...]
6.1.11 Lexical alternatives
The representation for lexical tokens and separators given in 6.1.1 to
6.1.10, except for the character sequences (* and *), shall constitute a
reference representation for these tokens and separators. To facilitate the
use of Extended Pascal on processors that do not support the reference
representation, the following alternatives have been defined. All processors
that have the required characters in their character set shall provide both
the reference representations and the alternative representations, and the
corresponding tokens or separators shall not be distinguished. Provision of
the reference representations, and of the alternative token @, shall be
implementation-defined. The alternative representations for the tokens shall
be
                Reference token Alternative token
                       ^              @
                       [             (.
                       ]             .)
 
NOTE --- 1 The character ^ that appears in some national variants of ISO
646 is regarded as identical to the character ^. In this International
Standard, the character ^ has been used because of its greater visibility.
The comment-delimiting characters { and } shall be the reference
representations, and (* and *) respectively shall be alternative
representations (see 6.1.10).
[...]"
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 messaggi e` preferibile].
credo di capire cosa intendi. Ho avuto un mio piccolo casino, tempo fa, 
per non aver considerato certi fastidiosi effetti collaterali della 
memoria condivisa. C'era questo server con un protocollo basato su 
message passing e memoria condivisa (necessaria, perchè i messaggi 
avevano delle dimensioni massime troppo ridotte), con un pool di thread 
per gestire le richieste. Beh, credo il problema sia abbastanza ovvio 
:-) Dovrei mettermi a riprogettarlo in un modo un po' più furbo


"Alex Martelli" ha scritto
: > : Temo di no, perche` gcc su architettura Intel ha strcmp come funzione
: > : built-in, implementata in assembler assai ottimizzato; non credo che
ci
: > sia
: > : molto da guadagnare riscrivendola invece in C.  Comunque, l'unica e`
: > : provare.
: >
: > Allora meglio che niente si puo` disordinare l'array prima di darlo
: > in pasto alla qsort. Contando anche quel tempo ovviamente.
:
: Brrrr -- un milione di generazione di numeri casuali?  Prova, prova,
: dubito che avrai un vantaggio.
Io pensavo ad un migliaio di swap abbastanza sistematici, tanto, se
la lista e` molto ordinata, e` facile disordinarla. Trucco che ha senso
quando si dispone di una qsort molto naif. Per esempio la qsort del BCB
5.5 dimezza quasi i tempi scommentando il ciclo di swap che ho aggiunto
al tuo esempio, mentre con gcc 3.02 non vi sono significative differenze.
Ma la cosa interessante rimane che se si dispone di un algoritmo piu`
appropriato al caso in esame, poco importa con quale linguaggio viene
invocato. Una volta che si misura solo il suo tempo di esecuzione, oppure
ogni volta che quello rappresenta il collo di bottiglia, le differenze
dipendono dall'algoritmo.
ciao
Massimo
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#define TANTI 1000000
int paragona(const void* a, const void* b)
{
    return strcmp(*(const char**)a, *(const char**)b);
}
int main()
{
    char* arrayone[TANTI];
    int i;
    clock_t before, after;
    for(i=0; i<TANTI; i++) {
        arrayone[i] = malloc(8);
        sprintf(arrayone[i], "%d", i);
    }
    before = clock();
/*    for(i=17; i<TANTI; i += 4321) {
        char* tmp = arrayone[TANTI - i];
        arrayone[TANTI - i] = arrayone[i];
        arrayone[i] = tmp;
    }*/
    qsort(arrayone, TANTI, sizeof(char*), paragona);
    after = clock();
    printf("Sorting took %f seconds\n",
            ((double)(after-before))/CLOCKS_PER_SEC);
    return 0;
}

 il disastro...).
ovvio che sarebbe meglio avere il corretto layout anche visivamente, ma 
io non ci vedo un gran problema: uso una tastiera italiana con layout 
americano e oramai ho imparato la disposizione dei tasti a memoria ;-)
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 Alex
ok penso che con questo msg privo di contenuti sulla programmazione sia 
finito abbondantemente OT... perciò
Alla prox
-- 
Molebio

(che e' una costante, ovviamente!).
Che "si intenda" la massima altezza, questo lo sai solo tu ;)
Sarebbe stato più chiaro e leggibile scrivere:
if (altezza > altezza_max)  ... per esempio.
-- 
A lurker.

 dipendono dall'algoritmo.
Se ci sono abbastanza dati in gioco, si`.  Ma per il caso specifico
del sort, a me pare di capire che il natural mergesort e` "sempre"
piu` appropriato delle varianti anche piu` raffinate dell'idea base
di qsort (samplesort, a spingere, si puo` ad esempio classificare
come tale); almeno, cosi` leggo le note tecniche di Tim e i risultati
delle sue prove.  Ci possono essere tutt'altre alternative se quello
che serve non e` davvero un sort (ad esempio, per determinare invece
gli elementi unici senza cura dell'ordine, l'inserimento in hash
table puo` essere assai piu` efficace di qualsiasi variante di sort
o struttura autosortante tipo red-black tree) o se le chiavi di sort
hanno proprieta` particolarissime (adatte ad esempio ad un bin-sort), 
e benche` si tratti di "casi particolari" possono avere importanza
pratica notevole quindi e` bene tenerli a mente.
Insomma, sembra che siamo in feroce accordo...?
Alex

 :-) Dovrei mettermi a riprogettarlo in un modo un po' più furbo
...se l'architettura soggiacente te lo permette...  io avevo
progettato un sistema basato sul passaggio di messaggi, che in
Win/NT funzionava benissimo, e quando fu poi portato a Win/95
_pareva_ funzionare bene, ma ogni tanto crac.  Salto` fuori
che i *CARI* programmatori di Win/95 avevano implementato un
limite NON DOCUMENTATO di 4096-epsilon (mi pare 4080, quindi
epsilon==16, ma non sono sicuro) sulla quantita` di dati che
un messaggio poteva portarsi dietro fra processi diversi.
Finii appunto per dovere fare una pezza malefica che, solo
su Win/95, costruiva e gestiva una coda in shared memory per
i messaggi "troppo grossi" (a mandare TUTTO via la coda, si
rallentava troppo).  Credo che sia stato solo Win98 2nd Ed
a correggere finalmente il baco e permetterci di fondere di
nuovo i branch tipo-NT e tipo-Windows (con prestazioni
decenti su entrambi).  Naturalmente, MS si rifiuto` sempre
recisamente di ammettere che questo loro bug fosse un bug:-).
Alex

 Ho davanti ai miei occhi l'ISO 10206:1990, e vengono discussi, assieme
Ah si`, ma il Pascal lo usavo negli anni '80, lo "standard" (de
facto, non ancora ISO) era un altro (partecipai anche un poco al
lavoro su Extended Pascal -- per l'IBM Research era un orgoglio
pagare la partecipazione di sue persone ai comitati di gestione
della standardizzazione -- ma dovetti mollare ben prima che lo
standard fosse pronto).  Lo standard "ufficiale" in una parte
degli anni '80 era per un sottoinsieme cosi` minimale di Pascal
che in pratica nessuno lo curava, salvo forse che non lo usasse
solo per insegnare a programmare -- ma come molti altri utenti
di UCSD, Turbo Pascal, e Pascal/VS, io ci facevo tutt'altro... l'ho
poi ANCHE usato per insegnare, quando facevo a tempo perso il
professore all'Universita` (e li ho visto sia dei pregi, sia dei
limiti che, usandolo "professionalmente", non trasparivano
altrettanto).
Alex

 che uso moltissimo)
Anche io uso tantissimo i tasti di win: lo ho rimappati per farci ~ { }
nell'ordine, da sx a dx ;-)
-- 
 Ciao, Bianco.                         Reply to luca.bianco (at) 
tiscali.it
|---------[Powered by Debian GNU/Linux 3.0 - 2.2.20 - AMD K6-200]---------|
|------------[Linux Registered User #287769 - Machine #169192]------------|

"Alex Martelli" ha scritto 
: 
: Giusta precauzione, dunque, se si deve girare con librerie standard
: del cavolo (e` un peccato che quelle Borland lo siano).  Non che
: glibc sia perfetta (chi mai lo e`?), ma e` curioso che gente che
: si fa pagare per i propri prodotti (come Borland) si permetta di
: implementarli con i piedi, mentre chi li regala (come GNU) pone
: piu` cura nell'implementazione:-).
Ad onor del vero, le mia non e` l'ultima versione per cui non so
se la nuova sia migliore o meno, da questo punto di vista. E poi 
mi pare che le librerie std del C, del C++, siano scaricabili 
liberamente dal loro sito con il compilatore free. 
: 
: Insomma, sembra che siamo in feroce accordo...?
: 
I numeri, alla fine, mettono d'accordo tutti.
  10 000 000 + 1 > 7 500 000 + 15
ciao
Massimo

 prova, dubito che avrai un vantaggio.
si può usare anche le cifre decimali di Pi. Hanno una buona entropia


 so mai se mettermi a ridere, o a piangere...
è un discorso un po' pericoloso. Il C con gli stessi algoritmi sarà 
comunque più veloce di Python. qsort() è un'interfaccia volutamente 
generica e lo standard non specifica nessuna implementazione, quindi in 
realtà stiamo confrontando due runtime. Come quel benchmark che diceva 
che Linux è più veloce di Windows perchè la memcpy era più veloce (per 
qualche *misteriosa* ragione, poi, usando direttamente un int * era più 
veloce Windows... Oltretutto ho davanti i sorgenti della runtime C di 
Microsoft, e ho avuto la conferma)


richiede ottime prestazioni, Pyrex e` una buona scelta.
Questa tua affermazione mi fa pensare.
A me finora non è mai capitato di scrivere estensioni per velocizzare
gli applicativi, In modo superficiale potrei pensare: << non mi sono
mai servite >>. Ma come faccio a definire i limiti dell'utilizzo di
codice "pure" Python e capire quando _devo_ integrarlo con Pyrex o
tecnologie analoghe?
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
http://bw-crema.blogspot.com

so mai se mettermi a ridere, o a piangere...
Eh eh devi essere contento che tu lo usi, ti diverti e ci guadagni
sopra :)


 (qualcuno con il C++).
Esperienza personale? Mi permetto di dubitare..
BTW una grande società italiana che costruisce centrali telefoniche
aveva portato quasi tutto in C++ già nel 1998 (fonte: i progettisti),
mentre una grande multinazionale francocanadese che fa la stessa cosa
sviluppa in C++ per il GSM e per quel poco che è a mia conoscenze sta
usando anche Java per UMTS; e non credo che i finlandesi o gli svedesi
agiscano diversamente, anzi; giusto come ultima chicca sono certo al
100% che almeno un sottosistema di una centrale prodotta in Italia e
venduta in tutto il mondo è scritto in Perl.
Credo nel campo delle telecomunicazioni il C lo stiano abbandonando
proprio tutti (appunto per la criticità dei sistemi, e l'impossibilità
di gestire enormi progetti a così basso livello).
--
ale
www.sen.it

 comunque più veloce di Python. qsort() è un'interfaccia volutamente
Forse, se si prende "algoritmi" in un senso molto esteso che
comprenda anche tutti i trucchetti e le strategie di implementazione,
nonche` l'uso dello stesso hardware (raramente incluso nelle
definizioni standard di "algoritmo", ma probabilmente era fra le
ipotesi inespresse che tu stavi ponendo:-) _E_ si ignorano le
possibilita` offerte ad esempio dall'interfaccia con Blitz (Blitz
notoriamente puo` generare codice piu` rapido di quello C per
tipici problemi di algebra lineare, usando template C++ per
espandere codice in-linea -- e weave.blitz traduce espressioni
Python Numeric in codice macchina attraverso Blitz), che per la
maggior parte dei programmatori sono abbastanza marginali.
Naturalmente, "l'ottimizzazione prematura e` la radice di tutti i
mali della programmazione" (Knuth); scegliere il linguaggio per la 
stesura di un programma sulla base di "a parita` di _tutti_ gli
altri fattori sara` piu` veloce" e` l'ottimizzazione piu` prematura
che si puo` immaginare, visto che viene fatta prima ancora di
avere steso anche una sola riga di codice.  Se un linguaggio A
permette di sperimentare una mezza dozzina di architetture
alternative per un sistema software nel tempo in cui chi
programma in un altro linguaggio B non ha ancora finito di
scrivere la prima, il linguaggio A dispone allora di un concreto
e interessante vantaggio di prestazioni rispetto al linguaggio B:
le "macro-considerazioni" di architettura di sistema sono spesso
piu` rilevanti per le prestazioni complessive di qualsiasi dettaglio
implementativo, visto che i colli di bottiglia possono spesso
trovarsi sulla comunicazione fra processi (anche in rete), sull'I/O,
sulla commutazione di contesto fra thread e processi (quindi
merita studiare come partizionare il sistema in processi e thread,
studiare architetture asincrone / ad eventi entro un thread, &c),
sulle interazioni con uno o piu` database.
C'e` poi un "ciclo di retroazione" fra l'architettura di sistema e
le scelte di progetto a livello via via piu` dettagliato -- per cui
la "fluidita`" del linguaggio, la facilita` di cambiare le scelte fatte
in precedenza e non dover lavorare necessariamente "in
cascata", presenta ulteriori benefici, anche in termini di
possibilita` di ottimizzazione delle prestazioni.
Se disponi di risorse umane illimitate (rispetto alla dimensione
del problema da risolvere) puoi sicuramente scrivere un dato
programma in varie versioni di linguaggio macchina, ciascuna
ottimizzata per quel dato stepping level di quel dato processore
con la cache sistemata cosi` e cosa`, etc.  In questo modo, e
solo in questo, puoi _garantire_ prestazioni massime assolute
del programma su ciascuna singola piattaforma.
Se, ipotesi piu` realistica, devi porre un limite alla quantita` di
risorse umane spendibili per la soluzione di un problema, allora
non e` affatto detto che scegliere ("prematuramente", cioe`
sin dall'inizio) un linguaggio di programmazione di livello piu`
basso (linguaggio macchina invece che C, C invece che Python)
ti permetta di produrre un programma di prestazioni migliori
(non si puo` escludere, ma neppure e` scontato).
Alex

tecnologie analoghe?
Prima lo scrivi tutto in python, poi se le prestazioni non ti
soddisfano analizzi il programma per trovare i colli di bottiglia, una
volta che li hai individuati li ottimizzi (passando al C se non č
possibile ottimizzarli decentemente in Python).
-- 
Marco Barisione (ICQ 84277092)

 tecnologie analoghe?
Se devi usare una libreria, tipicamente una libreria di sistema, per
cui non trovi facilmente un modulo d'interfaccia gia` fatto, Pyrex e
tecnologie analoghe ti permettono di rivestire quella libreria e di
usarla da Python.  Gli esempi sul sito di Pyrex mostrano come
rivestire la libreria che interfaccia il sottosistema CUPS per potere
controllare le code di stampa di un sistema Linux.  (Su WIndows
e` piu` probabile usare altri meccanismi -- di solito il COM, a
volte anche la calldll).
Ma tu specificavi "per velocizzare", quindi il caso e` diverso.  In
questi casi, "_devo_" si applica quando il cliente non accetta il
sistema con le prestazioni che stai ottenendo, tu non sai piu`
a che santo votarti per ottimizzare di piu` il sistema in Python,
e il profiling ti mostra che una modestra parte del codice sta
consumando la gran parte del tempo di esecuzione.  Quando
tutte queste condizioni sono soddisfatte, allora puo` meritare
prendere in considerazione Pyrex, C o altro allo scopo di
accelerare quella piccola parte del codice che fa da collo di
bottiglia per le prestazioni dell'intero programma.
Alex

 universita` italiane: il mondo va avanti!
Al corso di Ingegneria del software che ho seguito (Politecnico di
Milano) i docenti hanno dedicato una una quindicina di lezioni al
testing, divise abbastanza equamente tra black box (functional)
testing e testing strutturale.
All'esame scritto ci fu una scena divertentissima, uno degli esercizi
presupponeva il test di un pezzo di codice, i docenti avevano previsto
l'uscita dopo 4 cicli ma non avevano considerato uno shortcut sulla
proposizione logica della condizione d'uscita.. io sono uscito in 2
cicli, con un 28 in tasca ;-)
--
ale
www.sen.it

possibile ottimizzarli decentemente in Python).
Mmm alllora discorso abbastanza semplice
codice Python -> profiler -> riscrittura parti lente con C/C++ o Pyrex


bottiglia per le prestazioni dell'intero programma.
Ok. Proverò comunque a riscrivere pezzi di qualche piccola
applicazione con Pyrex, almeno per provare...


 applicazione con Pyrex, almeno per provare...
Buona idea, e` uno studio che male non puo` fare.
Alex


Sbagliate tutti e due:
Il tasto CTRL non è necessario se usi [ALT GR] (che equivale poi alla
combinazione dei tasti [CTRL]+[ALT]), altrimenti non funzia...
Martino

 Forse, se si prende "algoritmi" in un senso molto esteso che
[...]
sfondi una porta aperta. Era solo una precisazione


 questo loro bug fosse un bug:-).
voi chi contattate per le lamentele?


 combinazione dei tasti [CTRL]+[ALT]), altrimenti non funzia...
Hai ragione, ma non avevo mai provato con ALT (per le graffe uso la destra).
Kiuhnm

 voi chi contattate per le lamentele?
Io per fortuna ne sono fuori, comunque l'azienda (think3 inc) paga un
tot per avere un certo livello di supporto per sviluppatori (a mio parere
non fu mai un buon affare) che prevede UNA persona dal lato think3
(conoscendo il mio grande dono per la diplomazia, non fui mai
assegnato io a quel ruolo, quindi non so il nome di chi dal lato MS
ci segue e/o seguiva).
Alex

 altrettanto).
quali sono i limiti del pascal usato come linguaggio didattico? A me e` 
sempre piaciuto un sacco!


sempre piaciuto un sacco!
Forse se si vuole esplorare l'OOP a scopo didattico non è indicato. Ad
ogni modo anche a me Pascal (il primo linguaggio non si scorda mai :P)
è sempre piaciuto ma non sono più abituato alla sua rigidità :(


 è sempre piaciuto ma non sono più abituato alla sua rigidità :(
Io c'ero pienamente abituato, ma scoprire "Rexx" (di Mike Cowlishaw,
un collega alla ricerca IBM) quando tra l'altro ancora aveva una "x"
sola fu una rivelazione -- sintassi leggibile (piu` di Pascal) _e_
potenza quasi paragonabile a quella di Scheme (che pure amavo) senza
la valanga di parentesi.  Tanto del lavoro di studio statistico del
linguaggio naturale lo feci in Rexx (con giusto quel minimo di
Pascal, Fortran, o IBM/370 BAL che proprio ci voleva...).  Oggi
confrontandolo con Python vedo i suoi difetti, ma allora sembrava
magico.
Alex

Io c'ero pienamente abituato, 
Idem, infatti ho usato per parecchio Delphi e ObjectPascal, ma da
quando mi sono "evoluto" al C e poi al Python non riesco più a
scrivere ' := ' oppure ' var ' o  ' begin ' e ' end '. Forse è anche
per questo che il mio tentavivo di usare VB (a mio avviso una sintassi
penosa) dopo Delphi s'è risolto in un " lasciamo stare :P "


corso e mi ci vorrebbe una pagina per descriverle :-)
Immagino non tanto diverse da quelle dei miei compagni quando c'è
stato spiegato il C.


stato spiegato il C.
Beh non condivido la scelta di spiatellare in faccia a chi non sa
nemmeno cosa sia un linguaggio di programmazione la scritta
namespace Pippo {
  namespace Paperino {
   class Pluto {


 su implementazioni gratuite e open-source...).
qua a Genova le esercitazioni per il corso di "Basi di dati" si basano su 
Access e SQL-server :-((( (che per inciso messi assieme mi hanno dato 
non pochi problemi l'unica volta che ho dovuto realizzare per lavoro un 
programma un poco piu` complicato del solito)
Per fortuna il corso di Sistemi Operativi si basa interamente su Linux 
:-))


Per fortuna il corso di Sistemi Operativi si basa interamente su Linux 
non vedo l'ora di arrivare al secondo anno :)
ora devo smazzarmi Architettura degli elaboratori (interessante ma
pesante :) 


 pesante :)
Bello questo esame (se studi dai libri giusti), insieme a quello di "Calcolo
Numerico" (so che ti sembrera' strano, ma io impazzivo per la matematica e
la fisica dei primi due anni) e' uno di quelli che mi e' piu' piaciuto.
Ricordo che cominciai a sudare freddo quando sul testo scritto dal nostro
professore, notai che c'era la spiegazione *dettagliatissima* di un
perforatore di schede, dei cicli di isteresi e di tante altre cosette
simpatiche. In seguito mi procurai quello di Tanenbaum e si apri' tutto un
altro mondo, anche se in alcuni passi c'e' del tipico umorismo inglese,
veramente poco divertente ;)
--------------------------------
Inviato via 
http://usenet.libero.it

veramente poco divertente ;)
il Tannenbaum sull'architettura giusto? non stai parlando di Calcolo
numerico :) ?!


 numerico :) ?!
Gia' :)


Un po' come uno studente di medicina operare sui pupazzetti di peluche ! ;)
hehe, a quel punto potrebbero mettere la frequenza non obbligatoria :P


 c'e' del tipico umorismo inglese, veramente poco divertente ;)
perche`? A me l'umorismo di Tanenbaum fa impazzire :-)
<quote>
Pertanto, quello che fanno gran parte delle macchine quanto si trovano ad 
un salto condizionato e` prevedere se questo verra` eseguito o no. 
Sarebbe bello poter inserire una sfera di cristallo nelPCI per farci 
aiutare con la predizione, ma per ora questo approccio non e` possibile.
Poiche` manca una periferica di questo tipo...
</quote>
:-)))


 pesante :)
anche da noi Architettura e` l'esame piu` pesante del primo anno, ma IMHO 
e` senz'altro il piu` bello (assieme a Matematica Discreta)
Per quel che riguarda il libro ti consiglio di comprarti il Tanenbaum, e` 
*ottimo* (trovi anche la mia recensione su 
www.programmazione.it
, 
sezione Altri)


 Poiche` manca una periferica di questo tipo...
LOL, be', migliora invecchiando ;))


sezione Altri)
Ho letto la rece e lo trovo ottimo, ma aspetto il secondo semestre ad
ordinarlo...prima vediamo di passare il compitino di reti logiche :)


 e si apri' tutto un altro mondo
Confermo, approvo e sottoscrivo.
Un gran bel libro, e non solo dal punto di vista dell'architettura dei
calcolatori (nell'edizione in mio possesso parla di Pentium II, JVM e
Sparc 8 o 9, non di Zilog 80, con tutto il rispetto), infatti
esemplifica magnificamente il concetto di approccio a livelli (anche
se poi uno potrebbe anche essere in disaccordo sui livelli scelti da
Tanenbaum).
--
ale
www.cercote.it

 perche`? A me l'umorismo di Tanenbaum fa impazzire :-)
Mi ricordo un passo di Computer Networks:
"Mai sottovalutare la banda passante di un furgoncino lanciato a tutta
velocita` sull'autostrada"
:-)
-- 
 Ciao, Bianco.                         Reply to luca.bianco (at) 
tiscali.it
|---------[Powered by Debian GNU/Linux 3.0 - 2.2.20 - AMD K6-200]---------|
|------------[Linux Registered User #287769 - Machine #169192]------------|

velocita` sull'autostrada"
LOL! è un grande :)
