Newsgroup: it.lavoro.informatica
Titolo: Linguaggio/ piattaforma preferito

Qual'e' il linguaggio, che nella vostra lunga carriera avete 
piu' amato?
Io attualmente sto lavorando con php/mysql e devo dire che 
e' sicuramente tra i miei preferiti insieme all'object (di CHL)
e VB6
tra quelli peggiori sicuramente
CICS,  4th dimension (Database della Apple) , le macro in lotus 123,
per non parlare dei programmi CAD/CAM macchine a controllo numerico
per i quali i primi tempi mi provocavano veri e propri conati di vomito :-)
nel mezzo metto java e la piattaforma .net
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 
Quindi, php5 lo metti nel mezzo? :)

 piu' amato?
Il mio cuore si spezzo' per sempre con l'assembler, quando feci il virus.
N
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Il mio cuore si spezzo' per sempre con l'assembler, quando feci il virus.
ME l'ero dimenticato :-)
all'uni su PDP-11
5 anni fa l'ho ripassato in vacanza, mi so letto 'art of assembly',
un must :-)


 piu' amato?
Il russo.


 Il russo.
eeee  bei tempi....
1975 una lingua per tutti : il russo 
Canale Nazionale ore 15
subito dopo prove tecniche di trasmissione


 tra quelli peggiori sicuramente
j2ee e middleware in tutte le sfaccettature
Nel mezzo metto:
linguaggi funzionali, assembler, php, sql ecc...

 piu' amato?
Linguaggio: Assembler!
Piattaforma: VxWorks.
Ciao,
Marco. 
[SNIP]
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 piu' amato?
+: C++
-: Perl 
-- 
__________________________
Luc (32, CO)
MS Visual Studio developer
__________________________

 Il russo.
Ah... da questo punto di vista il tedesco :-) (anche se la
settimano scorsa ho letto la prima lezione 
di "teach yourself hungarian" e non mi e' dispiaciuto.  
Peccato che non so quando avro' il tempo di 
leggere la seconda lezione )  


 
Io uso ancora VB6 e non mi piace nemmeno un po'.
Cosa ho amato di più? Il C (senza ++, oggetti, cazzi e mazzi)
-- 
Ciao!
Luca

 piu' amato?
C + Win32 SDK (ancor di più DDK).

 
Pascal su PDP
o ADA..
direi anche lo Scheme su M24.

 piu' amato?
Il C ovviamente, capostipitite di una dinastia e assolutamente imbattibile 
nel campo dei linguaggi procedurali.
Per i linguaggi a oggetti, sarei tentato di preferire il C++ che è quello 
più potente; io preferisco che un linguaggio abbia più funzionalità 
possibile, poi sta al programmatore usarle bene. Aneddoto: tutti dicono che 
l'ereditarietà multipla non serve assolutamente a niente e crea solo casini, 
a me è servita giusto pochi giorni fa; ma siccome il progetto era in Java, 
ho dovuto farne a meno e duplicare inutilmente codice in una classe.
Il C++ ha però un grosso problema: è un progetto *vecchio*, che soffre di 
problemi di retrocompatibilità col C e, soprattutto, della stessa 
impostazione generale. Dover dividere le classi tra file header e file di 
codice è, al giorno d'oggi, una pura follia, che rende questo linguaggio 
inadatto per l'uso comune e ristretto ad applicazioni specifiche. Peccato.
Rimangono C# e Java, nello stesso campo; sono fondamentalmente identici, 
anche se C# ha un paio di funzionalità carine in più. Ma lo preferisco 
soprattutto per un altro motivo: trovo le librerie .NET parecchio, ma 
parecchio migliori di quelle Java. Ah, e .NET compila in codice nativo, non 
dimentichiamolo.
Massimo

 non dimentichiamolo.
Io lo dimenticherei, invece :-)

 dimentichiamolo.
Non e` vero per niente. C# si compila in IL assembly. Che poi girera`
sulla CLR.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

 Io lo dimenticherei, invece :-)
E perché, visto che questo risolve l'annoso problema del Java, ossia le 
prestazioni paurosamente basse?
Massimo

 sulla CLR.
Scusa, ho saltato un passaggio. l'IL si compila in codice nativo però, 
quindi il risultato finale è identico: il programma gira senza una VM in 
mezzo a massacrarne le prestazioni.
Massimo

 mezzo a massacrarne le prestazioni.
Cosi` come con Java. Si chiama JIT ed e` assolutamente indipendente dal
linguaggio, basta implementare un JITter (se necessario).


 prestazioni paurosamente basse?
La JVM sun non ha prestazioni inferiori alla CLR .NET
Hanno entrambi prestazioni analoghe.


 prestazioni paurosamente basse?
Perchè è falso. Il compilato dotnet non è nativo.
Sulle prestazioni ti consiglio di fare delle valutazioni più attendibili.



Quoto e sottoscrivo :-)
PaF

 piu' amato?
er Pitone :-)
A parte gli scherzi, Python e C su Linux. Ma non ho una grande anzianita', 
sono ancora un mezzo "pischelletto" :-)
Comunque, sia lodato S. Guido van Rossum 

 Purtroppo.
ah no? E cos'è? Non è completo, ma è ad oggetti. Smalltalk chi lo usa 
nelle aziende? Io conosco solo privati e appassionati che lo usano, poi 
per certe applicazioni è molto scomodo visto che non hai librerie di 
supporto.
Cmq come puro linguaggio è meglio smalltalk, ma la pratica è una cosa 
diversa dalla teoria.

 Hanno entrambi prestazioni analoghe.
Questa mi sembra un'affermazione un pelino discutibile.
Massimo

 di supporto.
