Newsgroup: it.comp.os.dibattiti
Titolo: Chicca: C# 2.0

http://www.c-sharppro.com/features/2003/10/cs200310bw_f/cs200310bw_f.asp
Articolo splendido, ho riso per ore.
Dove l'ho visto quello yield ?
Ao', gratta da Lisp, gratta da Python, prima o poi diventera' decente ?
-- 
                                                __Nicholas Wieland
Explicit is better than implicit.
                                                __The Zen of Python

 Ao', gratta da Lisp, gratta da Python, prima o poi diventera' decente ?
Ho dato uno sguardo all'articolo... mmm a parte che sono cose che gia si
sapevano (sul sito msdn ci sono le specifiche di C# 2), non ci vedo niente
di male nel fatto che stiano copiando i linguaggi migliori ;-)
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com

 Ao', gratta da Lisp, gratta da Python, prima o poi diventera' decente
Embrace, Extend and Exterminate.
Saluti.

 di male nel fatto che stiano copiando i linguaggi migliori ;-)
allora stanno copiando dal prolog? ;-)
Vado subito a vedere.
PS: i generics di C# danno la birra ai template di C++
-- 
Best Regards,
Maurizio Colucci
Please remove the uppercase letters "S,P,A,M":
seSgPuAsM...@tin.it

 Embrace, Extend and Exterminate.
Questa è bellissima :-))))))))


Ao', gratta da Lisp, gratta da Python, prima o poi diventera' decente ?
Ma dai mica è così brutto C# ;)
E poi yield stava in ruby parecchi anni prima che in python, e prima
ancora in CLU prima ancora non lo so :)
E poi, Copiare Fa Bene (TM) 
PS
copiato da lisp cosa?

 copiato da lisp cosa?
Credo le funzioni anonime (che anche Python ha copiato da lisp)


 Credo le funzioni anonime (che anche Python ha copiato da lisp)
Si, e gli sviluppatori hanno fatto una cosa incredibile: hanno detto "che
figata le lambda functions di Lisp, prendiamole !".
Hai per caso visto GvR dire "hey, Python da la birra a tutti, il nuovo
grandissimo interprete avra' queste nuovissime e innovative ficiurs".
Questione di stile.

 PS: i generics di C# danno la birra ai template di C++
Nei linguaggi decenti non servono a un cazzo ne i template ne i generics.

 ancora in CLU prima ancora non lo so :)
E allora ? Tutti i linguaggi copiano, danno credito, e innovano. Di C# me
ne mancano due.
NP - VU & Nico, Heroin (a fagiuolo :p)

 Questione di stile.
Eddai Nicholas sai bene che e` inutile comparare GvR al marketing MS


 Nei linguaggi decenti non servono a un cazzo ne i template ne i generics.
Se vuoi puoi anche spiegarti meglio.
-- 
\/               
wirix...@libero.it
          ICQ UIN: 3233084
/\ e l l o s s   (per rispondermi in privato, elimina il DEMONE)

ne mancano due.
Ok, ma il problema è il marketing MS non il linguaggio in se.
Se filtri l'hype, rimane C# nasce come un java migliore, non come
grande innovazione della tecnica. 
E poi quale linguaggio ha introdotto nuovi importanti concetti
ultimamente? L'unica cosa nuova che viene in mente a me è l'aop, che
però era in realtà già possibile con il CommonLisp (almeno è quello
che mi dicono)
Cmq, nessun intento polemico, volevo solo spiegarmi e capire. 
Viva i linguaggi con duck typing!

 di male nel fatto che stiano copiando i linguaggi migliori ;-)
Non fosse che li spacciano per innovazioni loro non ci sarebbe nulla di
male.
Ma del resto se il programmatore e' stupido la major sguazza.
-- 
                                                __Nicholas Wieland
Sparse is better than dense.
                                                __The Zen of Python

 che mi dicono)
Le innovazioni possono anche non essere implementative, cosa vuol dire.
Anche l'OO era possibile in C.
Un sistema di template basato su XHTML mi sembra abbastanza innovativo,
ad esempio, su framework attualmente piu' blasonati di Zope, ad esempio
ASP.NET
, tanto per prenderne uno a caso, per avere XHTML valido devi
sgozzare un capretto al chiaro di luna, per non parlare delle esilaranti
invenzioni di PhP (aka Smarty e altre fesserie).
Al di la di questo l'approccio all'implementazione di un linguaggio e'
fondamentale: il ragionamento di questi pirla e' "rubiamo programmatori
a questo linguaggio", non "rendiamoli produttivi".
-- 
                                                __Nicholas Wieland
Errors should never pass silently.
Unless explicitly silenced.
                                                __The Zen of Python

 Se vuoi puoi anche spiegarti meglio.
Credo che intenda i linguaggi altamente dinamici, insomma non i soliti Java, 
C++ e C#


 Ma del resto se il programmatore e' stupido la major sguazza.
Beh il problema qui piu` che altro è il famoso "pointy-haired boss" ;-)


 Nei linguaggi decenti non servono a un cazzo ne i template ne i generics.
In altre parole: linguaggi altamente inefficienti rendono inutili template e
generics perchè generalizzano il mondo. Vanno poi lentissimi, ma è un altro
discorso.
Saluti
Massimo

 qualcosa.
Dipende. Personalmente l'approcio di C# (C++ *meno* qualcosa) mi piace.
Cosa toglieresti a Java per renderlo migliore? Personalmente io trovo solo
cose che andrebbero aggiunte, non levate!
Saluti
Massimo

 Se vuoi puoi anche spiegarti meglio.
A cosa servono i 'generics' se i containers sono gia' 'generic' ?
E' un problema che chi ha progettato C# si e' creato, e si e' risolto, con
una discreta pezza, fatta passare per 'incredibile ficiur', come sempre.
E' un non-problema.
-- 
                                                __Nicholas Wieland
Beautiful is better than ugly.
                                                __The Zen of Python

 A cosa servono i 'generics' se i containers sono gia' 'generic' ?
type checking statico


 : 

Stai parlando di VBScript ? Si, in effetti e' cosi', per questo *anche*
C# in un certo senso puo' essere visto come un miglioramento, ma non e'
cio' che avevo in mente.
Se vuoi trovarne altri puoi dare un'occhiata a Brainfuck.
Non preoccuparti, anch'io al liceo usavo il trucco di uscire con il piu'
sfigato, cosi' sembravo piu' figo io :)
Se pero' ti riferisci a Ruby/Python ti serve una buona ripassata al
concetto di 'tipizzazione dinamica', che a quanto pare ti manca
completamente.
BTW, non preoccuparti, sara' una nuova ficiur di C#++ 1.0


 messo i generics in un linguaggio"
 In time, you might see other languages add generics support. C# will
 be, however, the first to implement generics.
L'indirizzo per l'articolo l'ho gia' postato.
Del resto come e' ingenuo da parte mia aspettarmi dalla MS la stessa
correttezza di un GvR e' ingenuo da parte tua aspettarti che la solita
cricca non spacci il tutto per grande invenzione.
Non per dire, ma gugolando il nome dell'autore spunta un direttore
generale MS o qualcosa del genere. Non so pero' se e' lui.
-- 
                                                __Nicholas Wieland
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
                                                __The Zen of Python

  be, however, the first to implement generics.
Credo volesse dire "altri linguaggi CLR".
C# è il primo linguaggio CLR/CLS/CLI compliant che supporta i generic.


 type checking statico
E il type checking statico a cosa serve ?
-- 
                                                __Nicholas Wieland
Namespaces are one honking great idea -- let's do more of those!
                                                __The Zen of Python

 E il type checking statico a cosa serve ?
Per lo sviluppo incrementale.
Se cambio un'interfaccia non devo ritestare il programma


  be, however, the first to implement generics.
