Newsgroup: it.comp.lang.c++
Titolo: [semi-OT] linguaggi OO

Quale pensate sia il miglior linguaggio per produrre codice OO dal
punto di vista della chiarezza della sintassi e dello stile di
programmazione che permette di adottare?
scusate la domanda magari vaga, è semplice curiosità e mi piacerebbe
ricevere e dare qualche spunto di conversazione. Ad esempio, per non
andare OT, si potrebbe discutere di quali features mancano al C++ (se
si pensa che ne manchino) e che potrebbero essere inserite nel nuovo
standard.

programmazione che permette di adottare?
A questa domanda io ti risponderei il Java, ma la mia risposta č
dettata da un gusto personale verso quel linguaggio e non č un
giudizio imparziale :-P
--
Rhymes - 
rhy...@myself.com
http://www.foxhound-games.it
"Sapete cosa fa un InputStream quando
gli si racconta una barzelletta? Reader..."

programmazione che permette di adottare?
Non sono un grande espeto di linguaggi ma a me piace molto Python
perché permette di fare in modo naturale cose molto comode, in
particolare le nuove versioni permetteranno di derivare classi dai
tipi built-in, questa caratteristica può essere molto comoda in molte
occasioni. Il problema maggiore nell'aggiunta di queste
caratteristiche è data dal fatto che per il C++ è molto importante la
velocità.
-- 
Marco Barisione (ICQ 84277092)

 standard.
i thread! secondo me e' una mancanza, visto che in quasi tutti (almeno 
tutti quelli che conosco) i target per cui esiste un compilatore c++ 
esistono dei thread.
mi piacerebbe molto il meccanismo di eiffel in cui un oggetto thread 
viene creato e vive in un processo tutto suo

 gli si racconta una barzelletta? Reader..."
sob...

 viene creato e vive in un processo tutto suo
forse pero' cosi' si appesantisce troppo il programma,
e visto che un'arma del C++ e' proprio la velocita' fose sarebbe deleterio.
--
Ciao by Allanon

 velocità.
