Autor: NeuraL Data: Dla: hackmeeting Temat: Re: [Hackmeeting] censura di piratebay e chiusura di colombo bt
On Sunday 24 August 2008, mikro wrote: > Tuesday 19 August 2008, lobo ha scritto:
> > e per design e' piu' facile da imparare/debuggare/usare - forse
> > per questo chi non sa codare ci si avvicina e fa disastri.
>
> Non ti sei mai perso in una eccezione java, eh???
> 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, di cosa sia un puntatore o di come vivere senza un garbage
> collector...e questo ti porterà inesorabilmente a fare cagate *solo
> diverse* da quelle fatte in C o C++
OOOhh ma ancora mi state a confronta' java col C, C++??? :-))
Gli anni '90 hanno chiamato... e rivogliono indietro le loro flame
war! ;)
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.
Ha i suoi pregi in questo e, per fare determinate cose (CON LE DOVUTE
CAUTELE), va piu' che bene come scelta... mentre il C/C++
risulterebbero insensati.
La diattriba e' nata perche' fa andare lento freenet :)
E' lento perche' astrae innumerevoli concetti di basso livello in un
linguaggio semplificato (anche se il termine che mi veniva
era "semplicistico") dove tutto si fa in un solo modo, al di fuori del
controllo del programmatore.
Questo ha un costo sulle prestazioni.
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. Il problema dal punto di vista del programmatore java e' che
molte cose non si possono fare (cose tipo i template stile c++) e
quindi si ricade nelle implementazioni opinabili anche per limitazioni
del linguaggio (ma questo non lo ammetteranno mai :)
Infatti un linguaggio che produce codice indiretto (poco tracciabile)
causa facilmente troppi accessi "compulsivi" alla memoria e questo fa
sclerare le pipeline del processore.
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.
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.
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.
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.
> <troll>comunque java è una merda</troll>
mettiamola cosi':
JAVA E' MERDAVIGLIOSO! :-)
--
... "Nel tempo dell'Inganno Universale, dire la verita' e' un atto
rivoluzionario" - George Orwell
