Mono, C#… e se il problema fossero le GTK+?

e se il problema fossero le seghe mentali ?

e se il tuo problema fosse che non ti ricordi il tuo indirizzo email?

o lo sbagli o te lo inventi, cmq sia piantala

Ok in parte certamente vero ma però vorrei invertire un paio di fattori:

Com'è che tanti (troppi, decisamente troppi) progetti KDE4 (o cmq parenti stretti) sono in ritardo? Questo uso di C++ in ogni situazione può centrare nulla? Amarok2, K4B, raptor, koffice sono alcuni esempi di programmi che hanno avuto (o hanno tuttora) molte difficoltà.

La voglia di ottimizzare il tempo non deve poi essere confusa IMHO con l'incapacità. Molti degli sviluppatori gnome non lo fanno di mestiere, ma per passione e riuscire a portare a casa la pagnotta, avere un minimo di vita sociale, magari una fidanzata/moglie che non venga ridotta a una schiava tuttofare/porca da letto (beh su questo un pensierino... :D) richiede tempo. Riuscirsi a ritagliare anche un pò di tempo per progetti opensource è per molti un miracolo (io stesso vorrei studiare mono o python ma NON NE TROVO IL TEMPO, sono le 7.00 ed è già 1 ora che sono davanti al pc per cercare di sistemare un progetto urgente) quidi se esistono strumenti che consentono di sviluppare in modo rapido ed efficiente allora perchè non usarli?

Il 'fatto' gnote poi è 1a goccia nel mare, soprattutto ragionando su quanto ho appena scritto. Magari lo sviluppatore si è trovato un sacco di tempo libero (licenziato o simli a causa della scrisi). Inoltre non ho trovato poi molto su una data di reale inizio dello sviluppo (se diversa quindi dalla 'prima apparizione ufficiale').

Quoto, infatti anche il C++ è troppo difficile per gli sviluppatori della domenica.

La reale differenza è che in C# e Java si può lavorare senza sapere cosa sia un PUNTATORE.

no aspetta

anche un mago dello sviluppo software può ottenere vantaggi (principalmente maggior rapidità di sviluppo) dall'usare c# o java? allora perchè non farlo?

infatti C# e Java sono linguaggi C-like ma nulla a che vedere con C e C++.
Io per esperienza personale ho programmato in C++ un po' a scuola (sono perito inform. da 3 anni) ma l'ho sempre coltivato a casa per passione.
Ho provato a fare un player in gtkmm e c++ e all'inizio ci sono un po' di difficoltà ma poi quando hai preso mano è una minchiata.
Il vero problema a dire la mia è che manca un ambiente di sviluppo serio, se vogliamo fare un paragone con MS direi Visual Studio.
C# secondo me è molto gettonato perchè con Mono Develop che nella scrittura di codice di da suggerimenti e sintassi ti da anche la possibilità di disegna la GUI in modo visuale.

quindi pensi che un monodevelop c++ basterebbe per abbandonare mono?

Certamente sarebbe una bella cosa ma non penso che basti, i vantaggi di c# e java nella rapidità di sviluppo sono cmq molti altri immagino. Conosco un pò php e sto cercando di migliorare la mia conoscenza di questo linguaggio di scripting. Sul manuale che mi sono acquistato (la documentazione in italiano sul web è molto scarsa) ci sono spesso riferimenti a C. Il non dover dichiarare le variabili e 1000 altre cose sono evidenti vantaggio nella rapidità di sviluppo (ok di contro sono un rischio perchè causano confuzione, aumentano i rischi di bug e cavolate simili).

poi bisogna dire che va a filosofie...
Diciamo che io la penso così: sviluppo un programma, ok... se lo scrivo in qualsiasi linguaggio, in maniera standard è comunque abbastanza portabile ad un'altra architettura. Il fatto che la gente scriva in Java o C# secondo me è dovuta anche al fatto che sotto hai una VM multipiattaforma... che nel caso di Java, fai un programma in GUI in Windows, due modifichette e va su Linux, Mac ecc.. nel caso di C#... non riesco a capire il perchè di questa corsa al C#...
Poi velocità di sviluppo... C# non lo so ma non credo sia il vero vantaggio di Java rispetto a C++...
Comunque non credo che un buon IDE possa bastare per abbandonare Mono ma darebbe sicuramente una mano.. :)

Mettiamola così: il C++ ha molte più caratteristiche di C# e Java assieme. Se lo si sa usare può dare soddisfazioni non da poco. Inoltre è compilato, va (molto) più veloce.