Ah be`, se cominciamo a parlare di velocita`, ahime`, nessuno dei
linguaggi che ho sinora elencato merita la palma.  Bisogna allora
parlare invece di C++, o di O'Caml, linguaggio (come O'Haskell)
assieme funzionale e ad oggetti, ma pieno di trucchi vari che gli
permettono prestazioni paragonabili a quelle ottenibili con il C++
(pare che eleganza e prestazioni massime assolute siano un
po' difficili da raggiungere allo stesso tempo:-).
Fortunatamente nella maggior parte dei casi il grosso del codice di
un programma non pesa poi tanto sulla sua velocita` di esecuzione,
controllata invece da "colli di bottiglia" che tipicamente vanno dal
5% al 20%, massimo 25% dei sorgenti.  Codificando i "colli di
bottiglia" nei linguaggi piu` performanti, si puo` quindi mantenere
il resto nel proprio linguaggio preferito, purche` quest'ultimo sia in
grado di comunicare efficientemente con i linguaggi "veloci" (e al
giorno d'oggi, qual piu` qual meno, questa funzionalita` i vari
linguaggi di altissimo livello, da Python ad Haskell, ce l'hanno).
Alex

 deleterio.
non mi sembra che, almeno in linux, i thread aggiungano tutta questa 
pesantezza, e poi mi riferivo solo all'oggetto thread, non a un 
qualunque oggetto

 programmazione che permette di adottare?
Altri ti hanno gia' espresso svariate opinioni, alle quali non ho molto
da aggiungere (semmai da togliere :-). Vorrei pero' sottoporti un paio
di osservazioni: in primo luogo OO e' un paradigma e non un marchio di
qualita'; un linguaggio non e' migliore di un altro perche' e' piu' OO,
ne tantomeno un'applicazione e' ben fatta perche' e' orientata ad
oggetti. Esistono diversi paradigmi di programmazione ciascuno dei quali
e' piu' adatto a risolvere determinati problemi e meno a risolverne
altri.
Un altro preconcetto che vorrei sfatare e' legato alla comune
affermazione che un linguaggio possa essere "piu' OO" di un altro
perche' *manca* dei costrutti necessari per applicare altri paradigmi.
Detto questo leggi pure le opinioni degli altri :-)
Ciao,
Nicola

 prevalentemente, compile-time).  
ne sento spesso parlare ma non ho mai ben capito cosa sia in realta'. Cosa 
e' la tipizzazione dinamica?
Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 qualunque oggetto
si, anch'io mi riferivo solo ai thread ed al fatto che possano essere
implementati in processi diversi.
e' questo e non i thread in generale che IMHO appesantiscono.
poi in linux non so come siano implementati (sono processi pesanti tipo
fork?)
--
Ciao by Allanon

 si dice che dei manager abbiamo imparato smalltalk in pochi giorni
"Ho letto 'Guerra e Pace' dopo aver seguito un corso di lettura
 veloce. Parlava della Russia" (Woody Allen)
scusate, non ho resistito ...
Saluti
Andrea Vinzoni

 programmazione che permette di adottare?
Come semplicità della sintassi dubito che esista nulla di piu' semplice di
Smalltalk.
In termini di stile di programmazione molto dipende da cosa intendi come stile.
Per esempio laddove e' molto importante la correttezza del codice viene ancora
preferito ADA.
Comunque Python, Java e altri sono generalmente considerati ottimi tools. E lo
stesso vale per molti linguaggi di origine funzionale.
Concordo in linea di massima sulla completa e approfondita risposta di Alex.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 wrote in message
news:3a9fb639.01091...@posting.google.com...

Per imparare la sintassi di Smalltalk e per saper usare il linguaggio in se e
per se bastano poche ore. Per studiarsi la libreria e capire quando conviene
fare cosa e per capire il paradigma OO, ovviamente ci vuole molto piu' tempo.


 e' la tipizzazione dinamica?
Quella per cui una variabile puo` fare riferimento a oggetti
di diversi tipi, purche` implementino la stessa "firma" (si
usa sempre il termine inglese "signature"), cioe` l'insieme
di metodi e operatori effettivamente usati su quella data
variabile.  In C++, la trovi solo nei template, e quindi e`
risolta a tempo di compilazione.  In altri linguaggi, lo
stesso concetto si puo` applicare anche durante l'esecuzione
del programma, con maggiore flessibilita` ma normalmente
non con le stesse eccezionali prestazioni potenziali del C++.
L'idioma di "casting dinamico da altra classe" (dynamic_cast
in C++, tipico uso in Java di downcast da Object, ecc), e`
parente alla lontana della tipizzazione dinamica, ma le
differenze sono molte e importanti.  La tipizzazione DEBOLE,
per cui oggetti di un tipo sono trasparentemente nonche`
implicitamente trasformati in oggetti di altro tipo, e`
altra cosa ancora -- e` quella che puo` mordere in C++,
quando un float o double e` accettato al posto di un int,
con perdita d'informazione (varie _implementazioni_ ti
possono dare un warning in questi casi, ma, ahime`, il
_linguaggio_ non lo richiede), e morde piu` spesso in VB
e piu` spesso ancora in Perl.
La "programmazione generica", e quindi la tipizzazione
dinamica, presenta elementi di estremo interesse.  La
tipizzazione debole al contrario puo` far comodo in un
programmuzzo usa e getta di tre righe, ma e` solo una
iattura nei programmi "seri" (da quattro righe in su:-).
Intermedia puo` essere la valutazione per idiomi parenti
di questi, come il cast dinamico da altra classe, ovvero
il possente approccio "typeclass" di Haskell (grandioso
quando si applica, ahime` leggermente limitato come
campo di applicazione).
Alex (MVP di Brainbench per il C++)

 perche' *manca* dei costrutti necessari per applicare altri paradigmi.
concorderai con me però se dico che il paradigma OO è più facile da
applicare scrivendo il codice in C++ piuttosto che in assembly! Il
senso della mia domanda era proprio questo: capire in base alle
opinioni e alle esperienze degli altri (quindi un parere soggettivo)
quale ldp permettesse di scrivere codice OO nella maniera più pulita.
Ora tu mi dirai: cosa intendi per pulita? Rispondo: fate vobis,
rimango nel vago appositamente ;-).
--SF

 Io sono esperto di linguaggi, di OO e di programmazione in generale,
Conosci Eiffel? ne ho sentito parlare molto bene, ho dato una veloce
occhiata alla sintassi e mi sembra molto carina: l'idea ad esempio di
poter definire a livello di codice gli invarianti di una classe (si
può fare anche in C++, ma deve essere gestito manualmente) mi sembra
veramente un notevole passi avanti nella programmazione OO.
[Ho letto tutto il resto - molto interessante!]

 rimango nel vago appositamente ;-).
