Newsgroup: it.comp.os.dibattiti
Titolo: Java e le performance

Salve,
    dopo qualche test, diciamo più di qualche, ho realizzato che
effettivamente la JVM (sia IBM che SUN) è più veloce su
NT che su Linux.
Il mio test è semplice, il crivello di Eratostene su 10.000.000 di
numeri con 250 threads.
I risultati non li posto perchè sono solo semplici secondi, ma fatta e
rifatta risultano sempre più veloci i risultati su w2k.
Questo potrebbe voler dire poco o niente, ma ci sono alcune
considerazioni che vorrei qualcuno mi potesse chiarire.
L'hw: i test li ho effettuati su un cpq pl 8500 8 cpu 4 giga di ram.
W2k advanced server e rh 6.2 con kernel 2.2.16-3.
La brutta notizia è che w2k oltre ad essere più veloce è anche stabile,
mentre la jvm su linux non lo è (nessuna delle due, più blackdown).
La bruttissima notizia è che un rs/6000 p44 con due cpu è molto, ma
molto più veloce di tutto quanto sopra!!!!
La bella notizia è che solaris su una e4500 con 6 cpu è più lenta di
tutto quanto sopra!!!
...peccato che il costo di questa sun è 2 volte maggiore dell'hw di cui
sopra messo insieme.
Quali potrebbero essere le conclusioni di questi test??
A) sun non conviene come application server
B) la jvm è meglio farla girare su OS proprietario, tranne che su sun,
se le performance vi interessano
C) linux ne esce con le ossa rotte, la jvm è instabile a causa dei
threads...
D) come fare per usare linux su quel bell'hw compaq??
Ciao

 D) come fare per usare linux su quel bell'hw compaq??
credo che non ci sia nulla da fare finche' qualcuno non faccia un robusta
'donazione' per un porting all'altezza.
--
Antonio Baldassarra
anto...@seeweb.com

molto piů veloce di tutto quanto sopra!!!!
Toh, invece io la trovo bellisssima.... btw, quanto intendi per
"molto, ma molto piu'???
Obelix

 decente).
Dimmi, usi i green o native?? fai uso dei thread nelle tue applicazioni??
usi sistemi SMP??
Sugli UP ho almeno un caso di problema sui thread, ma sugli SMP il tutto è
ingestibile....

 Obelix
ntendo che fatto un valore 90 alla velocità di SUN ho:
75 Linux su intel
50 NT su Intel
25 IBM su IBM
......

 stabilità...l'unico dato rilevante è questo....
Questo e' e rimarra' uno dei cardini su cui si basa l' intera filosofia
produttiva di Sun. Le performance sono importanti ma non cosi' tanto quando
si ha UNA piattaforma che ti permette di scalare semplicemente cambiando l'
HW.
Io non sono totalmente d' accordo con questa politica. Condivido l' uso di
una piattaforma HW anche poco aperta per avere sotto controllo la stabilita'
di un sistema informatico e il totale supporto verso il cliente che la usa.
Sul rapporto prezzo/prestazioni sono invece molto contrario perche' alla
lunga, eccezion fatta per i clienti di un certo tipo, si perde mercato.
Ciao
UltraSparc

25 IBM su IBM
Il piu' basso e' piu' veloce, suppongo.... hmmm, *due*volte piu'
veloce???
Obelix


si, ma come ho detto non c'e' alcun sensibile miglioramento (almeno in green)
dall'avere piu' CPU (ho netfinity 4500, 6500). in particolare con i native thread
+ SMP colleziono solo crash. Parlo di linux ovviamente.
--
Antonio Baldassarra
anto...@seeweb.com


Due volte, in SMP anche piu' di due volte .... ripeto la jvm non trae
nessun giovamento dalla presenza di piu' cpu (almeno in modalita' green
threads, nojit l'altra e' tutt'altro che stabile).
--
Antonio Baldassarra
anto...@seeweb.com


