GNOME 3.0 uscirà nel 2010
In News, Opinioni il 10/07/08 @ 18:42 trackback
Da prime attendibili indiscrezioni, la fantomatica versione 3 di GNOME potrebbe uscire al posto della 2.30, e cioè, calcolando il ciclo di sviluppo e se non ci saranno smentite o variazioni e salti di versione, nella prima metà del 2010. Nei prossimi due anni si dovrebbe dunque assistere al tanto atteso balzo in avanti che per le informazioni disponibili adesso si può ben definire “balzo nel buio”.
Quello che tutti a questo punto cominceranno a chiedersi è se il progetto GNOME sarà in grado di stilare un percorso credibile, quali saranno le principali aree di intervento e soprattutto se sarà in grado di aderirvi. Le prime personalissime aree di curiosità che mi vengono in mente riguardano:
- L’integrazione/interazione di Clutter con GTK+ 3 – Le GTK+ potrebbero solo beneficiare dall’innesto di modernità offerto da Clutter, che oltretutto permetterebbe interfacce meno legnose, così tipicamente GNOME 2.
- L’uscita dal bozzolo di GNOME Online Desktop – Spero che Red Hat riesca a far recepire l’importanza e la lungimiranza dell’Online Desktop al resto dei capoccia di GNOME, perché Google sta molto investendo sulle stesse (vecchie, ma nuove) idee.
- L’affaire Mono/Java – Ovviamente se ad un certo punto ci sarà da scegliere tra Mono e Java propendo per Sun/Java piuttosto che Microsoft/.NET, non riesco a trovare alcun motivo per cui qualcuno dovrebbe fare diversamente. Spero solo che non si continui con l’ambiguità, che ha arrecato gravi danni all’immagine di GNOME.
- Un po’ di sana dittatura in fatto di GNOME Mobile – Qui la competizione sarà altrettanto serrata e diretta: con l’attenzione di Google, Nokia e tutti gli altri incentrata sul modo di sfruttare a proprio vantaggio la situazione, il rischio è di ritrovarsi con troppi dialetti di GNOME.
Ovviamente ci sarà ben altro, e credo che uscirà allo scoperto con il tempo. Il resto però sono dettagli: non mi interessa (e spero non interessi neanche a voi) sapere se la la fottuta trasparenza dei menu sarà al 95% o se i desktop virtuali saranno mappati su un cubo o su un dada¹.
La transizione da GNOME 2 a GNOME 3 dovrebbe essere pianificata in modo da non lasciare tutti spiazzati come sta succedendo per KDE 4. E a proposito di KDE 4, ne giro di un paio di versioni Plasma finirà il suo primo attuale pesantissimo ciclo di sviluppo e sarà pronto e definito, così come tutto l’insieme di framework ormai in cantiere da anni. GNOME 3 quindi si troverà di fronte un’alternativa già abbondantemente rodata e stabile…
Oh che bello, si ricomincia! ;)
–
[¹] Spero che questa stronzata non la capisca nessuno
|
|
— Pagine forse correlate:
Commenti »
[1] o su futu.
manca ancora almeno un 9,5% del market share ad arrivare al famoso 10 by 10… GNOME 3 magari dovrebbe velocizzarsi un po’.
solo a me spaventa?
http://wordle.net/gallery/wrdl/61575/Pollycoke
/OT mm Gnome al Cantalupo e’ bellissimo… :P
tornando /IT come hai esposto benissimo Felipe i punti in cui GNOME come comunita’ e ambiente desktop integrato e’ chiamato a rispondere, come strategie e modalita’ operative, sono tante. Due anni sinceramente sono molti, sia per immaginare quanto e quale lavoro sara’ possibile apportare al progetto, ma anche e soprattutto per immaginare il distacco che sara’ guadagnato nel mentre da KDE come sviluppo e diffusione.
Staremo a vedere.
Ad ogni modo continuare ad avere scelta, e scelta di qualita’, non ha prezzo.
Purtroppo l’ho capita…
Il problema con GNOME è la natura policentrica del progetto. La vera sfida, secondo me, non è quella di stilare un percorso (credibile? KDE 4 non mi sembra ancora tale, il 4.1 certamente lo è), ma quello di coordinare le varie teste dell’idra.
Un altro punto che tu hai segnalato, GNOME imparerà dagli errori non marginali di “roadmap” che KDE ha “scatenato” (definizione ingiusta, ma la maggioranza degli utenti KDE4 la pensa così)?
Si perderà per lungo tempo la caratteristica centrale di GNOME, la stabilità. Una roadmap così spinta crea confusione nei primi rilasci.
Speriamo che Canonical tenga nel 2010 delle versioni separate fino a quando il piedone non riuscirà a reggersi da solo.
Mono?!?!? Java?!?!? Stiamo scherzando?!?!? Ci sono alternative migliori… ( leggasi Python ( giudizio totalmente di parte -_-’ ) )
Python non ci arriva neanche alla potenza di una piattaforma del tipo NET come il Framework .NET di Microsoft o Java di Sun, personalmente credo sia inutile utilizzare Mono che non è neanche al passo con l’ultima versione del Framework; Mono è giusto per il testing, PER ORA, almeno finché non raggiungerà una piena compatibilità con la versione 3.5 o la futura 4.0.
Come dice Felipe anche io opterei per Java, si perde un po’ in prestazione, perché in effetti è pesantuccio (basta avere abbastanza RAM, e al giorno d’oggi non credo sia un problema), ma vogliamo mettere la sicurezza, la flessibilità, la potenza di una piattaforma così vasta al servizio di GNOME?
Sun Microsystem già ci ha provato moddando GNOME e creando un neo-JavaEnterpriseDesktop che a mio parere è molto buono e integrato nel Solaris Developers Edition.
Saluti
hawake
Per dirla terra terra, l’interprete Python “prende colpi” in quanto a performance dalla JVM di Sun. Rispetto alla piattaforma .NET e al suo compilatore JIT non so dirti, non ho mai avuto il privilegio di programmare in C#. Ciò che però trascuri è la maggiore “produttività” del linguaggio Python: il Java di Sun ha una API terribile. Per non parlare di quanto sia “prolisso”: 100 righe di codice Java spesso possono corrispondere a una decina di righe di codice nella sua controparte Python. Per Mono, ripeto, non so dirti niente a riguardo, ma dubito che possa vantare la compattezza e l’immediatezza del Python. Di cicli di CPU tutti ne dispongono in abbondanza. E se proprio sono quelli che ci interessano neanche si opta per linguaggi interpretati. La vera risorsa che veramente scarseggia è la produttività dei programmatori. Ed è su questo fronte che il Python riesce a dare il meglio di se. E poi, per dirla tutta, c’è poco da dire anche sul fronte delle performance: il Python è tremendamente semplice da “estendere”: per quasi ogni libreria C esistono bindings Python, scritti ovviamente in C nativo, che di fatto eliminano quasi totalmente qualsiasi perdita di performance. Ho odiato il Java nei miei corsi di Programmazione a Oggetti, e dubito che uno standard di casa Microsoft porti qualcosa di buono in un contesto open ( chiunque è libero di smentirmi :) ). Se si deve scegliere un linguaggio interpretato che contribuisca a far crescere la terza reincarnazione dello gnome bene e in fretta il Python è l’unica alternativa :)
Vala e Genie non sarebbero brutti linguaggi per GNOME III: velocita’ in esecuzione di C e sintassi di C# o Python. Genie e’ figlio gemello di Vala.
live.gnome.org/Vala di Jürg Billeter
live.gnome.org/Genie di Jamie McCracken
Il mio blog è chiuso.
Non sono d’accordo sul fatto che Java abbia una API terribile.
Forse a primo impatto le classi non sono di immediate al 100%, ma una volta imparate si scopre che sono molto potenti e versatili (anche troppo).
La documentazione c’è ed è fatta molto bene e poi il linguaggio è un *bel* linguaggio.
Poi ovviamente ognuno ha i suoi gusti, questo è solo il mio…
nel 2010 sarò vecchio
tanto sara’ sempre usabilmente indietro.
@hawake
per quanto riguarda le prestazioni quello che hai detto potrebbe anche essere vero se compari .NET di microsoft con Java (anche se poi hanno caratteristiche simili in quanto a prestazioni), ma se prendiamo Mono per il confronto l’ago della bilancia pende decisamente verso Java.
ma finchè esisterà novell non credo che GNOME possa liberarsi facilmente di mono..
Basta un semplice esempio di lettura da file e stampa su schermo per dare una vaga idea di cosa intendo per API terribile
public class Foo
{
public static void main( String args[] )
{
File f = new File( “foo.txt” );
FileInputStream fis = new FileInputStream( f );
FileInputStreamReader fisr = …. bla bla bla…. è tardi e non ho voglia di proseguire. -_-” Mancano ancora ben non meno di 5 righe di codice per terminare la classe. Ecco il corrispondente Python.
f = open(”foo.txt”, “r”):
for line in f:
print line
fclose(f)
Direi che non c’è paragone. L’API del Java è una “buona” API, nel senso che mette a disposizione del programmatore tutto il necessario: Database, interfacce grafiche, programmazione distribuita e concorrente. E’ inoltre ottimamente documentata. Ma, ritornando all’esempio di sopra, è quasi ridicolo dover istanziare 3-4 classi e scrivere una decina di righe di codice per una operazione così semplice quanto basilare e frequente come può essere l’I/O. Un programmatore Java non vive senza la documentazione del JDK. Per un programmatore Python invece sono sufficienti un paio di giorni per memorizzare buona parte dei componenti base dell’API Python e riutilizzarli senza quasi mai riferirsi alla documentazione ufficiale.
@lollo
Poi ovviamente ognuno ha i suoi gusti, questo è solo il mio…
Io ovviamente sono per il Python ;) Riconosco i suoi limiti ( performance, multithreading… ) ma penso che all’interno di un progetto come gnome possa fare tanto :)
“L’integrazione/interazione di Clutter con GTK+ 3 – Le GTK+ potrebbero solo beneficiare dall’innesto di modernità offerto da Clutter, che oltretutto permetterebbe interfacce meno legnose, così tipicamente GNOME 2.”
Questo è quasi sicuro.
“L’uscita dal bozzolo di GNOME Online Desktop – Spero che Red Hat riesca a far recepire l’importanza e la lungimiranza dell’Online Desktop al resto dei capoccia di GNOME, perché Google sta molto investendo sulle stesse (vecchie, ma nuove) idee.”
Durante gli ultimi giorni si è parlato molto di integrare online desktop, telepathy e soylent. Speriamo di tirarne fuori qualcosa di buono e utile.
“L’affaire Mono/Java – Ovviamente se ad un certo punto ci sarà da scegliere tra Mono e Java propendo per Sun/Java piuttosto che Microsoft/.NET, non riesco a trovare alcun motivo per cui qualcuno dovrebbe fare diversamente. Spero solo che non si continui con l’ambiguità, che ha arrecato gravi danni all’immagine di GNOME.”
No, non si sceglierà. Anzi la linea è di essere meno restrittivi e di non considerare un problema l’avere un problema avere tecnologie concorrenti, ad esempio rhythmbox e banshee, poi le distro e gli utenti saranno liberi di fare le loro scelte.
Evvai anche gnome nello stesso errore di kde
scriviamo un altro toolkit così dobbiamo riscrivere le nostre app
EVVIVA!!!!
:(
@19
…senza parole, veramente…
@ 19
vedo che quindi non sono l’unico ad aver paura…
ragazzi, tanti di voi hanno la smania del desktop avanzato e futuristico come kde, ma gnome in realtà lo è di piu, è realmente stabile e non viene rilasciato come stable quando ancora è in fase di scrittura -.-
insomma è bello anche perchè si muove lentamente e senza eccedere come fanno altri DE…
ad ogni modo la roadmap ha sempre previsto il rilascio della versione 2.30 ad aprile 2010, se fate un paio di calcoli coincide alla perfezione… quindi spero non facciano davvero come con kde, che per diversi aspetti ha smantellato un ottimo desktop enviroment… vedremo che succede, io intanto mi tengo stretta la mia 2.20, ancora non mi va di compilare la 2.22, magari passo direttamente alla 2.24 :)
Insomma avremo relativamente presto
- un post “Passo a GNOME 3, ma voi non imitatemi”,
in cui KDE4 sarà LIQUIDATO con una riga, nella storia dei desktop felipeschi
- la notazione GNOME TRE, per indicare la serie TRE
- la versione GNOME di SEIGO
- i GNOMOIDI, che susciteranno molte discussioni,
insieme all’abolizione delle icone dal desktop
- il temibile port per GNOME 3 di nepomuk,
perché anche GNOME TRE deve essere semantico
- un post “Idioti vs GNOME”
Mi sembra tutto molto probabile, che ne dite?
Proprio vero: si ricomincia! ;)
In realtà vi siete dimenticati del cantalupo di Felipe, che potrebbe giocare un ruolo essenziale nei piani di sviluppo del progetto!
Io voglio solo dire che ho avuto una soffiata: nella prossima versione di Gnome 3 non useranno più il cubo (ormai ce l’hanno tutti)…
Vogliono passare al TESSERATTO!
AHAHAHAHAH
@mUogoro:
Sarà anche vero che puoi scrivere di meno con Python, ma:
1. con Java puoi fare di tutto e ripeto di tutto, con Python no
2. Java è 100 volte più veloce di Python e lo dimostrano i test (soprattutto se si usa la versione 1.6 della JVM), vedere per credere: http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
(3. personale) io trovo molto più comprensibile la sintassi di Java che di Python
Quindi appoggio pienamente la scelta di “integrare” Gnome con Java.
Saluti.
@mUogoro
le API di Java sono fatte benissimo, difatti l’esempio che hai portato è un ottimo esempio di programmazione a oggetti
@Marco
puoi sempre fare affidamento su ncurses, quelle non cambiano mai -_-
voto Java più documentato e sicuro :)
Riguardo ai linguaggi e bindings, io da buon esperto amatoriale sono abbastanza agnostico, anche se preferirei java per la velocità e il relativo basso uso di risorse, sarebbe altresì possibile usare qualsiasi linguaggio che viene compilato sul runtime java, vedi python, ruby, groovy, scala ecc.
mUogoro:
Dipende dall’uso che fai del file: Quanti motori DB sono scritti in 100% java e quanti in python (un paio sperimentali)? Premesso che puoi scrivere FileInputStream fis = new FileInputStream(”nomefile”) direttamente!
Anche io alle mia prime armi di java pensavo che fosse uno spreco di linee, poi ho assimilato il giusto punto di vista ed ho capito che si dovrebbe programmare così sempre. Neanche le api di .NET raggiungono lo stesso livello di potenza e flessibilità e “danno troppe cose per scontate” per i miei gusti.
Poche linee in più incapsulate bene non sono tutto questo ostacolo che puoi pensare quando vedi i tutorial “scrivi il tuo primo editor di testo in due minuti / il tuo primo frontend web verso un DB in 3 minuti”. Il bello è che oltre quello, in quel modo lì, non puoi andare o non hai la stessa “felicità”.
Certo che alcune mode tipo spalare merda sul java non passano mai eh
At Reload:
Quoto!!
Permettetemi di essere un po’…come dire…pessimista. Come fanno a mettere nella roadmap uno Gnome 3 fra meno di due anni quando ancora non hanno iniziato a riscrivere le GTK+ e nel nuovo DE non sanno nemmeno cosa fare? Qualcuno nel progetto Gnome ha una visione di come dovrebbe essere il futuro desktop per guidare tutti in un’unica direzione? Al momento mi sembra che brancolino nel buio, il che non è una buona cosa. Prima che abbiano completato una minima discussione su cosa fare passeranno almeno alcuni mesi, mesi preziosissimi che non potranno essere utilizzati per sviluppare software.
Riscrivere un DE da zero non è uno scherzo, in KDE ne sanno qualcosa, davvero pensano di riuscirci in così poco tempo? Questo a meno che non sia affatto nelle loro intenzioni riscriverlo da zero. Ma allora farebbero una 2.30 e non una 3.0!
@Guada
1.con Java puoi fare di tutto e ripeto di tutto, con Python no
2. Java è 100 volte più veloce di Python
(3. personale) io trovo molto più comprensibile la sintassi di Java che di Python
Il punto 1 è una grandissima cazzata ( senza offesa :) ). Sul punto 3 concordo pienamente, nel senso che concordo il fatto che ognugno abbia le proprie preferenze. Ognugno ha i suoi gusti, :) Sul punto 2, diciamo che la JVM è molto più veloce dell’interprete Python. Su quest’ultimo pesano tantissimo la tipizzazione dinamica, i dictionary lookup e l’implementazione delle iterazioni. Se però la velocità la misuriamo in termini di produttività e non di cicli di CPU, come ho accennato sopra, il Python non ha eguali :)
@Reload
Certo che alcune mode tipo spalare merda sul java non passano mai eh
Sarà pure una moda ( -_-’ ). Sarà pure spalare merda. L’importante è spararla dando le motivazioni per il quale l’ho spalata, cosa che penso di aver fatto. :)
@mazzulatore
Premesso che puoi scrivere FileInputStream fis = new FileInputStream(”nomefile”) direttamente!
Vero. Me lo stava facendo notare un amico. Il mio codice Java non rappresentava un valido esempio. Pardon. :( Sul basso uso di risorse, quello che Java (o meglio la JVM) guadagno in termini di cpu lo perde in termini di memoria ciucciata. Vabbè, ora i PC vengono venduti con a bordo mediamente 4giga di ram, quindi non posso neanche definirlo un punto a sfavore del java :) Tirando le somme: io ho programmato in Java per vari corsi universitari, e in Python al lavoro. E una volta che si comincia col Python, indietro non si torna :) Ma questo penso sia un fattore personale. Provate comunque a riscrivere qualche vostro piccolo programmino Java in Python e capirete… ;) Nel contesto di gnome 3 potrebbe avere un ruolo fondamentale. Penso che un’applicazione cresca molto più velocemente se sviluppata in Python, accelerando il processo innovativo che dovrebbe comportare il salto di versione.
asd… anche tu cominci a stufarti della moda KDE4?
Ragazzi, non facciamo come con KDE 4. Non mettiamo carne al fuoco più di quanto in verità ce ne sia. Al momento c’è in atto una seria discussione su un piano di rilascio e sviluppo di Gnome 3 come era facilmente prevedibile una volta che il piano delle Gtk 3 fosse stato definito. Tutto il resto sono nostre seghe mentali.
Già sto incominciando a leggere deliri dell’altro mondo.
gp
@35: sono d’accordo con te.
Mi piacerebbe inoltre sapere quanti di coloro che hanno commentato sono andati sul sito di gnome, hanno navigato un pochetto, sono arrivati alla pagina dove si parla di gnome 3 e letto se c’è l’intenzione di riscrivere tutto o fare diversamente.
Le intenzioni sono scritte molto chiaramente (per chi mastica un pò di inglese).
Se volete conoscerle cominciate a darvi da fare.
@matteo
Quale pagina? Una di queste?
http://live.gnome.org/ThreePointZero
http://live.gnome.org/RoadMap/FromThreePointZero
Se sono queste, controllerei la data di ultima modifica.
Ma invece di avere le visioni
fare un DE che fornisca:
tutti i servizi necessari
file-manager completo
utilità minimali (gedit gcalc)
toolkit grafico compatibile + uno avanzato o integrati
toolkit web per programmatori integrato
che funzioni bene
e lasciare programmi vari browser posta IM interfacce masterizzatori e troiate varie al proprio destino (sviluppo a gruppi esterni) quindi non legati ai rilasci del DE,
non sarebbe meno dispersivo (meno bug) e più efficace?
Qui bisogna semplificare non incasinare aumentando la complessità del tutto.
IMHO
Oramai GNOME è un desktop morto
mi sono disintossicato da questa svaccata il giorno che ho comprato un fiammante portatile apple
con OSX Leopard sopra.
Gnome fa cagare sfido io ha lavorare professionalmente su un desktop con il file manager piu brutto della storia un toolkit scritto da babbuini fissati con il c le librerie astratte multimediali lente e piene di memory leak che non sanno sfruttare a dovere manco le schede video accellerate.
senza parlare del mito dell’usabilità un mito appunto perchè con quel desktop ci puoi fare solo una cosa aprire firefox e cazzeggiare tutto il giorno su internet.
@mUogoro
1. Java è presente nei cellulari di fascia bassa (non bassissima ovviamente, almeno una cpu e poca ram libera), qualsiasi altra piattaforma si basa su symbian o equivalenti o su java stesso ;) e dove le risorse sono più vicine a quelle di un pc. Questo la dice lunga sul mito di java come esoso di memoria. Vero è che più c’è ram e meno viene usato il GC e puoi usare strategie di GC più efficienti.
2. Python o Ruby sono linguaggi meno prolissi di java, e questo può risultare migliore in alcuni contesti ma ora il discorso è diverso; se contiamo gnome e il suo futuro ecosistema di applicazioni:
Python va benissimo per Gnome, Gnome dipenderà dall’interprete/VM python + Bindings per python delle Gnome API.
Ruby va benissimo per Gnome, Gnome dipenderà anche dall’interprete/VM Ruby + Bindings per ruby delle Gnome API.
Java va benissimo per Gnome, Gnome dipenderà dall’interprete/VM Java + Bindings per java delle Gnome API.
Mono va benissimo per Gnome, Gnome dipenderà dall’interprete/VM Mono + Bindings per mono delle Gnome API.
escludendo Mono, il cui JIT è immensamente più lento di java hotspot e non credo che in futuro si possano fare miracoli:
Java va benissimo per Gnome, Gnome dipenderà dall’interprete/VM Java + Bindings per java delle Gnome API.
Python va benissimo per Gnome, Gnome dipenderà da jython (opzionale se l’applicazione è precompilata in java)
Ruby va benissimo per Gnome, Gnome dipenderà da jRuby (idem, opzionale)
Groovy
Scala
.
.
.
Lo scenario si delinea molto più gestibile di come è adesso che si danno le martellate sugli zebedei.
Evvai col troll!
Ma guardatevi poi vi lamentate se la gente comune snobba GNOME
il 90% delle discussioni era sul tipo di framework da adottare a nessuno è venuto in mente che oltre al framework ci deve essere un toolkit grafico al passo coi tempi.
gtk allo stato attuale è un aborto la gente sta ripiegando sulle webapps proprio perchè sono 100 volte piu espressive delle controparte gnomara.
clutter è un pagliativo un gestore di scene vettoriale e con i controcazzi esiste gia javafx / flash / silverlight.
senza parlare di apple che lei ha addirittura un composer 3d punta e clikka a portata di utonto.
il resto sono solo pagliacciate che servono a giustificare il lavoro inutile che stanno portando avanti da ormai troppo tempo.
@mUogoro
in realtà l’input di java è volutamente cosi!Pensi che non abbiano pensato a fare cose tipo python che con una riga ti prendi tutto?In realtà è stato strutturato appositamente per aderire al pattern decorator,per avere flessibilità e permettere il riutilizzo delle classi ed evitare la duplicazione del codice.
Certo se poi arrivano bande di presunti programmatori che non hanno minima conoscenza di ingegneria del software quello è un altro discorso,c’è anche il visual basic allora! ;)
Senza nulla togliere a python che reputo un ottimo linguaggio,purtroppo non ho proprio tempo per dedicarmici a pieno alla sua scoperta!
il grosso problema di gnome è che e scritto in C
a me gnome piace cosi’ com’e’.
certo che non avere un DE funzionante completamente in 3D nel 2010 e’ un po’ triste, inutile dire che sono inezie, ormai sono indispensabili. pensate a dei computer con cpu a quattro core e 4 giga di ram come requisiti minimi, senza pensare alle schede video potentissime, possibile che una scrivania tipo Looking Glass non serva da spunto per trasformare Gnome in quella che ormai e’ l’evoluzione naturale dei DE?
aspettando la realta’ virtuale in stile matrix :)
@43:
> il grosso problema di gnome è che e scritto in C
Sante parole. O meglio gtk 2 scritte in C che per stare al passo si sono andati ad ingarbugliare la vita facendo una via di mezzo tra C e linguaggi orientati ad oggetti. Da mal di testa leggere quei codici.
Circa quanto detto da matteo nel post 41: anche se non condivido in pieno quanto ha detto, per certi versi, nella sostanza ha in parte ragione. E lo dico da utente Gnome.
Ad ogni modo, tornando in topic…non scaldiamoci inutilmente per un qualcosa che ancora non si sa. Diamo tempo al tempo. Al momento qualsiasi cosa si dice rientra nel campo delle seghe mentali.
gp
si può scaricare la presentazione su GTK al GAUDEC qui http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf
particolarmente interessante la slide 34
Problems with GTK+ 2.x
• GTK+ 2.x considered a dead-end
• Large scale refactoring impossible
• Maintainance very hard
• This affects ALL GTK+ applications
questo può significare solo una cosa… serve un’iniezione di programmazione a oggetti in GTK, tentare di programmare a oggetti con un linguaggio che non supporta gli oggetti non è il massimo della vita.
spero che gli sviluppatori prendano in seria considerazione l’ipotesi di cambiare linguaggio
Passare al C++ è chiaramente una cosa che va decisa subito.
Ogni mese trascorso è un mese perso.
@47,@48:
concordo!!!
gp
ps: grazie per la presentazione…io ne avevo reperita una ma era incompleta.
« Dada non significa nulla. »
Corsi e ricorsi storici. Anche KDE 4 si sta scontrando con qualcosa di già rodato e stabile, ovvero Gnome 2. E, anche se da un paio di gg sono passato a KDE4, trovo che Gnome sia la scelta indicata per tutti quanti: molto più veloce, terribilmente più stabile e, perchè no, più elegante (anche perchè privo di artefatti, a differenza del pur bello e sobrio Kwin). Inoltre software come OOo oppure Firefox sono molto meglio integrati in Gnome: mica pizza e fichi!
PS: [1] «Dio e il mio spazzolino sono Dada»
@ 51
sul piu veloce credo si possa discutere, io non ho ancora avuto la (s?)fortuna di provare la versione 4 di kde, ma fino alla 3.x era piu veloce di gnome, DE che utilizzo anche io :)
Ancora due anni di attesa, un po’ troppi credo.
@matteo
fondamentalmente quoto in toto.
io uso lunux slackware sin dalla versione 3.4 per i miei server, ma se qualcuno mi dice di usare linux desktop mi faccio solo una gran risata.
inutile girarci troppo attorno: il desktop su linux e’ indietro di 50 anni rispetto a win e di almeno 100 rispetto a osx, soprattutto per tante piccole sfumature piu’ che per un problema di sostanza generale.
inoltre, l’umiliazione ricevuta di osx: a un certo punto quasi sembrava che non fosse possibile tirare fuori un desktop decente in ambito *nix/bsd e… voila’, arriva osx, facendo in due anni quello che kde+gnome non riescono a fare assieme da 10 e passa anni.
a linux desktop ho rinunciato da tempo.
@luca
ma che stai a di? ma de che?
punti di vista, questi sconosciuti …
Colpa del C, colpa di GObject…ma lo sapete che anche le QT hann l’ecquivalente di Gobject nonostante siano scritte in C++? :°D
Tutti programmatori della domenica, eh?
matteo perchè non mi fai qualche esempio pratico in cosa le gtk sono inferiori rispetto ad altri framework? Essì perchè parli parli…ma mancano i fatti :)
luca cos’ha Mac OS X che KDE/GNOME non hanno? Finder? :°D Quel Finder che tutti da anni aspettano che venga riscritto? :°D
Oh e a pensare che matteo è appena passato ad un Mac, e trova fenomenale Finder rispetto a Nautilus…mi chiedo in cosa …nel fatto che con GVFS Nautilus non si blocca più come fa tutt’oggi FInder?
Mi sembra di stare sognando
gente che sostiene che java sia + veloce di python portando come tesi test assurdi fatti su pezzi di codice riscritto in vari linguaggi, cosa per altro assurda ogni linguaggio ha il suo stile e se lo usi le performance sono buone anche in python, prova a scrivere in java procedurale poi vedi quanto e’ veloce.
il problema del multithreading del python e’ stato risolto con l’introduzione di pyprocessing e per quanto riguarda le cose che non riesci a fare in python la domanda e’
QUALI ?
please non gettate fuffa su python just for the sake of it
ritiro tutto quello che ho detto qui c’e’ un flame in atto a cui non voglio partecipare (uffa non si possono cancellare i commenti (o sì ?))
Lasciatemi capire… un’applicazione tipo OO può essere presa d’esempio come integrazione JAVA+GTK? e emesene può essere presa d’esempio per python+GTK?
Cerchiamo di essere meno virtuali e più reali… Anche perché per interfaccia OO non è perfettamente integrato con le GTK.. almeno rispetto a programmi gtk tipo emesene.. Cmq voglio essere smentito :D
Ciao, non scrivo quasi mai qui, ma leggo sempre… lasciatemi dire che certi benchmark sulla velocita’ dei linguaggi lasciano veramente il tempo che trovano: un conto sono i benchmark fatti su codice fatto ad-hoc per mettere in luce un certo linguaggio, un altro sono le applicazioni reali. Addirittura nel benchmark linkato sopra risulta che C++ sia piu’ lento di Java?!? Quando C++ raggiunge e supera in prestazioni anche FORTRAN con l’ausilio della programmazione generica (vedi librerie Blitz++ vs. BLAS proprietario INTEL)…
I programmi Python scritti bene non hanno nulla da invidiare, quanto a prestazioni, ai cugini scritti in Java, anzi spesso questi ultimi appaiono lenti e pesanti rispetto ai colleghi Python, al punto che Python e’ utilizzato anche in ambiti in cui le prestazioni sono fondamentali: ad esempio sono scritti col pitone i demoni MPD della libreria MPICH2:
http://www.mcs.anl.gov/research/projects/mpich2/
che e’ l’implementazione del protocollo MPI-2 (calcolo parallelo ad altissime prestazioni) dei laboratori Argonne (il nome supercomputer BlueGene dice nulla?).
Per il resto dico solo che sto’ per formattare il mio macbook perche’ trovo finder insopportabile e non vedo l’ora di piazzargli una Gentoo con gnome! :D
[...] pollycoke.net, qui. No responses to “GNOME 3.0 uscirà nel [...]
Masturbarsi con i benchmark prestazionali dei linguaggi di programmazione è un esercizio di “celodurismo”
Gli aspetti da valutare nella scelta di un framework devono essere ben altri. Grazie a dio le prestazioni *nell’utilizzo generico* non sono più così importanti (grazie Moore). Longevità, stabilità delle API, documentazione disponibile, supporto, diffusione, possibilià di interagire con altri framework/linguaggi, questi dovrebbero essere i parametri da tenere a mente.
@58
“Mi sembra di stare sognando
gente che sostiene che java sia + veloce di python portando come tesi test assurdi fatti su pezzi di codice riscritto in vari linguaggi”
Chi ci lavora o li ha provati abbastanza sa che java è *molto* più veloce di python, guarda, lo noti anche senza strumenti di misura…si vede proprio.
A chi poi dice che il multithreading di python è come quello di java invito a scrivere un programma nei due linguaggi che gestisca 100 thread e poi vediamo se i due programmi sono equivalenti ( a livello di tempi di esecuzione ). Per i programmini con 1 o 2 thread python va anche bene e la differenza con java non la vedi, ma per applicazioni complesse python è *inusabile*. Prova a scrivere un’ applicazione multi-tier in python .
Java di contro richiede più tempo dedicato alla programmazione, e quindi richiede sforzi maggiori ai programmatori allungando i tempi di sviluppo. Però , essendo un linguaggio fortemente tipizzato permette di scrivere codice più corretto, o quantomeno ti evita molti bug di programmazione, che il python, lasciandoti molta “mano libera” ti induce a fare.
Io penso che ogni linguaggio abbia un proprio target, considero python come eccellente linguaggio di scripting, ottimo per programmini di installazione o di gestione configurazioni, ma per quanto mi riguarda si ferma qui, con java o .net andiamo già su altri livelli di programmazione.
senza flame please;-)
@sevy72
se siamo ancora al “python non e` fortemente tipizzato” buonanotte.
Come se in java in applicazioni anche banali non piovessero cast come in una tempesta tropicale
@65
infatti le piccole app conviene farle in python, scrivi 4 righe e ti sbrighi subito,
ma se vuoi fare cose serie allora …. devi andare altrove…
@sevy72
Vabbeh.
@CiccioPasticcio:
>Colpa del C, colpa di GObject…ma lo sapete che anche le QT hann l’ecquivalente di Gobject
>nonostante siano scritte in C++? :°D
>
E dunque? Non è forse questo il nocciolo della situazione? Applicare un design pattern tipico di un linguaggio orientato ad oggetti su un linguaggio che ne è il suo esatto opposto. Che se pur potendoci, in parte riuscire, non potrà mai essere la stessa cosa. Rischi di aumentarne la complessità e quindi tutto quello che ne consegue.
Io penso che se vuoi adottare un certo design pattern devi utilizzare il linguaggio che più si accosta a quel tipo di programmazione. Non mi sognerei mai di usare Java per scrivere codice procedurale.
>Tutti programmatori della domenica, eh?
Ecco, il giustiziere di turno.
Io non capisco perché sbeffeggiare chi scrive opinioni diverse e modi di vedere diversi.
gp
e cmq da quello che si è capito gnome 3.0 avrà una sola feature ( secondo i miei calcoli sono 0 )
* PULIZIA GENERALE DEL CODICE
ammazza ci hanno fatto un talk per sta stronzata ?
ROTFL a curvatura
@CiccioPasticcio
mah non vedo cosa c’entra QObject.. è normale che ci sia un oggetto da cui tutti derivano.
i programmatori della domenica sono quelli che non sono in grado di scegliere gli strumenti adatti al loro scopo. ad esempio usare C per “programmare a oggetti” è una pessima scelta.
aNoNiMo a quanto pare non hai capito niente :)
http://doc.trolltech.com/4.4/metaobjects.html
Che guarda caso fa le stesse cose di GObject, nonostante le QT siano scritte in C++
@CiccioPasticcio
ehm si.. ma cosa c’entra? non è che perchè esiste GObject e le QT hanno QObject allora in C si può programmare a oggetti, sono due cose totalmente scorrelate.
la principale differenza tra QT e GTK è che le prima sono state programmate in un’ottica a oggetti, mentre le seconde sono state programmate imitando un’ottica a oggetti, ma usando un linguaggio che non permette di ragionare in quest’ottica.
si tratta solamente di usare lo strumento più adatto allo scopo
Si potrebbe riscrivere l’intero GNOME nel linguaggio della macchina di Turing, così siete tutti contenti e nessuno avrà ragione o torto…
Cubismo, dadaismo…
Come ha evidenziato Khelidan in Message Box,
pare che le TABS saranno il fondamento dell’interfaccia di Gnome 3
http://blogs.gnome.org/cosimoc/2008/07/12/gnome-30-tabs/
Interessante inoltre notare come si sia rimasti al C
http://blogs.gnome.org/johan/2008/07/12/simplified-tabbing-support-in-gtk/
e come potrebbe essere il pannello di Gnome 3
http://davyd.livejournal.com/255065.html
Niente da fare, pare abbiano tenuto il C,
e, come ha segnalato khelidan in messagebox,
GNOME 3.0 = Tabs!
Ecco qui come potrebbe essere il pannello
http://davyd.livejournal.com/255065.html
sono stanco, stufo. gnome mi ha letteralmente fatto cadere i co$%&ion\i a terra. nel 2008 dove cavolo si presente gnome?????????? è quasi indietro windows xp (explorer). le gtk2 sono la cosa piu obsoleta e mal scritta del mondo. e ora finalmente le qt4 serviranno a far capire a quei pochi idioti rimasti che il futuro non è certo nelle gtk e gnome. e smettetela con la storia che è gnome è pulito , essenziale , elegante. la realtà è : gnome è talmente castrato a vita, le sue applicazioni sono dei cloni di quello di kde e quasi sempre fanno schifo a confronto, gnome ha bisogno di cose esterne per renderlo “bello”, di suo come mamma lha fatto è un obrobrio.
e poi diciamoci la verità. gnome non doveva mai nascere. è nato per una stupida licenza proprietaria delle qt di oltre 10 anni fa. è partito in partenza inferiore a kde e morirà anni luce inferiore. e poi michela de icazzo dove lo mettete? non vi rendete conto che gnome è un copia incolla voluto di windows 98? castrato al massimo? ora per piacere parliamo di desktop manager seri.
dimenticavo, una cosa positiva le gtk ce l’hanno: la sua licenza e indipendenza assoluta da tutto, e il fatto che siano state scritte totalmente dalla comunità open source. tutto il resto a riguardo sono favole.
@ matteo & luca: fenomenali.
Quanto prendete a spettacolo?!
Potreste illuminarci sulle innovazioni di Aqua rispetto a GNOME/KDE e tutto lo scibile umano, che so, dove è più usabile e perché (ovviamente avrete anni di studi su ergonomia, usabilità, interfacce..), cos’ha di tanto fantasmagorico rispetto ai cugini poveri, e ’ste robine qui.
@ 443: tu sei il re!
Sappilo!
Ed io ti venero per questo.. XD
Calma ragazzi… bisogna approfondire la questione di più prima di trarre conclusioni.
IMHO: gtk+ è una buona libreria e scritta abbastanza bene. Tutti la usano per DISEGNARE WIDGETS, (persino con qt e KDELIBS è possibile farlo) e sono estremamente configurabili. Qual’è il problema? Che Gnome tratta gtk+ come KDE tratta le QT. STOP. Non coinvolgiamo gtk+ in questa storia anzi è un bene che siano ancora in c. I programatori Gnome vogliono inglobare in gtk+ sempre più features ma poi si lamentano che non è possibile per la natura attuale delle gtk. allora BASTA, non si fa. Facciamo piuttosto una libreria che implementa un modello di programmazione DI SUCCESSO come in java o come QT per il c++ (in questo sono molto simili qt e java). In c non esiste, in c++ c’è qt la cui licenza è troppo restrittiva (gpl rispetto alla lgpl). Forse Boost può essere considerata un’alternativa o un buon punto di partenza ma se vogliono rimanere sul c se la devono fare loro in GObject e uno dei linguaggi modellati su gobject menzionati da qualcuno prima.
Chiarimenti (sempre imho, siete liberi di contraddirmi):
- Java è più veloce di C++: E’ ovvio, sono quasi lo stesso linguaggio, in più in java l’istruzione new/delete non chiama una system call tutte le volte come in C++, alloca un macroblocco (configurabile) una volta e distribuisce la memoria a pezzettini agli oggetti. Mica pensate ancora alle prime applet java che giravano interpretate? In c++ è ovviamente ripetibile il risultato, previa inclusione di una libreria di GC e riscrittura del codice adatto ad utilizzarla.
- ad esempio sono scritti col pitone i demoni MPD della libreria MPICH2: che c’entra? dipende dove è il grosso dell’elaborazione, parecchi programmi hanno plug-ins scritti in python, le cui funzioni sono scritte in c.
@mazzuolatore
non è possibile progettare una libreria del genere in C perchè il C non supporta la programmazione a oggetti.
a questo punto perchè non usare un linguaggio a oggetti che sono stati creati apposta?
il difetto di Java sarebbe solo il fatto di dipendere dalla JVM, bisogna vedere se ne vale la pena. se riescono a rendere affidabile e veloce GCJ allora sì che si ragiona (producendo codice macchina al posto del bytecode), ma non la vedo come una possibilità nel breve periodo.
peccato perchè come linguaggio Java è molto più “pulito” di C++. l’alternativa è usare C++ e avere delle linea guida abbastanza rigide sul modo di programmare, in modo da produrre codice comprensibile alla maggiorparte del mondo.
@aNoNiMo
Non è vero che non è possibile, d’altronde le istruzioni macchina supportano direttamente solo la programmazione imperativa e la compilazione di codice c++ è modellata su di essa ma non è questo il punto. La scelta del c e gobject è motivata dalla possibilità di avere tutti i possibili bindings del mondo, compreso c. Non condivido appieno, e sono d’accordo sul resto del tuo commento.
@mazzuolatore
direi che un binding in C non serve se incentri tutta la libreria sulla programmazione a oggetti (che con il tempo si è dimostrata particolarmente indicata per la realizzazione di interfacce grafiche). ad esempio non mi pare che le QT hanno un binding per C eppure non si è mai lamentato nessuno :P
il fatto che poi il codice viene tramutato in linguaggio macchina (e quindi non a oggetti) non c’entra niente, i linguaggi di alto livello astraggono completamente dalle istruzioni in assembly che vengono generate. i linguaggi a oggetti servono per creare codice più mantenibile, leggibile e flessibile, non per generare istruzioni macchina diverse.
c’è anche la possibilità (a mio avviso molto interessante) di usare ObjectC, molto più “pulito” di C++, ma con il difetto che implementa un paradigma a oggetti “insolito” e più ispirato a smalltalk che ai linguaggi a oggetti diffusi oggi. OSX usa questo linguaggio per esempio
ops intendevo ObjectiveC
Che palle con questo “pulito”… sempre ad usare questo termine quando si vuole generalizzare…
Gnome pulito kde4 pulito c pulito ma che palle! Basta! siate specifici e usate i vocaboli della lingua italiana che ne abbiamo tanti.
PS Lavatevi cosi siete “puliti” anche voi……….
@aNoNiMo
curioso rispondermi da solo eheh comunque se non hai capito cosa vuol dire “pulito” si vede che non hai mai usato C++ e un altro linguaggio a oggetti per poterne apprezzare le differenze
qui è Super Man che vi parla:
- piuttosto che usare Gnome, nel mio pianeta usano Windows Vista.
- gnome 3? cos’è una barzelletta per far credere che è il nuovo enorme passo come kde4? ma fatemi il piacere.
@aNoNiMo 86
Io uso il C e il C++ per lavoro da mooolto tempo caro, sto dicendo di essere precisi coi termini e pulito usatelo per dire che avete “pulito” la frutta, che il vostro sedere è pulito ecc. Ma per un linguaggio di programmazione non esiste la definizione di “pulito”.
Ah non commettere l’errore di sottovalutare i tuoi interlocutori ;)
@aNoNiMo_Sporco
ah mi scusi sua eminenza programmatore -_- mica programma solo lei comunque.
se conosce un termine migliore di “pulito” può sempre rivelarlo a noi comuni mortali che non sappiamo esprimerci.
in ogni caso avevo detto: conoscenza di C++ e di un altro linguaggio a oggetti (es. Java o C# per dirne due a caso) per poterne apprezzare le differenze.
quindi se come linguaggio a oggetti conosce solo C++ non mi stupisce che non capisce quello che intendo dire con “pulito”
in questo caso il mio messaggio non era rivolto a lei
Felipe non fa altro che ostacolare il progetto GNOME da quando è stato sbeffeggiato dalla comunità. Questo titolo è un altro della serie “GNOME è in ritardo e KDE 4 è bellissimo” con tanto di immagine che fa scena.
Visto che qua è pieno di fanboys con l’obbiettività di un bradipo dicon anchio la mia
Trovo arrogante arrivare nel 2008 e dire che adesso il toolkit gtk va ringegnerizzato e molte strutture publiche devono diventare private per facilitare il refactoring senza rompere di continuo le API
a distanza di anni arrivano a quello che qualsiasi programmatore (pure scarso) sa ossia se esponi tutti il tuo framework dopo perdonatemi il termine è un cazzo su per il culo modificarlo ma anche solo mantenerlo,gia solo con questa roba si capisce del perchè GNOME è concettualmente featureless.
ma poi anche volendo effettuare un refactoring del genere significa che fra 2 anni gnome 3.0
sarà lo stesso di adesso leggermente piu “pulito” ma anche qui le migliorie per le gente comune portranno arrivare solo tra 3 4 o addirittura 5 anni,a questo punto visto che si devono fare il mazzo perchè non accettano la superiorità intrinseca del c++ ( quantomeno per i sistemi desktop ) e basano gnome3.0 sulle qt ?
in questo modo oltre ad avere interoperabilità col mondo kde non si devono piu preoccupare delle fondamenta che obbiettivamente sono state scritte seguendo ideali faziosi e gare a chi cè l’ha piu duro piuttosto che asservire la comunità con un desktop moderno utile e gratis.
@Matteo:
perché avere i due più grandi DE in QT non va bene!!! E lo dico da fan di KDE4…
La licenza delle QT è GLP e non LGPL, ciò vuol dire che ogni applicazione sviluppata in QT è un derivato e dunque va rilasciata sotto GPL. Un ottimo modo per far fuggire a gambe levate ogni azienda che aspirerebbe ad porting di proprie applicazioni commerciali.
Certo che se l’alternativa è costituita da queste GTK…
@aNoNiMo
Evidentemente non capisci che sto parlando di proprietà di linguaggio informatico e se c’è qualcuno che non si sa esprimere, al punto da dover scomodare termini lavandai per definire un linguaggio di programmazione, quello non sono di certo io. Tuttavia non sto ad elencarti i linguaggi che conosco e il mio livello di conoscenza, visto che non hai colto il fulcro del discorso, che non è chi ne sa di più di linguaggi di programmazione, ma che personalmente mi fa schifo la parola “pulito” per definire questo o quel linguaggio oppure questa o quella interfaccia grafica.
Non mi rivolgo solo a te, non è un affare personale, ma è che sempre più spesso mi capita di leggere ad esempio che kde3 è più “sporco” di gnome… o il c è pulito e il c++ è sporco…. usiamo i vocaboli precisi e non restiamo sulla superficie delle cose. In questo modo sarà più facile capire i vari punti di vista delle cose.
Con affetto da uno che la pulizia la vede in casa, nella cura del corpo e nella frutta ;
@aNoNiMo
:D :D mitico!
Ad ogni modo tanto per chiarire il concetto di «pulito» basta far notare che con Java per creare una classe è sufficiente un file, mentre in C++ bisognerebbe crearne 2 (.h & .cpp). Creando progetti grossi è quasi automatico che il disordine si crei, è sempre possibile anche con Java, ma a differenza di C++ cerca di essere più «pulito» possibile =) poi ovviamente dipende molto dall’abilità del programmatore di saper gestire il proprio progetto.
aiuto,
personale opinione da programmatore da 4 soldi, con Java come giustamente dice qualcuno si può fare proprio di tutto (il software della macchinetta del caffè che usi ogni giorno in ufficio per esempio) ma secondo me, non dico sia il male, ma lo vedo come un ancora. Python lo conosco poco ma per quel che conosco, è limitato si, ma è molto più integrabile con gnome secondo me.
Il top a mio avviso sarebbe di implementare in Python qualcosina di importante che ancora non gestisce (vedi i thread).
Dopotutto io sono più che fierio del mio legnosissimo Gnome 2.22.1 :)
@aNoNiMo_spoRco
poi sembra che qui tu stia solo portando polemica sterile.
Lavati il cervello.
dai non mi sembra il caso di iniziare con gli insulti.. comunque ho scritto “pulito” tra virgolette proprio perchè è un uso improprio di questa parola. in ogni caso era per capirsi, non c’è un termine specifico
ok va bene. E poi non mi sembra di averti insultato. Se così ti è sembrato, sono stato frainteso.
Ciao e buon lavoro a tutti.
@skizz87:
Scusa? sapresti essere specifico? e poi non credo di aver parlato con te, ma con una persona più ragionevole e intelligente.
Ciao e mind your own buiseness… ;)
per gli insulti mi riferivo al commento di skizz87 ( lavati il cervello :P )
Giusto per gongolarmi un pò Shuttlework la pensa come me il Troll di pollycoke :>
http://tech.slashdot.org/tech/08/07/14/1245204.shtml
mah sono un pò scettico sul fatto che gnome possa essere riscritto usando le QT… come hanno già fatto notare le GTK sono diverse soprattutto dal punto di vista della licenza, per cui penso che debbano continuare a esistere
@matteo:
Le sue frasi sono estrapolate da una lunga discussione durante il meeting di GNOME mobile al GUADEC e in realtà la frase è mal attribuita. Ma non dirò chi ha detto cosa e perché :P
Io programmo con Lysoform, niente di più pulito.
Ragazzi, per chi può…un bel bagnetto a mare farebbe bene a tutti.
gp
@gp
aggiungo: un bel po’ di sana gnocca
@aNoNiMo_Sporco
Codice pulito vuol dire codice leggibile e comprensibile. Ed è italiano.
Se in anni ed anni ed anni… di programmazione non ne hai capito il senso mi sa che devi rivedere le tue “conoscenze” ;)
@ mazzulatore
- Ho qualche serio dubbio sul fatto che Java possa essere paragonabile a C, C++ e FORTRAN, quanto a velocita’: sinceramente vedessi un mplayer/mencoder con i codec implementati in Java o un codice FEM puramente Java avrei qualche serio pregiudizio circa le performance… ci sara’ anche un motivo se tutte queste applicazioni di solito sono scritte in C o FORTRAN… Quanto al C++ con la programmazione generica e’ imbattibile (anche se e’ un incubo da mantenere un codice generico).
- MPD: il demone e’ tutto scritto in python che io sappia, poi non so’ effettivamente quanto faccia questo demone che si trova fra l’applicazione (C,C++ o FORTRAN) e il protocollo di comunicazione (SSH o altri protocolli ad-hoc), comunque il punto e’ python viene usato anche laddove le prestazioni contano: ci sono molti progetti scientifici che usano python.
Tutto questo IMHO.
@Il Mignolo col Prof.:
Ok accetto pulito se non conosci altri termini.. ma non ti arrabbiare perchè chi ha le conoscenze limitate non sono certo io.. almeno conosco altri 4 vocaboli ;)
@aNoNiMo_Sporco
Non volevo essere offensivo, voleva essere una cosa simpatica magari in risposta al tuo tono che a me è parso un po’ saccente ma comunque la risposta non voleva essere offensiva. piuttosto scherzosa visto che il 99% dei programmatori che conosco usano il termine “pulito” come tutti gli altri qui sopra…
Comunque illustratraci un paio dei tuoi almeno 4 vocaboli ;)
Comunque Gnome sarà antiquata, scritta in C con dei workaround pazzeischi per aggirare certe limitazioni però offre qualcosa che KDE non sa dare e mai saprà, come anche il contrario, KDE sa dare qualcosa all’utente che Gnome non darà mai sia per etica che per limitazioni.
@aNoNiMo_Sporco
Io di vocaboli ne conosco (ricordi quando dicevi di non “sottovalutare” mai il tuo interlocutore? :D ), il termine “pulito” l’ho proprio scelto. In un’unica parola trasmetto l’idea di codice: compatto, leggibile e comprensibile.
Così come si dice che un programma è “pesante”. Per caso lo pesi al kilo? :P
@david_e
E io invece non vedo perchè non debba esserlo, la sintassi è simile a c++ e viene compilato in codice macchina nativo in fase di esecuzione. Tu potresti arguire sullo spreco di fatica di compilare tutte le volte ma questo è necessario per alcune caratteristiche di java usate ad esempio da eclipse, inoltre la compilazione in fase di esecuzione non è statica bensì adattiva e permette di generare il codice macchina per sfruttare al massimo la cache, la branch prediction, e l’instruction set disponibile e in base al flusso di esecuzione corrente. Alcune di queste caratteristiche semplicemente non sono possibili in c/c++. Compilare java in eseguibile nativo è inoltre possibile, le tecnologie migliori non sono free ma è ipotizzabile che in un futuro le tecnologie java possano essere fruibili più facilmente al di fuori della jvm.
@Marco Barisione
noooooooo adesso la devi spiegare perchè altrimenti non dormo :D
ps. tu che sei dell’ambiente… secondo te è fattibile/utile passare a un linguaggio a oggetti?
@aNoNiMo:
Nah, troppo lungo da spiegare e io sono pigro :)
Intanto qualcuno bloggherà sull’argomento nei prossimi giorni.
La base delle librerie di GNOME deve rimanere abbastanza compatibile (alcuni cambiamenti sì ma ridotti), non si può riscrivere tutto[1]. Questo blocca la possibilità di passare a qualsiasi altro linguaggio (eccetto Vala che però non è pronto).
Nuove librerie possono essere scritte in qualsiasi linguaggio purché ci sia un’interfaccia in C, ad esempio WebKit è in C++. In più non ha senso scrivere una libreria in Python/C#/Java per motivi di prestazione e interfacciamento con i programmi che le usano.
I programmi si possono scrivere in qualsiasi linguaggio.
[1] Scrivere codice stabile e testato (ripeto stabile e testato) costa molti soldi e tempo, per riferimento ecco i costi stimati di alcune librerie base secondo il modello COCOMO:
glib+gio+gobject+gthread: $ 5,983,442
gtk+gdk+gdk-pixbuf: $ 16,804,705
cairo: $ 1,879,301
qt (senza i moduli 3dparty come qtwebkit): $ 29,522,386
Ora chi si sente di riscrivere da capo una di queste librerie?
@ mazzulatore
Sapevo che il Java non è interpretato (come non lo è nemmeno Python), ma è comunque un linguaggio di alto livello e questo credo si paghi da qualche parte… anche il C++ diventa lento se si cominciano a sfruttare pesantemente il polimorfismo (la vtable ha il suo peso)… poi anche i linguaggi compilati sono in grado di sfruttare al massimo la CPU sia agendo a livello di compilazione che facendo agire direttamente a basso livello il programmatore.
Forse il mio è solo pregiudizio verso Java, ma fino a che non vedo un esempio di una libreria Java di quel tipo e con prestazioni simili a quelle di una libreria C non ci credo… :D
Eclipse certo non è un bell’esempio di applicazione veloce: è così tremendamente pesante rispetto ad Anjuta… (certo ha molte più feature però…)
@Il Mignolo col Prof.:
Ecco bravo ora sei stato specifico nell’esprimerti (compatto, leggibile e comprensibile). Meriti una medaglia! Ah con le battute non sei molto bravo ;)
Ciao e buon lavoro.
il termine “linguaggio pulito” in informatica principalmente a differenza di quello che avete detto voi scienziati va interpretato in questo modo:
il linguaggio C permette per sua natura grandi flessibilità. questa sua flessibilità ha però un fattore non trascurabile: la difficoltà nell’assicurarsi che il codice scritto generi cose non volute. in altre parole il C è un linguaggio MOLTO permissivo e la conseguenza è che se non sei un bravo programmatore e conoscitore dell’hardware per cui stai scrivendo, finisci per genere codice sì funzionante ma potenzialmente “sporco” dove per sporco si intende spazi di memoria involontariamente occupati, cicli di cpu non ben controllati ecc. il java sotto questo punto di vista è molto meno permissivo. essere meno permissivi non significa che il C puo fare piu cose del Java. ogni linguaggio che rispecchia la macchina di turing ha tutti gli strumenti per fare le stesse identiche cose.
Non meravigliatevi se il kernel linux è scritto quasi totalmente in C. I programmatori del kernel sono dei veri e proprio guru della programmazione/conoscenza hardware e algoritmi. E’ ovvio a questo punto che a Torvalds non piacciono altri linguaggio se non il C. Le sue conoscenze sono talmente vaste che usare ad esempio il C++ o il Java (a oggetti dunque) lo fa sentire rinchiuso in una tana, e questo nonostante che con il C++ o Java si possono fare le stesse identiche cose.
I tempi si sono evoluti, le esigenze dei software aumentano sempre di piu e non sempre è facile valutare quale sia il linguaggio di programmazione piu adatto. Il c++ si è dimostrato ottimo in alcuni ambiti, il java in altri ancora. Il C sopratutto a livello di kernel e driver. Ma insomma questo GTK che problemi ha? E’ veramente il linguaggio di programmazione che usano il problema? A mio modesto avviso NO. Il problema di GNOME e delle GTK sono 2:
- la forza lavoro totalmente inesistente
- la filosofia che c’è alla base che ha rovinato tutto.
Possibili soluzioni? Non ne vedo e anzi vedo nel futuro un fallimento totale. Quello che fa la differenza con le QT è sopratutto la forza lavoro. Sarebbe un bene se GNOME fosse riscritto in QT? Tralasciando i problemi di licenza, la risposta per tanti motivi è SI. E qui il discorso kde vs gnome non c’entra niente. E’ un discorso puramente tecnico. Ma questo non accadrà mai a causa del secondo motivo prima citato: – la filosofia che c’è alla base che ha rovinato tutto.
Distinti Saluti
@saluti:
finalmente qualche cosa che condivido e detta come si deve.
ciao
@116: finalmente leggo cose intelligenti e mi va di scrivere.
Condivido ciò che hai detto compreso il discorso Gnome+QT che rappresenta una sorta di mio sogno\fissazione…ma come hai ben scritto impossibile da realizzare se non forkando ma da qui poi nascerebbero altre 100 complicanze.
Circa il discorso del problema delle GTK condivido quasi tutto solo che io credo che il problema sia ‘anche’ nell’utilizzo dello C. Ma no perché non sia valido o non possa fare certe cose ma perché se oggi vuoi produrre certe cose ed avere forza lavora a sufficienza conviene usare un linguaggio, diciamo, più moderno. Ed io opterei per C++ che non sarà modernissimo ma adotta un paradigma di programmazione più moderno del C e nello stesso tempo è un giusto compromesso tra flessibilità e restrittività (brutto termine ma dopo una giornata di stress è il massimo che posso scrivere :D ).
Comunque effettivamente il succo del tuo discorso non cambia…c’è stato un errore alla base…presumibilmente, oltre alla filosofia, anche quello di puntare sul C.
gp
nessuno l’ha notato?
”
12. felipe – 10/07/08 @ 22:20
Il mio blog è chiuso.
“
Non sarà chiuso davvero?
Sarebbe con lo sfondo bianco se fosse Felipe no?
secondo me saluti al 116 è felipe in vacanza :)
non esistono linguaggi puliti, ma programmi puliti, cioè scritti con uno stile di codice pulito…Java, C, C++, Python, Haskell dipendono tutti dal programmatore è lui ad essere pulito non il linguaggio. Il linguaggio è solo un atrezzo, più è funzionale meglio è…
@sick
Ne dubito felipe è un professore di spagnolo non un informatico, quindi di programmazione non sa una cippa.
@saluti
Stiamo parlando di cose diverse. Dire “linguaggio pulito” (suppongo ti riferisci alla sintassi del linguaggio, perchè di “linguaggio pulito” ne ho sentito parlare ben poco…) è ben diverso dal dire “codice pulito”.
E menomale che gli “scienziati” eravamo noi :P
@ mUogoro
Non è necessario istanziare quattro classi.
Prima di criticare Java forse sarebbe il caso di leggere meglio la documentazione.
public class Foo {
public static void main( String args[] ) {
PrintWriter w = new PrintWriter (”foo.txt”);
w.println(”Hello World”);
}
}
Aspettando Gnome 2.30 / 3.0
Sarà la volta buona che toglierò Windows del tutto.
Grazie Felipe.
@Zagor:
Anche io anche io! :D
@Marco Barisione:
Molto interessante! Mi spiace invece per MoNo, ma forse sono solo io ad essere sbagliato :D
@Sniz92:
Moda? Ho cominciato ad usarlo prima che nascesse e a parte me ne parlano tutti in maniera ignorante. Non direi che KDE4 sia una moda
@codice-pulito-sporco-qt-gtk-tab-ecc:
Non c’è un po troppa enfasi? :)