Newsgroup: it.comp.os.linux.development
Titolo: linguaggio ad alto livello per linux (con binding per gtk, possibilmente...) ??

ciao,
se volessi
- iniziare a scribacchiare qualcosa per linux,
- usare un linguaggio il più possibile ad alto livello ed elegante,
- la possibilità di integrarmi "bene" con il sistema, anche a livello
   grafico e/o sviluppare "cross platform" o portabile
- non avere possibili rogne per i patent in futuro (per questo mono
   mi lascia qualche dubbio...)
- non trovarmi a sviluppare su una tecnologia destinata ad un lento
   oblio (pericolo "rimane solo per motivi di legacy")
cosa mi suggerireste?
fra mono, java, c++, perl6 + parrot, python, scheme, i vari widget
(preferirei gtk perchè non costringe ad usare un oopl, o magari anche qt
lo permette?) non ci capisco 'namazz...
grazie infinite
gabriele, con una passione per la programmazione dinamica, ma
   sacrificabile....

    sacrificabile....
Tcl e` molto dinamico, senza dubbi.  Tanto per fare un esempio, "do
.... while ..." non esiste in Tcl, ma e` possibile scriverlo in Tcl
stesso!
-- 
David N. Welton
 - 
http://www.dedasys.com/davidw/
Apache, Linux, Tcl Consulting
 - 
http://www.dedasys.com/

 cosa mi suggerireste?
python+gtk(+gnome)+pygtk+glade+pyglade
Se puoi (alcune distro ancora non le hanno) parti con gtk 2.6, gnome
2.10 che hanno alcune cose che facilitano molto lo sviluppo.
Dovrebbero migliorare ancora (miglior supporto per pango, per esempio)
dalla 2.8 di gtk e 2.12 di gnome, ma per adesso ci si puo` accontentare.
Bye.
-- 
Alessandro Pellizzari

   sacrificabile....
..ha un senso sacrificare se hai qualcosa in cambio :)
Ruby e python sono decisamente dinamici (il primo leggermente di più)
PS
gabriele pure io, con una passione per la programmazione dinamica non 
sacrificata :)

 per te non vadano bene. Va detto però che anche Gtk sebbene scritto in C
No. Python non e` completamente a oggetti. Ci si puo` programmare anche
a funzioni.
In particolare con Gtk si puo` adottare un approccio completamente a
funzioni, completamente a oggetti o ibrido, a scelta. A me piace
l'ibrido con Glade.
Bye.
-- 
Alessandro Pellizzari

 l'ibrido con Glade.
..e lo stesso vale per ruby (e tcl e perl, AFAIK)

 il che non toglie che sia completamente ad oggetti.
Da come lo scrivevi sembrava fosse obbligatorio programmare a oggetti.
Non conosco minimamente Ruby, quindi non mi ero permesso di commentare.
Bye.
-- 
Alessandro Pellizzari

 Java, nota che la OO può essere semplice e piacevole ;)
aspè aspè mi sono accorto di essermi spiegato male! mi trovo benissimo 
con la programmazione ad oggetti ;)
sicuramente tendo a preferirla alla programmazione 
"imperativa/procedurale classica", ed è mia intenzione usarla quasi 
sempre per eventuali miei piccoli sviluppi sotto linux
solo che se un toolkit mi mette a disposizione un'interfaccia ad oggetti 
ed una non a oggetti mi sento un pò meno "vincolato" ad un solo 
strumento; a volte -in determinate circostanze - torna maledettamente 
comodo mettere direttamente le "mani sotto" e usare il c, ad esempio. 
quindi, avendo tempo di imparare al più un toolkit (lo spero..), tendo a 
preferirne uno sfruttabile in più modi
e poi... a volte ho il dubbio che... - oddio a dirla sembra una cosa 
terribilmente presuntuosa - che l'oop  "dura" (stile java e .net) sia 
stata un pò sopravvalutata, nel senso che è molto buona ma non credo sia 
una panacea per ogni situazione...
non mi sorprenderei se alla lunga si "sgonfiasse" un pò.... magari in 
favore di object model meno rigidi (magari tipo quelli dei linguaggi che 
mi avete citato finora) e/o la parziale introduzione di altri stili di 
programmazione...
posso farvi una domanda clamorosamente ot? ma secondo voi, fra tutte le 
caratteristiche di un linguaggio come ad esempio java o c#, pensate che 
effettivamente l'ereditarietà (singola) (non i namespace, la 
composizionalità, ecc.) sia la più utile/spendibile per progetti di 
piccole dimensioni?
grazie ancora delle vostre risposte ;) e buona pasqua a tutti
gabriele

 lo permette?) non ci capisco 'namazz...