Però scrivere programmi in C++ e in particolare mantenerli può essere un calvario. Un semplice esempio su tutti: C# e Java prevedono che l'interfaccia di una classe sia estratta dal file sorgente stesso e sia quindi *implicita*.In C++ hai un header esplicito che ti devi scrivere tu e quindi se in C# e Java hai un file per classe (per fare un esempio) in C++ ne hai due per classe che devono chiaramente essere tenuti sincronizzati.
Non è solo una questione di tempo: non sempre avere un linguaggio potente come il C++ è un vantaggio perchè maggiore è la complessità del linguaggio più cose il programmatore deve conoscere. E questo problema non affligge per forza il programmatore della applicazione ma anche chi si ritrova poi a voler lavorare sull'applicazione senza averla programmata da zero: è chiaro che un programma scritto in Java è più semplice da capire.

Esistono campi in cui l'efficienza è necessaria però in generale in ambiente desktop non sono convinto che il C++ sia la scelta giusta. Quindi mono, java e python dovrebbero essere scelti piuttosto che il C++ secondo me.

Molto interessante.

Mono però non è solo un linguaggio ma un framework. L'avere a disposizione strumenti evoluti messi a disposizione da mono rende lo sviluppo molto più semplice.

Comunque il C++ è di per se un buon linguaggio e con QT e Boost dietro può essere usato molto facilmente, io mi stupisco di chi riesce ancora a programmare in C sotto Gnome...non che il C sia un cattivo linguaggio, ma esistono alternative (java e mono in primis) che indubbiamente rendono la vita più semplice. Esistono progetti come Vala che dovrebbero essere la pietra base di Gnome 3 e renderebbero tutto più immediato oppure senza stare a farsi linguaggi di programmazione in casa esistono alternative come il D che eliminano tanti difetti della programmazione classica in C/C++ senza per forza dover stare su una macchina virtuale.

Chiariamo un paio di cose:

1) Java e C# sono linguaggi compilati, JIT ok, ma pur sempre compilati, quindi al limite hanno un overhead iniziale ma poi sono eseguibili macchina a tutti gli effetti.

2) I linguaggi JIT sono INTRINSECAMENTE più veloci di quelli precompilati, per diversi motivi. Quindi, in teoria C# e Java potrebbero superare C++ come velocità.

Ma anche no. Java esegue in una virtual machine che converte le istruzioni macchina virtuale in istruzioni macchine fisica. Per poco che ci metta ci perde sempre del tempo. Questo è il motivo per cui un binario in java gira su "tutte" le architetture e non solo x86.
Se usi gcj e compili in codice macchina x86 (mi sembra si possa fare) fai un'altra cosa.
Stando alle tue conclusioni meglio fare un kernel in java (JIT) che in C (precompilato).

Sono d'accordo, infatti avevo scritto "hanno un overhead iniziale", che come dici tu è dovuto alla conversione.
Sarai però d'accordo con me che in molti contesti questo è irrilevante, soprattutto se l'applicazione deve stare accesa parecchio. E si possono comunque implementare meccanismi di caching (non so se lo faccia già) per ridurre ulteriormente questo overhead.

Nota poi, sul secondo punto, il mio "in teoria". Il C deve la sua velocità alla sua bassa astrazione e al suo basso livello, e a mio parere non è un linguaggio che va confrontato con Java e C#. Stavo solo facendo notare che la compilazione JIT permette la creazione di eseguibili migliori e più performanti rispetto alla precompilazione, dove un piccolo overhead iniziale è accettabile.
Lo dichiara anche M$ riguardo a .NET:

- "Myth: JITed Programs Execute Slower than Precompiled Programs"

- .NET still provides a traditional pre-compiler ngen.exe, but "since the run-time only optimizations cannot be provided... the code is usually not as good as that generated by a normal JIT."

Potenzialmente invece sì: I programmi compilati JIT possono essere ottimizzati a runtime tramite analisi statistica dell'esecuzione del codice. Oltre ad avere altri tipi di ottimizzazioni che i programmi precompilati non possono avere.

Se usi un designer, come qtdesigner, entrambi i file dovrebbero essere generati automaticamente. In generale mi pare che il nuovo KDeveloper aggiorni in automatico gli header in base ai sorgenti.

Io mi trovo abbastanza d'accordo con Dario, se non fosse che io non darei la colpa (almeno non tutta) ai programmatori, ma ne darei una grossa parte alla complicatezza delle GTK stesse. Io ho scritto solo un paio di programmi in C++/GTK... rispetto a C++/Qt è un suicidio bello e buono....