LOL a me questa frase sembra anche un controsenso semanticamente
parlando: in pratica ammettono che esistono altri linguaggi coi
generics (a proposito... chi ha i generics? in C++ si chiama template
e sono leggermente diversi) ma loro sono i primi (beh in teoria Java
arrivera` dopo)
ciao


 Se cambio un'interfaccia non devo ritestare il programma
Dai, ho un'opinione troppo alta di te per sentire queste cose: nessuno
dice 'a' di Nautilus senza passare per le mie ire, gli unici vivi siete
tu e Lawrence :ppp
Fammi un esempio, cosi' ti dimostro che non e' vero.
BTW, parti da un assunto errato, i test vanno *sempre* eseguiti, non
eseguire i test non e' un aumento produttivo, ma una perdita di
sicurezza. Un aumento produttivo e' non dichiarare il tipo di ogni
variabile, anche se questo non e' particolarmente inerente al concetto
di tipizzazione statica, ma del resto di C# stiamo parlando.
-- 
                                                __Nicholas Wieland
Simple is better than complex.
                                                __The Zen of Python

 di tipizzazione statica, ma del resto di C# stiamo parlando.
-- 


 type-checking statico.
Beh, Zope e Plone sono grossi progetti. Il problema non esiste, anche
per quello che mi riguarda gli errori dovuti al type checking dinamico
li conto sulle dita di una mano, e di gente rincoglionita come me ne
trovi poca.
HAND,


 per quello che mi riguarda gli errori dovuti al type checking dinamico
Mi dici le righe di codice di Zope e Plone? Secondo me siamo molto lontani
dal "grosso" progetto per come lo intendo io.
Saluti
Massimo

 dal "grosso" progetto per come lo intendo io.
Cioe' secondo te un application server non e' un grosso progetto ?
Interessante. Le 'righe di codice' per linguaggi che fanno del basso
numero di righe di codice un vanto ? Ottimo metro.
Mi dici un progetto piu' grosso di un application server ? 
Comunque l'attuale Zope sono poco piu' di 100k.
HAND,
-- 
                                                __Nicholas Wieland
Special cases aren't special enough to break the rules.
Although practicality beats purity.
                                                __The Zen of Python

 niente di male nel fatto che stiano copiando i linguaggi migliori ;-)
Già. Ma i generics sono annunciati anche per j2se 1.5. In questi casi, chi 
copia? 
1 - Entrambi, sono i template del C++
2 - Nessuno dei due, è un paradigma consolidato
3 - La Microsoft per definizione

 Già. Ma i generics sono annunciati anche per j2se 1.5. 
Eh... ci voleva la Microsoft per farli svegliare. In un linguaggio
fortemente tipato è semplicemente ridicolo avere container debolmente
tipati.


 2 - Nessuno dei due, è un paradigma consolidato
ti sei risposto da solo.


 Ao', gratta da Lisp, gratta da Python, prima o poi diventera' decente ?
hehe, arrivo tardi... ma sto thread mi e' piaciuto. :)
c# per essere stato progettato da uno sponsor con i milioni
di dollari nelle tasche non e' nulla di speciale.
e' li il dramma, o se volete, la truffa.
-- 
email: goldicus1970 AT yahoo DOT it
blog: 
http://www.deelan.com/

 3 - La Microsoft per definizione
A dir la verita' si parla da *tanto* dei generics di Java, semplicemente
Sun ci impiega una vita.


 3 - La Microsoft per definizione
No, non per "definizione", per "cose di fatto"...
Qualche _reale_ novita' introdotta da MS che non sia lo slogan
"freedom to innovate" [1]?
C:\>iao Angelo
[1] Anche il FUD ha copiato :-)
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 No, non per "definizione", per "cose di fatto"...
Cioè, insomma, mi dici chi ha copiato o no? <g>

 Cioè, insomma, mi dici chi ha copiato o no? <g>
Nel caso di linguaggi di programmazione tutti copiano qualcosa
dagli altri. Nel caso specifico non ti so dire: se lo ha fatto,
non ha fatto niente di strano.
C:\>iao Angelo


 "freedom to innovate" [1]?
Mi balena alla mente una cosa: la SUN cosa ha fatto di innovativo? (non
penso che abbiano inventato loro il concetto di virtual machine)


 penso che abbiano inventato loro il concetto di virtual machine)
Se non haltro hanno avuto il buon gusto di non creare slogan
tipo [1].
C:\>iao Angelo
P.S. Anche perche' l'utente medio SUN si sarebbe messo a ridere,
     al contrario dell'utente medio Windows.


 tipo [1].
"We make the net work" ti sembra molto meglio? Come se fosse merito loro.
Saluti
Massimo

 "We make the net work" ti sembra molto meglio? Come se fosse merito loro.
Infatti e' merito della Cisco :-)
Non so quanto e' recente lo slogan, fino a qualche anno fa un fondo di
verita' c'era.
C:\>iao Angelo


 penso che abbiano inventato loro il concetto di virtual machine)
Assolutamente nulla, da quel che so.
Ma tra prendere da diversi linguaggi e crearne uno e clonarne uno per
aggiungere poi da diversi linguaggi c'e' una bella differenza.
Il punto fondamentale e' che non aggiunge nulla di nuovo, potevano
semplicemente prendere un buon linguaggio gia' esistente e integrarlo
nella piattaforma .net.


 nella piattaforma .net.
Ma vuoi mettere che Java e' gia' consolidato sul web e che loro hanno
dovuto togliere da Windows la loro bella MSJavaMachine?
Qualcuno e' ancora convinto che C# restera' per molto un linguaggio
aperto (nonostante mono)?
C:\>iao Angelo


 cose che andrebbero aggiunte, non levate!
toglierei le "checked exception".
tanto e' vero che C# non le ha.
:)
-- 
email: goldicus1970 AT 
yahoo.it
blog: 
http://www.deelan.com/

 nella piattaforma .net.
Sai bene che non l'avrebbero fatto, piuttosto mi domando perche` de Icaza
abbia investito tanto tempo e sforzo in Mono quando poteva benissimo usare
un linguaggio come Python e ricamarci sopra.


 aperto (nonostante mono)?
Beh dallo standard non si torna indietro e per quanto ne so
hanno gia` inviato le specifiche del 2.0


 un linguaggio come Python e ricamarci sopra.
Beh, in tal caso le applicazioni scritte per windows non ci avrebbero
girato!


 Beh dallo standard non si torna indietro
:-)
Anche Java e' "standard" [1] e ti lega da una licenza d'uso,
nonostante tutto alla Microsoft se ne sono sbattuti gli zebedei
nel senso piu' ampio del termine [2]. HTML e' standard e, come e'
noto, IE lo ripetta alla lettera. Kerberos e' standard e mamma MS
ha sentito impellente bisogno di implementarlo in modo che tutte
le installazioni presenti fossero compatibili.
C# e' "cosa loro" vuoi che non peschino carpe a sufficienza per poi
fare (come hanno sempre fatto) quello che gli pare e piace?
Poi non dite che sono monotono :-)
C:\>iao Angelo
[1] Mi si passi il termine.
[2] Se ne sono sbattuti tanto ampiamente che SUN li ha citati. Lo
    sbattimento era talmente palese che hanno perso prima di mettere
    piede in tribunale.


 girato!
Arguta osservazione ;-) Ma da quando ai linuxari importa molto se
le app per windows girino su linux? :)
ps. è una provocazione, come d'altronde il mio post precedente


 fare (come hanno sempre fatto) quello che gli pare e piace?
Stiamo a vedere.


 penso che abbiano inventato loro il concetto di virtual machine)
Beh, hanno inventato i packages con le classi devono stare nella stessa 
struttura delle directory... ah, poi hanno inventato i file sorgenti che si 
devono chiamare come la classe che contiene (un s'avessero a perdere)... 
:)

 :)
Il motivo c'è: ai tempi della nascita di Java il filesystem MS era ancora
8.3. Oltretutto, come da specifica, un file Java per essere riconosciuto
dal compilatore deve avere estensione .java.
Chiaro? Semplicemente alla Sun erano un tantinello ottimisti...
-- 
"It is not enough to succeed.  Others must fail."
Linux Registered User #301571, running Gentoo
Memeber of Luganega - Linux User Group Crema (IT)
http://filibusta.crema.unimi.it/

+++++++++[<++++++++>-]<----.>+++++[<+>-]<.>++++[<-->-]<.>+++++[<++++>-]<.

 8.3. 
Mmm... non vedo il nesso.

 Mmm... non vedo il nesso.
Era per rendere impossibile l'utilizzo di java su piattaforma MS: i nomi dei
package e delle classi non sarebbero potuti essere più lunghi di 8
caratteri e comunque il compilatore non avrebbe accettato nessun sorgente,
visto che è obbligatoria l'estensione .java.


 Era per rendere impossibile l'utilizzo di java su piattaforma MS: 
Non era impossibile, non da quando java si è affacciato come linguaggio 
applicativo per computer. E poi il jdk 1.0.x chi ce l'ha portato sotto 
windows, io? :) Anche se Sun ci ha abituato a strategie bizzarre...

 nella piattaforma .net.
In ogni caso il senso del mio post non era tanto "copiare e' male"
quanto "c'e' modo e modo".
-- 
                                                __Nicholas Wieland
In the face of ambiguity, refuse the temptation to guess.
                                                __The Zen of Python

 un linguaggio come Python e ricamarci sopra.
Piattaforma comune con Windows, mi sembra abbastanza chiaro.
Io *so* bene che le strategie commerciali della Microsoft vanno dal
divertente al demenziale, cio' non significa che non possano di tanto in
tanto avere uno sprazzo di intelligenza. Sara' per la prossima volta.
-- 
                                                __Nicholas Wieland
If the implementation is hard to explain, it's a bad idea.
                                                __The Zen of Python

 tanto avere uno sprazzo di intelligenza. Sara' per la prossima volta.
Era ironico.


 dovra` usare .NET e un linguaggio di tale piattaforma. Vedi un po` tu.
Aggiungo che ho sottolineato con e per MS, nulla ti vieta di usare
Python, Java, C++, Ruby o che altro. 
In futuro su win ci sara` una piattaforma comune e linguaggi diversi,
che ti serve di piu`... ?? Certo che il C# sara` piu` diffuso degli altri,
e` anche uno dei linguaggi con cui e` scritta la piattaforma.


 Corporation.
Che c'entra ?
HAND,
-- 
                                                __Nicholas Wieland
Namespaces are one honking great idea -- let's do more of those!
                                                __The Zen of Python

 Che c'entra ?
Dato che Python e` po` piu` sconosciuto e` ovvio che sia meno diffuso.
Nell'universita` dove sto io, chi conosce Python li conto sulle dita di
una mano (forse una e mezza)... i Javisti sono _legioni_


  i Javisti sono _legioni_
   ...detta cosi` fa quasi paura...
Vh
-- 
                          | Mi sto arrabbiando...
\|/ ____ \|/   \ ||_|     | ...non vi piacerebbe vedermi
"@'/ ,. \`@"    \|| |     |    arrabbiato...
/_| \__/ |_\ Vax Headroom |
   \__U_/                 |       Dr. David Bruce Banner

    ...detta cosi` fa quasi paura...
deve farne infatti ;-) ahahah


 Ho i test.