se un linguaggio lo si conosce, allora si puo' parlare di "pulizia del 
codice" con cognizione di causa.
Parlando a priori, quindi senza una conoscenza del linguaggio, direi 
che "pulizia" equivalga ad una linearita' del codice, e questo e', 
oltre che fortemente influenzato dalla cultura di un popolo, anche 
dalla propria visione delle cose.
voglio dire, un arabo che scrive da destra a sinistra trovera' strano 
lo scrivere screen.clear(), mentre un giapponese che scrive in 
verticale trovera' lo scrivere in linea, etc...
Non credo quindi che una domanda generale come la tua abbia senso.
anche fare un sondaggio non serve a nulla: se (poniamo) fosse python il 
piu' votato, ma x me e' + facile pensare in temrini di eiffel o 
smalltalk, o in assembly, perche' dovrei usare strumenti che trovo 
diversi dalla mia forma mentis ideale?
In sintesi: credo che ognuno debba usare gli strumenti che trova + 
adatti al proprio modo di pensare, per quanto riguarda la parte 
"generica" di un programma e, come gia' detto da altri, usare un 
linguaggio + performante ma comunque di proprio gradimento nei bottle 
necks. Non credo infatti che il vantaggio di scrivere una routine 
particolare, ovviamente gia' in forma ottima quanto a design, 
in fortran, c, c++, assembly o quel che sia, con i compilatori e le 
macchine di oggi, siano tanto differenti tra loro da giustificare l'uso 
dell'uno o dell'altro imperativamente.

veramente un notevole passi avanti nella programmazione OO.
Cosa sono esattamente?