@barra
In realtà molti progetti KDE hanno rallentato sia per la necessità di imparare ad usare le nuove features che Qt4 ha messo a disposizione, sia perchè la maggior parte dei programmi sono stati riscritti quasi da 0 nel passaggio da KDE3.x a KDE4.x.

Io ho sviluppato con GTK+/C, GTKmm/C++, PyGTK/Python e QT/C++... sia QT che GTK hanno sia pregi che difetti, ma sinceramente non vedo come GTK possa risultare più complessa di QT. Anzi, nonostante la mancanza di documentazione ho sviluppato su GTKmm più agilmente di quanto abbia mai sviluppato su QT. Per non parlare di Glade o GtkBuilder, a parer mio immediati e capaci di semplificare un mucchio di lavoro, cosa che non posso dire della controparte designer.
A parer mio questo Dario Freddi non ha le idee molto chiare.

Invece che "idee non molto chiare" direi molto più semplicemente che avete opinioni diverse. Dario di esperienza ne ha parecchia, basta che leggi i suoi vecchi blog o l'intervista.

Se porta la complessità di GTK nelle sue versioni C e C++ come giustificazione all'introduzione brutale di Mono non sono opinioni diverse poichè da programmatore (e lui ha citato i programmatori) non trovo alcuna giustificazione. C'e' Python, c'e' Ruby e QT non è la manna. Potrei accettare che abbiamo opinioni diverse su quale toolkit sia semplice o no da utilizzare, ma non che questo comporti uno sfavore o favore per Mono.

Chiedo scusa, ma se accetti il fatto che abbiamo opinioni diverse e poi non accetti una mia opinione mi sembra che sia tu a non avere le idee molto chiare :)

Scusa, sono appena tornato dal lavoro. Non ho detto che accetto tutte le tue opinioni :) Accetto opinioni diverse su (in questo caso) la facilità o meno di utilizzo di toolkit specifici (QT/GTK). Ciò che non ritengo corretto è ritenere Mono un modo per alleviare le sofferenze ai programmatori che ritengono C++/C/GTK/GTKmm troppo complesso e poco immediato. Come dicevo esiste Python, esiste Ruby... entrambi ottimi, ed entrambi capaci di semplificare la vita del programmatore); Inoltre la suddetta opinione si scontra con chi ritiene GTK semplice ed intuitiva e richiederebbe quanto meno una prova concreta che molti sviluppatori Gnome ritengono GTK complesso e Mono superiore alla concorrenza. Scusa ma non posso ritenerla una semplice opinione divergente dalla mia.

Il fatto che le gtk siano pensate per il C
era la PRIMA cosa da cambiare per GNOME3 secondo MOLTI.

Basta leggere i commenti al PRIMO articolo su gnome3 che hai scritto
https://pollycoke.net/2008/07/10/gnome-30-uscira...

Naturalmente ci sarà sempre qualcuno che dirà a caso
"gobject gobject gobject"

ma fare tutto gnome 3 in qt 4????

io non capisco perche questa cosa non è stata proprio presa in considerazione....

un DE alla gnome (pulito, immediato, user-frendly) con la potenza delle qt4 ...

dove CA**O è il problema?

retrocompatibilità?

La retrocompatibilità non c'è, nonostante la gente lo pensi, neppure con le gtk 3.

Perchè riscrivere milioni di righe di codice che funzionano BENONE quando si possono introdurre grandissime novità (clutter ad esempio) in gkt senza (come dice luca) perdere in retrocompatibilità?

No ma questa è una boiata... se introduci novità devi riscrivere, a meno che non hai un'API della madonna estremamente astratta che GTK non ha... e per altro guarda che pure Qt è un framework... informati...

Qt semmai è un toolkit...
Comunque secondo me ha ragione barra...

Guarda, a dire il vero Qt è un framework completo, non è solo un toolkit, ed è la ragione per cui la gente si trova comoda con il C++.

Barra ha ragione nella misura in cui GNOME in Qt spero non si vedrà mai. Però attenzione: non rompere la retrocompatibilità non vuol dire avvantaggiarsi di migliorie, possano esse essere clutter o altro, senza riscrivere grossi pezzi di codice.