Bene, benissimo. Mi interessa. Questo significa che il prolog diventa
un linguaggio perfetto sotto ogni punto di vista. Quando hai tempo
fammi un esempio. Grazie :-)



AFAIK 
java.net
 non esiste, ne' esistera' perche' Microsoft non puo' farlo e
Sun non ha intenzione di farlo, quindi...
Alessandro.

 fammi un esempio. Grazie :-)
Sinceramente non credo esista il linguaggio perfetto (tant'e` che hai
dovuto usare c++ e non ti e` bastato solo il prolog), pero` non si e`
ancora capito perche` sia cosi` perfetto. Quel po` di codice prolog
che ho letto non e` cosi` semplice da leggere, almeno non ai livelli
di altri linguaggi piu` espressivi.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 Sun non ha intenzione di farlo, quindi...
A parte che esiste l'ibrido J#, prova a guardare questo:
http://www.ikvm.net/
Trovi il codice su sourceforge/projects/ikvm
Comunque hai ragione, non esistera` mai un Java di MS per .NET (non avrebbe
alcun senso cmq)


  dicevo, il refactoring diventa tragicamente faticoso.
D'altro canto, in un ambiente di sviluppo serio ed anche no,
dovrebbe esserci un tester per ogni sviluppatore, con il
preciso compito di scrivere il codice di test.
Lo fanno persino in Microsoft... :-)
bye,
-- 
   Piergiorgio Sartor


Scusate se mi intrometto: ma se il dominio della funzione somma e' infinito
come fai a verificare che sia corretta per ogni coppia (a,b)?
Alessandro.


A questo non ci avevo pensato...
Alessandro.

 altri linguaggi piu` espressivi.
Ma se si legge come l'italiano! :-)
Beh, devi prima entrare un po'nel paradigma logico.


test...@despammed.com
 (test) writes:

Questa e` roba che io ingegnere lascio a voi matematici...
Io so che se ti mando 3 e 3 deve uscire 6 e non 7. 
La verifica di tutte le operazioni possibili e` inutile, si verificano
i casi limite e qualche caso palesemente errato e si vede cosa
succede, interessa che funzioni.
Ad ogni modo la base di ogni test e` che il linguaggio sia giusto e
funzioni nel modo corretto, se non sa fare le somme e` sbagliato il
linguaggio e per quello potrebbe essere sbagliato tutto, anche il
processore.


 A questo non ci avevo pensato...
Beh io si ;-)


 Beh, devi prima entrare un po'nel paradigma logico.
Non supporta altri paradigmi?


 e` una keyword e solitamente si usa proprio quella per il testing.
Confonduto ti sei. assert_, non assert, che serve ad altro.
HAND,


>> type (a ['bar'])
<type 'tuple'>
Questo e' un linguaggio *fortemente* tipato, ma dinamicamente.


 come fai a verificare che sia corretta per ogni coppia (a,b)?