Infatti,infatti...i test prendono per assunto che io voglio avere dei
miglioramenti delle performance con sistemi multi proc.
Non uso i gren per questo motivo, e so che i native , o meglio adesso lo
so, sono instabili.
Ma come dicevo w2k è più veloce(i dati vanno appunto da sun 90 lento a ibm
25 veloce).
E potrei anche capirlo, le solite storie di piattaforme proprietarie (a
parte SUN) contro general purpose.
Ma, a questo punto, mi fa incazzare il fatto che curano le release e non si
rendono conto che è assolutamente non usabile
su linux dando la colpa al sistema, ma a priori dicono: not fixed, linux
unstable.
Il mio dubbio è questo: una macchina SMP potrebbe essere instabile a causa
dei thread??
capisco l'istabilità delle applicazioni, ma tutto il sistema??? e io non ho
mai soferto alcun problema di instabilità ( e credo,. non sono sicuro,
faccia uso dei thread , ed un mio sistema è un file server da 120 giga
proprio con resiserfs)...
Poi quando dico di fare test per poi usare massicciamente java,
chiaramanete non parlo di netscape o del demo 2d, ma parlo di weblogic (che
è un macigno) e di sollecitazioni tali che si comincia  a parlare di 4/8
cpu e 2/4/8 giga di ram.
Magari potrei accontentarmi di un 25% in meno di performance, ma non della
assoluta instabilità.........

numeri con 250 threads.
Per quanto riguarda Linux bisogna prima stabilire se la JVM usa i kernel
threads cioe' usa la libreria LinuxThreads oppure gli user threads.
#ifdef LINUX_THREADS
I problemi della libreria LT consistono di una mancanza di
performance cronica dovuta al fatto che deve supportare lo standard
POSIX dei threads.
Questo standard mal si adatta alla visione dei threads che ha
Linux. POSIX pensa che i threads siano contenuti nei processi,
Linux invece vede i threads come casi particolari di processi,
cioe' processi che condividono l'address space.
Linux ha una syscall, clone(2) che e' piu' generale della fork(2).
Accetta dei parametri che consentono di selezionare cosa si
vuole clonare del processo padre. In questo modo la fork() e'
un caso particolare di clone() dove il processo figlio non
condivide l'address space del processo padre.
I threads quindi vengono implementati con i normali processi,
solo che sono processi che condividono l'address space.
Perche' Linux implementa i threads con la clone()?
KISS principle.
Consente di avere uno scheduler ad un livello, senza districarsi
tra processi e threads. Ne risulta uno scheduler piu' leggero
e di bassa latenza. lmbench, un microbenchmark che misura latenze di
context switch, fork() e tante altre cose lo dimostra.
La libreria LT invece parte dall'assunto che i threads sono
entita' distinte dai processi, che siano cioe' contenuti in
essi. Vi e' quindi tutta una gestione dei segnali che risulta
complessa da implementare in Linux. Infatti se ci si fa caso,
nella creazione di N threads vengono attualmente creati N+1
threads, il +1 e' il thread che gestisce i segnali.
Il risultato di questa discordanza e' che la pthread_create() di
LT fa molto piu' che una semplice chiamata alla clone(2).
Oltre a passare tra diversi lock() e unlock() e' intrinsecamente
inefficiente e mal implemetata. 
Se la libreria LT fosse implementata meglio si potrebbe guadagnare
qualcosa, ma non piu' di tanto. Per avere una gestione dei threads
efficente e' necessario buttare a mare i POSIX threads...
I POSIX threads sono il tipico esempio di "design by committe", cioe'
un design fatto a tavolino senza riferimenti ai problemi di
implementazione reali.
#else
Se la JVM usava gli user threads le performance scadenti sono
del tutto ovvie.
Gli UT sono dei threads implementati all'interno di un singolo
processo. Come tali, e' impossibile per loro sfuttare il SMP.
#endif
Fondamentalmente il design dei threads in Linux e' pulito ed
elementare, purtroppo pero' ci sono degli standard (braindamaged)
su come le applicazioni devono vedere i threads. Questo comporta la
necessita' di scrivere delle librerie che per le ragioni che ho
esposto sono inefficienti.
--
Lorenzo
(address rot13 encoded)

 esposto sono inefficienti.