Mutter (un muovo metacity, basato su clutter) è compatibile con tutto il software esistente.
I passaggi che porteranno a gtk3 sono stati ben chiariti e saranno fatti senza una rottura secca con il passato. Operazione che da sempre avviene in gnome. Un esempio? E' stato introdotto g-vfs che doveva sostituire gnome-vfs ma gli applicativi hanno avuto 1 anno (2 release) per fare il passaggio visto che i 2 sono rimasti affiancati. Quindi si può innovare senza dover riscrivere da capo tutto.

QT che centrano? si sta parlando di applicativi gtk, basati su C e si sta discutendo delle difficoltà (presunte o non) di lavorare in questo contesto e della (sempre presunta) maggiore semplicità di sviluppo in ambiente mono(c#+gtk#).

Anche KWin funziona perfettamente come tutto il software esistente, mi sembra scontato.

Il senso era: Passiamo a QT? allora è necessario riscrivere tutti gli applicativi, in GTK3 manterranno una forte compatibilità con il passato (gli step sono sempre: integrazione nuove parti che vanno ad affiancare le vecchie che saranno poi rimosse nel corso del tempo). Con QT4 invece o riscrivevi da 0 o cmq l'applicativo restava QT3

"potenza delle qt4"... quale "potenza"?
a me sembrano equivalenti... tutta questa differenza non la vedo: qt eccelle in alcune cose, gtk+ in altre. Alla fine è una questione di scelte, ma non è che Gtk+ sia più potente di Qt o viceversa.

In cosa eccelle gtk+?

In tante cose legate alla grafica a mio parere, cairo è davvero potente e semplice da usare, per non parlare di clutter.

Non mi risulta che cairo sia legato a gtk+.

beh allora sei ben poco informato :)
cairo è stato praticamente concepito per lavorare con le gtk+, dopo pochissimo che è nato è stato immediatamente integrato nelle gtk+ (parecchi anni fa, gtk+ 2.8.0), e le stesse gtk+ ora lo usano per disegnare tutti i widget: gli engine usano cairo, compiz usa cairo, awn, gnome-do, screenlets, firefox usano cairo, le applicazioni in gnome usano cairo, i grafici ed i disegni, gli effetti delle applicazioni usano cairo... e chi più ne ha più ne metta...

Andrò contro corrente ma aggiungo Glade/GTKBuilder. QT sarà semplice ma a parer mio Glade prima e GTKBuilder ora sono nettamente superiori a designer di QT. Anzi, GTK è stata la prima ad evere (tramite glade) un'interfaccia completamente descritta su XML, cosa che, passatemi il termine, spacca durissimo.
Devo dire che ci sono anche dei piccoli accorgimenti che mi fanno preferire GTK, come il widget GtkFileChooserButton o il selettore colori, nel primo caso mancante in QT (a meno di smentite) nel secondo caso scandalosamente brutto nella versione QT non commerciale (ma in questo caso ci si riallaccia al fattore Cairo.

P.S: se vogliamo essere pignoli aggiungerei che GTKmm non ha quelle odiosissime tag di QT che non vengono digerite dal sistema di autoindent di Vim ;)

Dario è un ragazzo molto intelligente, e programma bene... solo forse non ha mai provato Mono/Gtk#: tra scrivere un'applicazione anche in Qt e scriverla in Mono/Gtk# la differenza si vede eccome... è davvero facilissimo ed intuitivo programmare con Mono/Gtk#.
Allo stesso tempo trovo un po' "una sparata" dire che il problema siano le Gtk+/C/C++, mentre con Qt si risolverebbe tutto: la riprova sta nell'abnorme numero di applicazioni Gtk+ che popolano nel web rispetto alle poche che si trovano su qt-apps.org. I nuovi sviluppatori scelgono Gtk+ anche perchè è semplice programmarci sù, altrimenti non ci sarebbero tutte queste applicazioni in Gtk+ e ci sarebbero molte più applicazioni Qt.
E non voglio dire che scrivere in Qt sia complicato! Solo che mi sembra siano equivalenti se non addirittura a favore delle Gtk+ con i vari python/pygtk.

Ma ciao Andrea! :D Spero tu te la stia passando bene. Cmq:

Riguardo il primo paragrafo: d'accordissimo con te. Era proprio il mio punto la faciltà estremamente maggiore di sviluppo con Mono.

Qt non risolverebbe tutto, la mia proposta era rendere l'API di base (e non i bindings, che chiaramente facilitano il lavoro, indipendentemente dal toolkit/framework/etc che utilizzi) delle GTK più intuitiva ed al passo con i tempi, che ridurrebbe di molto la necessità di usare bindings. Poi è ovvio: C# l'ho provato con WPF e Forms, che dubito siano più difficili di GTK# ed è molto semplice: ad ogni modo trovo ugualmente intuitivo Qt e C++, ovviamente con le aggiunte del fatto che stai usando un linguaggio che ha caratteristiche molto diverse. Ma qui si sta anche parlando di gusti. Ad ogni modo