Se punti sulle GTK+ (Ottimo!) esistono i binding
(
http://www.gtk.org/bindings.html
) per molti linguaggi, ma
essenzialmente dovresti scegliere tra C/C++, Java e Python...
Per quanto riguarda la portabilità...le scelte si riducono a due : Java,
e Python.
PS: Sarei interessato a Java, e l'uso di SWING non mi esalta (non
fraintendetemi...è che le GTK+ sono le GTK+!!), qualcuno programma in
Java ed usa le GTK+? I programmi restano portabili "alla Java" (anche su
Windows, è importante)?
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Xoen
Jabber ID : 
xo...@jabber.linux.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 (anche su Windows, č importante)?
Una possibilita` interessate per scrivere applicazioni Java con un
look and feel nativo, e anche portabile nello stesso momento puo`
essere SWT:
http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
http://www.eclipse.org/swt/


 
http://www.eclipse.org/swt/
In effetti avevo pensato all'uso di L&F ... anche perchč penso resti
sempre piů portabile (o sbaglio).
Ma SWT?!? C'č nulla per Swing? Ho trovato questo progetto
(
http://gtkswing.sourceforge.net/
) ma (potrei sbagliarmi) non mi
convince tanto, qualcuno l'ha provato?


 piccole dimensioni?
definisci progetto di piccole dimensioni :)
Se io penso, tanto per dire, ad una piccola gui per una calcolatrice, mi 
pare normale pensare subito a creare una classe BottoneNumerato che 
erediti da Bottone, quindi direi di si.
Ma in assenza di un ambiente OO risolverei con una funzioncina, quindi 
boh :)

 cosa mi suggerireste?