E` per questo che c'e` gente pagata per rompersi la
testa su come verificare al meglio ed in minor tempo
possibile una data funzione.
Insomma serve un po' di ingegno per controllare i
potenziali punti dolenti dell'implementazione.
Ovviamente la cosa non e` infallibile, serve pero`
a dare un discreto grado di confidenza che tutto
funzioni come dovere.
Di solito partendo dalle specifiche...
Esempio, diciamo di definire la funzione e=div(a,b,&c)
che calcola a/b, ritorna il risultato in "c" ed un
eventuale codice di errore in "e".
La specifica dice che e=-1, se b=0, e=-2 se c=NaN,
ovviamente e=0 se non vi sono errori.
Devi testare la funzione in non piu` di 5 tentativi... ;-)
bye,
-- 
   Piergiorgio Sartor

 E il type checking statico a cosa serve ?
1) A rendere il programma più efficiente, eliminando tutti i controlli
    altrimenti necessary a runtime.
2) Ad evitare che il tuo programma crashi quando meno te lo aspetti per
    situazioni che un compilatore con controllo statico dei tipi avrebbe
    fatto venire a galla durante la compilazione.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                 |     Bertrand Russell
falemagn (AT) aros (DOT) org    |     The Philosophy of Logical Atomism

 succede, interessa che funzioni.
E' per questo che non esistono test esaustivi.
Saluti.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004

    fatto venire a galla durante la compilazione.
credo sia già stato detto N volte che, per chi usa i test, questo è un
non problema. Per non dire che, in assenza di generics il compilatore
non può individuare i suddetti bug.
Chi non usa i test.. ops, è questo il bug ;) 
IMNSHO la tipizzazione statica è utile a livello documentativo ma non
fondamentale.. 

 fondamentale.. 
C'è chi la pensa diversamente. Fammi vedere dove si usano linguaggi 
blandamente o per niente tipizzati in applicazioni mission critical, e 
ti do ragione.


 fondamentale.. 
La tipizzazione *è* fondamentale. Stiamo parlando di linguaggi (C#,
java) dove non esiste nulla che non sia un tipo, figuriamoci se adesso è
solo "utile a livello documentativo". Per assurdo, niente ti vieta di
scrivere un programma java dove definisci ogni variabile di tipo Object,
nessuna tipizzazione statica, lo puoi fare e funziona... se è questo che
tu intendi quando dici che la tipizzazione statica non è fondamentale.
Ma il programma di solito deve anche funzionare :) In oop esiste
l'astrazione e deve essere usata quando serve, non per dire che la
specificità del tipo è opzionale... 

 L'indirizzo per l'articolo l'ho gia' postato.
Se non fossi accecato da questa tua voglia di dare addosso a MS, forse 
avresti notato anche la prima parte del paragrafo:
"To implement C# generics, Microsoft is changing the CLR and Microsoft 
Intermediate Language (MSIL) as well. In time, you might see other 
languages add generics support. C# will be, however, the first to 
implement generics."
Si riferisce chiaramente al fatto che il C# sarà il primo linguaggio 
della famiglia .Net ad avere il supporto per i generics, ma che in 
futuro altri linguaggi di tale famiglia li supporteranno. Niente a che 
vedere, quindi, con l'essere "i primi del mondo".


ti do ragione.
ti do ragione prima io ;)
Non credo nel "linguaggio taglia unica" per ogni situazione. Ho detto
"non fondamentale", non 'inutile'. 
Poi che cosa intendi per mission critical? Se intendi quelle cose tipo
razzi, treni etc.. insomma roba per ADA ed Eiffel, non credo che la
tipazione statica sia l'unico requisito. 
Si pone la necessità di subtyping per range, controllo sulla semantica
dei parametri alle funzioni, Design By contract, gestione della
visibilità più complessa del semplice 'private', e constraint di tutti
i tipi. Per ADA si parla anche di processo di validazione di tutta la
build toolchain, per eiffel non so. 
Insomma, si aggiungono layer di controllo, come sempre, e si fa molto
testing. Ma io ritengo che la cosa primaria sia il testing, e quella
secondaria la tipazione statica. E  nonostante tutte ste belle cose è
esploso un ariane per un errore in virgola mobile ;)
Se invece ci limitiamo ad applicazioni real time tipo, che ne so, i
satelliti, ce ne sono parecchi che girano con codice C (vedi il
progetto PAMELA, ad esempio, e il SO RTEMS). E ancora, C  *è*
blandamente tipato.
Ad ogni modo, io non sono contro la tipazione statica in toto. Ritengo
solo di non aver visto sistemi con tipazione forte+statica che
garantissero effettivamente il funzionamento di un sistema. Ma non
conosco i linguaggi con auto type inference

 controllo a compile time sui tipi. 
In un linguaggio fortemente tipato, se fai abuso dell'astrazione non c'è 
dubbio che devi testare molti più percorsi e molte più situazioni. Cioè ti 
complica molto la fase di test. Su questo non c'è dubbio.

 Se non fossi accecato da questa tua voglia di dare addosso a MS,...
Meno male, mi sembrava che il NG si stesse rammollen... ehm...
"rabbuonendo" negli ultimi tempi :-)
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

     fatto venire a galla durante la compilazione.
Scrivere i test, come detto altrove.
Non risulta un po' strano che tutte queste situazioni apocalittiche non
siano mai capitate a chi mantiene grosse quantita' di codice in
linguaggi tipati dinamicamente mentre siano piu' frequenti nei linguaggi
tipati staticamente ? Zope e' sensibilmente piu' grosso di Apache, ma ha
avuto meno problemi, tant'e' che di tanto in tanto il bacherozzo con
relativo upgrade salta fuori, anche in Apache 1.3, che e' in produzione
da un buon secolo ... a me un dubbio verrebbe.
Benritrovato Alemagna :)
HAND,
-- 
                                                __Nicholas Wieland
Beautiful is better than ugly.
                                                __The Zen of Python

 vedere, quindi, con l'essere "i primi del mondo".
Chiaramente ? Dove lo dice ? "Languages" = "linguaggi della famiglia
.net" ?
Rimarcando continuamente che dire "C# e' merda" non significa dare
addosso a MS, o sempre "dato addosso" anche a Java, e credo che tra le
tante volte che ho parlato di .net questa sia la prima volta che ne
parlo male. Ma non mi devo giustificare, se non volevi fare il troll
cercavi sul buon Google e ne trovavi a iosa. A questo punto potresti
anche darmi dello GNUlebano, qui e' moda andar dietro ai luoghi comuni e
piagnucolare appena qualcuno ha il dubbio che i giocattoli della MS non
siano cosi' perfetti.


 ti do ragione.
Definisci mission critical, poi mostrami applicazioni mission critical
in Java o C#, poi guardati QNX (C).
Rimarcando (ancora, e ancora, e ancora, e ancora) che Python e Ruby sono
fortemente tipati.
-- 
                                                __Nicholas Wieland
Simple is better than complex.
                                                __The Zen of Python

 cercavi sul buon Google e ne trovavi a iosa
Eh? Fare il troll? Ma come, TU spari cazzare, ed IO faccio il troll? :-)
Suvvia, ti brucia, s'è capito... Niente di grave, capita a tutti prima o 
poi.


 fortemente tipati.
Ed io ho forse detto il contrario? Sei tu che dici che i linguaggi 
tipati non hanno senso d'esistere, non io.


 E' per questo che non esistono test esaustivi.
y/x   (y diviso x)
Che test faresti?  Dalla tua risposta scommetto che ti limiteresti a
vedere che siano tipi numerici e poi controlleresti ogni coppia di
valori ovvero infinite. Oppure eviti addirittura di controllare e
quindi non e` funzionante.
Ricordiamoci di evitare le boiate quando sappiamo che le stiamo
scrivendo.
Che senso ha testare un dominio anche dove sappiamo che esiste o non
esiste sicuramente?


 complica molto la fase di test. Su questo non c'è dubbio.