diversi dalla mia forma mentis ideale?
Non sono completamente d'accordo con te, python è un linguaggio
coerente per questo è+ semplice di altri linguaggi, ad esempio io non
amo molto VB perché non lo trovo molto coerente.
Come ha detto Alex Martelli in un recente post su it.comp.programmare
ci sono stati dei veri e propri studi scientifici sulla facilità di
apprendimento dei linguaggi, cito il messaggio originale anche se un
po' lungo perché molto interessante:
:Piu` spesso che no, si valuta "a braccio", ovvero "a naso",
:basandosi sull'intuizione e sul ragionamento e non sui soliti
:metodo scientifici.  Ci sono un piccolo numero di eccezioni:
:lo Stichting Mathematisch Centrum di Amsterdam, ad esempio,
:condusse a suo tempo studi rigorosi sul linguaggio di
:programmazione ABC, che era stato sviluppato da ricercatori
:olandesi con lo specifico obiettivo di essere un linguaggio
:adatto ai principianti, esaminando vari aspetti del linguaggio
:stesso con metodi analoghi (ma non altrettanto rigorosi) a
:quelli usati in farmacologia nello studio degli effetti sulla
:salute di un certo complesso di medicine e cure.  Ad esempio,
:due versioni del linguaggio, differenti soltanto relativamente
:al particolare X, venivano insegnate a due diversi gruppi di
:studenti (demograficamente bilanciati, campioni statisticamente
:significativi, ecc), verificando poi se vi erano differenze
:statisticamente significative, quali, e quante, sull'efficacia
:degli studenti nei due gruppi nella scrittura di programmi per
:vari specifici problemi.
:
:Come puoi bene immaginare, questi studi sono costosissimi.
:Solo trovare e motivare molte centinaia di principianti a
:partecipare allo studio, senza dire degli anni-uomo degli
:istruttori necessari a condurlo, per CIASCUN dettaglio di
:un linguaggio: valutandone i costi a livello commerciale,
:si parlerebbe di molte decine di milioni di dollari per una
:analisi anche modesta e ben delimitata.  Poco da stupirsi,
:dunque, che pochissime analisi del genere siano reperibili
:in letteratura, e la progettazione di linguaggi (come per
:molti aspetti quella di altri sistemi software) resti piu`
:un'arte che non una scienza.
:
:Che io sappia, l'unico linguaggio esistente ad avere tratto
:un (sia pur parziale) beneficio da questo tipo di studi
:rigorosi e` Python.  Molti aspetti in cui differisce da
:altri linguaggi seguono esattamente le risultanze degli
:studi olandesi (cio` non stupisce, visto che l'architetto
:di Python e` di origine olandese e lavorava appunto allo
:SMC allo sviluppo del linguaggio ABC).  Alcuni degli attuali
:sviluppi del linguaggio sono motivati dal desiderio di
:tenere conto di altre ricerche piu` recenti, che (pur
:non essendo altrettanto complete e rigorose) sembrano
:convalidare (dal punto di vista della facilita` per i
:principianti) due scelte progettuali che hanno in comune
:Pascal e Basic, ma non altri linguaggi diffusissimi:
:    -- considerare minuscole e maiuscole come separate
:        aumenta la difficolta` di apprendimento del
:        linguaggio
:    -- la divisione fra numeri interi con il segno di /
:        NON dovrebbe effettuare troncamento (se tronca,
:        aumenta la difficolta` di apprendimento)
:
:In C, Java, Perl, e cosi` via, le variabili Peep e peep
:sono distinte e separate, e 1/2 vale 0.  Python a suo
:tempo adotto` le stesse convenzioni.  Non e` certo facile
:cambiarle oggi, su un linguaggio in uso da dieci anni e
:con molti milioni di righe di codice in produzione (su
:Python si basano ad esempio gli strumenti usati dal
:motore di ricerca Google!), ma sembra che Guido van
:Rossum sia deciso, almeno relativamente al problema della
:divisione fra interi: a un certo punto nel futuro 1/2
:varra` "un mezzo" (numero razionale), NON 0 (intero con
:troncamento).  Pare invece che sulla questione della
:distinzione fra minuscole e maiuscole Guido dovra`
:accettare la quasi unanimita` dei pareri degli utenti,
:praticamente tutti opposti alla rimozione di questa
:distinzione (io sono fra le poche eccezioni:-).
:
:Fra gli aspetti piu` fondamentali della progettazione
:di Python che discendono da studi rigorosi di usabilita`:
:
:-- moderazione nell'uso peculiare di segni di punteggiatura
:    e altri glifi strani: linguaggi come APL e Perl ne
:    usano a bizzeffe, mentre il Lisp e derivati sono
:    rigorosamente minimalisti (solo le parentesi, e in
:    certi casi il segno di . [punto], hanno valore
:    speciale); secondo gli studi, la massima facilita`
:    di apprendimento si ha ad un livello intermedio.
:
:-- uso dello spazio bianco ("indenting") come indicazione
:    di raggruppamento: pochi linguaggi ne hanno fatto uso
:    (OCCAM, linguaggio di Tony Hoare per la programmazione
:    concorrente, e Haskell, linguaggio funzionale puro,
:    sono le due principali eccezioni), ma gli studi mostrano
:    la validita` di questo concetto, e Python lo adotta.
:
:-- *regolarita`*, ovvero, mancanza di eccezioni, casi
:    particolari, "comode" scorciatoie, interpretazioni
:    dipendenti dal contesto, e cosi` via: per Python e`
:    praticamente una bandiera.


Distinguerei due aspetti: da una parte e' vero che nel concetto di
"pulizia" vi e' una forte componente soggettiva; io ad esempio
preferisco scrivere la parentesi graffa a capo, mentre altri la scrivono
di seguito; io separo gli elementi dei nomi compositi con le maiuscole,
mentre altri usano la sottolineatura, e via dicendo.
Esiste pero' anche una componente piu' strettamente legata al
linguaggio; le sue caratteristiche, la filosofia che vi sta dietro, la
pratica acquisita portano ad usi tipici che in qualche modo determinano
cosa e' pulito e cosa no in un linguaggio. Proprio poco fa mi e'
capitato di leggere un passo dello Stroustrup citato quasi letteralmente
da Alex Martelli in un vecchio post a proposito dell'idioma
while ( *p++ = *q++ )
  ;
E mi e' tornato in mente come Alex difendeva proprio l'adozione di
tecniche comuni, come piu' leggibili di approcci piu' da "principianti",
che in realta' possono risultare piu' confusi ed a rischio di errore.
Penso che qualsiasi principio "estetico" della programmazione non possa
prescindere dal principio di minima sopresa (principle of least
surprise), ovvero l'invito a scrivere il codice nel modo in cui e' piu'
probabile che gli altri programmatori se lo aspettino (cioe' evitando
trucchi e furbate).
Ciao,
Nicola

 po' lungo perché molto interessante:
[...]
non metto in dubbio che cio' sia vero, e che la semplicita' sia di 
enorme aiuto per l'apprendimento, ma lo stesso concetto di semplicita' 
e' dipendente dalla cultura... che il tabbing indichi un raggruppamento 
di concetti sembra logico ad un occidentale, ma un cinese che tende a 
leggere in verticale e raggruppa in orizzontale, deve prima entrare 
nell'ordine di idee di un occidentale, e poi puo' capire il 
raggruppamento di concetti espresso dal tabbing. 
Parlando in termini + generali: per chi guida a sinistra e' logico e 
semplice fare le rotatorie in senso orario, cosi' come l'opposto e' 
semplice per chi guida a destra...
Inoltre dire che un linguaggio e' il + semplice da apprendere dipende 
ugualmente dal contesto culturale di chi deve apprendere: quale sarebbe 
l'ideale per chi non sa l'inglese? e per chi non conosce la logica 
booleana? per non parlare di chi non usa caratteri romani...
Tutto questo, logicamente viene meno se ci riferiamo esclusivamente 
alla cultura occidentale.
ma non del tutto, IMHO, basta vedere, come esempio, come esprimono 
concetti complessi gli inglesi (frasi brevi e concise, poche relative e 
ubordinate, senza troppe congiunzioni) e gli italiani (un groviglio di 
principali, subordinate, relative, unite da una selva di congiunzioni, 
interpunzioni, virgolettature, etc)

[...]
Infatti ho detto che non sono *completamente* d'accordo, bisogna però
tenere presente che tutti i linguaggi che conosco hanno un modo di
pensare occidentale e che chi usa professionalmente il computer
conosce almeno un po' l'inglese. Comunque chi scrive sul ng italiano
del C++ non penso abbia un modo di pensare molto diverso da quello
occidentale.


 occidentale.
 
ah, be' era solo per far riferimento alla "societa' olandese", che 
facendo ricerche su un linguaggio per princiapianti, ha fatto un 
linguaggio per princiapianti occidentali, a quanto mi sembra di capire. 
Secondo me, trovare il modo di insegnare i rudimenti della 
programmazione a culture diverse come quelle africane, asiatiche e 
polinesiane, visto che da noi si e' vicini alla saturazione del 
mercato, potrebbe essere una delle svolte economiche dei prossimi anni.
ma bidogna elaborare dei modelli che siano adattati al loro modo di 
pensare, non si puo' credere di imporre la nostra cultura per 
raggiungere un tale obiettivo, ci si scontrerebbe con la visione 
tradizionalista che ogni popolo ha delle proprie abitudini ed usanze. 

 apprendimento dei linguaggi, cito il messaggio originale anche se un
Si`, certo, ma sono studi che si basano sulla *MEDIA* delle
persone.  Come fare portare a tutti le scarpe del 41 se quello
risultasse il "piede medio"...:-).
Chi progetta e produce scarpe (linguaggi) fa benissimo a fare
le proprie scelte tecnico-commerciali sulla base degli studi
statistici su come si distribuiscono i piedi (le teste).
Chi deve comprarsi le scarpe (scegliersi un linguaggio) fa
meglio a seguire il consiglio di Mr. uffa, provvedendo alla
misurazione del piede proprio (alla scelta di un linguaggio
adatto alle proprie idiosincrasie), e considerando le varie
statistiche come elemento di pura curiosita` culturale.
Alex

 pensare, non si puo' credere di imporre la nostra cultura per
Quando un elemento culturale presenta aspetti di superiorita`
intrinseca in un dato contesto, esso tendenzialmente si impone da
se`.  Cio` vale soprattutto per aspetti di cultura materiale -- ti
invito a leggere "Guns, Germs and Steel" di Diamond per un ottimo
trattamento del tipico "pacchetto" (di animali allevabili e di
piante coltivabili) che si e` diffuso nella preistoria, e di come
l'asse Est-Ovest del continente Europa-Asia, appunto fornendo un
contesto appropriato per la diffusione di un ottimo "pacchetto",
ha dato all'Eurasia vantaggi enormi rispetto ad Africa ed Americhe
(i cui assi Nord-Sud non consentivano diffusioni analoghe).  Ma
gli elementi di cultura materiale spesso si accompagnano ad altri,
sino a toccare gli aspetti piu` reconditi della filosofia.
Facciamo un esempio.  Qui le letture consigliate sono "The
Nothing That Is: a Natural History of Zero" di R. Kaplan, e
"Zero: The Biography of a Dangerous Idea" di C. Seife.
La *nostra* cultura (nelle sue radici sia greco-romane sia
semitiche) non poteva concepire lo zero -- troppo lontano
dall'intuizione naturale umana, e in diretto conflitto con
le filosofie che la cultura mediterranea aveva sviluppato.
Per fortuna, le filosofie dell'India andavano invece in
tutt'altra direzione, e lo Zero ci stava proprio benissimo.
Dagli indiani agli invasori arabi, dagli arabi all'Europa,
lo zero, e la notazione decimale che esso permette (e che
e` cosi` incredibilmente piu` produttiva di quelle che si
ottenevano prima, in mancanza di zero, come ad esempio i
"numeri romani"), si sono imposti eccome.
Pensa se un qualche tuo antenato morale sul subcontinente
indiano avesse voluto applicare questa tua idea, cercando,
invece di spiegare all'arabo invasore cosa fosse lo zero
("abra kad abra", "aria senz'aria", e` apparentemente una
delle metafore piu` semplici usate all'epoca per indicare
"il nulla", "il vuoto", "lo zero": ancora oggi, questi
suoni non ci suggeriscono forse una formula di magia
nera?-), di "elaborare dei modelli adattati al modo di
pensare" di culture monoteistiche e (rispetto a quelle
del subcontinente) materialistiche e "concrete".
Staremmo ancora a sudare sangue per moltiplicare XXIII
per LXVI, altro che computer...!-)
Per fortuna i numeri cosiddetti "arabi" sono arrivati
eccome, gli intellettuali ed i mercanti sia pure con
tante difficolta` li hanno infine capiti e provati, e
la matematica ha continuato a progredire...
Alex

 capire.
bello, ho toppato 2 volte su 2 a scrivere principianti...

 wrote in message
news:48cb28ef.01091...@posting.google.com...

Si`, ma e` in totale conflitto con la filosofia di verificare
tutto a tempo di compilazione -- le verifiche degli invarianti,
precondizioni e postcondizioni sono effettuate a runtime (e`
facile dimostrare come non si possano fare a compile time
se non risolvendo l'"halting problem" di Turing:-), e sono
quindi un tipico esempio di approccio dinamico alla programmazione,
mentre Eiffel (quando non sta parlando del "programming by
contract":-) difende a spada tratta l'approccio statico.
Piu` in generale in Eiffel si concretizzano tutte le teorie
del suo inventore e grande guru, quindi o "compri" tutto il
pacco, o ciccia.  NON e` orientato al multi-paradigma, come
ad esempio C++ o Python.  Ad esempio una funzione (che torna
un valore) e` drasticamente distinta da una procedura (che
modifica lo stato, tipicamente dell'oggetto di cui e` un
metodo).  Questo significa scrivere codice non rientrante e
men che meno thread-safe, ed e` quindi, secondo me, un
approccio disastroso -- ma se vuoi Eiffel, accetti anche
questo aspetto.
Continuo a prenderlo in considerazione, ad esempio proprio
ieri suggerivo ai colleghi di esaminare la versione .NET (che
pare sia assai ben implementata) -- visto che comunque si
deve cambiare linguaggio (anche il "managed C++" non e` il
linguaggio C++, ha complicazioni _diverse_ da esso:-) se si
vuole sviluppare per .NET, guardiamo anche quello.  Ma ancora
una volta (non e` la prima che lo esaminiamo a fondo, con
vari progetti-pilota) dubito che passera` l'esame; vedremo.
Alex

 vari progetti-pilota) dubito che passera` l'esame; vedremo.
Deduco che stai-state valutando i vari linguaggi che permettono/permetteranno di
sviluppare codice sotto .NET. Anche se siamo leggermente OT vorrei chiederti che
impressioni avete da Smallscript.


 Cosa sono esattamente?
gli invarianti?
detto molto brevemenete sono le condizioni che per una classe devono
essere sempre verificate. Possono essere non verificate soltanto
all'interno di un metodo, ma prima della sua chiamata e al termine
della chiamata esse devono ripristinate.
Ad esempio, in una classe Quadrato l'invariante è che la lunghezza del
lato e l'area sia sempre area = lato*lato, ma in un eventuale metodo
"ingrandisci" è ammissibile che ci sia un istante in cui l'invariante
non sia verificato:
void Quadrato::ingrandisci(int zoom)
{
   lato = lato * zoom;
   // in questo istante l'invariante non è verificato
   area = lato * lato;
   // ora è di nuovo verificato
}
Comunque i vari guru potranno spiegarti meglio!

 se`. 
