Newsgroup: it.comp.macintosh
Titolo: Il sistema ideale. Linux. MacOS X

Uso indifferentemente GNU/Linux o MacOS X. Ho una buona conoscenza di
entrambi (anche se non sono piu` aggiornatissimo).
In generale mi trovo a svolgere compiti simili in entrambi i sistemi. 
Come GNU/Linux uso Debian Sarge.
Faccio anche presente che io GNU/Linux me lo sono configurato per
benino, non sto provando a sostenere che sia piu` facile di MacOS X. Me
la sono sudata. Ma ora ne godo i frutti.
In generale a me GNOME piace come interfaccia utente. La trovo molto
usabile, e per assurdo quasi piu` maccosa di MacOS X (beh... per
assurdo. in realta` non lo e`).
E mi piace pure molto Aqua.
Mi chiedo... perche` ogni volta che sono su uno dei due sistemi, deve
mancarmi qualcosa dell'altro?
Per esempio su Debian installare programmi e` una brezza. Faccio una
ricerca sul mio database locale, poi installo. Non ho problemi di
dipendenze... non devo quasi mai compilare.
Tutto centralizzato. Mi viene tutto aggiornato.
Su MacOS X questo vale (in parte) per fink. Tutto il resto grava sulla
mia attenzione (vedere quando esce una nuova versione, vedere se e`
compatibile con il resto del mio sistema).
Inoltre FinkCommander imho non e` usabile quanto Synaptic (di recente lo
preferisco perfino ad Aptitude).
Per esempio... quando ho voluto iniziare a provare a programmare con
PyQT, mi sono dovuto sudare 7 camice. I pacchetti stabili non erano
ancora compatibili, ho dovuto usare quelli in beta... poi alla fine ha
funzionato tutto... ma ci ho perso tanto a compilare. E tutt'ora la
documentazione di QT per esempio non e` integrata con quella del MacOS
(certo, colpa di Trolltech, non di Apple). Fortunatamente ci lavoro
tramite Python, e li tutta la doc e` uniforme e ben accessibile.
Con Deb ho scritto di installarmi PyQt, e ha fatto tutto lui.
E poi vabbe`... per i compiti di tutti i giorni MacOS X e` piu` facile.
Per esempio non devo ricordarmi di installare Flash. Java funziona bene
(su Debian per esempio non e` integratissimo... anzi... un giorno ci
dovro` lavorare su).
D'altra parte quando sono su GNU/Linux mi manca alla follia MacSOUP
(anche se credo che piano piano lo abbandonero`, troppo poco
'compatibile').
Insomma... per molti dei compiti di sviluppo GNU/Linux e` piu`
amichevole. Certo, si riesce a ottenere lo stesso anche sotto MacOS X...
pero` magari io non consoco il metodo altrettanto intuitivo.
E poi c'e` Cocoa. Cocoa e` fantastico. Mi piace perfino piu` di QT (poi
quando avro` tempo daro` un occhio approfondito a gtk... sono rimasto
alle 1.x in C... poi lo credo che le trovo poco amichevoli ;) ).
E` rapidissimo sviluppare.
AppleScript e` bellissimo... ma ancora una volta... e` una cosa che io
conosco poco e uso poco. Problema mio, certo.
Quando sono su MacOS X per contro mi manca OpenOffice, e mi chiedo per
quale ragione Firefox risulti un po' marziano...
Potrei andare avanti per molto molto tempo.
E in generale quello che mi manca di GNU/Linux non lo posso aggiungere
(non e` un programma che posso scrivermi, insomma... anche perche` i
singoli applicativi funzionano quasi tutti).
Beh... scusate per lo sfogo.
-- 
RiK0
Non credo negli schemi non vincenti.

 dovro` lavorare su).
Di Java mi affascina l'integrazione della JVM nel sistema, che promette
prestazioni brucianti. Su Debian per motivi di licenza non e' disponibile
il JRE di Sun (anche se puoi installarlo manualmente), e devi ripiegare sul
port di Blackdown Java.
-- 
artemis.alpeia
Mi consenta avvocato, le hanno detto che il garzone del garage ha investito
sua figlia con l'automobile dell'amministratore?

 quale ragione Firefox risulti un po' marziano...
NeoOffice, no? E' parecchio usabile.
Firefox... ragione, c'hai, ma conta che a disegnare le finestre non e'
ne' Cocoa ne' Carbon direttamente, ma il motore XUL di Mozilla (vedi
anche Nvu, Thunderbird, Sunbird) che poi usa Carbon per parecchi aspetti
ma "fa da se'" anche dove non dovrebbe. Camino fa una figura molto
migliore a livello di integrazione con l'OS (usa Cocoa per tutto, anche
i widget nelle pagine visualizzate da Gecko).
 - ∞ 

 'compatibile').
