Sebbene la guerra per il controllo del desktop Windows tra .NET e Java sia essenzialmente terminata con la vittoria di .NET, il fronte GNU*/Linux è tuttora aperto; ora che i sorgenti di Java sono stati pubblicati con licenza GPL persino la più intransigente delle distribuzioni può iniziare ad includerlo nei suoi repository, affiancandolo all’osteggiato Mono [*].
KDE, probabilmente, continuerà ad utilizzare i linguaggi supportati dalle QT ( C++ e Java ) ma GNOME? Nonostante ogni release dello “gnomo” apporti novità e miglioramenti rispetto quella precedente prima o poi sarà necessario fare il grande passo e rivedere completamente la struttura del desktop environment ( com’è accaduto con KDE4 ); a quel punto tornerà a scaldarsi la discussione sul linguaggio “ufficiale” da utilizzare in GNOME.
Chi dominerà il futuro desktop libero? Java? Mono? Python? O il buon vecchio C++?
[*] osteggiato da qualche distribuzione / società / utente
[ via OSNews ]
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
j
12 mar 2007 - 10:35 - #1cosa centra python con mono e java? :|
python rimane e credo che non sia in discussione, oltretutto è interpretato…
Quello che (spero) sarà discusso sarà la rimozione dello schifo di mono sostituendolo con java che, tempo forse 1 o 2 anni perderà il suo problema fondamentale: la lentezza (grazie alla community che ora si ritrova x le mani il codice). Problema rimane il fatto che il fondatore dei 2 progetti (gnome e mono) sia il medesimo. mha, vedremo… io, naturalmente, se non si fosse capito: parteggio per java ora che diventerà open e ci parteggiavo (segretamente) anche prima :D
depaloan
12 mar 2007 - 10:48 - #2Ho accennato a Python perchè è stato più volte proposto come linguaggio di default per tutte le applicazioni ed i tool di GNOME
LucaC
12 mar 2007 - 10:49 - #3Potresti indicare la fonte di questa notizia? Grazie.
depaloan
12 mar 2007 - 10:54 - #4Nessuna fonte ma mi pare evidente come il desktop Windows ( e sottolineo desktop ) sia territorio di .NET; anche Java ha una sua parte ma è sicuramente inferiore rispetto a quella di .net
calca
12 mar 2007 - 10:57 - #5in desktop-devel ci sono stata parecchi discussioni su quale sia il linguaggio migliore da utilizzare in un desktop.
alla fine non si è giunti ad una conclusione.
ogni linguaggio ha i suoi vantaggi, il suo ambiato di applicazione.
l’idea che era passata in d-d-l era quella di usare il C avendo poi tutti gli altri linguaggi supportati per gli applicativi.
(in python e mono i tempi di sviluppo sono ridotti rispetto al C)
per java, in gnome ci sono i bindings java-gnome appena riscritti.
il problema vero di java sono le swing: un pessimo toolkit ..
j
12 mar 2007 - 11:23 - #6@LucaC: che fonte ti serve scusa? è PALESE che .NET sia nato con quell’intenzione e che ci sia riuscito… grazie: un FW di casa microsoft su piattaforme microsoft… bello sforzo…
devURandom
12 mar 2007 - 11:24 - #7“il problema vero di java sono le swing: un pessimo toolkit ..”
meno male che esistono le SWT ;)
Emmanuele Bassi
12 mar 2007 - 11:35 - #8riscrivere gnome in un altro linguaggio non ha alcun senso: ci sono milioni di linee di codice, portarle ad un altro linguaggio di programmazione significherebbe anni-uomo di lavoro, nuovi bug, nuovi problemi di performance. impensabile e alquanto stupido. e questo solo nelle applicazioni: nelle librerie l’uso di un linguaggio diverso dal C portebbe alla perdita dei binding e delle performance.
insomma, una riscrittura né per gnome 3.0, né per gnome 4.0, né per gnome 100.0.
ekerazha
12 mar 2007 - 11:40 - #9Java è da poco tempo open-source… mentre Mono lo è sempre stato, C# è un linguaggio superiore a Java, più potente (consente anche una gestione esplicita di codice unmanaged) e più pulito. C# con le GTK# possiede anche una migliore integrazione con GNOME.
malex
12 mar 2007 - 12:06 - #10Obiezione: perché “prima o poi sarà necessario fare il grande passo e rivedere completamente la struttura del desktop environment”? Forse kde ne aveva bisogno, gnome ne ha bisogno?
ossmc
12 mar 2007 - 12:07 - #11…java che, tempo forse 1 o 2 anni perderà il suo problema fondamentale: la lentezza
Non contarci troppo: i problemi della lentezza sono strutturali, non sono difetti implementativi. Per accelerare il linguaggio servono modifiche radicali e l’interruzione della compatibilità retrograda, cosa che non avverrà mai (perchè smetterebbero di funzionare sw java importanti in giro per il mondo).
Emmanuele Bassi
12 mar 2007 - 12:26 - #12@malex:
non penso ce ne sarà bisogno: la piattaforma si evolve in maniera continua, non discreta. gli amici di kde hanno anche il problema del C++, in cui la compatibilità binaria si “rompe” più facilmente - per loro rivedere periodicamente la piattaforma è un’ottimo modo per giustificare rotture di API/ABI.
vincent
12 mar 2007 - 12:40 - #13Per quanto riguarda il futuro del C++ c’è questo documento
usato da Bjarne Stroustrup nel suo “Keynote: C++ 0x Directions and Status”
acrive
12 mar 2007 - 14:26 - #14Sinceramente non è chiaro ne l’articolo e ne i post.. Se parliamo di linguaggi di prog. che dovrebbero integrarsi nell’ambito desktop linux (e chi tra questi dovrebbe avere la meglio) io credo che la strada da percorrere sia Python.
Se non mi sbaglio le Widget gestite da SuperKaramba sotto KDE sono in Python. Quindi non vedo perchè non sfruttare questo linguaggio per amplificare le features di un desktop env, in modo da alleggerire il suo “cuore” e lavorare in maniera modulare…
Se invece si vuole discutere su quale piattaforma basare lo sviluppo di un Desktop Enviroment allora dico ad occhi chiusi il C++. Perchè programmare il “motore” di un desktop env. in Java..? L’esperienza di Looking Glass è percaso valida? .NET??? non conoscendolo bene (sopratutto le possibilità e i confini di Mono e .NET Microsoft) non saprei pronunciarmi.. Ma sembra che questo linguaggio accolga sempre più adepti anche nella parrocchia del freesoftware, vuol dire quindi che qualcosa di buono c’è l’ha per davvero!:)… Concludo dicendo che per me il futuro dovrebbe essere modulare anche per il Desktop. Env. Magari con un cuore in C e i fronzoli in Python…
CRV§ADER//KY
12 mar 2007 - 15:42 - #15“Chi dominerà il futuro desktop libero? Java? Mono? Python? O il buon vecchio C++?”
per quanto detesti, dal punto di vista stilistico e della robustezza, il C++, non ho alcun dubbio: vincerà il C++, perché tutti gli altri linguaggi richiedono interpreti e/o liberie pesanti come mattoni.
ice
12 mar 2007 - 17:41 - #16.NET ha vinto in ambito MS Windows lo dimostra il fatto che addirittura i tool integrati nei driver ATI richiedano .NET2.0
non faccio priu il programmatore da 1 anno, ma ho odiato i meccanismi perversi cui sono stati costretti in Java per mantenere la compatibilita’ col passato (un po’ come quando la Chiesa ha dovuto ammmettere che era la terra a girare intorno al sole…..capovolgendo l’interpretatione di quel passaggio del vecchio testamento….con buona pace del buon vecchio Galileo….)
detto questo Java dovra diventare un vero framework aperto a piu linguaggi (pur mantenedone uno di elezione)
Nascera’ a questo punto la necessita’ di chiamare in modo diverso il framework dal linguaggio di programmazione (in M$ l’hanno capito e hanno aggiunto un bel # a tutti i linguaggi di programmazione supportati dal framework e chiamto .NET il framework stesso)
sirus
12 mar 2007 - 22:01 - #17Per quanto mi riguarda ritengo che Mono e Java non siano piattaforme valide per la base di un DE, il C++ rimane la scelta più logica, e sinceramente continuo a non capire l’ostinazione degli sviluppatori di GNOME di lavorare in C.
L’utilizzo del C++ è logico parlando di core e API, quindi GTK comprese. Oltre direi che un linguaggio vale l’altro, Python mi piace, C# è IMHO superiore a Java (allo stato attuale)…
Emmanuele Bassi
15 mar 2007 - 22:58 - #18@sirus
scrivere binding per altri linguaggi partendo da librerie in C++ non è quasi mai possibile (o consigliabile). in più, mantenere la compatibilità binaria in C++ è quasi impossibile. ergo, il C come linguaggio di base per le librerie è la scelta più sicura, logic e ovvia.
per la applicazioni, al contrario, si può usare veramente di tutto.