OCaml!! Sicuramente di alto livello ed elegante (come tutti i
linguaggi funzionali). Portabile, perché compilabile in bytecode ed
eseguibile su qualsiasi piattoforma (un po' come java), ma anche molto
performante quando compilato in codice nativo.
Ha un controllo sui tipo molto forte e statico, inferenza di tipo,
higer order functions, polimorfismo parametrico e molto altro...
Per sviluppare interfacce grafiche ci sono bindings per tk e gtk (e
prossimamente wxwidgets).
Non mi dilungo piů di tanto, ma a
http://lurker.oltrelinux.com/message/20030422.153743.5c0efaae.it.html
trovi un mio vecchio messaggio in cui sono illustrate le
caratteristiche principali del linguaggio in maggiore dettaglio.
Maggiori informazioni su 
www.ocaml.org
. 
Flavio

 cosa mi suggerireste?
Pascal, soprattutto nella sua incarnazione FreePascal:
- portabile (ricompili senza problemi);
- utilizzabile sia ad oggetti che in maniera procedurale;
- semplice;
- in caso di ottimizzazioni e` possibile lavorare a basso livello (leggi
  ASM);
- ha i binding per GTK 1 e GTK 2;
- con Lazarus hai un ambiente RAD alla Delphi.
L'unica cosa per cui pecca, secondo me, e` il fatto di non avere qualcosa a
livello di JDBC (cosa che invece hanno Java, Perl, Python e Delphi), ma per
il resto e` ottimo
Henryx

 altre piattaforme.
Intanto un progetto in Java gira su un qualsiasi sistema che abbia una Java
Virtual Machine, sia essa di Sun o di altri (e.g. IBM e Apple scrivono una
JVM per conto proprio). Per quanto riguarda i binding per le varie GUI, che
io sappia vi sono questi:
- binding per le QT;
- binding per le GTK;
- binding per GNUStep;
- binding per KDE;
- binding per console (con sintassi simile a Swing);
- SWT.
A parte i binding per console (che, se non erro, sono indipendenti dalla
piattaforma), tutti gli altri molto probabilmente (non li ho mai provati)
dipendono dalle librerie a cui sono associati. Discorso a parte invece per
le SWT che, oltre ad avere un approccio di programmazione differente
rispetto alle Swing, riproducono una GUI similare all'ambiente su cui
lavorano (per ora win32, OSX, GTK2/Motif). Ovviamente, utilizzare uno di
questi binding comporta il dover distribuire le librerie associate assieme
al progetto creato, cosa non necessaria invece se si sviluppa in Swing
Henryx
P.S. vi e` anche un binding di nome SwingWT (non ho mai capito pero` se sia
un progetto che mira ad essere un compromesso tra SWT e Swing oppure
altro), ed un binding per WxWidget

 Apple scrivono una JVM per conto proprio).
Il problema e` che ci sono tanti sistemi che non hanno JVM.


 Il problema e` che ci sono tanti sistemi che non hanno JVM.
Tanti? Quanti? (a me viene in mente solo bsd e non ne sono neanche sicuro).
Alessandro.

 Il problema e` che ci sono tanti sistemi che non hanno JVM.
Ripeto, se non vi e` una JVM Sun, non significa che non vi sia il supporto a
Java
Henryx

 writes:

Debian gira su:
i386, m68k, sparc, alpha, powerpc, arm, mips (sia big che little
endian), hppa, ia64, s390, amd64, sh (SuperH).
Per non parlare di NetBSD che gira su una varieta` ancora piu`
impressionante di sistemi.
E visto che Java (TM) ufficiale non e` software libero, e` vietato
fare il porting per questi sistemi senza l'ok di Sun.
Saranno sistemi meno importanti, ma comunque e` un esempio pratico dei
limiti del software propretario.
Se uno vuole puntare su Java, comunque, penso che questo problema
sara` aggirato a breve dal lavoro di Classpath + GCJ/Kaffe/etc...  ma
bisogna stare piu` attenti a dove quei sistemi sono compatibili o no.
Saluti,


 
Piu' che altro ci vuole qualcuno che si prenda la briga di farlo :-D
 > Saranno sistemi meno importanti, ma comunque e` un esempio pratico dei
 > limiti del software propretario.
Si, attenzione pero' a non esagerare.
Avere un linguaggio non proprietario non e' garanzia di disponibilita' 
su qualunque piattaforma: per esempio qualche tempo fa ho cercato una 
versione di python per palm, esiste, ma non e' che sia proprio 
aggiornatissimo.
Alessandro.

 fare il porting per questi sistemi senza l'ok di Sun.
Ok che, a quanto mi sembra di vedere, la Sun da volentieri se tu rispetti le
sue regole (e.g. non modificare le funzionalita` base della JVM[1]).
Altrimenti mi spieghi perche` gcj, kaffe e gli altri progetti derivati da
Java sono ancora in circolazione? Per quanto riguarda inoltre i *BSD, a
parte la possibilita` di utilizzare la versione per linux, vi e` un
progetto di creazione di una JVM nativa su FreeBSD (sul sito vi dovrebbero
essere maggiori dettagli) in cui vi e` l'appoggio diretto di Sun stessa
Henryx
P.S. tanto per citare un distributore di JVM non Sun: Blackdown
[1] vedi il caso MS contro Sun

 python per palm, esiste, ma non e' che sia proprio aggiornatissimo.
Certo, hai ragione, e come avevo scritto, c'e` chi sta lavorando molto
bene su "free java".  Infatti, la nuova Fedora dovrebbe avere java ==
gcj.


 P.S. tanto per citare un distributore di JVM non Sun: Blackdown
Blackdown, a differenza di gcj e kaffe, e` un derivato dal codice Sun,
e quindi sono sempre vincolati...


> piccole dimensioni?
Ehm...non ho capito la domanda :(
Comunque in teoria Java non supporta l'ereditarietà multipla, ma in
pratica grazie all'uso delle interfacce è come se la supportasse.


 pratica grazie all'uso delle interfacce è come se la supportasse.
permettimi di dissentire. L'uso delle interfacce non ti permette di 
supportare l'ereditarietà multipla o, perlomeno, non al livello 
consentito dai linguaggi che la prevedono esplicitamente (ad esempio, 
C++). Non voglio entrare nel merito del giusto o sbagliato, ma la tua 
affermazione imho è discutibile.
-- 
si prepara direttamente nel bicchiere basso detto "tumbler basso". Tre o 
quattro cubetti di ghiaccio, aggiungere il gin, il martini rosso, il 
bitter campari e mescolare. Guarnire con una fetta d'arancia.

 affermazione imho è discutibile.
Lo so, non supporta l'ereditarietà multipla, ma grazie alle interfacce
si possono creare classi che hanno "caratteristiche" "ereditate" da più
"classi" (interfacce).
Non so se mi spiego, non voglio dire che supporta l'eredità multipla
(bestemmierei ;)), ma che grazie alle interfacce evita che sia un limite
al linguaggio.


 Da come lo scrivevi sembrava fosse obbligatorio programmare a oggetti.
Che io sappia l'unico linguaggio diffuso che ti *obbliga* a creare un 
oggetto anche se non serve è java...
In effetti è stato detto più volte che nonostante il suo approccio 
"rilassato" python è "più a oggetti" di java :-)
-- 
Renato

 aggiornatissimo.
Solo perchè evidentemente il progetto non ha generato abbastanza 
interesse in abbastanza sviluppatori.
E poi PalmOS è una piattaforma in declino, non ha molto appeal (casomai 
le nuove versioni...).
Python però c'è per Symbian Serie60, scaricabile liberamente dal sito di 
Nokia assieme a sdk e documentazione.
-- 
Renato


Che conferma la mia obiezione.
Alessandro.

 pratica grazie all'uso delle interfacce è come se la supportasse.
sinceramente l'ereditarietà multipla di interfaccia in java mi è sempre 
sembrata una palla, perché porta (o può portare) ad una certa 
duplicazione di sforzi. Non è un caso che ogni tanto qualcuno proponga 
di aggiungere a Java i mixin, che evitano i problemi dell'ereditarietà 
multipla ma permettono di risparmiare molto codice.
Esempio: in ruby esiste un modulo chiamato Enumerable.
Per usarlo bisogna implementare in una nostra ipotetica classe 
Collezione un metodo "each()" che restituisca uno dopo l'altro gli 
elementi, e "mixare" il modulo Enumerable.
Automaticamente, ogni oggetto della nostra classe ottiene i metodi:
- all?, verifica se tutti gli elementi verificano una condizione
- any?, verifica se almeno un elemento verifica una condizione
- entries, trasforma la collezione in array
- find, trova la prima occorrenza per cui valga una condizione
- find_all, li trova tutti
- include?, verifica se un oggetto è nella collezione
- map, applica una trasformazione agli elementi
- max, trova il massimo
- min, trova il minimo
- partition, divide la collezione in due secondo un criterio specificato
- reject, cancella gli elementi
- sort, quicksort sulla collezione
ed altri ancora. Il che è un risparmio di codice notevole :)

test ha scritto:

Uh... se l'obiezione è che per avere java su una piattaforma basta che 
ci sia qualcuno che si sbatte... non è del tutto esatto.
Prova a chiamare "java" o "jvm" la tua versione per (diciamo) C64 e 
vedrai quanto ci mette l'ufficio legale di SUN a scriverti...
Microsoft ha *perso* la causa per aver chiamato jvm la sua versione che 
faceva anche chiamate native (ad activeX se non erro)... che poi fosse 
un'aborto sono d'accordo, ma resta che non puoi fare il porting di java. 
Puoi solo fare un "work-alike".
Per l'hobbysta puo' bastare, ma un'azienda che vuole java vuole java 
(non kaffe)
-- 
Renato

 vedrai quanto ci mette l'ufficio legale di SUN a scriverti...
La cosa interessante e` che, se non sbaglio, Redhat sta facendo
proprio questo con l'ultima Fedora, dove includono gcj come Java.
Vedremo come si muove Sun...


 java... non la troverai :-)
