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

Di: Alessandro Bruni

Alessandro Bruni — Sat, 04 Jul 2009 01:27:36 +0000

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.

Di: Mesh

Mesh — Fri, 03 Jul 2009 19:22:52 +0000

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

Di: charon

charon — Fri, 03 Jul 2009 18:48:16 +0000

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. :)

Di: Mesh

Mesh — Fri, 03 Jul 2009 12:54:15 +0000

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."

Di: Barra

Barra — Fri, 03 Jul 2009 12:39:40 +0000

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

Di: Andrea Cimitan

Andrea Cimitan — Fri, 03 Jul 2009 07:07:41 +0000

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)

Di: charon

charon — Fri, 03 Jul 2009 05:28:07 +0000

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)?

Di: charon

charon — Fri, 03 Jul 2009 05:11:56 +0000

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

Di: charon

charon — Fri, 03 Jul 2009 05:01:58 +0000

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.

Di: charon

charon — Fri, 03 Jul 2009 04:51:24 +0000

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