Bene, su queste tue parole si può solo dire che si potrebbe, volendo, usare
una implementazione diversa di threads, che
tra gli altri usano anche il meccaniscmo usato sa SOlaris che sono i LWP...
Tu pensi che, a parte il problema delle performance, risolverebbe il
problema della stabilità??

problema della stabilità??
Non lo so, dipende dai programmatori della JVM per Linux.


processo. Come tali, e' impossibile per loro sfuttare il SMP.
Forse su Linux. In NT puoi decidere su quale (preferenziale) CPU
mandare ogni singolo thread.
-- 
Tieni per te il Papero se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

 mandare ogni singolo thread.
Nella mia prova ho notato che l'affinity la fai sul processo, non sui
threads che il processo crea...
Anche su Solaris, Aix e Tru64....
Non mi pare utile fissare questa possiiblità...

Non mi pare utile fissare questa possiiblità...
In un sistema sostanzialmente multitask come puo' essere Linux
sicuramente no. In un sistema sostanzialmente multithread come NT
sicuramente si.
Personalmente io preferisco un S.O. multitask ad uno multithread, ma
qui non si parlava di preferenze personali.


 SetThreadAffinityMask "lavora" sui thread e non sui task.
Non parlavo di programmazione Java, parlavo dell'affinity che puoi
decidere dal task manager....

mandare ogni singolo thread.
Sono due cose diverse e non confrontabili.
Gli UT di Linux sono implementati a livello di utente (infatti si
chiamano user threads) mentre i threads di NT sono oggetti del kernel.
Gli UT sono simulati all'interno di uno stesso processo, cioe' e' solo
l'applicazione che li vede, in realta' non esistono, esiste solo un
processo che per ovvie ragioni non puo' essere eseguito
contemporaneamente su piu' processori.
Va da se che gli UT siano scarsamente utilizzati.
Sul fatto di decidere su quale CPU mandare ogni singolo thread:
non credo sia una decisione che spetti all'utente, specie in un
ambiente SMP. Il SO ha da solo abbastanza informazione per decidere
in ogni momento su quale CPU eseguire un thread. Solo lui conosce
lo stato di localita' della cache, dei TLB etc. Di conseguenza solo
il SO puo' fare la decisione piu' giusta.
Insomma, mi sembra piu' un compito da SO che da utente.


Non parlavo di programmazione Java,
Nemmeno io. Io parlavo delle API di sistema.
Se il S.O. e l'architettura hardware lo permette la gestione dei
thread su piu' processori e' competenza dei programmatori (utenti e
sistemisti dormano tranquilli che c'e' chi veglia sul loro sonno).
In caso di task su piu' processori anche i sistemisti possono dire la
loro.


Insomma, mi sembra piu' un compito da SO che da utente.
A me sembra compito da programmatore o da sistemista. Il sistemista
potrebbe decidere che un certo processore "deve" essere dedicato solo
ed esclusivamente al DB e al S.O, (magari) con un tot di memoria
minimo ad uso esclusivo.
Mi sembra una scelta ragionevole, anche se molto da mainframe.
Ho letto da qualche parte che NetWare 5 dovrebbe permettere qualcosa
del genere.


Mi sembra una scelta ragionevole, anche se molto da mainframe.
I mainframe hanno un vero e proprio sistema di partizionamento hw delle
risorse. CPU, memoria, dischi etc. Il VM di S/390, per esempio.
Lo dico per sentito dire ovviamente, non ho mai avuto la fortuna di
vederne uno all'opera! Obelix? ;-)
Cmq qui stiamo parlando di intere classi di risorse virtualizzabili ed
allocabili dinamicamente, tutta un'altra cosa rispetto alla semplice
selezione della CPU mask per un processo, mi sembra.
Il sistema adottato dai mainframe e' veramente utile, non mi convince
invece feature troppo povera di NT.
Tra l'altro il partizionamento hw e' presente in qualche misura anche
sulle Sun della serie Enterprise e negli AlphaServer GS di Compaq.