Ehm, calma.
Questo č sempre stato il tasto dolente di C e C++, casomai: non si portano 
appresso alcun framework nativo, a parte poche librerie di base come lo 
stdio. In C e C++ č praticamente impossibile scrivere programmi 
multipiattaforma, e ovunque si vada a programmare occorre studiarsi librerie 
differenti. Inoltre, spesso di librerie C++ non ce ne sono proprio, oppure 
se ci sono sono abominevoli (MFC).
Gestire i thread, i socket, o qualsiasi altra cosa in questi linguaggi non č 
affatto semplice... in Java e C# invece sě.
Massimo

 Questa mi sembra un'affermazione un pelino discutibile.
Per discuterla servono dei dati.
Per fare in fretta prendiamo questi:
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=csharp&lan
g2=java&sort=fullcpu
sulla colonna full cpu time.
7 bench vedono java vincere (valori > 1)
7 bench vedono C# mono vincere (valori < 1)
Mi sembra che si equivalgano in velocita`.
Se hai altri dati tirali pure fuori.


 Sì, ok, ma chi lo usa il Lisp fuori dalle università?
Paul Graham usa Lisp, e ci ha fondato un'azienda che puoi è stata 
acquisita da Yahoo!. In pratica YAHOO! usa LISP (non in maniera 
esclusiva, ovvio).
http://www.paulgraham.com/lisp.html
Cheers,
-- 
Antonio Cangiano
Administrator of 
www.visualcsharp.it
La Comunità Italiana della programmazione C# e .NET

 non è affatto semplice... in Java e C# invece sì.
è facilissimo anche in C e C++, forse perchè ho imparato a programmare 
con quelli e mi sembra facile, in java e C# è proprio una boiata, alto 
livello e comodità massima, ma per prestazioni elevate non puoi fare un 
lavoro in java su dai :-) a meno che non convenga per costi e tempi di 
sviluppo e portabilità, ma se le prestazioni sono indispensabili addio java!

portabilità, ma se le prestazioni sono indispensabili addio java!
Scusa, ma non ti seguo.
In Java, le librerie per thread e socket sono le stesse si qualsiasi 
sistema.
Vorresti dirmi che in C++ sotto Windows e in C++ sotto Linux usi le stesse 
librerie per queste cose?
Massimo

 Massimo


 release di Java? :-)
Questo non motiva la tua affermazione che "Le librerie Java sembrano un 
ammasso informe e caotico di classi e metodi buttati lì a casaccio". 
Semmai puoi lamentarti dei problemi a supportare due versioni differenti 
(cosa che, a quanto pare, avverrà anche con .net. Bastava solamente 
aspettare che ci fosse più di una versione).
Se vuoi criticare l'ingegneria non c'è problema, se ne parla. Si prende 
una libreria a caso (tanto non sarà difficile, se fanno tutte schifo) e 
si discute del design.

 Esempio pratico: ottobre/novembre 2002 -
Sono problemi comuni quando comunichi via socket con sistemi eterogenei 
e (scusami) protocolli fragili. Un protocollo che si aspetta la fine 
della comunicazione quando non trova più dati nel buffer è un po' 
deboluccio. Anche quando l'hai messo a punto funzionerà solo a patto che 
ogni pacchetto non trovi il men chè minimo intoppo di rete, su internet 
il suo funzionamento sarà random.
Idem per il byte order. Java utilizza l'ordinamento big endian 
indipendentemente dalla piattaforma su cui gira, che è detto anche 
network order in quanto "convenzionalmente" utilizzato per le 
comunicazioni in rete fra sistemi eterogenei. Quindi semmai è l'altro 
programma (windows?) che dovrebbe rigirare l'ordinamento prima di 
inviare i dati e dopo averli ricevuti. Il problema fra l'altro l'avresti 
avuto anche nel momento in cui avresti compilato e fatto girare un 
programma C su solaris, esigenza che (a quanto pare) avete manifestato.

 non dimentichiamolo.
Anche un bel programma in assembly viene compilato in codice nativo, così 
come quelli in C++... ma questo cosa c'entra??? Java è portabile (NB: io NON 
programmo in Java).
Stefano 

 è affatto semplice... in Java e C# invece sì.
Calma calma... il confronto tra C++ senza framework e C# non è "politically 
correct". Il C# è un prodotto Microsoft. Ci sarà pure un framework... ma è 
IL framework che ha deciso MS. Un confronto più corretto sarebbe tra C++ con 
un framework come WxWindows o simili e C#. Di fw per C++ ce ne sono a 
decine. Ci sono decine di librerie per gestire thread e socket. Ce ne 
saranno sicuramente di buone e di cattive. Col Borland C++ Builder io 
gestisco in modo semplice thread e socket ed ho un fw ottimo (per i miei 
scopi). WxWindows è solo un esempio, l'ho visto di sfuggita, ma non dubito 
che permetta di gestire thread e socket in modo decente. Insomma, scegliendo 
C# "sposi" Microsoft, così come scegliendo "C++ più fw xyz "sposi" qualcun 
altro. chi "sposi" dipende più dai tuoi gusti personali che da 
caretteristiche particolari... e la crisi viene il 7imo anno ;))))
Stefano 

 librerie per queste cose?
Certo... evidentemente dovresti informarti meglio, su ciò che offre il 
"mercato" Open Source. Anche restando nel commerciale vero e proprio, ci 
sono prodotti Borland che girano sotto Windows e Linux. Questo non significa 
che Borland sia meglio di MS o C++ sia meglio di C#... semplicemente 
significa che le cose sono più complesse di quel che credi. Ti piace C#, 
bene... benissimo. Ma tieni presente che non c'è solo MS e non esiste solo 
Windows.
Stefano
Stefano 

 scopi). WxWindows è solo un esempio, l'ho visto di sfuggita, ma non dubito 
non so se gestisce anche socket, forse fa solo GUI, cmq io ho provato 
vari framework e i socket li gestiscono, così come tutta la gui, 
eccezioni e facilities varie.
Ci sono framework che usano alcuni paradigmi di funzionamento (message 
passing) ed alcuni ne usano altri, ce ne sono di free (LGPL) e ce ne 
sono a pagamento.
In C++ con un minimo di esperienza si programma senza pensare al SO su 
cui girerà l'applicazione (coi dovuti limiti ma si fa praticamente 
tutto), in maniera ordinata e logica (con il framework giusto), 
scrivendo programmi efficientissimi in termini di prestazioni e, a mio 
parere, divertendosi parecchio e stressandosi poco.
Bisogna solo trovare il proprio framework e non mollarlo finché non se 
ne trova uno migliore o meglio aggiornato per i propri scopi.
Consiglio a questo punto un link a caso con elenco di toolkit:
http://www.thefreecountry.com/sourcecode/gui.shtml
Poi cercando bene si trovano pagine di confronto fra framework che non 
gestiscono solo la gui. Quelli che gestiscono solo la gui sono la 
maggior parte ma non servono a niente :-P

 ridondanza. Servono per migliorarne la comprensione.
Tipo
((((((2*((((((4+(((((3*4)))))+3))))*4))))))*3*4))))+4)))*4)))
Guarda te. Che chiarezza pazzesca (non stare a contarle sono a caso, ma
e` per ridondanza imposta dal linguaggio che diventera` piu`
comprensibile)
Ma e` vero che C++0x proporra` un'aggiunta a private e const?
private under_lock you_cant_use_this_directly you_dont_own_your_code
e
private under_lock you_cant_use_this_directly you_dont_own_your_code \
const I_wont_change_ever you_cant_change_me
Cosi` e` chiaro che nessuno puo` accedere o cambiare


 usarli da allora.
Allora, aspetta un attimo.
Quelli di cui tu parli sono problemi che si possono incontrare nella 
programmazione di rete, specialmente se occorre colloquiare con un programma 
(mal) progettato da qualcun altro. Per dire, nelle librerie socket BSD, che 
troverai su tutti i sistemi Unix e che con qualche variante (sufficiente a 
rendere un programma non portabile da Unix a Windows e viceversa, 
ovviamente) costituiscono la base della libreria WinSock, ci sono delle 
funzioni fatte apposta per invertire l'ordine dei byte, proprio perché ogni 
possibile sistema con cui potresti decidere di parlare ha facoltà di 
gestirli come meglio crede; e stendiamo un velo pietoso su cosa intenda ogni 
sistema per "newline", che nel caso di un server interattivo è una cosa 
assolutamente non priva di importanza. Quanto al tuo server che si aspettava 
che fosse il client a parlare per primo, e per di più entro un certo 
timeout, possiamo procedere di nuovo col velo pietoso.
Quello che voglio dire, però, è che questa roba ti avrebbe dato problemi 
anche se tentavi di collegarti al server usando i socket BSD in C, il C# o 
qualsiasi altra cosa; e sono pronto a scommettere che, a suo tempo, aveva 
dato problemi anche a chi aveva realizzato il client Delphi, che ovviamente 
aveva dovuto risolverli.
Ma tutto ciò non toglie che Java, almeno, ti mette a disposizione delle 
librerie per i socket, e queste librerie sono uguali su qualsiasi sistema 
dove tu possa sognarti di usare il Java; e lo stesso per i thread, e per 
parecchie librerie grafiche. Prova un po' a portare un server in C anche 
banale (ma che normalmente usa socket e thread) tra due sistemi operativi 
diversi, e vedrai come lo rimpiangerai, il Java :-/
Quanto al discorso che la VM spedisse un pacchetto ogni morte di papa... 
beh, sono il primo a dire che il Java sia lento da far paura; lo ritengo il 
suo problema principale. Ma almeno fornisce un ambiente di sviluppo 
multipiattaforma, cosa che del C++ proprio non si può dire.
Non a caso, allo stato attuale delle cose, per me la scelta migliore è e 
resta C#. Che, ovviamente, nonostante l'ottimo progetto Mono, non prenderà 
mai piede fuori da Windows perché tanto a Microsoft bisogna dare addosso per 
definizione, e perché "tanto è solo un clone di Java"... :-/
Massimo

 come quelli in C++... ma questo cosa c'entra??? Java è portabile
.NET è portabile *e* compila in codice nativo. Java no. O meglio, lo farebbe 
in presenza di un JIT, ma si tratta di implementazioni piuttosto rare... nel 
90% dei casi Java è un linguaggio interpretato, e questo lo rende 
paurosamente lento.
Il C++ sarebbe perfetto se le librerie standard includessero il supporto per 
alcune cose di cui oggi un ambiente di sviluppo proprio non può fare a meno: 
comunicazioni di rete e multithtreading. Ah, e anche una reflection degna di 
questo nome non gli farebbe affatto male, eh...
Massimo

 anno ;))))
Vero in parte. C# (e tutto l'ambiente .NET) è stato progettato fin 
dall'inizio con l'intento di essere portabile, e laddove questo è stato 
tentato (Mono) i risultati sono stati ottimi.
Il problema, semmai, è che proprio perché è un prodotto MS è stato spesso 
scartato a priori, fuori da ambienti Windows. Come se scegliendo Java non si 
sposasse Sun, peraltro... :-/
Massimo

 template direttamente negli header...
Appunto, ottimo esempio.
È *codice*, che ci fa negli header?
L'architettura header-codice conduce inevitabilmente a questioni su dove 
vadano determinati elementi (i membri statici, ad esempio, o i template); e 
inoltre appesantisce solo il linguaggio. Ma è necessaria laddove il runtime 
non ha la più pallida idea di cosa sia una classe, e la tratta solo come una 
struttura con delle funzioni dentro.
Massimo

 Java non si sposasse Sun, peraltro... :-/
Beh, ad essere onesti oltre a Sun c'e' pure un altro po' di gente, come 
IBM (Websphere e co.) e Oracle (Oracle IAS) tante per dirne un paio che 
vanno abbastanza di moda dalle nostre parti. Un po' più di possibilità 
di farti un'amante ce l'hai insomma, se ti stufi della moglie...
-- 
Fabrizio "Hermooz" Ermini

 il suo problema principale. 
Questo fatto del "lento" sta diventando una spece di leggenda 
metropolitana. Che ora la spedizione dei pacchetti da parte della VM 
faccia da collo di bottiglia mi sembra onestamente un ipotesi azzardata.
Per inciso una applicazione java in esecuzione non è poi così 
esageratamente lenta come si è soliti dire, visto che gli application 
server java sono performanti anzichè no. Certo è un linguaggio 
interpretato con tutti gli annessi e connessi (vedi il caricamento del 
codice a runtime, la reflection, eccetera) e quando fai uso spinto di 
queste cose il programmatore gode ma le performances meno. Però è la 
stessa cosa che succede a qualsiasi altro ambiente interpretato in una 
virtual machine.
L'unica penalizzazione seria è il toolkit dell'interfaccia grafica che 
sotto Windows non sfrutta appieno il gdi ed è visibilmente lenta.

 ha scritto nel messaggio 
news:3o8dj6F...@individual.net...

Aspetta. Quelli fanno application server, non linguaggi :-)
Se Sun decide di cambiare le specifiche del linguaggio o della VM, IBM e 
Oracle hanno da adattarsi e basta...
Massimo

 programma C su solaris, esigenza che (a quanto pare) avete manifestato.
Il programma in C su solaris era il server di cui sopra. L'esigenza
era quella di avere anche un client che andasse sia su Solaris
che su Windows (e per questo fu scelto java).
Comunque quello che dici e' vero. Ora che mi ci fai pensare,
quello che mi preoccupava era che non sapevo in che
formato java spediva i dati e temevo potesse spedirli little endian,
nel qual caso avrei dovuto inventarmi qualcosa
(era il primo programma che scrivevo professionalmente
in java).
Tra l'altro, visto che mi sto ricordando alcune cose,
mi sono ricordato anche che i vari client prevedevano 
l'utilizzo di un lettore di  SIM card collegato al PC tramite il
quale si dovevano leggere i dati della  SIM da inviare al server
(come fanno tutti i client con i quali ho a che fare anche ora),
ma che una libreria che fa questa lettura ce l'avevamo solo in Delphi
che non avrebbe potuto essere portata su Solaris => usammo il
framework OpenCard con lettore di SIM Card GemPlus 410 GR, seriale
con alimentazione presa dalla connessione della tastiera e,
all'epoca, unico lettore di SIM Card spacciato per "funzionante
sotto Sun Solaris": fu un vero bagno di sangue, 
sia per l'implementazione della libreria
java che doveva accedere alla SIM, sia per vari problemi hardware
(del tipo che il connettore dell'alimentazione del lettore
era fatto per essere collegato alla tastiera di un normale PC,
ma la tastiera Sun ha un connettore diverso, il lettore riconosceva
solo ed esclusivamente SIM a 8K [in pratica solo la mia che era 
vecchissima e che poi e' stata "bruciata" con 3 PIN errati
nei vari test di quel progetto]).
Ciao,
Marco.


 faccia da collo di bottiglia mi sembra onestamente un ipotesi azzardata.
Anche a me, in questo caso particolare; probabilmente doveva essere qualche 
altro problema.
Ma Java *č* lento, non neghiamolo :-)
Massimo

 dallo scheduler del Kernel del SO. 
Non conosco le specifiche delle VM, ma è palese che il *linguaggio* non 
ti da funzioni per creare il thread o processo direttamente sul sistema 
operativo. La cosa è mascherata e controllata dalla VM, ovvio. Però è 
altrettanto ovvio che la VM si appoggia sui thread del sistema operativo 
per gestire il suo multithread. Il che non è detto che sia peggio: 
potrebbe ad esempio anche ottimizzare l'esecuzione con un pool di thread 
"fisici" (ribadisco che vado ad ipotesi, non conosco le specifiche).

 diversi, e vedrai come lo rimpiangerai, il Java :-/
Veramente portare pezzi di roba che utilzza i socket in C/C++ da un
sistema all'altro e' una delle attivita' che mi e' capitata  piu'
spesso professionalmente; si va da Linux a VxWorks a Unix HP a
Windows 2000 a IBM Aix a TelORB su TSP (e scommetto che quest'ultimo
l'hanno usato in pochi :-)). Sinceramente non ho mai rimpianto java
(oddio in realta' i socket in java li ho usati "dopo" averli usati
in C sugli altri sistemi, tranne TelORB, per cui "rimpiangere java" 
sarebbe stato un po' difficile:-)).
[SNIP]
Comunque tutti i gusti sono gusti... ma se a me utilizzare i socket in
C/C++ non sembra tanto complicato e tutti mi vogliono far credere
che lo e', mi sembra che "andare addosso all'uso dei socket in C/C++"
sia un po' come "andare contro Microsoft per definizione".


 "fisici" (ribadisco che vado ad ipotesi, non conosco le specifiche).
Che intendi per "ottimizzare l'esecuzione" ?
In ogni caso da C in genere puoi creare dei thread schedulati 
direttamente dallo scheduler del Kernel (ovviamente mediante cose 
come l'SDK di Windows, non certo in ANSI C.  Vedi ad esempio 
beginthread o _beginthreadex).
Non se se da java c'e' un modo per richiamare direttamente
le API del SO (probabilmente ci sara' qualcosa legato alla JNI,
anche se al momento non mi viene in mente) pero' usare i thread 
della libreria java puo' essere un po' limitativo in certi casi
(ovviamente dipende sempre da quello che devi farci. 
Io quando li ho guardati venivo dalla progettazione/implementazione di 
un simulatore motociclistico con deadline comprese tra 
1 e 10 ms per cui ogni cosa diversa da C su VxWorks effettivamente 
mi sembrava un po' limitativa).


 Che intendi per "ottimizzare l'esecuzione" ?
Per esempio, mantenere un pool di processi invece di associarli
uno-ad-uno ai thread di java.

 paurosamente lento.
Questo e` _falso_.
Sia la lentezza che il fatto che i JIT in java sono rari.
Perche` continui a voler parare qua.
Guarda che a me java fa schifo tanto quanto C# per cui non farmelo
difendere. Si sta qua a discutere di velocita` e si usano linguaggi con
una VM per discuterne... Se vuoi la velocita` vai di asm o C, non usi
certo C#.


 beginthread o _beginthreadex).
È quello che intendevo io: devi appoggiarti sulle API del sistema operativo, 
il linguaggio non ti fornisce alcuna libreria un pelino più astratta. Il che 
significa che, per spostare un programma multithread da una piattaforma ad 
un'altra, devi impararti da zero un nuovo set di API, mentre in Java usi 
sempre le stesse e ci pensa la VM a implementarle.
Con questo non voglio dire che consiglio di mettere una VM sotto il C++: 
intendo semplicemente dire che, se il set di librerie standard C++ 
includesse una classe Socket (magari implementata sul modello degli 
iostream, un "sockstream" o qualcosa di simile) e delle classi per gestire i 
thread, poi starebbe agli implementatori del compilatore e delle librerie 
realizzarla come wrapper delle API di sistema (laddove possibile, 
ovviamente); il programmatore dovrebbe occuparsi solo di usarle, e userebbe 
le stesse identiche librerie indipendentemente dalla piattaforma. Non c'è 
alcun bisogno di macchine virtuali per fare questo.
Ovviamente so che esistono già dei framework adatti a questi scopi, ma io 
parlo di standardizzare la cosa a livello di includerla nelle librerie 
standard C++, in maniera tale che la soluzione sia "quella", su qualsiasi 
piattaforma, senza doversi andare a scegliere un framework prodotto da 
chissà chi, vincolato a un certo produttore e magari disponibile per due 
piattaforme ma non per la terza; o, peggio ancora, ricadere sulle API di 
sistema, che ovviamente sono quanto di meno portabile esista al mondo.
Massimo

 certo C#.
Ma che stai dicendo?
Una volta che l'IL è stato compilato in codice nativo, non c'è più nessuna 
macchina virtuale in mezzo, è un programma e basta. Dove sarebbe la 
penalizzazione in velocità?
Massimo

 penalizzazione in velocità?
Non ho voglia di spiegarti tutto... spero lo facciano gli altri.


 Cosi` e` chiaro che nessuno puo` accedere o cambiare