Ti faccio notare che tu hai preso sempre a termine di paragone Qt e C++, e mai Qyoto e/o PyQt. Proprio perchè chi programma in Qt non sente un bisogno impellente di utilizzarli, e l'incremento di facilità usando un binding è molto più percepibile utilizzando GTK rispetto a Qt, che era anche il punto del mio post.

Io spero vivamente che GTK riesca a "rimodernarsi" un po' alla base, per attrarre più sviluppatori nuovi verso C e C++.

Aggiungerei il miglioramento della documentazione. Chi usa con profitto QT/C++ non passa a PyQT anche perché QT è ottimamente documentata.
In GTK ho sentito solo una mancanza, una vera integrazione di OpenGL (gtkglext lascia perplessi), cosa che spiazza nel momento in cui si debbano usare librerie come VTK che offrono supporto ufficiale solo per QT e tk, appunto per la mancanza di un'integrazione credibile in GTK.
Ma continuo a non capire perché questo dovrebbe far cadere le attenzioni su Mono... Python è ottimo, sia come linguaggio che come integrazione con GTK; multipiattaforma, supportato da qualsiasi cosa al mondo (credo esista una libreria python anche per le penne bic e i tavoli IKEA); Perchè uno sviluppatore GTK afflitto da un'impellente voglia di buttare C o C++ nel dimenticatoio dovrebbe usare Mono? a che pro Gnome dovrebbe offrire supporto ufficiale a Mono invece di spostare le forze sul miglioramento dell'integrazione con Python/Ruby/Java (dio ci salvi da Java :P)?.

Ciao Francesco, ti rispondo a questo commento e non all'altro, ma penso di aver capito il tuo punto. Di politica non volevo parlare, e se hai orecchie per intendere, e visti i tuoi commenti penso tu ne abbia, mi hai capito :) Sono d'accordissimo con te su python. Penso che tu la pensi molto simile a me, ma forse il mio messaggio non è trapelato molto bene.

Peraltro questo è il mio ultimo commento alla cosa, volevo solo far riflettere e non generare flame o discussioni. Penso sia molto meglio usare la tastiera per scrivere codice piuttosto che discutere di cose sterili. Ognuno usi ciò che preferisce e che gli piace, e se qualcuno ha carpito qualcosa di costruttivo dal mio messaggio, spero ne tenga conto :)

concordo con te grande cimi... ma dimmi, da dove viene la semplicità dello sviluppo mono/gtk#?

Dalla qualità del framework Mono/Gtk#.
E' completo e si scrivono applicazioni complesse in poco tempo... Non hai da dannarti come col C++ su molti aspetti del codice (il C# aiuta molto), e Monodevelop è un IDE integrato potentissimo che da solo ti guida alla creazione di applicazioni con interfaccia grafica.

Secondo me non c'è niente di male a scrivere in GTK usando bindings, francamente non consiglierei a nessuno di scrivere una applicazione in C.
Penso inoltre che la scelta di utilizzare (e di restare) al C sia proprio legata a questo fatto ( che è facile creare bindings mantenendo una eccellente velocità) , quindi che senso a stare a rimuginare su C C++ e altro?

Ci sono linguaggi molto più adatti a scrivere applicazioni orientate al desktop, personalmente mi sono affidato a python (dio lo benedica), ma sento parlare molto bene anche di Vala.

Per Mono... sarà questione: conosco il C#, scrivo il C#. Non vedo particolari vantaggi per usare un linguaggio "sconsigliato" dalla community

ahh finalmente polly... ci sei arrivato! aspettavo un articolo del genere... certo, lo sviluppo mono è agile, python/qt è agile... python/gtk no... ergo, l'intruso è gtk... ma insisto col dire che basterebbe un ottimo ide, le gtk non sono male. Quel dannato anjuta andrebbe migliorato dal punto di vista delle gui

Uno sviluppo recente è proprio il Qt Creator che è un IDE eccezionale. Ed è disponibile su 3 piattaforme. Per uno sviluppatore che non vuole limitarsi a Linux, ad oggi non c'è niente di lontanamente paragonabile.

quoto.
qtcreator va provato.
ottimo, con il designer (ottimo pure lui) perfettamente integrato.
secondo me darà una bella "botta" allo sviluppo multipiattaforma (anche per i sistemi embedded)!