https://www.redhat.com/archives/fedora-announce-list/2005-March/msg00035.html
    A solid foundation of Java packages for developers (ant, gcj,
    tomcat, struts, more classpath stuff) and the ability to possibly
    run Java apps through gij.
Ci vanno comunque molto vicino.


 
Secondo me no. MS è stata condannata per aver messo "Java(tm) JVM" in 
explorer, mentre in realtà era la MSJVM leggermente incompatibile.
Sta parlando di java packages (pacchetti SCRITTI in java) e della 
possibilità di lanciarli con gcj, no?
-- 
Renato


Diciamo che *solitamente* (caso ms a parte) basta qualcuno che si sbatte 
(altrimenti non mi spiego l'esistenza di blackdown).
Alessandro.

 
Nein.
Redhat usa semplicemente il sistema "alternatives" che esiste da 
millanta anni su debian. Tu scrivi "java" a terminale e lui esegue 
quello che ad alternatives e' stato detto essere java.
Non equivale mica a vendere/distribuire un java alternativo a quello di 
sun con il nome java, no?
Ma prova a trovare dove Redhat sostiene di avere installato java, o 
prova a trovare con "rpm -qa | grep java" una menzione alla sdk di 
java... non la troverai :-)
-- 
Renato

 faceva anche chiamate native (ad activeX se non erro)...