vederne uno all'opera! Obelix? ;-)
Soory, io ne ho visti un paio, ma solo visti.... comunque, so per
certo che il 390 partiziona qualsiasi cosa dinamicamente(dischi, cpu,
ram, quello che vuoi..) perche' e' una delel cose che il
partizionamento del 400 fara' dalla versione 5 (e infatti ci dicono 'a
differenza del 390....')  :-))
Obelix


Sent via Deja.com
http://www.deja.com/

 sulle Sun della serie Enterprise e negli AlphaServer GS di Compaq.
E' possibile ottenere tutto cio' anche con W2K Datacenter e le nuove
macchine Unisys e Compaq.
--
Bye
Gianluca Zanelotto
Ducati ST2 "Red Devil"

differenza del 390....')  :-))
Ho avuto modo di leggere qualche .pdf sul VM di S/390.
Veramente notevole...
Si puo' allestire un intero server in una macchina virtuale separata da
tutte le altre e con le interfacce di rete virtualizzate in RAM (+ o -),
ottendendo una sorta di Gigabit Ethernet all'interno della stessa
macchina fisica.
Il tutto allocabile dinamicamente nel giro di pochi secondi, senza
toccare nessun hw, senza collegare cavi e senza occupare spazio.


macchine Unisys e Compaq.
L'hw per PC non e' adatto per simili cose, non e' facilmente
virtualizzabile (a parte V86 che virtualizza un 8086 a 16 bit).
Possono aver sopperito in qualche maniera ma non credo siano al livello
di un AlphaServer GS320 o di una Sun. I mainframe poi sono di un'altro
pianeta quando si tratta di virtualizzare le risorse.
Non e' possibile comparare il VM di un S/390 con VMware su x86.
Tutto cio' non e' ottenibile con i PC perche' non e' un'architettura
pensata per fare queste cose, non che le SPARC o Alpha lo siano ma di
solito si prestano meglio perche' hanno diversi vantaggi tecnici
rispetto alla piattaforma di Intel.


invece feature troppo povera di NT.
Se non ti serve non la usi. Che poi servi a poco nella realta' ... e'
probabile. 
Nel mondo reale discorsi teorici molto estetici di normalizzazione dei
DB (per esempio) portano a codice scarsamente mantenibile, e dalle
scarse prestazioni.
Su DataCenter non mi pronuncio perche' non l'ho mai visto, ne conosco
fonti degne di fiducia da cui prendere informazioni.
Sarei meravigliato che Microsoft "sbagliasse" un S.O. desktop, ma
sarei anche meravigliato che facessero un Server degno di questo nome.
Anche se a forza di assumere teste d'uovo nel loro gruppo di ricerca
prima o poi qualcosa di buono potrebbe anche venirne fuori.


DB (per esempio)
Non esistono discorsi estetici sulla normalizzazione....
Obelix

 pianeta quando si tratta di virtualizzare le risorse.
Spiegalo a questi signori di Unisys che sono di diverso avviso.
http://www.unisys.com/hw/servers/enterprise/7000/



