Re: [Slackit.org] cambio di licenza di XFree86

[Davide Angelocola]

On Jun 6, 2004, at 4:59 PM, Alessandro wrote:
> Le GTK non sono scarse, ma sono anacronistiche,
Ma hai mai usato le GTK+ seriamente? Sono di una flessibilita' unica 
poiche' sono strutturate a strati (glib, gdk, gtk). Esiste il supporto 
per diversi sistemi tra cui figura anche il framebuffer. Lo dimostra' 
l'enorme quantita' di software che le usa. Anche la GUI di Mozilla, se 
non vado errato, e' scritta in GTK+.

> si basano su concetti di
> programmazione vecchi di generazioni e sono ancora in una fase di 
> sviluppo
> tutt'altro che avanzata, forse sono buone in termini di prestazioni ma 
> hanno
> problemi abbastanza complessi per ciò che riguarda l'integrazione dei 
> propri
> componenti.
 Non e' vero che si basano su concetti vecchi: si basano su concetti 
nuovi (sono interamente OOP allo strato gtk) ma usando il ben 
noto/amato/diffuso/compatto C (e comunque sono disponibili binding in 
quasi tutti i linguaggi). E non sto contando swig =)

Per quanto la fase di sviluppo che tu dici essere "tutt'altro che 
avanzata" non sono affatto d'accordo. Siamo giunti alla versione 2.4 e 
uno dei punti di forza delle GTK+ e' la loro estrema affidabilita'. In 
definitiva trovo GTK+ uno dei migliori toolkit attualmente disponibili 
anche se probabilmente usarle da un linguaggio OOP (Python, Ruby, C++ o 
anche Perl al limite) potrebbe essere la scelta ideale.

> La OOP non è la soluzione a tutti i mali ma è la migliore attualmente
> disponibile. La complessità delle applicazioni moderne richiede una
> suddivisione dei problemi che solo con una buona analisi e la 
> programmazione  a oggetti si può raggiungere. Ogni altra tecnica oggi 
> conosciuta provocherebbe uno spreco di risorse ( tempo e programmatori 
> ) eccessivo, ed è anche per questo che le GTK, nonostante il notevole 
> sforzo del team di sviluppo, sono sempre più indietro rispetto a tutti 
> gli altri ( Qt, API Java e MFC ).

Certo che non lo e'. Nessuno scriverebbe mai un compilatore o un 
sistema operativo in un linguaggio OOP. E comunque OOP e' il miglior 
approccio per un certo sottoinsiemi di problemi dove la velocita' di 
sviluppo e la riusabilita' del codice sono fattori chiavi. Evito di 
finire il discorso poiche' gia' ho speso troppe parole per i soliti 
concetti.

La parola chiave nelle applicazioni moderne e' /progettazione/ non 
certo l'approccio per l'implementazione. Tant'e' vero che la tendenza 
degli ultimi anni e' quella di scrivere applicazioni in *diversi* 
linguaggi di programmazione. L'esempio principe e' Mozilla (C/C++).

Conosco diversi informatici e la frase che gli sento uscire piu' 
sovente dalla bocca e': "Ma questo e' un dettaglio di 
implementazione!". :-)

> Con questo non voglio dire che se programmi C++ sei più capace di
> uno che programma in C, anche perché non si può nemmeno fare un 
> confronto del genere.
Sono perfettamente d'accordo.

> Il C++, il C e l' ASSEMBLER, al contrario di come tu dici, sono 
> "stili" che influiscono sul prodotto finale: il C è stato inventato 
> perché
> con l' ASSEMBLER, già negli anni 70, si perdeva troppo tempo a 
> programmare,

Il C++, il C e l'assembly sono solo linguaggi di programmazione. Posso 
scrivere codice procedurale in C++ (che e' male[tm]) e codice OOP in C 
(vedi gtk+ e API python). I linguaggi che usi nell'implementazione non 
sono assopuffamente "stili" ma sono linguaggi, appunto. E' la 
progettazione che, se fatta bene, puo' rendere l'implementazione 
"straightforward" (banale) e il prodotto /dovrebbe/ essere poco 
influenzabile dal linguaggio che userai. In fondo potevo esprimere gli 
stessi concetti di questa mail anche in Inglese o in Spagnolo: la 
semantica non sarebbe cambiata. Non so se ho reso l'idea.

Infine per dire che un toolkit e' migliore di un altro bisogna 
determinare una serie di parametri di valutazione: quando avrai ne 
stillato la lista e analizzato per bene tutti i toolkit potrai dire che 
X e' meglio di Y per questo e questo motivo =)

> poi il C++ ne dovrebbe avere una decina di "+" per dare un' idea di 
> quanto
> sia più potente e versatile del C.
Vero, ma e' anche piu' complesso. La programmazione e' l'eterna lotta 
contro la complessita'. Un buon linguaggio dovrebbe rendere le cose 
facili, facili e quelle difficili, fattibili. Il C++ ci riesce e quindi 
e' buon linguaggio. Per quanto riguarda la versatilita' credo che 
dovro' darti torto marcio. Come ho detto gia' prima c'e' tutta una 
classe di software che e' ancora preferibile scrivere in C (un 
compilatore C lo scrivo in C, una macchina virtuale Java la scrivo in C 
non Java che secondo i tuoi parametri e' piu' potente del C).

Mi scuso per l'eccessiva lunghezza della mail ma quando si parla di C 
(ma anche di Emacs :P) divento suscettibile. Una bevuta gratis a chi ha 
pensato ad una mail di Linus. :-)

Riavulo.

-----BEGIN GEEK CODE BLOCK-----
   Version: 3.1
   GCS/LS/M/TW d? s: a22 C(++) UL++(+++) P+>+++
   L++(++++) E+>++ W++ N+ o? !K w--- !O !M- V PS+
   PE+++ Y+ PGP- t+@ 5? X++ R+++ tv-- b+(+++)DI?
   D+ G++ e>+ h! r- y++**
   ------END GEEK CODE BLOCK------