Erri. Microsoft ha perso la causa in quanto la JVM da lei implementata era
palesemente differente dalla JVM di Sun (ergo, un'applicazione scritta per
la JVM di MS funzionava solo con tale JVM, indipendentemente dal fatto che
venivano utilizzati solo componenti della libreria standard di Java). In
caso contrario, anche Apple sarebbe da citare, in quanto le Swing su MacOS
X fanno chiamate dirette al sottosistema grafico (senza contare
l'integrazione della JVM con l'intero sistema)
Henryx

 pratica grazie all'uso delle interfacce è come se la supportasse.
Da quello che ho capito dell'ereditarieta` multipla, questo e` l'unico
metodo sensato di utilizzo di tale caratteristica. In pratica, in Java e`
stato solo formalizzato e distaccato, permettendo quindi un utilizzo piu`
flessibile
Henryx

 si creano molte inconsistenze)
Attenzione, in Java qualsiasi tipo primitivo ha una sua controparte ad
oggetti. Inoltre, al posto degli array puo` essere utilizzata benissimo la
classe Vector. Che poi nella pratica vengano utilizzati quasi
esclusivamente tipi primitivi (e che la classe Vector venga relegata ad un
ruolo di secondo piano), con l'unica eccezione della classe String
(utilizzata soprattutto per la sua flessibilita`), e` un altro paio di
maniche
Henryx

 Henryx
ma gli sviluppatori poverini usano quello che si trovano davanti, non li 
incolpo :)
(non incolpo neanche java, è solo che ritengo sarebbe migliorabile)

 flessibile
perché più flessibile?

 al linguaggio.
Dipende da cosa intendi con limite.
-- 
[ RiK0                                ]
[ Go away! The internet is full!      ]
[ Non credo negli schemi non vincenti ]

 l'integrazione della JVM con l'intero sistema)
Nah... e poi non credi che Apple abbia preso accordi specifici con SUN?
-- 
Renato

 di C#, del CLR e tutta la baracca e burattini di .NET.
no, è passato a J#, quello di C# prima aveva fatto Delphi alla borland :)
Nota: se non ricordo male J# è in effetti ancora compatibile come 
sintassi con java 1.1, tant'è che naked objects compila sia per .net che 
per jvm

 per jvm
Beh, in fondo per quanto riguarda microsoft quella versione č l'ultima 
di java. Tutto ciň che č successivo non solo gli sta sui cosiddetti per 
motivi economico/politici, ma non la possono toccare neanche col 
proverbiale bastone di tre metri, per via della causa SUN.
-- 
Renato

 piccole dimensioni?
L'ereditarietà è la caratteristica della OOP di cui più si parla, solo
che se studi un pò di design patterns scopri che nel 90% dei casi non è 
conveniente usarla, nè per progetti piccoli nè per quelli grossi.
La vera potenza della OOP è nel polimorfismo è nell'uso di interfacce
che permettono di ottenere oggetti lascamente accoppiati e quindi
facilmente riutilizzabili.
Io sto lavorando ad un tool di sincronizzazione tra basi di dati
diverse, e sapere che un buon 70% di codice sarà riutilizzabile a
prescindere da quali basi di dati si utilizzano e da come comunicano
(network, file, piccione viaggiatore :) ), mi fa stare bene :).
Ciao

 conveniente usarla, nè per progetti piccoli nè per quelli grossi.
c'è una ragione per cui se ne parla[1], se non la usi tanto vale usare 
visual basic 6 o programmare in pascal con i record ;)
[1] 12, dice meyer, almeno nei linguaggi class based

 visual basic 6 o programmare in pascal con i record ;)
Probabilmente è più semplice spiegare l'ereditarietà che il motivo per
cui un oggetto non dovrebbe mai essere referenziato direttamente, ma
solo tramite una interfaccia.
In "Design Pattern" della cosidetta "Gang of Four" sono mostrati molto
bene i problemi derivati dalla progettazione di gerarchie di classi che
portano ad avere oggetti fortemente accoppiati e difficilmente riutilizzabili.
In particolare credo che dei 23 pattern presentati solo 4-5 utilizzino
l'ereditarietà, mentre tutti gli altri si basano sulla composizione di
oggetti, e naturalmente sulla definizione di opportune interfacce.
Chiaramente l'eredità è una caratteristica potente della OOP, solo che
va utilizzata con parsimonia e solo dove serve, e non deve stupire
trovare progetti complessi, basati sulla OOP, dove non viene utilizzata
per nulla.
Ciao

 per nulla.
Io discuto il "90% dei casi non va usata ne' in progetti piccoli ne' 
grossi". Oddio, qua discuterei anche "progetti basati sull'OOP dove 
lereditarietà non viene utilizzata per nulla" che è prossima 
all'ossimoro ;) ma sorvolo..
Per me la classica divisione is-a/has-a è un'indice sufficiente di come 
vada usata e quando, e non è una cosa tanto rara.
Tutto, ovviamente, IMHO, e chiudo qua.

 Nah... e poi non credi che Apple abbia preso accordi specifici con SUN?
L'unico accordo che Sun accetta e` quello di creare una JVM pienamente
compatibile con la propria :)
Henryx

 perché è l'unico sensato?