C'e` qualcosa che non va...
Se qualcuno qua avesse dei dubbi provo a dipanarli:
Tipizzazione statica/dinamica e forte/debole sono concetti DIVERSI.
Non mi si puo` parlare di tipizzazione forte come controparte della
tipizzazione dinamica.
Nello specifico si parlava di python che e` tipizzato FORTEMENTE e
DINAMICAMENTE. Pere e mele non si sommano, ma finche` non me le trovo
davanti so sempre fare una somma tra due cose.


 conoscenza accurata di che cavolo stai parlando.
Guarda... Magari ti rovino l'arrivo in trionfo pero` quello che hai
scritto sopra, oltre che palesemente sbagliato, fa anche capire che tu
i test non li conosci.
La verifica dei tipi e` un sottoinsieme (e pure piccolo) di unit
testing e system testing. Un algoritmo a cui fai entrare un tipo
sbagliato non funziona e quindi hai fatto il test che verifica i tipi.
Ma io dico... Non ci vuole molto a informarsi prima di dire cose
palesemente errate, come ti viene in mente che un test di
funzionalita` non sia in grado di verificare i tipi?
Nicholas sara` anche aggressivo (pure io lo sono e su questo NG lo
siamo in tanti) ma in questo caso non ha assolutamente torto. E non
sono certo io a dirtelo ma altri come Andrew Koenig, Alex Martelli,
Guido Von Rossum, Tim Peters e via via molti e molti altri che di
programmazione qualcosina sanno, sicuramente piu` di noi, con buona
nostra pace (anche se non ci stanno magari troppo simpatici).


 funzionalita` non sia in grado di verificare i tipi?
Se tu leggessi quello che uno scrive, capiresti che tale cosa non mi è 
mai venuta in mente, e non l'ho neanche scritta! Ho detto che gli unit 
test servono a testare algoritmi, non ho detto che "non sono in grado" 
di verificare i tipi.
Che poi in un linguaggio dinamicamente tipato tu ci metta pure il test 
sul tipo, è un requisito necessario per il funzionamento del test in se, 
nel senso che senza di esso sarebbe il test stesso a non funzionare, e 
non la cosa che testa.
Fatto sta, che tale controllo sul tipo, come detto, devi renderlo parte 
integrante del tuo programma, penalizzando le prestazioni ed anche 
influenzando la complessità dell'algoritmo stesso, nel caso il controllo 
del tipo non sia O(1).


 nostra pace (anche se non ci stanno magari troppo simpatici).
Beh, tanto di cappello, per carità, ma almeno due persone dovresti
toglierle dalla lista perché interessate personalmente...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 controllo del tipo non sia O(1).
Il controllo del tipo puo` essere una rottura ma non sempre serve,
anzi sovraottimizzare e` tanto criminale quanto non ottimizzare
assolutamente.
Molto piu` saggio ottimizzare solo quando serve e per quanto serve,
scrivendo l'estensione a mano, usando pyrex (del quale ho gia`
parlato), modificando l'algoritmo per farlo funzionare in modo piu`
furbo e tante altre cose. Tutto questo sulla velocita` pero` arriva
solo dopo la profilatura e il benchmarking del codice.  Ma il fatto e`
che il 90=95% dei compiti o e` gia` abbastanza veloce senza
ottimizzazioni oppure sta ad aspettare le latenze dei mezzi che usa o
aspetta l'input da tastiera, ragion per cui e` inutile fasciarsi la
testa prima di essersi fatti male.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 toglierle dalla lista perché interessate personalmente...
Eh eh :), hai sicuramente ragione pero` gente che conosce una ventina
di linguaggi direi che e` in grado di dare una valutazione globale
della cosa.
Tanto piu` che gia` Koenig e` abbastanza IMHO. Ora devo leggermi il
suo C Traps & Downfalls.
Gli altri 3 sono tutti programmatori che hanno accesso al CVS di
python e Peters e` il responsabile per molti degli algoritmi codati in
C presenti in python (come il sort che e` decisamente veloce, credo
abbia usato il samplesort ma forse ha cambiato algoritmo per l'ultima
versione). BTW e` gente che a prescindere sa abbastanza tanto sulla
programmazione per avere voce a riguardo.
Non sono comunque gli unici, anche i programmatori Lisp (che e` un
signor linguaggio) la pensano allo stesso modo.


 signor linguaggio) la pensano allo stesso modo.
Sai cos'è che non mi convince? Che ci sono validi motivi per
ritenere la garbage collection una pessima scelta (e neppure uno per
ritenerla una buona scelta). Quindi faccio fatica ad accettare le
opinioni di persone che invece la ritengono una buona scelta, anche se
parlano di altro...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 scoprono solo con lo Unit Testing.
E quello non l'ho mai messo in dubbio. Ma quello non è un controllo sui 
tipi.
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                 |     Bertrand Russell
falemagn (AT) aros (DOT) org    |     The Philosophy of Logical Atomism

 parlano di altro...
Oh caspita che balle... Ogni volta una nuova. Tu usi gli auto_ptr?
Bene, in python quando qualcosa ha 0 reference viene eliminato.
Le ragioni? Non ci sono memory leak, a meno di andarseli a cercare
apposta con referenze cicliche.
Se parli di java posso capirlo o in generale dei gc mark&sweep, ma non
del reference count di python che ha un funzionamento molto piu`
simile agli auto_ptr che ad altro.
Basta guardare il codice delle estensioni di python scritte in C/C++,
il gc e` si automatico ma l'estensione gli da una mano parecchio
grossa... La parte difficile della scrittura estensioni e` proprio la
gestione dell'incremento/decremento delle referenze.
La gestione della memoria e` roba di basso livello che neanche sempre
serve (anzi quasi mai) e ti fa perdere tempo a gestirla piuttosto che
pensare alla soluzione del problema.
Se permetti poi ritengo Koenig decisamente piu` esperto di qualsiasi
altro partecipante di questo NG, ovviamente con rispetto per tutti che
in buona parte ne sapete sicuramente piu` di me.


 in buona parte ne sapete sicuramente piu` di me.
Beh, non è che siano mie opinioni:
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
Oltretutto l'articolo è molto interessante anche per altri aspetti.


 succede, interessa che funzioni.
L'esempio di codice è insensato per essere preso in considerazione, in 
particolare le strategie di test che hai più o meno citato sono valide ma 
si riferiscono ad un approccio tipo "gray-box": ovvero, questa strategia si 
propone di progettare i test servendosi di criteri funzionali e quindi di 
usare i criteri strutturali per valutare se il test è adeguato e 
soddisfacente. In realtà sei in presenza di una "black-box", non sei in 
grado di conoscere i criteri strutturali della porzione di codice quindi 
non sei in grado di sapere se il test è adeguato o meno. 
In generale non ha senso parlare di test software su programmi/porzioni di 
codice di cui non si conosce l'implementazione, nel caso specifico si 
tratta di una esasperazione del concetto di test... 

 tratta di una esasperazione del concetto di test... 
Ma non e` affatto vero, anzi, i migliori test si hanno
nella piu` assoluta ignoranza dell'implementazione, dato
che la non conoscenza implica la necessita` di testare
molti piu` aspetti e consente di scoprire falle che
l'implementatore non aveva considerato.
Se si conosce l'implementazione si corre il rischio di
creare test suite che considerano solo gli aspetti noti.
Tra l'altro sarebbe buona educazione scrivere la suite
di test prima (o durante, nel caso si abbiano due team)
dell'implementazione della funzione da testare.
bye,
-- 
piergiorgio

 controllo del tipo non sia O(1).
Ma cosa diavolo stai dicendo ? Buttala via la vodka, perche' sei
evidentemente ubriaco.
Come dice Dialtone (un'altro emotivo) non hai la piu' pallida idea di cosa
siano i test. I test vengono eseguiti *a parte* sul codice in produzione,
non sono parte del codice in produzione, sono semplicemente classi che lo
fanno "girare".
Quello che tu dici e' il modo corretto di programmare in C, cioe' con
continui check sull'input per non fare casino. E pensa a quanto e' lento C.
Mi spieghi che cavolo di vantaggio avrei a far girare una tonnellata di
test in produzione, o comunque all'interno dell'applicazione rilasciata ?
Se l'utente inserisce un output del cavolo il test solleva un'eccezione e
mi manda un log ? Ma per favore, crashare per crashare non me ne faccio
nulla. Se sai programmare decentemente sarai tu a considerare gli input
possibilmente dannosi, e a gestirli a modo, e questo non c'entra una cippa
con il discorso, e' normalissimo, palese, lapalissiano "buon design". Se
il tuo software e' disegnato con i piedi puoi avere tutti i test che vuoi
e tutti i check a compilation time che vuoi, che crashera', e miseramente.
Faccio senza dire che non scrivere dei test nel caso in cui l'input sia
errato e' un suicidio: la bella assertRaises all'interno di unittest e' li
apposta, e le possibilita' di non gestire un determinato input soprattutto
in fase di refactoring sono altissime (almeno, io lo faccio sempre, con
la mia mania di togliere roba).
E' naturale che anche usando i test non c'e' alcuna garanzia che il
programma sia effettivamente corretto (pensavo fosse sottinteso), quello
che si sta' dicendo e' che i test (fatti *bene*, e anche questo pensavo
fosse sottinteso) lo rendono inutile, fino a prova contraria.
La *critica* che ti ha fatto urlare all'untore poco fa che questo grande
sabotatore di Microsoft ha fatto e' principalmente questa: perche'
riscaldare la stessa fottuta minestra con C# piuttosto che tentare
qualcosa di testato e sicuro per rendere le legioni di programmatori C#
piu' produttivi, insegnandogli *buone pratiche* (prima fra tutte quella
del buonsenso) piuttosto che mettergli 400 paracaduti sotto il culo ?
Semplice, perche' il *task* di C# e' il programmatore Java, non sono
discorsi *tecnici*, semplicemente si vogliono portare programmatori da una
piattaforma all'altra, esattamente come Java voleva portare programmatori
C o C++ da una piattaforma all'altra: ci sono riusciti loro, non ci
riusciamo noi ? Una considerazione semplicissima e discutibilissima.
Sai quanto mi sta sul cazzo .net, dal momento in cui posso scrivere codice
Python, compilarlo per la loro piattaforma, e farlo girare a 200 all'ora
su Windows con tutte le facilitazioni che il mio linguaggio di scelta
*gia'* mi da ? Con un compilatore che *gia'* funziona, e sulla mia
piattaforma di scelta ? Lo immagini.
HAND,
  nicholas
P.S. In alternativa, puoi riportare la discussione sui toni amichevoli,
anche se accesi, di prima. Potrei addirittura scrivere il prossimo post in
italiano (sorry, molto stanco).

 tipati non hanno senso d'esistere, non io.
Quindi sto dicendo che Python e Ruby non hanno senso di esistere ? Merda,
ho appena perso il lavoro.
Non hai capito un cazzo, suvvia.
  nicholas:wq

 creare test suite che considerano solo gli aspetti noti.
Non direi proprio. Se uno effettua dei test che non considerano 
adeguatamente i "percorsi" del programma, vuol dire al contrario che 
dell'implementazione se n'è sbattuto alla grande.   

 Oltretutto l'articolo è molto interessante anche per altri aspetti.
Quest'altro è ancora più in tema:
http://www.eptacom.net/pubblicazioni/pub_it/oopgen.html


 poi.
Alemagna, in tutta franchezza, non hai il potere di farmi bruciare
qualcosa, te l'assicuro :)
Se e' quello il tuo scopo fai meglio a puntare su altri cavalli.
Piuttosto patetico il silenzio di diversi mesi per intervenire come un
frago per una inesattezza: quanto hai aspettato ?
-- 
                                                __Nicholas Wieland
Beautiful is better than ugly.
                                                __The Zen of Python

 dell'implementazione se n'è sbattuto alla grande.   
Il problema e` che conoscendo l'implementazione si
rischia di fare un test troppo specifico o troppo
superficiale.
Se uno conosce come un certo problema e` stato
risolto, rischia di fossilizzarsi nel testing.
Per questo si parte sempre dalle specifiche, perche`
quelle sono usate anche da chi dovra` prendere il
componente ed inserirlo nel prodotto finito.
bye,
-- 
   Piergiorgio Sartor

 frago per una inesattezza: quanto hai aspettato ?
Io non ho aspettato un bel niente, ma se ritieni patetico avere altre 
cose da fare nella vita oltre che stare a leggere/scrivere su ICOD, 
allora mi sa che ci son problemi più seri di questa discussione di cui 
dovresti preoccuparti.


 Non hai capito un cazzo, suvvia.
Oppure, più semplicemente, qui c'è qualcuno che non è in grado di 
comunicare, come si evince anche dall'altro tuo messaggio dove non 
capisci di che cavolo sta parlando il tizio della MS.


 il SW "in parallelo".
A me non pare proprio. Non ho letto tutto sull'argomento ma la
letteratura che ho letto dice l'esatto contrario, si parla di design
evolutivo e non di specifiche, si dice che l'implementatore *e'* il
tester e viceversa, si parla di pair programming. Uno dei motivi per cui
ad esempio Beck ritiene che il TDD sia fondamentale soprattutto perche'
le specifiche cambiano ...
HAND,
-- 
                                                __Nicholas Wieland
Special cases aren't special enough to break the rules.
Although practicality beats purity.
                                                __The Zen of Python

 A me non pare proprio. Non ho letto tutto sull'argomento ma la
C'e` persino chi dice che si debba scrivere la test
suite prima del codice da testare.
bye,
-- 
   Piergiorgio Sartor

 capisci di che cavolo sta parlando il tizio della MS.
Naturale, dato che hai sparato cazzate su qualsiasi cosa vagamente
tecnica all'interno del topic, e sei stato abbondantemente bastonato un
po' da tutti, ti continui a riattaccare alla stessa piccolezza,
insignificante ai fini del discorso.
Interessante involuzione.
-- 
                                                __Nicholas Wieland
Errors should never pass silently.
Unless explicitly silenced.
                                                __The Zen of Python

 dovresti preoccuparti.
Mi fa piacere che il tuo tempo libero lo dedichi a me, solo a me, sempre
a me. FIGJAM ogni tanto variava, pero' (anche se a onor del vero tu non
mi hai ancora minacciato di rompermi il culo con salcazzo quale arte
marziale :p)
-- 
                                                __Nicholas Wieland
Readability counts.
                                                __The Zen of Python

 Io e Oluyede.
Alt alt, Nicholas io mi tiro fuori :)
Ho riletto meglio l'articolo e non mi sembra _cosi_
ambiguo e anche se lo fosse non mi sembrava il caso
di sollevare tutto questo polverone per una rogna semantica :)
ciao!
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com

 suite prima del codice da testare.