http://www.unisys.com/hw/servers/enterprise/7000/
Ho dato un'occhiata a qualche pdf che parlasse delle capacita' di
partitioning della serie ES7000, il server di punta di Unisys.
Ne ho trovato uno che metteva a confronto il loro ES7000 con una
Sun E10000. Purtroppo e' piu' un'articolo pubblicitario che tecnico
e immagino che i veri manuali siano disponibili solo con l'acquisto
del server. E' datato settembre 2000, quindi abbastanza recente.
http://www.unisys.com/hw/servers/enterprise/doc/dhbrown-es7000.pdf
Data la natura dell'articolo, e' volutamente forzato a loro favore,
ma la cosa interessante e' che i punti elencati per sostenere la tesi
che il partitioning di ES7000 e' leggermente superiore a quello di
E10000 in realta' si rivoltano contro :-)
Seriamente, e' inutile riportare i punti qui, basta una lettura
serena e senza pregiudizi per rendersene conto. Parlo in particolare
del paragrafo sul partitioning, alle altre cose ho dato meno peso.
Comunque, Unisys fa delle ottime macchine, e' fuor di dubbio, anche
considerato che usa x86 come piattaforma. Hanno propabilmente un
discreto vantaggio in termini di prezzo/prestazioni, ma sono ancora
(seppur di poco) indietro sul partizionamento dinamico e devono ancora
fare molta esperienza in questo campo, mi sembra di capire.
E' un bene che Unisys offra simili soluzioni per il mercato dei server
x86 ma molti altri prima di loro hanno offerto l'hw partitioning
dinamico su altre piattaforme, anche a 64 bit.
Poi ci sono i mainframe che queste cose le facevano dagli anni '70,
anche se appartengono ad una'altra categoria di macchine ma bisogna
ricordarlo, per correttezza se non altro.


 systems, four eight-processor systems or eight four-processor systems.
direi che rispetto ad un partitioning di S390 siamo anni luce distanti
(oltre che per il fatto che non si parla minimamente di dinamic..)
Obelix

 (oltre che per il fatto che non si parla minimamente di dinamic..)
Forse se ti leggi anche i case study vedresti che c'e' gente che non la
pensa cosi'. Comunque e' dimanico, fino al limite di poter caricare anche
due o piu SO sulla stessa macchina e passare cpu e ram da un SO all'altro in
tempo reale.


Non esistono discorsi estetici sulla normalizzazione....
La normalizzazione porta a frammentare il DB, cosi' come le tabelle di
cross reference portano a far perdere la pazienza ai programmatori.
Gia' sono attorniato da geni che parlano di mettere JavaServer tanto
estetetici quanto inutili, a creare protocolli di comunicazione tanto
belli quanto cretini, a parlare di Pattern e UML sul software degli
altri. Non ti ci mettere anche a tu con le banalita', che di DB ne
mastichi qualcosa.
La realta' ti obbliga a fare dei compremessi. Un DB di produzione
fatto seguendo in modo pedante le regole di progettazione
universatarie ha ottime probabilita' di risultare un DB "fuori dal
mondo". Dal punto di vista teorico il male e' la ridondanza e
l'incoerenza dei dati, dal punto di vista reale la risposta e' sempre
un insieme molto piu' ampio di fattori.


l'incoerenza dei dati,
Dal punto di vista pratico, il male e' l'incoerenza dei dati E basta. 
Obelix

tempo reale.
Dovresti rileggerti il PDF...
Obelix

(oltre che per il fatto che non si parla minimamente di dinamic..)
Ce l'hanno, ma non e' ancora sfruttato. L'impostazione sull'hw esiste,
stando a quello che dicono, gli manca il sw di gestione per w2k.
Per ora hanno il partizionamento hw statico e un meccanismo di
partionamento software per le applicazioni.


tempo reale.
I case study non contano, e' solo marketing per attirare clienti.
Fino a settembre 2000 Unisys non aveva il partitioning dinamico, lo dice
Unisys stessa nel pdf.


 Dovresti rileggerti il PDF...
Questo e quando dicevano all'ultima conferenza stampa.


Questo e quando dicevano all'ultima conferenza stampa.
Ah, gia'... conferenza stampa... come diceva iil mi' nonno?? "verba
volant, scripta manent'... sullo scripta c'e' scritto che il dinamico
'e' da venire'...
Obelix

stando a quello che dicono, gli manca il sw di gestione per w2k.
Che, stando a quello che dicono, dipedne dal vaporware di MS. Non lo
so, la vedo dura...
Oltretutto, giusto per curiosita', quanto e' 'vecchia' la macchina che
stanno confrontando con la loro???
Obelix