quando sono su osx mi manca da morire KNODE...
cmq dopo aver usato OSX, usare linux mi sembra quasi un 
"involuzione"...mi capita spesso di invocare invano exposé e di tentare 
arditi drag&drop
L'unica cosa invidiabile è il tool APT, IMO

 prestazioni brucianti.
Che mantiene solo in minima parte.
La JVM e' velocissima perche' il sistema puo' condividere le porzioni di
codice tra piu' processi. Ma la performance latita parecchio. Il nuovo
Swing (Cocoa-based invece che Carbon-based come quello di Apple Java
1.3) fa schifo. SWT, inoltre, e' parecchio lento. Provate a far girare
Eclipse con meno di 512mb di ram, o su processori < 1ghz...
(sul mio iMac 17" 1ghz, 512mb ram, Eclipse [girando dal disco interno,
mi pare un 5milaepassa rpm] si pianta per una ventina di secondi la
prima volta che apre l'autocompletamento. Sotto w2k, p4 1,8ghz, 512mb
ram, disco 5milaepassa rpm, situazione lavorativa simile, ci mette meno
di 5s.)
 - ∞

 preferisco perfino ad Aptitude).
fink ha altre sfighe notevoli
la peggiore delle quali e' che ti costringe a duplicare programmi gia' 
installati:
volevo vedere a che punto sono arrivati con koffice e gli ho detto di 
compilarmelo: e' partito lo scaricamento di 150 pacchetti di cui almeno 
4-5 duplicano cose che sono gia' installate (la piu' preoccupante e' il 
python) tant'e' che ho messo /sw/bin/:/sw/sbin in fondo al path e non 
davanti come vorrebbe lui
spero che basti a salvarmi dai casini, tanto poi fra 2 giorni vengo 
preso dal solito raptus e butto tutto/sw (per poi riscaricarmelo quando 
mi viene un altro ghiribizzo :-O)
(la compilazione dei 150 e' partita 2 min fa, speriamo bene, la ventola 
sta cominciando a pompare seriamente :-O!)

 arditi drag&drop
Boh... a me invece i drag and drop fungono bene.
Semmai mi capita di selezionare del testo con il mac e aspettarmi che
sia stato 'copiato' :))


 installati:
Giusto. Dimenticavo. Per esempio python... fink ha parecchi pacchetti di
python... ma mi vuole installare il suo caxxo di interprete.


  - ∞ 


 port di Blackdown Java.
Bzzz io non ho capito per quale ragione ho conflitti inenarrabili. Ma
vabbe`... prima o poi mi attrezzo.


 man deborphan
argh, non sapevo fosse integrato in synaptic... l'ho visto solo ora tra i
filtri ^^;
-- 
artemis.alpeia
L'amministratore avvisa i condomini che l'ascensore sara' fermo per
riparazioni per tutta la giornata di domenica

 quando sono su osx mi manca da morire KNODE...
completamente daccordo, ne stiamo facendo un porting su osx, vuoi unirti
a noi?
EmJey
-- 
Non prendere la vita troppo sul serio...
non ne uscirai mai vivo

 E in generale quello che mi manca di GNU/Linux non lo posso aggiungere
pero', dopo aver provato Gnome 2.8 direi che alcune cose stanno
procedendo piu' velocemente di quanto previsto: linux realmente desktop
in 3 anni, secondo me.


 la sono sudata. Ma ora ne godo i frutti.
<cut>
Hai installato entrabi i sistemi operativi su un solo mac ? 

 filtri ^^;
Io peraltro da synaptic non lo ho mai usato. Sono iperniubbo del
programma. 
Sono troppo comodo da linea di comando :))
Cioe`... quando mi ricordo Synaptic e` piu` comodo (piu` comodo di
aptitude e di diversi ordini di grandezza di dselect).
Pero` spesso ho fatto tutto da terminale prima di ricordarmelo :))


 in 3 anni, secondo me.