A parte il fatto che siamo ormai OT... se scherzi, metti qualche faccina... 
sennò spiegami cosa ti ha fatto di male il C++... ti ha forse fregato la 
morosa un programmatore C++??? ;)))))))))
Stefano 

 solo come una struttura con delle funzioni dentro.
Quale runtime???
Stefano 

 Non ho voglia di spiegarti tutto... spero lo facciano gli altri.
Io ci rinuncio... ;))))))
Stefano 

 morosa un programmatore C++??? ;)))))))))
No no, anzi. Il C++ semplicemente non lo digerisco. Trovo che sia uno
dei linguaggi piu` stupidi mai creati, non perche` stupido, ma perche`
l'autore sembra si sia divertito a mettere ogni sorta di complessita`
mai pensata sulle spalle del programmatore, oltre ad essere stato il
linguaggio che ha introdotto gli obbrobri di private/protected/public
[se non ricordo male] che sono la seconda cosa piu` inutile del mondo
[infatti ne` CL ne` smalltalk, che sono stati i primi a oggetti, hanno
quella roba]. Il fatto che basta cambiare ordine dei metodi in una
classe per rompere l'ABI e` un'altra cosa idiota.
Ne ha cosi` tante di cazzate sto linguaggio che sembra si siano
divertiti ad aggiungerle per vedere quanto lontano ci si poteva
spingere.


 l'eccezionalita` della cosa)