E' quello che ho appena detto :)
-- 
                                                __Nicholas Wieland
Namespaces are one honking great idea -- let's do more of those!
                                                __The Zen of Python

 di sollevare tutto questo polverone per una rogna semantica :)
Ma quale polverone ? Tu l'hai letto e hai frainteso esattamente come me,
ti tirerai anche fuori, cio' non toglie che hai frainteso.
Il polverone l'ha tirato su casomai Alemagna, perche' gia' Seguso aveva
rimarcato il senso della frase, e io non avevo risposto (Hint! Strahint!
Megahint!), e piu' di una settimana prima. (<- punto)
-- 
                                                __Nicholas Wieland
In the face of ambiguity, refuse the temptation to guess.
                                                __The Zen of Python

 E' quello che ho appena detto :)
Non mi pare, dato che se si ha la possibilita`, si
procede in parallelo, in modo da ridurre i tempi.
Tu hai detto che non e` cosi`.
Tra l'altro, se devi scrivere il test prima della
funzione vera e propria, vuol dire che devi partire
dalle specifiche, altrimenti come lo fai il test suite?
bye,
-- 
   Piergiorgio Sartor

 : 

Mi sono spiegato male allora.
Partiamo dal presupposto che io adotto (o tento di) l'approccio XP, che
_include_ il TDD, e che quindi anche le mie idee di TDD derivano dal
sopracitato approccio, e non da un semplice "scrivere i test".
Puoi trovare tutte le informazioni che cerchi su
http://www.extremeprogramming.org/
 .
Personalmente trovo che procedere in parallelo sia controproduttivo,
scrivere il test non e' semplicemente testare la funzionalita', ma ad
esempio e' incredibilmente utile per riflettere sull'interfaccia e per
avere immediatamente un feedback reale su un caso di utilizzo.
Io implemento la funzionalita' innanzitutto scrivendo un test e
facendolo fallire, la classe puo' essere benissimo una classe vuota, per
poi implementare la funzionalita' e far passare il test.
Riguardo alle specifiche cito:
<cite>
Creating a unit test helps a developer to really consider what needs to
be done. Requirements are nailed down firmly by tests. There can be no
misunderstanding a specification written in the form of executable code.
</cite>
Si puo' essere d'accordo (accento, non accento ? boh) o meno, l'unica
cosa che posso dire e' che finora con me ha funzionato, su un progetto
(per me) grosso e scritto con un linguaggio pessimo, altro non so.
HAND,


 (per me) grosso e scritto con un linguaggio pessimo, altro non so.
Hai usato davvero XP? Voglio dire in due sullo stesso PC?
bye,
-- 
   Piergiorgio Sartor

 Hai usato davvero XP? Voglio dire in due sullo stesso PC?
Si, raramente non si e' lavorato in coppie (per il succitato progetto, 
e per quello attuale, insomma gli ultimi due).
L'unica cosa e' il feedback dal cliente. Non dico sia impossibile, ma
sicuramente lo era nel mio caso, e non ho decisamente potuto rompergli
le balle ogni due giorni.
Lavorare in coppia e' incredibilmente utile: al di la' del continuo
feedback, e' molto meno faticoso lavorare (ovviamente mentalmente) e
piu' la sessione e' lunga e piu' si nota la differenza. Inoltre e' piu'
divertente, il che non fa decisamente mai male.
-- 
                                                __Nicholas Wieland
Flat is better than nested.
                                                __The Zen of Python

 riguarda la correttezza del codice.
Concordo.

 superficiale.
Non è vero. Rischia di fare un test superficiale chi fa i test in modo 
superficiale.
Semmai un modo superficiale è fondare i test sulla rispondenza alle 
specifiche. A meno che il programmatore non abbia capito una sega il 
programma più bacato del mondo difficilmente non risponderà alle 
specifiche.  

 comunque, anche con un linguaggio tipizzato staticamente fortemente).
Il problema non è così banale. Paradossalmente i test sul software hanno 
successo quando trovano il difetto, altrimenti hanno fallito. Purtroppo il 
software non è come un prodotto manufatturiero, dove cerco il difetto, non 
lo trovo ergo non c'è. Nel software il principio è che il difetto c'è e se 
non lo trovo vuol dire solo che non lo trovo (questo è un po' il paradigma 
che si trova in tutta la letteratura).
Nel caso che hai descritto, una volta che i miei test hanno raggiunto una 
copertura prestabilita senza trovare difetti, la domanda che mi devo porre 
è la seguente: ho adottato la strategia giusta per quell'implementazione? 
Può darsi che stia sbagliando metodo e che stia girando a vuoto. Se la 
risposta è si, allora valuto se è il caso di aumentare la copertura o 
dichiarare terminato il test (sulla base anche di un budget economico). 
Altrimenti cambio strategia e ricomincio daccapo.

 divertente, il che non fa decisamente mai male.
Infatti, quando a suo tempo abbiamo provato, si e`
visto che e` davvero produttivo, piu` di 2x.
Il problema, pero`, e` risultato essere che il management,
quando vede due persono con un PC, o pensa che vi sia una
persona di troppo, oppure che i due stanno giocando...
Poi, ovviamente, non tutte le coppie funzionano, ma in
generale direi che l'approccio e` valido.
bye,
-- 
   Piergiorgio Sartor

 specifiche.  