Il problema non e` in GNOME. Quello e` perfetto gia` ora.
Il problema sono:
1) tools di configurazione unificati e facili da usare
2) *installazione e configurazione periferiche*. ma qui bisognerebbe
spiegare alla gente che non possono pretendere che certe cose funzionino
davvero.


 Hai installato entrabi i sistemi operativi su un solo mac ? 
No. Sul Mac ho poco spazio. Per GNU/Linux ho un PC apposta (e un vecchio
Mac).


Ho visto molti messaggi a cui avrei dovuto rispondere, ma per non
frammentare il tutto farò un unico messaggio.
Molti hanno detto cosa manca a linux per essere simile a mac os x
(esteticamente e funzionalmente parlando).
Ecco il mio consiglio:
-) kernel 2.6.9 con patch sleep (nel 2.6.10 probabilmente sarà già
integrata), in questo modo gli ibook/pbook G3 e G4 (tranne pbook 12'' per
via della scheda video nvdia) andranno a nanna come con mac os x.
-) xorg (accellerazione 3D su ibook/pbook con schede video ati), inoltre in
futuro supporterà anche trasparenze reali come succede con mac os x (al
momento il tutto è ancora un po' sperimentale e lento)
-) kde 3.3.x
-) un set di icone stile mac
-) un cursore stile mac (ne esiste uno su 
kde-look.org
)
-) tema baghira: su ppc ha ancora un paio di problemi con i colori dei
pulsanti di apertura/chiusura delle finestre, per il resto il look è
identico a quello di mac os x
-) kompose per avere un buon clone di expose
-) kxdocker 
ed ecco fatto! :)
Per chi invece volesse usare le applicazione di kde *nativamente* in mac os
x consiglio di guardare il progetto kde on darwin:
http://wiki.befunk.com/tiki-index.php
Al momento funziona abbastanza bene, l'unico neo sono i programmi
leggermenti datati (si potrebbero sempre compilare a mano le nuove
versioni).
Da buon utente gentoo segnalo anche che attualmente è possibile usare il
portage di gentoo anche su mac os x.
Per maggiori info: 
http://www.gentoo.org
 oppure 
http://www.gentoo.org/doc/it/macos-guide.xml
Se avete delle domande fatevi pure avanti ;)

 -) kxdocker
Ah.. dimenticavo:
-) amarok: è chi la sente la mancanza di itunes?
-) kdevelop,quanta: per sviluppare in un ambiente grafico ottimo
-) kopete: come client di chat (aol, icq, messenger, yahoo messenger)
-) kvirc / xchat: per chattare su irc
e la lista sarebbe molto lunga... :D

 Se avete delle domande fatevi pure avanti ;)
 > Per chi invece volesse usare le applicazione di kde *nativamente* in 
mac os
 > x consiglio di guardare il progetto kde on darwin:
 > 
http://wiki.befunk.com/tiki-index.php
se installo sta roba e' poi facilmente cestinabile o mi infesta le dir 
in modo semi irreversibile?
 > Al momento funziona abbastanza bene, l'unico neo sono i programmi
 > leggermenti datati (si potrebbero sempre compilare a mano le nuove
 > versioni).
intendi le nuove versioni non portate *nativamente* su osx?
altra domanda
volendo giochicchiare con linux sull'imac g5 e avendo il seguente vincolo:
il disco interno DEVE rimanere intoccato, manco un butloader ci può stare!
e avendo un disco firewire esterno con spazio a sufficienza ma, ahime' 
tutto assegnato a una partizione HFS+ (volendo posso bacuppare e 
riformattare ma che OO, meglio sarebbe potere shrinkare la partizione 
senza perdita dei dati...)
cosa mi consigli?

 -) kvirc / xchat: per chattare su irc
Ecco... xchat. Quello si. Lo uso anche su MacOS X (peraltro).
Non mi fa nemmeno rimpiangere la puttanazza... (quanti ricordi con
BitchX :)) )


 senza perdita dei dati...)
Beh... al momento i tipi di Mdk PPC sostengono che la nuova Mdk si puo`
installare su dischi esterni firewire. Chiaramente io il backup lo
farei.
Se come a me non ti piace Mdk, puoi farlo di certo anche con le altre,
basta capire un minimo come :)) 
[ probabilmente e` banale ].


 
http://www.gentoo.org/doc/it/macos-guide.xml
Funziona bene? Come si integra con i pacchetti che mi installo a mano?


 
http://kde.opendarwin.org/
Ah... poi per i binari si appoggiano appunto a 
kde.opendarwin.org


 [ probabilmente e` banale ].