Perche` e` l'unico che permette all'eredita` multipla di essere utilizzata
in maniera proficua senza incasinare in maniera catastrofica il codice da
te scritto. Per quanto riguarda la flessibilita`, e` piu` che altro una mia
impressione (potrei quindi sbagliarmi)
Henryx

Henryx ha scritto:

E quella di apple lo č, AFAIK
Se chiamando le solite funzioni SWING l'interfaccia viene aqua invece 
che Ocean... sono questioni di Look and Feel, no?
-- 
Renato

 che Ocean... sono questioni di Look and Feel, no?
Da quello che mi e` parso di capire no (non ho approfondito molto
l'argomento). Nel senso, in OS X una chiamata Swing dovrebbe effettuare
direttamente una chiamata nativa alle Carbon, restando comunque pienamente
compatibile alle Swing di Sun (non dimentichiamoci che OS X e` stato
progettato con in mente una maggiore integrazione di Java rispetto agli
altri sistemi operativi, Solaris incluso)
Henryx

 compatibile alle Swing di Sun 
Non ci siamo capiti: tu descrivi esattamente quello che ho scritto io: 
che faccia chiamate native è irrilevante per SUN. L'importante è che non 
rompa la compatibilità.
La JVM di microsoft è stata cassata perchè NONOSTANTE fosse proposta 
come porting ufficiale era sottilmente incompatibile con la 
contemporanea jvm 1.1 di SUN (per ovvio tentativo di embrace and extend 
di microsoft, come con l'html malinterpretato di IE)
-- 
Renato

 impressione (potrei quindi sbagliarmi)
capisco