con il partitioning in mente fin dall'inizio. 
Perche' nessuno parla del grandissimo problema di DataCenter?
Tendere al kernel unico come tenta di fare Microsoft e' una cagata
pazzesca.
Che ci sta a fare un driver di una stampante a livello Kernel? E le
DirectX 8 sono cosi' importanti in un DataCenter? E la possibilita' di
fare il drag & drop OLE su DataCenter serve? Che cappero me ne frega
di avere un server MTS sul mio PC di casa?
Capisco avere parti in comune, ma gia' lo scheduler e' discutibile che
segua le stesse logiche, figuriamoci 30 milioni di linee di codice (o
erano 40?)


Dal punto di vista pratico, il male e' l'incoerenza dei dati E basta. 
Dai, non fare lo gnorri. Se per normalizzare e gestire i dati in modo
"teoricamente" corretto devo costruirmi centinaia di tabelle con un
campo ID e il campo valore, saro' bravo dal punto di vista teorico, ma
sto cercando guai dal punto di vista pratico.
Un certo grado di ridondandanza (non di incoerenza, che e' un male
assoluto n.d.p.) nella realta' puo' essere accettabile.
++++
Personalmente ho visto molte persone estasiate dei cursori (che odio
perche' costano dal punto di vista computazionale), e molte che odiano
usare le chiavi referenziali (che insiemi agli assert e hai commenti
considero un'ottima abitudine mentale).
Mi vengono in mente i libri che ho letto sul kernel di NT in confronto
con quelli su Unix (quello su AS400 aspetto a rubartelo alla prossima
"conference"), ai libri sul TCP/IP in confronto a quelli su Frame
Relay e ATM. La teoria senza un solida pragmatica e senza validi
progettisti provoca schermi blu.
Java ne e' un esempio. Una buona soluzione in attesa di un problema da
risolvere. Che non c'e', e non ci sara' mai. 


Perche' nessuno parla del grandissimo problema di DataCenter?
perche' siamo divisi in due grandi fasce: chi e' convinto che MS
sappia fare buoni prodotti e chi i buoni prodotti li conosce da
vicino....
Obelix

> (quello su AS400 aspetto a rubartelo alla prossima "conference")
Quando vuoi fissarla, io sono pronto., Se vuoi, ci si rivede dalle tue
parti....
Obelix

 assoluto n.d.p.) nella realta' puo' essere accettabile.
Puņ essere accettato solo da basi dati denormalizzate ricavate da basi dati
normalizzate.
E solo per fini di analisi dimensionale.
Saluti.

erano 40?)
Hanno semplicemente varcato il limite, sono arrivati al punto che e'
molto piu' facile aggiungere le cose che toglierle.
Le ragioni tecniche e quelle commerciali raramente vanno d'accordo e
questo caso non fa che confermare la regola.


normalizzate.
Dipende da cosa intendi per 'ridondanza'. Un certo grado puo' essere
accettato, purche' non ci sinao dati che stavano meglio in un tabella
per conto loro. 
Obelix

parti....
Quando fa piu' caldo.


E solo per fini di analisi dimensionale.
Tanti anni fa il sig. Carlo Lo Pescio scrisse un articolo sulla
programmazione OO che mi colpi' tanto. 
Il concetto che ho elaborato sulla rilettura di quell'articolo e'
questo:
<< Un tipico esempio di derivazione multipla potrebbe mostrarvi che
l'oggetto "Studente" puo' derivare dall'oggetto "Persona" e
dall'oggetto "Lavoratore". Bene, tutto semplice, tutto chiaro, ma la
realta' com'e'? Probabilmente l'elenco dei lavoratori e' dentro un DB
in un ente governativo, l'elenco anagrafico delle persone e' dentro il
DB di un altro ente governativo, e questi non sono collegati. In un
programma reale cosa e' uno "Studente"? >>
Oggi, dopo avere conosciuto l'Extreme Programming sono diventato
ancora piu' refrattario a castelli teorici esteticamente eleganti, ma
che non modellizzano per niente la realta'. 


 forte.