questo gia' lo sapevano i greci, i longobardi e piu' tardi gli arabi, 
come giustamente hai ricordato :)
Solo che propinare fast food, coca cola, completi di armani, meritocrazia
e quant'altro solo per insegnar loro il C++ mi sembra esagerato, o no?
PS la politica non c'entra per nulla, lasciamola fuori dal discorso

dell'informatica, come per qualunque altro settore
Devi tener presente che se usassi un linguaggio di programmazione
basato sul modo di pensare ad esempio di un cinese questo liguaggio
non si diffonderà in occidente (dove fra l'altro esistono già altri
ottimi linguaggi) creando maggiori problemi.


 ottimi linguaggi) creando maggiori problemi.
ce ne sono a bizzeffe, e l'unica cosa che ti serve per esportare il SW 
e' un compilatore.
In ogni caso parlavo piu' dei "corsi di avvicinamento all'informatica" 
che di linguaggi di uso professionale per progettisti sw: in pratica di 
linguaggi per imparare a pensare in termini informatici quali problemi, 
algoritmi, OO, programmazione procedurale etc

 dell'uno o dell'altro imperativamente.
Apprezzo il fatto che tu abbia perso parte del tuo tempo per
rispondermi, ma non capisco proprio il tuo punto di vista. C++ uguale
all'assembly per scrivere una routine??? se lo dici tu...

 all'assembly per scrivere una routine??? se lo dici tu...