(probabilmente richiede + tempo e risorse di quelle che posso dedicarci)

), e ci si possono fare
anche belle cose complete. Ma un linguaggio a forte tipizzazione aiuta a
trovare errori, a organizzare le idee, a progettare prima di scrivere.
Che non e' affatto male.
Che poi uno debba sputar sangue per chiamare metodi arbitrari su un
oggetto in Java e' vero, ma perche' stai chiamando un metodo arbitrario
su un oggetto? Qualcosa che non va c'e'. Ritornare al tavolo da disegno
please.
Poi tutto questo e' detto da un hobbista/studente. Lo so che in ambiti
lavorativi o cmq piu' seri la filosofia e' ben altra ("get the work
done").
 - ∞

 Funziona bene? Come si integra con i pacchetti che mi installo a mano?
Al momento è ancora in una fase di sviluppo iniziale. Funziona bene ma i
programmi installabili non sono ancora tantissimi.
Per i programmi che ti installi potrebbero esserci dei problemi se essi
fossero tra le dipendenze di un programma che stai installando. In questo
caso emerge li sovrascriverebbe con una sua versione (a meno che tu non li
metta nella lista dei programmi già installati). Ad ogni modo ti consiglio
di abbandonare le installazioni a mano ed usare direttamente il portage.
Spero di non essere stato troppo difficile, ti consiglio di dare un'occhiata
al funzionamento di gentoo e del suo portage.

 tutt'ora uso script di shell per ascoltare musica.
prova mp3blaster, molto carino
Dimenticavo un'altro programma notevole: mol (Mac On Linux).
Si tratta di un emulatore che permette di eseguire macos all'interno di
linux. Non è comunque un emulatore come vmware o virtualpc, infatti mol fa
partire macos direttamente dalla sua partizione nativa. Inoltre supporta
altivec, sfruttando direttamente l'hw della macchina (senza creare quindi
un pc virtuale).

 e cosa ti manca? :)
Quante CAVOLO di volte in AppleScript studio ho lanciato maledizioni a
ogni NSReceiverQuellocheèError o NSCannotCreateScriptCommandError perché
AppleScript mi lasciava scrivere codice in un certo modo quando poi non
gli piaceva quel che facevo a runtime...
Solo a cercare dove stavano "i file assegnati ad un certo target" nelle
innumerevoli suite Xcodiche ci sono stato una vita e ancora non li ho
trovati.
Agh.
Meno male che Anteprima di 10.4 e' scriptabile, che era uno dei dolori
che mi affliggevano da una vita :D
 - ∞

 davvero.
Dipende dalle cose. Se altrove funzionano, perché non devono funzionare
anche sul Pinguino? (Vedi udev con dbus.)
Se poi ti riferivi alle specifiche chiuse, li' si puo' far ben poco.
 - ∞

 allegramente pure su GNU/Linux.
vuoi iniziare un porting di Gnome su MacOsX? accomodati ma se posso
darti un consiglio metti su un bel gruppo perche' e' una vera ammazzata
(lo e' avendo le librerie gia' portate da qualcun altro, mi immagino che
culo debba essere se devi portare pure le librerie .-P)


 cosa mi consigli?
Fai un copia dei dati sul disco firewire, ripartizionalo da mac os x
lasciando dello spazio libero per linux.
Installa una distro su quello spazio libero e poi ha due alternative:
1 - metti yaboot (il boot loader per ppc) sul disco firewire
2 - ti crei un bootdisk, lo metti su un cdrom e fai il boot dal cdrom
Non per spaventarti ma sotto ppc lo schema di partizionamento, boot del
sistema e gli strumenti da utilizzare sono ben diversi dal mondo i386
(supponendo che tu abbia un po' di dimestichezza con fdisk, lilo/grub),
buona fortuna se sei alle prime armi ;)

 buona fortuna se sei alle prime armi ;)
no beh qualcosina so, sapevo, son passati troppi anni e le tennologie 
evolvon veloci (grub non c'era)
con calma daro' un occhio, magari incomincio a fare il becap, poi 
riformatto e lascio un po' di spazio (30 giga bastano?), ci sono altre 
avvertenze tipo lo spazio per yaboot deve stare in qualche posto 
particolare?

 Se poi ti riferivi alle specifiche chiuse, li' si puo' far ben poco.
Ecco appunto. Oppure alternativamente ti trovi davanti ad hardware
leggermente modificato, per cui viene riconosciuto in un modo, ma
effettivamente funziona un po' in un altro (tipo il fastrate... devi
metterti a patchare i driver... non proprio un esempio di user
friendlyness, permettimi di dirlo).
Ti trovi davanti cose che non hai la piu` pallida idea di cosa siano
*dentro*.
Non solo. Gia` il fatto di 'partizionare' spaventa. La gente comune non
ci e` abituata. 
Poi prendi una banale scheda wireless supportata. Devi scaricarti il
firmware da qualche parte, oppure estrarlo dal driver di windows.
Metterlo in una certa cartella...
Insomma... manca ancora molto. E non nascondiamoci dietro un dito. Puo`
essere fatto... ma finche` non si ha il minimo supporto dei produttori
di hardware (il driver di cui ti parlo e` open source, ma il firmware
non e` distribuibile con il driver)....


 please.
Ritornare a Python. O al piu` ad ObjectiveC. Java e` un ibrido
insensato. E` riuscito grosso modo a prendere il peggio di entrambi i
mondi.
Insisto. Sentirmi con le mani legate non mi piace. Esattamente come non
mi dispiace avere l'ereditarieta` multipla, anche se in modo *brutale*
non la userei mai. In pratica la uso come di possono usare le
interfacce, o roba simile. 
Ma mi e` comodo averla (certo che non faccio ereditare un gatto da un
pianoforte a coda perche` hanno 4 gambe e una coda).
Anche perche` qualche uso 'lecito' dell'ereditarieta` multipla che va
oltre l' 'implementazione di interfacce' ci puo` essere. 
Certo poi magari uno si trova a fare cross_casting... (in C++
tipicamente)... ma finche` sa quello che sta facendo, posso anche dire
che va bene... metta tanti bei commentini, e sia pronto a una palata
nella nuca se sega.


 Dimenticavo un'altro programma notevole: mol (Mac On Linux).
Capisco su Pegasos.... ma su un Mac :))
Voglio dire, al piu` mi fa saltare un reboot.
E poi io sono sempre stato contrario ai dual boot. si adattano poco al
mio modo di lavorare, e mi creano problemi sulla sincronizzazione dei
dati. Tutto risolvibile, ma preferisco risolvere alla radice. :))


 culo debba essere se devi portare pure le librerie .-P)