...
Non è questa la ridondanza di cui parlo. prendi, ad esempio, la parola 
"lingua". Capiresti di cosa parlo, anche se dicessi
- ingua
- lingu
- ling
Se però cambiassimo argomento, parlando di donne, di cosa sto parlando?:
- ling
- ngerie
Vabbhè... ho suggerito ;)))
La ridondanza è l'utilizzo di sillabe in eccesso, rispetto a quante ne 
basterebbero per avere un vocabolario composto da parole comunque distinte. 
Per "codificare" 30000 parole, basterebbero vocaboli composti da una 
manciata di sillabe (non sto a fare il conto). Si potrebbero evitare perfino 
le vocali. Ma sarebbe difficilissimo capirsi, soprattutto quando si parla 
sottovoce o in ambienti rumorosi. La ridondanza aiuta la comprensione del 
linguaggio. Si usa, del resto, anche tra computer... mai sentito parlare dei 
buoni vecchi bit di parità?
Stefano

 buoni vecchi bit di parità?
Si ma non vedo cosa questo possa c'entrare con il C++.
Il fatto che per accedere a qualcosa 'posseduto' da qualcos'altro io
abbia 3 modi diversi (come minimo) mi fa capire che c'e` qualcosa che
non va... E qui c'e` poca ridondanza, sono io che devo tenermi a mente
gia` 3 modi diversi di fare la stessa cosa, ed e` l'operazione piu`
banale e frequente che potro` incontrare durante lo sviluppo.


 la penalizzazione in velocità?
Gli altri hanno rinunciato, io ci provo anche se non sono di certo un 
esperto di compilatori, anzi!
Anche se compili in codice nativo, devi vedere come avviene questa 
compilazione e come è strutturato il linguaggio.
Esistono sostanziali differenze anche fra compilatori dello stesso 
linguaggio, prova a compilare lo stesso identico codice con visual 
studio (anche ultima versione), mingw32, cygwin e vedi che variano non 
solo le dimensioni (se li comprimi con utility di compressione 
eseguibili come UPX alla fine non ti cambia molto) ma anche nelle 
prestazioni!
Fu un mio prof di fisica al 3 anno, durante prove per il progetto di 
fisica dei sistemi complessi, a provare lo stesso codice (platform 
indipendent in C) con vari compilatori e SO, le prestazioni erano 
differenti, come è giusto che sia, perché ogni compilatore trasforma il 
codice come gli pare, potrebbe anche fare un ciclo 10000 volte senza 
motivo, per sicurezza sua, chi lo sa, e alla fine fare un giro di 
indirizzi di memoria assurdi per sicurezza sua, chi può dirlo.
Studiando compilatori, comunque, è stato facile capire questa cosa, 
visto che partendo dallo stesso linguaggio nei progetti ciascuno ha 
implementato il compilatore come gli pareva, tutti ovviamente linguaggi 
identici (mi pare LALR(1) non ricordo).
In conclusione se un compilatore per C che esiste da una vita, nel vero 
senso della parola per l'informatica, è estremamente ottimizzato e vi 
sono state fatte sopra svariate tesi e studi di ogni tipo, sia da 
appassionati che da ricercatori, un interprete java è oggi sotto studi 
intensissimi e di fatti si sono fatti passi da gigante negli ultimi 
anni, ma è ancora presto per competere con compilatori C e C++, se non 
altro anche per la natura di java, ma non solo.
Dando tempo al tempo java può raggiungere prestazioni elevatissime, ma 
MAI eguali al C, perché ci sono delle storie di mezzo che ne complicano 
la compilazione, a meno che non metti la JVM tutta in HW e la macchina 
virtuale sparisce, allora con compilatore ottimizzato fai quello che vuoi.
Non sono un grande esperto di compilatori e chiedo venia se ho detto 
boiate, ma questo è quel poco che so e se è sbagliato correggetemi, 
linguaggi e compilatori sono il mio punto debole, ma se imparo qualcosa 
non mi fa schifo :-)

 Una volta che l'IL č stato compilato in codice nativo,
E' inutile insistere, non č cosģ.
Non ci vuole molto, basta provare.

 banale e frequente che potro` incontrare durante lo sviluppo.