Scusa, ma guarda che i bug sono _solo_ la non
corrispondenza alle specifiche, mi altro.
Per questo nelle specifiche ci va messa anche
la robustezza.
bye,
-- 
   Piergiorgio Sartor

 generale direi che l'approccio e` valido.
XP deve *cominciare* dal management, e' impossibile farlo, altrimenti.
Il management deve programmare ad esempio le "riunioni" con il cliente.
Se il management non sa/non vuole sapere c'e' ben poco da fare, solo
adattarsi e fare il possibile.
Su questo ad esempio Kent Beck e' piuttosto chiaro: XP e' un processo.
HAND,
-- 
                                                __Nicholas Wieland
Explicit is better than implicit.
                                                __The Zen of Python

 chiedere sono loro a darmi continui feedback.
Non ci metterei la mano sul fuoco che sia tipicamente
italiano, mi sono trovato con diversa gente in giro
per il mondo che non vuole/riesce provvedere feedback
od indicazioni...
bye,
-- 
   Piergiorgio Sartor

 sui tipi.
Sara` ma se un algoritmo si comporta nel modo corretto con tutti i
miei input allora anche il modo di lavorare con i tipi e` corretto.
-- 
Valentino Volonghi, Regia SpA, Milan
Linux User #310274, Gentoo Proud User

 miei input allora anche il modo di lavorare con i tipi e` corretto.
Qua c'e` poco da dire invece :), va bene cosi`.


 la robustezza.
E perchè no, "Esente da bug". Anzi sbilanciamoci: "Perfetto"
:)
Queste sono caratteristiche che non fanno parte delle specifiche.

 Queste sono caratteristiche che non fanno parte delle specifiche.
Invece ti sbagli, precisamente nei "requirement", ci
metti anche "reliability", "recovery time", etc.
Ci puoi persino mettere che la funzione deve "resistere"
al massimo a 10000 chiamate, e cosi` hai anche posto
un limite al test.
Puoi metterci tutto quello che ti pare, sta all'abilita`
del compilatore delle specifiche scriverle in modo che
sia chiaro e ragionevole cosa si chiede.
bye,
-- 
piergiorgio

 sia chiaro e ragionevole cosa si chiede.
Indubbiamente. Poi starebbe anche al test verificarlo. 

 perchè fare il debug è una gran rottura di palle.
Il debug e` inutilmente lungo perche` con quello non sei stimolato ad
avere un design curato del codice e non hai sotto controllo le
funzionalita` globali del codice. Andava bene 10 anni fa magari, ma i
test fanno le stesse cose, solo piu` velocemente.


 quindi non e` funzionante.
Dalla tua invece? Sentiamo.
Abbiamo una scatola nera che dice di poter fare y/x correttamente per ogni
y,x.
Determinare il numero di test necessari per stabilire che dice il vero senza
incertezze.
Saluti.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004

 Indubbiamente. Poi starebbe anche al test verificarlo. 
Infatti, quello e` il secondo scopo, dato che le
specifiche finisco in mano anche dell'integratore
(che potrebbe essere ancora qualcun altro, magari
anche al di fuori della ditta), il test black box
consente di capire se queste benedette specifiche
sono chiare oppure no.
Se, sempre con "div()", vi e` un incomprensione su
cosa deve succedere per a=b=0, allora e` probabile
che le specifiche vadano chiarite, cioe`, detto in
altri termini, che il bug sia nelle specifiche.
bye,
-- 
   Piergiorgio Sartor

 test fanno le stesse cose, solo piu` velocemente.
Ti sbagli, debug e test sono due cose ben diverse. Il debug parte da un 
malfunzionamento accertato e ne va alla ricerca (e rimozione) della 
causa, il test parte da un programma che non ha malfunzionamenti evidenti 
e va alla ricerca di condizioni che possono causarli (e una volta 
evidenziati passa al debug).

 di sviluppare, non di testare. 
Allora non mi sei chiaro quando dici <cite>l'implementatore di una,
singola, funzione, deve fornire tale funzione in modo che non abbia 
problemi, non deve semplicemente scrivere un po' di codice e darlo al 
tester, deve poter fornire un certo livello di garanzia</cite>
Definire il "certo livello di garanzia" e come il programmatore dovrebbe 
fornirlo.
Quello che fa acqua nel tuo discorso è che il tester non può provare certi 
aspetti del programma, questi aspetti li deve garantire la programmazione 
però la programmazione ha il compito di sviluppare e non di testare. Il 
cerchio non è chiuso.

 cerchio non è chiuso.
Le specifiche, ci sono le specifiche.
Scusa, ma tu quando ti viene chiesto di scrivere
una funzione, scrivi quello che ti pare, o qualcuno
ti dice _cosa_ deve fare la funzione?
Quello e`, la funzione deve fare quello, come lo
fa non importa, per questo c'e` l'implementatore.
Il tester verifica che la funzione faccia cio` che
deve fare, fine.
Cosa ci sarebbe di piu` oltre le specifiche, ancora
non me lo hai detto.
bye,
-- 
piergiorgio

 evidenziati passa al debug).
Il test ti fa costruire un programma, non puoi usare i test per
trovare i bachi come se li scrivessi dopo che arriva il programma. Il
test ti dice che la funzione in un determinato e specifico caso la
funzione non fa quello che deve. Nella stragrande maggioranza dei casi
il debug non serve dopo il test perche` un test fatto bene ti permette
di individuare subito l'errore che hai commesso.
Comunque non sono la stessa cosa e` vero.


 deciso a priori?
Forse, per capirvi, dovreste abbandonare il termine vago "bug" (che non
è in letteratura) ed usare i termini "failure", "error" e "fault". 
error = il programma non si comporta come da specifica formale
failure = il programma non si comporta come l'utente si aspetta.
fault = il programma è entrato in uno stato non previsto dal
programmatore, privo di senso. ad esempio, una classe con due variabili
che valgono simultaneamente sesso = M, età del primo parto = 35 è in
fault :-) 
notare che ci possono essere error senza failure, e failure senza error.
-- 
Best Regards,
Maurizio Colucci
Please remove the uppercase letters "S,P,A,M":
seSgPuAsM...@tin.it

 Parti da qua e leggiti tutto il capitolo...
Guarda che su questi aspetti non ci piove sopra, siamo d'accordo. Il punto 
è un'altro, esistono diversi tipi di difetti e diverse tecniche in grado di 
scovarli. I test statici input -> verifica output hanno un certo tipo di 
valenza e sono indispensabili, ma coprono una parte dei requisiti. Ad 
esempio, esistono metodi dinamici che prevedono modifiche controllate al 
codice verificando che i risultati siano quelli previsti, o se il programma 
si "accorge" della mutazione di stato. Ciò consente di andare "oltre" il 
limite dei dati di input e testare il programma anche dove non verrà 
utilizzato andando a scovare altri difetti (alcuni certamente "latenti" 
alla normale esecuzione, altri non del tutto. E comunque in un concetto di 
qualità un difetto che non evidenzia malfunzionamenti in uso "normale" 
resta comunque un difetto).
Oltremodo, le tecniche di code inspecting (Fagan, mi sembra di ricordare) 
"garantirebbero" notevoli risultati in termini di qualità del software e 
eliminazione difetti di implementazione; il condizionale è d'obbligo perchè 
sono difficilmente applicabili, richiedono team numerosi e molto affiatati. 
In genere si tratta di affidare verifiche incrociate ai programmatori, i 
quali vengono edotti a grandi linee su quello che il frammento di codice 
deve fare, ma il loro compito è quello di individuare possibili errori, 
vulnerabilità, fragilità, e così via. I risultati documentati sono davvero 
egregi, ma l'applicabilità è difficile.
Torno a dire, niente sostituisce niente ci mancherebbe altro. La mia 
contestazione è nata a seguito di affermazioni in cui si sosteneva che i 
test che prevedono la (re)visione del codice e dell'implementazione hanno 
un esito viziato (ergo sono inutili). Il che non è assolutamente vero. 
Banalmente, qualsiasi programmatore manda in esecuzione N volte il codice 
prima di rilasciarlo, se viene istruito dei metodi di verifica e controllo 
(che esistono) è molto più probabile che questi test sommari diventino 
significativi e quindi il codice rilasciato sia molto più affidabile.

 significativi e quindi il codice rilasciato sia molto più affidabile.