E` lo so... il primo passo sarebbe portare le GTK2. Purtroppo da un lato
mi rendo conto che e` un macello incredibile. Sono tante, e per
'rimappare' il tutto su Carbon... forse basterebbe lavorare con gdk...
poi il resto si appoggia quasi tutto li (o per lo meno una volta era
cosi`...).
Ma si... mi rendo conto che e` un dolore atroce. E non ho a disposizione
un numero di persone sufficiente. E soprattutto mi mancano un po' di
skills. Gtk non lo conosco bene. Sembrera` assurdo, ma ho lavorato con
QT (Gtk non lo tocco da credo 3 anni).
Su tutto aggiungiamo che considero le interfacce grafiche un male
necessario (ovvero... preferisco dedicarmi a logica, progettazione,
strutture dati... roba del genere), non credo di essere la persona
giusta.
Poi mi sto rendendo conto di tutti i problemi delle GUI 'non native'.
Sono estremamente piu` lente. Un programma scritto con wx e` molto piu`
lento dello stesso programma scritto con Carbon o con Cocoa.
Certo... ci vogliono... e poi comunque non potrei integrare GNOME in
MacOS X come voglio io... alla fine potrei prenderne solo dei
programmi... ma non ce ne sono in media di cosi` eccellenti da portare
direttamente, e` piu` un feel generalizzato, quello che mi piace.
Insomma... quasi tutta fantasia :)


 al funzionamento di gentoo e del suo portage.
Sono radicalmente contrario a Gentoo. Debianita da tempo immemorabile,
io le mie macchine le devo usare, non posso perdere giornate a
compilare. Giornate ti sembra troppo? Ok. Mezze giornate.
E se parto da Stage 3, che gusto c'e`? Sto con Debian e via :))


 a noi?
se posso essere utile in qualche modo... sono uno studente di 
informatica al secondo anno, ma qualche lavoro di "bassa manovalanza" lo 
posso fare...
scrivimi a 
marc...@despammed.com

 nella nuca se sega.
Ehehehehe :D
 - ∞

 non e` distribuibile con il driver)....
Avevo gia' sentito tutto cio' in occasione della gente OpenBSDica che
aveva fatto quella petizione per trasformare in aperto il driver di
quell'altra scheda wireless...
Se non fosse per questi brutti "angoli taglienti", Linux sarebbe un
sistema operativo coi controcosiddetti...
...ma, fino ad allora, il Mac avra' ben poco da temere ;D
 - ∞

 comunque un compito a carico di ogni singolo sviluppatore.
Il DTD per gli oggetti e le classi c'e' gia'. Si chiama "dizionario
dell'applicazione" ed e' bello stringente. In Cocoa si mappa 1:1 con le
classi Objective-C dell'app se uno lo desidera. Peccato che sia un
macello da fare, ma vabbe'.
Il punto non e' (solo) quello. Il punto e' che quelli di Apple non hanno
speso una riga una a dirti, ad esempio, come scrivere un ca**lo di
plugin per Xcode. Una. Hanno messo anche il template, ma NON UNA LINEA
DI SPIEGAZIONI.
Io adesso sto cercando quella storia dei file e non la trovo no.
Non riesco nemmeno a trovare la classe file reference, per cui sto
andando a tentoni con script editor, una linea alla volta. Un
nscannotcreateecc. qui e un nsreceiverecc. la'.
 - ∞

 Sai che non me ne viene in mente proprio proprio nessuno?
C'e` un bellissimo esempio sul Lippman-Lajole. Capitolo 18. Non te lo
scrivo qua perche` e` lungo tanto tanto.
Comunque no... esempi proprio banali non me ne vengono. Se non di molto
'artificiali'. Resta il fatto che quando li incontri dici grazie. 
Senza si sarebbe fatto ugualmente, al limite in modo appena piu`
scomodo.


 sistema operativo coi controcosiddetti...
Ehg... purtroppo la gente in casa ha dei PC. :)


 Sai che non me ne viene in mente proprio proprio nessuno?
C'e` un bellissimo esempio sul Lippman-Lajole. Capitolo 18. Non te lo
scrivo qua perche` e` lungo tanto tanto.
Comunque no... esempi proprio banali non me ne vengono. Se non di molto
'artificiali'. Resta il fatto che quando li incontri dici grazie. 
Senza si sarebbe fatto ugualmente, al limite in modo appena piu`
scomodo.
-- 


 
marc...@despammed.com
hai posta


 scomodo.
(Be', la reflection in Java non la definirei "appena piu' scomoda". C#
almeno da quel punto di vista va molto meglio.)
 - ∞

 l'overloading non si puo' fare.
Non serve. Hai i named parameters.


 hai posta
Dai magari un po' di posta anche a me...  con Qt sotto MacOS un po' ci
ho sviluppato. 
Non so ben dirti se lo trovo il tempo per sviluppare attivamente... ma
almeno da betatester 'consapevole' ve lo faccio :)))


, a oggetti ma basato su prototipi. Ha anche
un ponte ObjC se lo fai girare sotto Mac OS X, per cui puoi accedere
alle classi Cocoa e viceversa. Caruccio tanto.
 - ∞

 alle classi Cocoa e viceversa. Caruccio tanto.
Ci daro` un occhio...


 stai facendo.