Se il database è normalizzato la sua modifica (aggiungere entità e
relazioni) è molto ma molto
piu semplice rispetto ad uno non normalizzato.

Una relazione con attributi.
Il problema nell'analisi OO è che molti analisti OO non sanno fara l'analisi
OO e
non capiscono che il modello relazionale dei dati in effetti è alla base del
paradigma OO.
Se leggessero qualche libro di Yourdon  capirebbero di più.
Saluti.

Ultimamente pero' sono dell'idea di silurare SQL Server e Oracle
Dovresti deciderti a passare al DB400   :-))
Obelix

Per me e' robusto e' cio' che non da schermi blu.
Anche tu monitor monocromatici??  :-))
Obelix

paradigma OO.
Che il modello relazionale possa stare sotto un modello a OO e' cosa
relativamente nuova. Fino a poco tempo fa sembrava un assurdo. Non so
se hai letto gli articoli di Robert Martin sul sito "Object Mentor" a
riguardo. Il fatto che si possa usare un modello relazionale come base
per lo storage di un modello ad oggetti non vuol dire che siano la
stessa cosa. Non e' una questione di moda se esistono i DB ad oggetti.
Il problema maggiore dell'OOP e' l'enfasi per la ricerca del sacro
graal. Il volere fare l'oggetto mitico che ti risolve non solo il
problema contingente, ma anche quelli futuri e' di per se una follia
che porta a scrive codice complicato. Se non ci riesci (e non ci
riesci nel 99.999% dei casi) allora e' colpa tua che non sei
abbastanza OO, dell'analista che non e' stato abbastanza OO e di altre
fesserie cosi'. Non e' il metodo sbagliato se non riesci, e colpa tua
che non sei adeguato. Qualcuno usa lo stesso discorso con la
complessita' di Unix.
Un altro problema dell'OOP in genere e' il non mettere gli uomini o i
Paperi al centro dell'attenzione. Non serve a niente fare data hidding
se hai a che fare con un cretino. Scrivere tante coppie di funzioni
Get e Set non ti serve a scrivere codice migliore. Pero' tu prova a
usare dei membri pubblici e passerai per un eretico.
Il problema della OO in generale e' che e' di moda, quindi viene
accetta in modo acritico. 
Ma se ci sono illustri e stimati professioniti che vanno ad una
conferenza negli stati uniti in cui gli dicono tante fesserie sul
nuovo PippoOS, e loro si bevono il fumo acriticamente, perche'
dovrebbe essere diverso con il resto?
Epoc e' un S.O. che esiste oggi in negozio in piu' di un prodotto.
Xbox forse uscira' nel 2002. Stessa cosa sul C#. Ho gia' visto libri
sul C#, e mi aspetto a breve libri sull'Xbox. Non mi aspetto libri su
Epoc. Il mondo e' fatto cosi'.
Comunque, se avessi un cane, sarebbe stato concepito ad oggetti.


 accetta in modo acritico.
Sta li il problema.
Saluti.

Sta li il problema.
Fosse per me farei imparare ai giovani programmatori i metodi di
programmazione classica, e non inizierei con le paranoia della OO come
panacea dei mali del mondo. 
Se non conosci il tuo passato non potrai mai pretendere di conoscere
il tuo futuro. Con la programmazione procedurale si sono create ottimi
prodotti. Il C e' per molti versi un ottimo linguaggio pragmatico.
La scelta di un metodo di programmazione, di un S.O., di una
automobile, dovrebbe essere una scelta consapevole. Magari emotiva, ma
consapevole. Non un fatto di moda.


Dovresti deciderti a passare al DB400   :-))
Non decido io, e la chi decide dice no.
Punto.
Fosse per me butterei nella spazzatura NT.
Avevo un bugs in un programma e' ho scoperto che su Win2000 puoi
aprire solo (circa) 44000 socket in contemporanea. La domanda e'
perche' solo 44000? Cosa c'e' di cosi' magico in questo numero?