Non vieni dal C, eh? Una delle cose più belle - e potenzialmente causa
di casini, se non sai cio' che stai facendo - del C e che il C++ ha
ereditato è l'aritmetica dei puntatori. Credimi, una volta che ti sei
abituato a adoperare bene i puntatori, ne sentirai la mancanza qualora
non ci dovessero essere. Certo, prima bisogna BEN comprendere di cosa
si tratta...
-- 
Ciao!
Luca

 Non ci vuole molto, basta provare.
Beh, per l'esattezza teoricamente è così.
La rogna è che il JITter, per quanto sia buono, per le ottimizzazioni
che non può apportare (sennò renderebbe il tutto mortalmente lento) non
riesce a ottenere un eseguibile tanto performante quanto uno compilato
con tutti i crismi.
Da 'sto punto di vista devo dire che, filosoficamente, trovo la strada
del JITter una strada senza sbocchi e, paradossalmente, una di quelle
più battute. Microsoft non ha avuto coraggio di distinguere il proprio
ambiente da Java in questo.
A me sarebbe piaciuta una cosa del genere. OK IL, ma una volta che
installo la mia applicazione IL su una macchina, questa viene compilata
completamente e messa in cache, in modo che alle esecuzioni successive
venga preso il compilato in cache. Eventuali compilazioni successive
sarebbero eseguite solo in caso di modifica di uno o più componenti
l'applicazione. La cosa peraltro sarebbe fattibile, perché un sistema
di versioning esiste già. Il tutto sarebbe estremamente efficiente.
Il risultato della strada intrapresa ora, viceversa, è avere
applicazioni che girano su macchine ultrapotenti in modo più lento di
quanto giravano normali applicativi 5 o 6 anni fa. Non la trovo una
gran cosa.
-- 
Ciao!
Luca

 si tratta...