Si', intendo dire che in C++ scrivere, come sopra, 1.0 puo' portare
all'istanziazione di un complex<double> piuttosto che al passaggio come
double primitivo e hai ambiguita' di fondo (cioe' sei costretto a
chiederti "dove andra' a finire questa chiamata?"). In linguaggi
fortemente tipizzati come Java o C# questa ambiguita' di fondo non c'e'
mai. Ad esempio:
public class Buttapureme {
    public static void main (String args[]) {
                Giancarlo g = new Giancarlo();
                Padre p = new Padre();
                Figlio f = new Figlio();
                Padre pf = new Figlio();
 
                g.faiQualcosa(p);
                g.faiQualcosa(f);
                g.faiQualcosa(pf);
    }
 
        private static class Padre {
                public String ciao() { return "Ciao da Padre!"; }
        }
 
        private static class Figlio extends Padre {
                public String ciao() { return "Ciao da Figlio!"; }
        }
 
        private static class Giancarlo { // ma lo sa come si chiamano i
tipi come lei?
                public void faiQualcosa(Padre p) {
System.out.println("p: " + p.ciao()); }
                public void faiQualcosa(Figlio f) {
System.out.println("f: " + f.ciao()); }
        }
 
}
Giancarlo stampa rispettivamente:
[Session started at 2004-11-25 09:06:58 +0100.]
p: Ciao da Padre!
f: Ciao da Figlio!
p: Ciao da Figlio!
Come vedi e' sempre possibile conoscere, anche senza sapere il reale
tipo degli oggetti, come andra' a finire una chiamata a un metodo con
overload. Se e' in una variabile di tipo Padre verra' chiamato
faiQualcosa(Padre) (ed e' anche logico: se io so solo che e' un Padre
lo potro' solo trattare come un Padre); solo se so che e' un Figlio
verra' chiamata faiQualcosa(Figlio); se hai un oggetto Padre che credi
essere in realta' un Figlio, per richiamare faiQualcosa(Figlio) sara'
necessario introdurre un cast che puo' fallire (ed e' giusto: non sempre
i Padri sono anche Figli :D ). I metodi overridden nella classe Figlio
sono sempre richiamati, com'e' Buono e Giusto che Sia (se li ho
sostituiti e' perche' voglio che siano chiamati al posto degli
originali, no?).
Ovvio che nei linguaggi come Python tutto questo non si pone ed e' un
gran bene che sia cosi'.
 - ∞

 i Padri sono anche Figli :D ). 