Un po' da tutti i punti di vista, direi.. Tempo fa cercavo un buon IDE C++ ed ero incappato in questo, ma ero scappato dopo poco :D
Non so come sia messo ora, cmq.

Secondo me si rischia di confrontare mele con pere:
c/c++ sono linguaggi compilati e chiaramente richiedono una maggiore attenzione quando li si usa, però sono veloci.
Il resto è un interpretato&compilato ognuno con i suoi punti di forza e di debolezza.
Secondo me scrivere codice object oriented in C non ha senso, perché tutte le funzionalità degli oggetti vengono date con librerie, e non mi sembrano per nulla armonizzate con la natura del linguaggio. GTKmm e Qt mi paiono soluzioni comparabili, e decisamente la strada da scegliere.
Però a più alto livello si scrive il codice in meno tempo, questo è dato di fatto, meno righe si scrivono, meno errori si fanno.
Le domande sono: nel 2009 ha senso far uscire una libreria grafica ad oggetti in C? C'era proprio bisogno di un ennesimo linguaggio interpretato che fa più o meno quello che fanno già gli altri? E soprattutto perché Mono è preferito ad altri linguaggi (sempre che lo sia)?

ti rispondo alle 3 domande...
1) Il linguaggio va a preferenze, agli sviluppatori Gtk+ piace il C e preferiscono lavorare col C che col C++. Per scrivere un toolkit, gli oggetti non sono fondamentali... anzi se ne può fare benissimo a meno e preferire un linguaggio più snello come il C. La programmazione ad oggetti serve più nelle applicazioni, che hanno generalmente livelli di complessità maggiore e richiedono ereditarietà e classi, ma per far questo bastano i binding per altri linguaggi (Gtkmm, Gtk#, Pygtk etc etc...).
2) C#/Mono non è un linguaggio interpretato, ma genera una specie di bytecode (le prestazioni raggiungono quasi il C++ stando a moltissimi benchmark che si trovano su google), di conseguenza rappresenta già per questo un'alternativa differente (semmai che serve avere ruby e python che sono similissimi...). In ogni caso la risposta è semplice e in parte si rifà al punto 1: ad ognuno piace il suo linguaggio ed è contento se trova bindings pronti.
3) C# (Mono non è un linguaggio, ma il compilatore/VM) con Mono è preferito perchè ha un framework completo e *semplicissimo* da usare, il linguaggio poi si sbroglia da solo di molti problemi (come il garbage collector), ha un IDE che fra un po' fa anche il caffè, la gestione dei plugin nelle applicazioni è davvero semplice (guardate solo Banshee, Tomboy, F-Spot, Gnome-Do quanti plugin hanno... basta usare mono-addins, è davvero facile gestirli), chi viene dal Java lo ama (si studia moltissimo nelle università italiane ad esempio...) perchè ha una sintassi praticamente uguale (eccetto qualche parola chiave con nomi diversi)

Non ho mai scritto librerie grafiche per cui sul punto 1 la spiegazione è più che accettabile anche se mi pare strano che nel produrre una libreria che prevede l'ereditarietà (che è presente nei bindings) si usi un linguaggio che non la contempla. Sul punto 2 bisogna intenderci, per linguaggio interpretato intendo che ci vuole un software che traduca a runtime un file (binario o sorgente poco importa) in istruzioni macchina. I test che ho visto mostrano che Java di Sun è più veloce di C# su Mono, e che il C++ è più veloce di Java. So per certo che anche python produce bytecode, ma è probabile che lo facciano anche gli altri linguaggi. Si vedono in giro molti benchmark mi sembra che C# si piazzi tra Java e Python come velocità. Su KDE moltissimi programmi usano plugin, e ne hanno tanti, GIMP usa plugin, Firefox anche, non sono convito che sia così difficile scrivere programmi "pluggabili" senza usare Mono.
Con il terzo punto mi sa che siamo arrivati al dunque: fin'ora non c'era un framework completo da usare per programmare in GTK e neppure un IDE che faccia tutto. Io sono tra quelli che hanno iniziato da Java, ma di difficoltà ad usare python non ne ho trovate, dato che la sintassi è quasi la stessa, tranne molte cose che non bisogna neppure scrivere, ed è quest'ultima la qualità che mi ha colpito, non le cose che sono simili. :)

Python non è paragonabile a Java e C#, perchè non JITta, bytecoda e basta (evviva l'italiano :D)