So gia` ben usare i puntatori.


 piattaforma. Non c'è alcun bisogno di macchine virtuali per fare questo.
La questione è molto semplice: la libreria standard dei linguaggi come 
C/C++ ha lo scopo di fornire al linguaggio le funzionalità base, non 
quello di fornire portabilità delle API. API è un acronimo che sta per 
Application Programming Interface, quindi se vuoi programmare un sistema 
operativo *quella* è l'interfaccia per farlo e i linguaggi C/C++ hanno 
il compito di fornirti l'accesso. Se vuoi una astrazione o ti interessa 
la portabilità allora ti serve un framework come ce ne sono a giro.
Tieni conto che i sistemi sono molto diversi fra loro, la portabilità 
*costa* e non ha senso addebitare questi costi al linguaggio che, per 
sua natura, tende ad andare nello specifico (le API e le syscall sono 
librerie di funzioni C).

 sistema, che ovviamente sono quanto di meno portabile esista al mondo.
Questo e' solo un problema di inclusione delle librerie nello 
standard, non mi sembra che sia un limite del linguaggio in se.
Invece se, una volta incluse le librerie nello standard, non le
puoi piu' bypassare, in alcuni casi potrebbero notevolmente girarti
i cosiddetti.


 i cosiddetti.
Ah, questo č poco ma sicuro.
Massimo

virtuale sparisce, allora con compilatore ottimizzato fai quello che vuoi.
Esattamente quello che sostengo io: il Java, essendo basato su una VM, non 
raggiungerà mai le prestazioni del codice nativo a meno di non tirare fuori 
la VM dal gioco.
.NET, invece, elimina la VM, visto che compila l'IL in codice nativo quando 
sposti un programma in IL su una piattaforma specifica e lo esegui. Quindi 
nell'esecuzione di un programma .NET non ci sono macchine virtuali in mezzo.
Mi sta bene il tuo discorso che magari i compilatori .NET, essendo 
un'invenzione tutto sommato recente, possano non essere ancora ottimizzati 
al meglio; ma io stavo parlando di un limite intrinseco (la VM) che in Java 
c'è, e in .NET no.
Massimo

 banale e frequente che potro` incontrare durante lo sviluppo.