veramente intendevo l'opposto, cio che un buon compilatore creera' 
codice non cosi' lontano dall'assembly da giustificare il suo uso  per 
il bottleneck (anzi, a volte lo fa meglio il compilatore di un esperto 
di assembly), cosi' come usare il c++ per il resto del programma 
(interfaccia, inserimento dati) potrebbe portare un guadagno relativo 
in termini velocita' rispetto ad altri linguaggi che non giustificano 
il maggiore skill level necessario per creare e mantenere codice c++.

 risolta a tempo di compilazione.
Cosa intendi di preciso con "stessa signature"? I metodi devono avere:
1) lo stesso nome
2) stesso nome e stesso numero di parametri
3) stesso nome, stesso numero e tipo di parametri
4) come 3, ma anche con lo stesso tipo di ritorno
?
In questa prospettiva non si potrebbe considerare il polimorfismo una forma 
di tipizzazione dinamica?
Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 impressioni avete da Smallscript.
Pare competere esattamente per la stessa nicchia di Python,
con qualche piccolo potenziale vantaggio di deployment ma
senza tanti altri dei vantaggi di Python.
Alex

 PS la politica non c'entra per nulla, lasciamola fuori dal discorso
Ridicolo.  Tutti questi discorsi sono profondamente politici: non
penserai che "politica" significhi il piu` recente litigio fra
B...oni e B...otti, o che?!  Pensare di potere sradicare il tema
"geografia economica" (di quello stiamo parlando: studia ad esempio
"International Economics Theory and Policy" di Krugman e Obstfeld)
da quello "politica" e` veramente il massimo dei minimi...
Alex

 senza tanti altri dei vantaggi di Python.
