On Monday 05 September 2005 10:08, Davide Dozza wrote:
Gianluca Turconi wrote:
Davide Dozza wrote:
[...]
La legge non è una scienza che possa dirsi proprio esatta :-)
Sacrilegio!!!! ;-)
Lo sapevo che avresti risposto !!!!!! :-D
Ammettilo, che lo hai fatto apposta per costringere Gianluca a
intervenire ;-)
Piuttosto, me la dai una spiegazione sulla montante dipendenza da
JAVA di OOo 2.0? Non per altro, ma dovermi scaricare il JRE a parte
è una signora rottura.
Ehm... Uhm...
Scelte tecnologiche fatte dal management del progetto. Sembra che gli
sviluppatori ci mettano 1/10 del tempo che ci mettono a sviluppare in
C++
Questa mi fa tanto pensare a cose come la campagna disinformativa "get
the facts"... >;-)
Dato e non concesso che a sviluppare in java ci voglia 1/10 del tempo
che ci vuole a sviluppare in C++, strano che, ad es., in ordine sparso,
- se ne siano accorti solo ora e per anni di sviluppo di SOffice/OOo non
se ne fossero ancora accorti...
- il modo opensource non prema sullo sviluppo del front-end java di GCC
e non sviluppi in java pure KDE, Gnome, Mozilla, perché no, pure il
kernel Linux (ma ROTFLOL...)
- gli altri progetti opensource non facciano affatto altrettanto... ma
non dicevano che java lo conoscono pure i muri e che invece di bravi
programmatori C++ non se ne trovano? >:-D
Ma poi scusa, i programmatori che ieri erano di Star Division e ora sono
sempre loro ma sono targati SUN, come mai ai tempi di SOffice 4 e 5
java lo usavano pochissimo e, se non erro, quasi solo per ciò che
riguardava il modulo browser (sì, OOo 4 e 5 contenevano anche un
browser, anche se di qualità discutibile...), mentre ora infarciscono
OOo di roba scritta in java?
Uno dei motivi che ho sentito è "c'è più gente con know-how su java che
su C++"... a parte che pure questa mi suona come sopra, ma delle due
l'una: o gli sviluppatori di Star Division non conoscevano java, e
allora il know how non è vero che ce l'hanno, oppure lo conoscevano
pure prima e a ragion veduta non lo usavano >;-P
e per di più il codice gira in multipiattaforma con meno problemi.
Mi ci verrebbe da ridere se non sapessi che lo dicono davvero...
Peccato che non solo non è vero: è vero l'esatto contrario!
Il limite più grosso di portabilità di OOo ad oggi è proprio dovuto
all'avere usato così pesantemente java, dato che la JVM SUN supporta
pochissime piattaforme, lasciandone a piedi tantissime, e dato che per
OOo sembra quasi che lo facciano apposta a scrivere codice java
strettamente dipendente da tale JVM... e non farmi dire altro
<sarcasmo>
(Marco stai calmo quando parli di java, che la pressione alta fa male, e
poi lo sanno tutti che java è portabilissimo, leggero come una piuma, e
veloce come una gazzella...)
</sarcasmo>
Detto tra noi, invece di hdbsql si poteva anche scegliere sqlite
come database, per il quale c'era già un driver ODBC ai primi
vagiti nel progetto dba. Boh, io le scelte "tecniche" non le ho mai
capite... :(
HSQLDB è in java.
E diceva un tale che a pensar male si fa peccato ma qualche volta ci si
azzecca >;-)
Piuttosto, la speranza è nell'uso di GCJ che permetterebbe di
compilare il codice Java e quindi non richiederebbe la JRE.
Speranza che è appunto una speranza, peraltro anche di ambito limitato:
che io sappia, chi sta lavorando più intensamente a questa cosa è lo
sviluppatore di Red Hat, che, ovviamente, ha come priorità assoluta la
piattaforma Linux, ma non sono sicuro che ad es. possa produrre
soluzioni che vadano completamente bene anche ai *BSD.
Inoltre, va precisato che, per l'ambiente mswindows, il GCC non è un
compilatore supportato, quindi l'uso di GCJ, che si appoggia appunto a
GCC, temo proprio che non sia una soluzione per la piattaforma
mswindows, che, credo, continuerà a dipendere pesantemente da una VM
proprietaria per poter utilizzare un programma con licenza
opensource...
C'e' una discussione aperta importante con Stallman in questo
momento. Speriamo bene.....
... e Stallman a mio modo di vedere sta dimostrando quanto siano fuori
strada quelli che lo ritengono non pragmatico... ed evito di dire
altro ;-)
Marco Pratesi
In effetti C++ è più stabile di java, avete notato le ultime "leggere"
modifiche al linguaggio che sono state implementate in Java? E
comunque, il collo di bottiglia sono le risorse di cui Java continua ad
essere molto più mangione di C++ in qualsiasi ambiente. Che ci sia una
guerra in atto tra Java e .NET è ovvio, comunque chi cerca prestazioni
e tecniche di software engineering certe e documentate non può
prescindere da C/C++. Sun vuol combattere una battaglia sapendo che
Microsoft è in vantaggio e questo può giustificare certe scelte, però
non si può combattere una battaglia su 2 fronti. Microsoft è ancora in
vantaggio per quello che riguarda l'integrazione di applicazioni con
tecnologia ole e dde e l'automazione delle stesse in ambito MS Windows;
lo stesso livello non è ottenibile in Java (e ahimè lo dice chi di
Microsoft ne farebbe volentieri a meno).