Il problema non è nemmeno questo. Avere tre modi diversi per fare la stessa 
cosa sarebbe ridondante... ma qui ci sono tre modi diversi da usare in tre 
situazioni "diverse" (che in sostanza sono analoghe), e ogni volta bisogna 
usare quello giusto o non si compila proprio niente.
Come se ci volessero tre verbi diversi per dire che sei bello (aggettivo), 
che sei incazzato (stato d'animo) o che sei qui (presenza).
Massimo

 si tratta...
Scusa, di preciso che problema avrebbero i puntatori se l'accesso a un 
membro di un oggetto puntato si facesse con l'operatore "."?
Massimo

 gran cosa.
ah fai te! Insomma un minimo vantaggio nei tempi di sviluppo e 
flessibilità dei progetti può anche starci, ma se poi le prestazioni 
sono queste tanto vale creare framework meglio progettati in C++ e usare 
quello. Io tutta questa difficoltà nell'usare C++, se si usano librerie 
e framework adeguatamente progettati, non la vedo.
L'unica cosa scomoda di C++ (o C) sono le librerie e i framework, in 
java tutto è ordinato e presente, basta includere, in C e C++ bisogna 
cercarsi le librerie, installarle, fare bene le inclusioni con gli 
header, evitare le inclusioni ricorsive, insomma, un po una seccatura 
effettivamente, ma con un minimo di esperienza si superano senza problemi.
Il java mi pare tanto un linguaggio comodo per chi programma da poco 
tempo e vuole sviluppare applicativi grandi e anche complessi, come 
struttura, ma con un linguaggio semplice e che necessita di solo un po 
di esperienza. Anche io programmo in Java eh, ma riconosco le sue 
potenzialità e i suoi limiti, non puoi usarlo per tutto perchè se lo fai 
vieni meno a specifiche di progetto (quando ci sono di mezzo prestazioni 
ad esempio, cosa non così rara).
In .NET è vero che non c'è una vera e propria VM, ma c'è cmq una fase 
intermedia (non ricordo il nome) di traduzione ed il codice eseguibile 
generato non ha di certo la struttura di un codice C o C++, vedi mio 
post precedente. Questo fa sì che le prestazioni siano comunque 
inferiori, non solo per la giovinezza del compilatore ma anche per la 
struttura del codice generato.
Insomma, secondo me va usato il linguaggio che ti permette di gestire 
meglio il progetto e in meno tempo purché le specifiche siano rispettate.
Se le specifiche vogliono portabilità e sviluppo in diversi ambienti e 
tempi rapidi di sviluppo da gruppi eterogenei di sviluppatori, allora 
Java. Se vogliono la stessa cosa ma in windows, .NET.
Se si vogliono un minimo di prestazioni e le persone che sviluppano 
hanno il dovuto background, C++ per progetti grossi o in rapida 
evoluzione e C per progetti dai contorni più delimitati e di medie 
dimensioni.
Poi ci sono sempre i limiti di librerie, se so usare e conosco solo una 
libreria, che ne so, per elaborazione di immagini, con trasformate di 
fourier, analisi statistiche e amenità varie, non posso fare il progetto 
in C se sta libreria è in C++, mi dovrò adattare :-)
Idem per i framework, per quello il C++ si rende più necessario del C, 
anche per adattarsi a librerie di supporto che sono necessarie per il 
progetto.

 Quale runtime???
Appunto. Il C++ definisce un linguaggio, ma non il relativo runtime di 
supporto. Ma non ha molto senso parlare di un linguaggio ad oggetti, quando 
per il compilatore si tratta sempre e soltanto di manipolare file di testo. 
E, tra l'altro, questo impedisce cosette utili come la reflection :-(
Massimo

 un membro di un oggetto puntato si facesse con l'operatore "."?
Nessuno. Immagina pero' la confusione se il codice fosse almeno un po'
lungo...
-- 
Ciao!
Luca

 lungo...