Immagino sia cosi'. Ma come sta a prestazioni? La versione nativa (non .NET)
pare essere una delle implementazionei SmallTalk migliori che ci siano in giro.


 di tipizzazione dinamica?
Credo si possa considerarli concetti simmetrici. Il polimorfismo permette di
usare un oggetto di un dato tipo in contesti differenti (quali dipende dalla sua
gerarchia di inheritance: in pratica un tipo derivato puo' sostituire sempre un
tipo base ovunque questo sia richiesto). La tipizzazione dinamica permette di
usare tipi differenti (e non per forza correlati per inheritance) nello stesso
contesto.


 di tipizzazione dinamica?
Al contrario, e` la tipizzazione dinamica che e` una
delle tante forme di polimorfismo.  Alcune forme di
polimorfismo operano a compile-time, altre dinamicamente:
la tipizzazione dinamica opera, appunto, dinamicamente.
Alcune si basano sui tipi, altre no: la tipizzazione
dinamica si basa non sui tipi ma sulle signature.
Se intendi per polimorfismo specificamente il polimorfismo
ottenuto in C++ attraverso l'eredita`, quello e` dinamico
ma basato sui tipi (non sulle signature).  Ne` questo
specifico senso del termine "polimorfismo" e` una
tipizzazione dinamica, dunque, ne` viceversa (come, anche
pensando solo al C++ stesso, puoi desumere verificando se
detto polimorfismo sia una forma di template ovvero
viceversa... ovviamente no!-).
Nella progettazione di un sistema software si puo` spesso
avere la scelta fra l'uso di varie forme di polimorfismo
supportate da un dato linguaggio, e/o una sinergia fra
piu` forme.  Esempio C++:
int confrontaPippi(const Pippo& p1, const Pippo& p2)
{
    return p1 < p2;
}
questa puo` essere polimorfica fra oggetti di classi
che ereditano da Pippo SE Pippo::operator< e` virtuale
(prassi normalmente da evitare, quella di rendere gli
operatori membri di una classe, com'e` noto).  Vs:
template<class PP, class QQ>
int confronta(const PP& p1, const QQ& p2)
{
    return p1 < p2;
}
questa e` polimorfica _compile-time_ rispetto alle
class PP e QQ, e per una data class PP (solamente:
nessun multi-dispatching in C++, sigh) _puo`_ essere
polimorfica run-time come la confrontaPippi suddetta.
C'era una forma sperimentale di polimorfismo run-time
basata su signature, in vecchi release di gcc, vista
come una estensione non-standard al C++, ma in tempi
piu` recenti e` stata rimossa e non ricordo i dettagli
precisi di come si presentava.
Alex (MVP Brainbench per il C++)

 pare essere una delle implementazionei SmallTalk migliori che ci siano in