Ho capito quello che dici. Mettiamola cosi` allora, dal mio punto di
vista (non sono cosi` esperto comunque), il test va fatto _prima_ per
aiutarti a pensare alla soluzione del problema in modo
organizzato. Poi inizi a scrivere codice, se mentre lo scrivi ti
accorgi che si creano i presupposti per un ulteriore tipo di test
allora _prima_ di scrivere la funzionalita` devo scrivere il test e
poi scrivo la funzionalita`. 
test e software si evolvono insieme (tant'e` che fanno parte dello
stesso programma e si distribuiscono rigorosamente insieme) e quando
mi accorgo di qualcosa di nuovo che mi serve e va testato allora
scrivo il nuovo test.
Con questo approcio sono ragionevolmente sicuro che: 
a) il software finale sara` di ottima qualita` (l'approcio stesso del
pensare prima di fare rende il codice migliore)
b) lo rende piu` robusto e piu` esente da malfunzionamenti/errors e
failures
c) in ogni momento e` verificabile la funzionalita` dei singoli
blocchi senza fare strani test...
Te lo dico perche` ho finito poco tempo fa un progetto in cui per fare
i test c'erano i 'capi' che si mettevano a usare il software finche`
non andava in crash e poi riportavano la linea di traceback di
python... Purtroppo non l'ho iniziato io quel progetto ma a furia di
fare cosi` abbiamo sicuramente perso parecchio tempo. Ci saremmo
risparmiati un sacco di fatica se avessimo fatto fare tutto a dei test
(e anche il design ne avrebbe giovato) ora pero` e` finito ed e` tardi
per inserire queste modifiche :P.


 fare cosi` abbiamo sicuramente perso parecchio tempo. 
Io purtroppo sto "lottando" per togliere una pessima abitudine 
organizzativa nel progetto in cui lavoro, che è quella di far fare i test 
agli installatori del programma. Quest'ultimi, pur essendo parte 
integrante del team di progetto, sono completamente astratti dalla 
programmazione (non conoscono niente degli strumenti) mentre sono molto 
preparati sulle specifiche funzionali. Il risultato purtroppo è 
disastroso sotto questo punto di vista; i test non sono adeguati; i 
feedback verso la programmazione sono lentissimi (parlano due lingue 
diverse); siccome queste persone sono anche coloro che vanno sul cliente, 
spesso danno priorità all'impegno con il cliente saltando a piè pari il 
test (e riverberando i problemi sulla programmazione, perchè poi il debug 
è un problema tipico di programmazione). Oltre ai problemi tecnici si 
creano degli attriti poco sopportabili in un luogo di lavoro.
Purtroppo per varie vicissitudini non è facile convincere la direzione 
che questa struttura va rivista. Fra queste persone ci sono dei 
"riciclati" del vecchio progetto in cui erano dei guru factotum, 
gestivano i clienti sviluppando direttamente sul posto, etc... Sul nuovo 
progetto lo scenario è cambiato, nuove tecnologie e la programmazione è 
*rigorosamente* centralizzata in sede. Non conoscendo le tecnologie e non 
avendo capacità di comunicare decentemente le specifiche, la verità è che 
queste persone dovrebbero "evolversi" o essere relegati a compiti di 
second'ordine... verità amare da ingoiare. E' una lotta dura...

 preparati sulle specifiche funzionali. Il risultato purtroppo è 
Non hai idea... Io col managament ci ho litigato pesantemente per
questo... Anche perche` i 'capi' di cui parlo io sono proprio
loro. Totale e completa ignoranza informatica.


 non me lo hai detto.
La specifica dice cosa e non dice come. Dopo aver scritto "come lo fa non 
importa" non credo che tu lo possa confutare facilmente :)

 importa" non credo che tu lo possa confutare facilmente :)
E cosa ci sarebbe da "testare" nel "come"?
Il "come" e` sviluppo, non test.
Che poi, ripeto ancora, tu per sviluppare abbia
bisogno o ti piaccia o sia costretto ad usare
altro codice di supporto (test suite, se vuoi)
questo _non_ significa che tu faccia "testing".
Perche` il problema e` sempre lo stesso, devi
riuscire a garantire che il pezzo di codice sia
"compatibile" con quello che viene richiesto e
questo lo puoi fare solo in un ambiente esterno,
per tutta una serie di ragioni che ho ripetuto
allo sfinimento.
Il semplice fatto che l'implementatore possa
fraintendere le specifiche e` un problema.
Lui magari fa tutto perfetto, ma fa un'altra cosa.
Cosa succede se le specifiche sono scritte in
inglese, magari da un inglese, e chi le riceve
non riesce a cogliere esattamente certi dettagli,
che per l'altro sono chiarissimi?
Ovviamente sarebbe da evitare una situazione del
genere, ma e` solo un esempietto per far vedere
come l'implementatore non possa garantire la
funzionalita` a tutti i livelli.
Deve garantire quella al suo livello, cioe`, come
tu stesso dici, deve garantire che quella specifica
implementazione sia corretta.
Questo non vuole affatto dire che sia in grado di
garantire che la funzionalita` *richiesta* sia corretta.
Che forse, mi sorge il dubbio, si stia parlando
di cose diverse?
bye,
-- 
piergiorgio

 E cosa ci sarebbe da "testare" nel "come"?
Mah, secondo te? :)
Banalmente, nel "come" ci sta il fatto bene, fatto male, bello, brutto, 
manutenibile, immanutenibile, documentato, non documentato... divertiti 
quanto vuoi.
La cosa buffa è che se non hai una forma di garanzia sul "come" è stato 
sviluppato un programma, i tuoi test funzionali "black-box" non valgono 
una cicca. Se fai 100 cicli di test su una funzione come fai a dire che 
100 sono sufficienti e non ne servono 200? Per tornare all'esempio 
automobilistico, il collaudatore deve guidare *ogni* macchina per tre 
anni e fare 100.000 km prima di dire che *ogni* macchina è affidabile? 
No, ovviamente. Però se non ci fosse un adeguato controllo sul "come" 
avviene il processo produttivo, non c'è motivo di desumere che un certo 
numero di collaudi è rappresentativo dell'intera produzione.

 numero di collaudi è rappresentativo dell'intera produzione.
Ma il processo produttivo include l'implementazione
ed il collaudo, non solo l'implementazione.
Non e` che provano tutti i singoli pezzi e poi sperano
che l'insieme funzioni.
Livello per livello provano le varie parti, ma da un
certo punto in poi, vi e` solo test, non implementazione
Prima si progettano, costruiscono e provano le bielle,
poi si assembla il motore, con tutto il resto, poi si
fa la prova al banco, che gia` inizia ad essere black
box, poi, quando si arriva all'auto, il test diventa
completamente black box. E questo ultimo test e` quello
determinante, nel senso che se tutti i test precendenti
sono passati, questo ultimo comunque non deve fallire.
Tu dirai: ma i primi possono fallire?
Fallire no, ma possono comunque portare a considerazioni
sul livello di affidabilita` richiesto e sul costo.
Infine, il test porta anche alla riconsiderazione delle
specifiche, cosa che l'implementatore puo` controllare
in misura minore.
bye,
-- 
piergiorgio

 Oppure a +50, oppure vanno in F1.
Già. Ma come fanno a dire che quel test vale anche per l'affidabilità 
della *tua* macchina che non è quella sottoposta a prova?

 della *tua* macchina che non è quella sottoposta a prova?
cp auto_test auto
bye,
-- 
   Piergiorgio Sartor

 
non l'ho capita

 non l'ho capita
E` difficile capire le battute di deelan se non lo si conosce ;-)
-- 
Lawrence