In realta` questo e` cosi` anche in C++, oppure io non ho capito cosa
vuoi dire.


 chiamato. Se lo sai, lo sai anche in C++.
Hmmm, non sono molto chiaro io qui :) ma dato che anche le mie idee non
sono chiarissime, cerchero' di chiarirmi (prima di tutto per me, poi per
non passare da stupido sul ng :D).
Quello che intendevo dire con quella frase e': se ho un oggetto di un
tipo sconosciuto puntato da una variabile di un tipo noto, Java
garantisce che, passando questa variabile a un metodo sovraccarico,
venga richiamato il metodo che ha una corrispondenza esatta col tipo a
me noto. Per cui "so" dove finira' il metodo anche se non conosco il
tipo dell'oggetto. Mi sono espresso malino, eh gia'.
Un altro pregio che nella mia confusione (perenne x_x) volevo indicare
e' l'impossibilita' in Java (pre-1.4) di effettuare conversioni
implicite. Dunque, se un metodo viene richiamato con un parametro 1.0,
il compilatore si lamentera' se non lo sto passando a un metodo che
accetta un double in quella posizione. Se voglio incapsularlo in un
oggetto di un qualche tipo, lo devo fare esplicitamente (di solito, se
l'oggetto non serve mantenerlo, costruendolo al volo con un new
Classe(1.0)). Java 1.5 ha introdotto il boxing/unboxing automatico tra
valori di tipi primitivi (1, 2.0, 'c') e oggetti delle classi
corrispondenti (new Integer(1), new Double(2.0), new Char('c')), ma
anche in questo caso e' valida la regola della corrispondenza esatta
rispetto al punto di vista del chiamante (per cui, se passo 2.0 a un
metodo che ha un overload double [primitivo] e un'altro java.lang.Double
[oggetto], il compilatore preferira' il primo metodo al secondo).
Tutto questo perche' e' un pregio? Perche' toglie regole da memorizzare;
se un metodo e' stato sostituito, e' stato sostituito e basta. Se voglio
chiamare un dato metodo lo chiamo e basta, senza possibilita' di errore.
E' ovvio che e' una cosa soggettiva (c'entra parecchio anche l'essere
principiante e la pigrizia mentale). Se conosco tutte le regole di
chiamata del C++ (e prima o poi ci dovro' cozzare anche io) allora e'
ovvio che non ho problemi a chiamare un metodo su un oggetto sapendo
esattamente dove andro' a parare. Ma la difficolta' insita nell'imparare
le regole del C++ e' maggiore rispetto a quelle di Java o C# (che sono
uguali). E io sono un programmatore alle prime armi. A quale linguaggio
daro' "l'assalto" per primo? Io non ho avuto dubbi.
 - ∞

 .
Alex

 Sai che non me ne viene in mente proprio proprio nessuno?
Anzitutto i mix-in, implementativamente parlando.  Progettualmente
parlando, evitare la jattura della tassonomia.
Alex

 wrote:
[snippone che ho letto tutto, giuro!]
Ma dai, adesso come fara' la gente a scrivere:
q = lambda l,s,e:s<e and (lambda p:(q(l,s,p-1),q(l,p+1,e)))((lambda
o=[l[e],s-1,e,0,0,0,0,0,0]:\
    (o.__setitem__(6,lambda:
(o.__setitem__(4,0),o.__setitem__(5,lambda:(not o[4] and not o[3])\
    and ((lambda:(o.__setitem__(1,o[1]+1),(o[1]==o[2]) and
(o.__setitem__(3,1),o.__setitem__(4,\
    1)) or (l[o[1]]>o[0] and
(l.__setitem__(o[2],l[o[1]]),o.__setitem__(4,1)))))(),o[5]())),\
o[5]())),o.__setitem__(7,lambda:(o.__setitem__(4,0),o.__setitem__(5,lamb
da:(not o[4] and\
    not o[3]) and (o.__setitem__(2,o[2]-1),(o[2]==o[1]) and
(o.__setitem__(3,1),o.__setitem__\
    (4,1)) or (l[o[2]]<o[0] and
(l.__setitem__(o[1],l[o[2]]),o.__setitem__(4,1))),o[5]())),\
    o[5]())),o.__setitem__(8,lambda:not o[3] and
(o[6](),o[7](),o[8]())),o[8](),l.__setitem__(\
    o[2],o[0]),o[2])[-1])())
per fare quicksort, eh?
http://p-nand-q.com/python/lambdaizing_quicksort.html
:D
 - ∞

 per fare quicksort, eh?
Eh pasiensa, dovremo accontentarci di:
def q(L):
  if not L: return L
  return qs([lt for lt in L if lt<L[0]]) + \
            [eq for eq in L if eq==L[0]] + \
         qt([gt for gt in L if gt>L[0]])
rinunciando alla chiarezza e concisione dei lambda...
Alex

 tipizzazione statica non aiuta la leggibilita`.