giro.
Non ho eseguito benchmark di alcuna delle due implementazioni
di Smallscript, sarebbe interessante vederne (fatte da qualcuno
neutrale:-).  La versione sperimentale Python.NET non ha per
ora buone prestazioni -- funziona, ma piu` lentamente sia di
Classic Python sia persino (usando una buona JVM) di Jython
(che dimostra la perfetta implementabilita` di Python su di
una VM ad esso "aliena":-).
Alex

 B...oni e B...otti, o che?!  
se tutti intendessero la politica come discorso coerente e logico tra 
posizioni diverse al fine di trovare una mediazione, avresti 
perfettamente ragione. Ma sembra che pochi abbiano questo concetto di 
politica, e vorrei evitare flame della serie "brutta comunista" "sporco 
fascista" e via di seguito, tanto piu' che non sono ne' comunista, ne' 
fascista, ne' altro, ma mi riservo di giudicare un politico da quel che 
fa e da quel che aveva detto avrebbe fatto.

 proprio marito.
Sei fortunata che non ti sentono le mie numerose colleghe,
perche` sono personcine abbastanza agguerrite e si fanno il
mazzo esattamente altrettanto dei maschietti!-)  Certo che
ci sono anche aspetti sociali: le "people skill" sono una
parte cruciale della maggior parte delle occupazioni
produttive.  Nello sviluppo software, ad esempio, sapere
"giocare in squadra" e` normalmente fondamentale, pochi
sono gli "eremiti".  Se operi in un ambiente in cui i tuoi
pari ti giudicano sulla qualita` della tua automobile, ecc
(non ne ho mai trovato uno in un quarto di secolo che
programmo: fra noi, sembra che i criteri sociali siano
invece tutt'altri!), c'e` poco da fare: nessun "diktat"
dall'alto cambia la testa alla gente.
E questa e` la natura umana, non un "peccato", se non forse
nel senso ipotetico del "peccato originale" (se pensi che
sia da quello che derivano tutti i nostri difetti...:-).
Piu` facilmente, il "team" di sviluppo software si
formera` in modo produttivo, o meno, a seconda di
fattori, pur sempre sociali, ma del tutto diversi.  Ad
esempio, negli anni ottanta, per gusto mio di italiano
temporaneamente emigrato in USA, vestivo molto elegante.
Di conseguenza, ero considerato con sospetto e con
diffidenza dai miei pari (smanettoni informatici nella
IBM Research, universita` come Cornell, eccetera), che
vedevano "la divisa" (jeans e maglietta o felpa) come
parte dell'"essere veri programmatori".  Toccava dunque
a me dimostrarmi SUL CAMPO e superare l'handicap sociale
imposto dalle circostanze.  Ti assicuro che non ho mai
avuto nessuna difficolta` in merito...:-).
Alex

 polimorfica run-time come la confrontaPippi suddetta.
innanzitutto ti ringrazio per l'esauriente spiegazione. Poi voleva porre 
un'altra domanda: cosa e' il multi-dispatching? A naso direi che si tratta 
della capacita' di chiamare la funzione giusta basandosi sul tipo a 
run-time di piu' variabili; in pratica una estensione delle funzioni 
virtuali, dico bene?
C'e' modo di "simularlo" in C++?
grazie Anto


 C'e' modo di "simularlo" in C++?
Esempi sono presenti in "More Effective C++" di S. Meyers, in "Modern
C++ Design" di A. Alexandrescu, e se non sbaglio anche in "Advanced C++
- Programming Styles & Idioms" di J. Coplien. Nel dubbio prendili tutti,
tanto non sbagli :-)
Ciao,
Nicola
P.S. La numerosita' delle alternative e' un'indicazione del fatto che
nessuna e' perfettamente soddisfacente.


Dare anche un'occhiata al sito di Carlo Pescio, sezione pubblicazioni in inglese, C'è un articolo che tratta due nuove
tecniche che pare non soffrano dei difetti delle precedenti.