Io uso python.
Lavoro abitualmente su Twisted Matrix.
Tutto il framework sono oltre 150 mila line di codice (sembrano 'poche'
ma python e` molto piu` conciso di quello che si crede).
In python c'e` un solo modo per accedere a qualsiasi cosa: .
Ti assicuro che nessuno si confonde neanche con Zope che e` attorno alle
400 mila linee di codice.
Neanche in pypy che sono 100 mila circa.


 nel mezzo metto java e la piattaforma .net
Conosco troppo poco .net per giudicarlo, ma in fondo non č malaccio. Ha 
dalla sua il mastodontico ambiente di sviluppo che in un certo qual modo 
incuriosisce chi come me č abituato a semplici editor di testo (tipo 
Ultraedit) :-)

di versioning esiste già. Il tutto sarebbe estremamente efficiente.
Sbaglio o quello che intendi tu si può già fare con ngen?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfnativeimagegeneratorngenexe.asp

 ls/html/cpgrfnativeimagegeneratorngenexe.asp
Più o meno. Pero' con ngen lo devo fare a manina, e potrebbe esserci
caso che io non voglia che finisca nella GAC.
-- 
Ciao!
Luca

 lungo...
Al punto da non ricordarsi più se una variabile rappresenta un oggetto 
locale oppure uno creato con new?
Temo che un codice siffatto abbia ben altri problemi...
Massimo

 Massimo
Non so, io ho l'impressione che l'utilità di un codice leggibile al
primo sguardo sia sottovalutata.
Il fatto secondo me di avere ben distinti puntatore, reference e
oggetto è un elemento di chiarezza in più. Poi se vuoi possiamo
discutere sul fine di un reference (che alla fine è un puntatore).
Una cosa del genere non esiste ovviamente in linguaggi recenti, peché
comunque hai a che fare con un reference (in C# o in Java, ma anche nel
vetusto VB), ma in C++ è ben presente e il fatto di due o tre notazioni
differnti non fa che aiutare il programmatore nel comprendere con cosa
ha a che fare.
-- 
Ciao!
Luca

 che il C bagna il naso piu` e piu` volte.
...
Questo dimostra quanto tu non conosca affatto il C++. Il C non bagna il naso 
al C++... semplicemente perché il C++ può essere usato come se fosse C. 
L'eventuale rallentamento lo ottieni solo se inizi ad usare classi con 
metodi virtuali. L'accesso indiretto (tramite virtual table) ad un membro di 
una classe può essere un rallentamento... non certo l'uso di -> 8che c'è 
anche in C, tra l'altro).
Forse, se ti studiassi il C++ ed iniziassi ad usarlo veramente, cambieresti 
idea. Evidentemente hai rinunciato a studiarlo, dopo una prima breve lettura 
di qualche manuale. La prima volta ch eho letto un libro che spiegava il 
C++, mi sono detto anch'io "'mmazza quant'è complicato"!!! Non per questo ho 
rinunciato ed ho iniziato a denigrarlo... ma, anzi, ho avuto un motivo in 
più per approfondirlo (era praticamente una sfida, capirlo). ora non ne 
potrei fare a meno.
Stefano 

 E, tra l'altro, questo impedisce cosette utili come la reflection :-(
Forse, prima di specchiarsi (scherzo!), si dovrebbe guardare meglio gli 
altri (non scherzo!).
Stefano 

 un'invenzione tutto sommato recente, possano non essere ancora ottimizzati
...
Invenzione... quale invenzione???????? Cosa avrebbe di tanto innovativo .NET 
da poter parlare di invenzione? Compilare in codice nativo??? Fors el'uso di 
qualcosa di simile al P-Code???
Stefano

 potrei fare a meno.
Il C++ lo conosco abbastanza bene. E ho modi migliori di spendere il mio
tempo che sfidare la cervellotica mente dell'inventore nella gara a chi
capisce i ragionamenti piu` contorti dietro a un compilatore.


 potrei fare a meno.
sì, il C++ se studiato a modo e soprattutto se studiando i vari testi 
(anche in rete gratuiti) su come usare C++ senza perdere in prestazioni 
si ottengono risultati eccellenti, mantenendo quasi tutta la 
flessibilità del linguaggio e degli oggetti.
Ovviamente usarlo come ci pare e piace è più flessibile ancora ma dopo 
addio alle prestazioni ottime :-)

 da un punto di vista strettamente tecnico, come kernel e driver ad esempio.
 
PostgreSQL dove rientra?
Le GTK+?
X?


 X?
bhè uno sviluppa con quello che vuole e secondo me progetti del genere 
fatti ad oggetti sarebbero stati più comodi da gestire, vedi programmare 
con xlib che è uno schifo (fatto nella tesi).
Se uno ritiene di essere più produttivo con C giusto che usi quello, ma 
dubito che coordinare molte persone in un progetto e mantenerlo, 
sviluppandolo in C se grosso (come quelli citati) sia produttivo.
Poi c'è chi è bravissimo tecnicamente e non gli importa se C o C++, 
sviaggia lo stesso, però in generale trovo il C++ molto più comodo e il 
paradigma ad oggetti molto più efficace per gestire i progetti grossi.

 paradigma ad oggetti molto piů efficace per gestire i progetti grossi.
Io te lo ripeto pero`...
Esistono tonnellate di trucchi per programmare a oggetti in C.
Sia le gtk che il kernel di linux usano la loro versione del trucchetto.
Il fatto che una libreria sia brutta da usare significa 0.
Per me wxWidgets e` un aborto dal punto di vista dell'API, eppure e`
scritto in C++.
Il fatto che un linguaggio non supporti nativamente il paradigma a
oggetti non significa nulla, specialmente quando hai le funzioni che
sono first class objects e le struct per contenere puntatori a funzione.
L'unica cosa che poi 'mancherebbe' sono le solite inutili
private/public/protected. Per spiegare perche` sono inutili riporto le
argomentazioni di qualcuno che sicuramente ne sa piu` di me (che con me
condivide anche l'odio profondo per il c++ e tante altre cose) Erik
Naggum.
http://groups.google.com/group/comp.lang.lisp/msg/917737b7cc8510e3?q=g:t
hl2218095647d&hl=en&rnum=9
Riporto davvero la parte piu` memorabile di questo bellissimo post:
==
  C++ is philosophically and cognitively unsound as it forces a
violation 
  of all known epistemological processes on the programmer. 
==
...
==
  I actually think C++ is ideal only for programmers without any ethics.
  you must lie, you are encouraged to declare your private stuff and
keep 
  the cards very closely to your breast, but if you need access, you
just 
  go ahead and change other people's class definitions.  the "improved"
  strong typing is designed to cause errors if you make simple mistakes,
  forcing you to use a lot more of your brain on remembering silly
stuff, 
  but then you get to templates and all hell breaks loose because
suddenly 
  you have _no_control_at_all_ over where things fly.  when I wrote that
  C++ and CLOS is a question of what kind of people you wish to live
with 
  in your community, I was not _just_ making an analogy.  one can only 
  imagine what having to lie to your compiler _every_ day and to make 
  unwarranted guesses that your colleagues will depend on the same way
they 
  depend on your hard-earned knowledge _does_ to a human brain -- I know
I 
  couldn't handle even the prospect of it. 
==


 Fors el'uso di qualcosa di simile al P-Code???
Intendevo che sono compilatori con un paio d'anni di vita alle spalle, 
sicuramente non possono rivaleggiare per ottimizzazioni con prodotti come 
GCC.
Massimo

 
Sempre sia lodato!
Con l'occasione vi posto questo link:
http://users.bestweb.net/~ctips/