Io putroppo la trovo di un comodo... mi manchera` una cifra. Anche
perche` per assurdo mi trovero` ad usare lambda in C++  e non in Python.
Poi capisco la leggibilita`... ma io sono tutt'ora convinto che lambda
usata bene e non abusata possa aumentare la leggibilita`, invece di
diminuirla. Se pero` vedendo molto piu` codice altrui di quello che vedo
io ti rendi conto che sono troppi gli abusi...
Chiaramente un costrutto come lambda ben si presta agli abusi, ma in
alcuni casi, trovo che sia leggibile mettere l'azioncina da dare. 
Poi vabbe` e` il mio personalissimo parere, e mi fido che la valutazione
che ha portato alla scelta sia piu` meditata e motivata della mia.
Solo e` un po' un peccato :))
F/UP e XPOST it.comp.lang.python


          qt([gt for gt in L if gt>L[0]])
Hey, ma questo e` scritto in Python ;) 


 Hey, ma questo e` scritto in Python ;) 
Eh si`, anche se la differenza rispetto ad Haskell e` minima.  In
Haskell definiresti qs due volte, sfruttando il pattern matching
condizionale del compilatore per dire:
qs di lista vuota e` lista vuota;
qs di testa seguita da coda e`
    qs degli elementi di coda < testa piu`
         gli elementi di coda == testa piu`    
    qs degli elementi di coda > testa
In Python il compilatore il pattern matching lo fa NON condizionale,
quindi devi ricorrere a un meno elegante 'if'.  Ma a parte quello la
struttura e` virtualmente identica (apposta abbiamo copiato le list
comprehension da Hashell).
Sia in Python o in Haskell, questa e` comunque l'espressione piu`
elegante del puro quicksort che io abbia mai visto.
Alex

 elegante del puro quicksort che io abbia mai visto.
Sono assolutamente d'accordo.


 daro' "l'assalto" per primo? Io non ho avuto dubbi.
Tieni presente che io ti ho fatto esempi patologici. Avessi una
conoscenza di Java pari a quella che ho di C++ sono sicuro che potrei
farne di altrettanto patologici. 
Dopo di che nemmeno io ho avuto dubbi.
Dopo il mio primo BASIC, sono volato al C. Senza paura. Poi C++, qualche
occhiata al Lisp (non quanto avrei voluto... purtroppo tanto tempo
necessita il Lisp), Perl (tanto Perl, anche se quello e` ancora piu`
incasinato. a furia di volere semplificare devi installarti mezzo
interprete in testa per capire quello che hai scritto), anche se, PHP,
perfino Java (ma questo e` tanto tanto tempo fa Java 1.3 e ormai ho
scordato quasi tutto), ASM. Poi ho conosciuto l'ObjectiveC. Un
linguaggio semplice, dinamico, rapido, efficace. E` stato amore.
Poi ho conosciuto un Python. Un linguaggio piu` semplice, piu` dinamico,
piu` rapido e piu` efficace. Nulla di quello con cui sono entrato in
contatto poi mi ha entusiasmato cosi` tanto (Fortran, Free Pascal)
Al momento ho abbandonato quasi tutto salvo Python, C++ e ObjC. Beh, il
C non si puo` si puo` abbandonare, non ci si riesce a scordarselo.
Beh... anche FreePascal non e` mica male. Ha alcune cose carine il
Pascal... era proprio un bel linguaggio, peccato che abbia fatto la fine
che ha fatto :)) Vedi... non e` piu` di moda.
Tra l'altro mi pare che tanto tanto tempo fa, Apple avesse indicato il
Pascal come principale linguaggio di sviluppo... ma chi ricorda piu` :)
E ora appena ho un po' di tempo guardero` anche altri linguaggi.
Resta una cosa. Quando penso qualcosa, tendo a pensarla in Python. E
quando la scrivo, faccio molto molto prima in Python. Con python e
twisted ho in mano cose che prima mi sognavo. Ora sono davvero
produttivo. Il fatto che poi di mio sia molto dispersivo, e` un altro
discorso.


 da int a long). Puoi anche forzare che non avvengano.
E in questo il C++ sbaglia.  Se le istanze della tua classe sono
testabili come vere o false nel modo che _parrebbe_ normale (operator
bool), allora puoi moltiplicarle per 3.14 -- perche` bool diventa int
diventa float.  Cosi` per permettere "if(x)" ma non "x*3.14" uno
definisce (EEK) un "operator void*" o simili mirabilie...
"meglio esplicito che implicito", insegna Python.  Chi ha provato le
delizie delle conversioni implicite (del C++, ma peggio ancora, del PL/I
o dell'Algol 68, beati voi giovincelli che ve li scampaste) sa perche`.
Alex

 o dell'Algol 68, beati voi giovincelli che ve li scampaste) sa perche`.
Ma questo lo ho detto pure io. Secondo me avrebbe avuto piu` senso
definire i costruttori explicit di default, e semmai lasciare
specificare al programmatore quando averli impliciti.
Comunque vabbe`...


 o dell'Algol 68, beati voi giovincelli che ve li scampaste) sa perche`.
Ma questo lo ho detto pure io. Secondo me avrebbe avuto piu` senso
definire i costruttori explicit di default, e semmai lasciare
specificare al programmatore quando averli impliciti.
Comunque vabbe`...
