> E comunque è proprio solo un luogo comune che sia piu facile da
> imparare/debuggare/usare...tutto dipende dal background informatico
> che hai...certo che più si avvicina a zero, più ti farà comodo un
> linguaggio in cui non devi preoccuparti della differenza tra stack
> e heap,
se si è incoscienti, non ci se ne preoccupa.
Ma il garbage collector non sta ai comodi dell'incosciente, eh. Poi quando la
macchina si schianta per "out of memory", magari il programmatore incosciente
capisce che è bene sapere cosa è un puntatore e cosa è un riferimento (che
usa java), come funziona il deferenziamento, eccetera, eccetera.
> Dipende sempre da che cosa ci vuoi fare.
> Java e' un po' il BASIC degli home computer di 20 anni fa, in un certo
> senso.
ci vuole del coraggio barbaro per paragonare java al basic eh...
> La diattriba e' nata perche' fa andare lento freenet :)
freenet è stato scritto 10 anni fa da gente che non sapeva programmare, e usa
delle costruzioni che anche all'epoca erano viste come fumo negli occhi.
Si, è stato scritto da gente che voleva ottenere tutto e subito senza avere
arte nè parte. Risultato: è lento. L'avessero fatto in C, tutti gli
utilizzatori avrebbero avuto le macchine bucate. Trovatevi contenti.
> Vedi l'implementazione dei cast dinamici ... chi programma in java usa i
> cast a profusione e se ne sbatte di tutto quello che viene generato
> sotto.
Dipende: prima di fare un cast ci si pensa quattro, non due volte. Chi sa fare
OOP non fa i cast, semmai si crea altre gerarchie.
> Il problema dal punto di vista del programmatore java e' che
> molte cose non si possono fare (cose tipo i template stile c++)
Esistono i Generics da 4 anni, implementati su tutte le classi
Quali sono le altre cose che non si possono fare ?
Io ci controllavo Netfilter, da java, tramite hook java/C... fai tu.
> quindi si ricade nelle implementazioni opinabili anche per limitazioni
> del linguaggio (ma questo non lo ammetteranno mai :)
noi ammettiamo le limitazioni di java.. ad esempio non metterremmo mai un
servlet container su un pentium166, ma nel 2008 ancora c'è gente che li usa?
si, ce n'è, ahinoi.
> Infatti un linguaggio che produce codice indiretto (poco tracciabile)
definisci "poco tracciabile"... usato mai un qualsiasi reverse engineer per
java? ci sono di quelli che ti creano anche i grafici uml delle classi..
ma che java usate voialtri?
> ausa facilmente troppi accessi "compulsivi" alla memoria e questo fa
> serare le pipeline del processore.
un pentium166 forse, non una QUALSIASI Sun
Occupa molta memoria e quando la usa (in continuazione per le sue
ottimizzazioni) appesantisce l'esecuzione di un applicazione in modo
sproporzionato rispetto alla sua complessità.
> E' troppo stratificato per requisiti di isolamento e sicurezza ma, chi
> programma in C lo sa bene, avere troppi layer di codice da passare per
> fare qualsiasi cosa da come risultato un'architettura pesante.
troppo? ......
> Di per se' tutte queste cose non sono sbagliate se vengono usate
> correttamente ad alto livello. Il problema nasce quando sono feature
> interne, non le vedi e, invece, sei portato a vedere solo l'eleganza di
> certe astrazioni facendo delle cagate assolute :-) Succede anche in C
> sia chiaro.
Si traduca in: se programmi male, fai cagate. Ma non c'era bisogno di
scomodare l'ennesimo flame su java per saperlo.
> In parole povere java SCALA male. Non e' un problema di risorse di
> calcolo piu' che sufficienti al giorno d'oggi. Piu' l'applicazione e'
> complessa e piu' e' facile incorrere in grosse penalita' difficilmente
> prevedibili o evitabili.
ma soprattutto no. se si prende come fondo scala un pentium166mmx e come
esempio opposto un esacore-supermulti-blabla.. si.. java scala male, nel
senso che non c'è una proporzione lineare.. piuttosto una quadratica se non
cubica.
Del resto chi scrive programmi in java
1) non li fa per farli girare su p166
2) non usa p166 :D
Inoltre, se devo scegliere tra l'usare un pentium2@350 con
apache+php+millemila accorgimenti per non farmi bucare la macchina, e un
pentium3@1000 con su tomcat che fa il suo sporco lavoro cosicchè io non mi
debba preoccupare che ogni 3 minuti un lamer prova a lanciare il suo ultimo
exploit per php/apache/affine... beh.. io prendo anche un p4.
Certo, non per tirar su un forum di gamer o una chat, ma questi non sono casi
contemplati in nessuna delle alternative... o si ?
> Detto questo la virtual machine JIT invece e' notevolmente veloce e
> ottimizzata, e su algoritmi numerici puri (implementati con tutti i
> crismi) si avvicina alle prestazioni dei compilatori C/C++. Questo
> paradossalmente ha dato a java un senso d'esistere nel mercato dei
> giochini (applicazioni semplici multipiattaforma) e in alcune
> applicazioni numeriche/matematiche (CPU bound) dove la portabilita'
> binaria e' un requisito per evitare di tenere conto di tutte le
> varianti di sistemi esistenti.
nel mercato server dei grandi portali no?
ebay, google, oracle, vodafone, tim, ibm? ah! questi sconosciuti!
onde evitare che io passi per l'unico infoiato, ecco un simpatico link:
http://www.theserverside.com/discussions/thread.tss?thread_id=39644
When to use J2EE architecture?
"For example, I might recommend you to go with j2ee if you must build big,
high availability, distributed transactions enabled system.
If what you want to build is a simple bookstore, forget j2ee, go for php. If
you need to build a bookstore that must integrate data from many databases,
maybe external systems (if you don't have the book maybe you can get it from
amazon, and this way you don't turn down a client :-) ) and ensure
transactional integrity across those, I would rather recommend j2ee :-)"
c'era un tale barbone vissuto circa 2000 anni fa, che diceva una che suonava +
o - cosi:
"date a cesare quel che è di cesare", eccetera.
E basta co sti flame inutili eh. Che io ne ho le scatole piene di leggere
strafalcioni, e di dover rispondere per rimediare a queste offese al pudore.
