Newsgroup: it.comp.macintosh
Titolo: Aiuto programmare

Ciao e' da un anno che sono un felice possessore di un iBook..ora che
conosco abbastanza bene il S.O. vorrei avvicinarmi al magico mondo della
programmazione...
Googolando ho trovato molta gente che consiglia il C anche se molto duro
da imparare ma completo e forma un bel binomio con Unix...
Voi che mi consigliate?
-- 
...Basta un Mac per vivere sereni..iBook 12"Late 2005

 Voi che mi consigliate?
Hai mai programmato in vita tua?
Se si, con che linguaggi?
E che finalita` avrebbe?
Infine, multipiattaforma o sarebbe tutto limitato al mondo Mac?
-- 
Amiga 500 - Sensible World Of Soccer inside
http://www.digitroom.com/
The only thing necessary for the triumph of evil
is for good men to do nothing - Edmund Burke

 da imparare ma completo e forma un bel binomio con Unix...
Secondo me varrebbe la pena vedere un linguaggio di basso livello (come
il C) ed uno di alto livello (come il Python).
Sono entrambi molto formativi.
E comunque, visto che siamo in casa mac, puo' valere la pena guardarsi
l'Objective-C che sommato a Cocoa e' uno strumento niente male per
programmare.
-- 
Ciao da Francesco B.

 Infine, multipiattaforma o sarebbe tutto limitato al mondo Mac?
Meglio se multipiattaforma..


 Meglio se multipiattaforma..
Allora io ti consiglio di iniziare con qualcosa di multipiattaforma  e
alto livello (quindi minore curva di apprendimento) come Python o Ruby
(moda recente), Perl...
Tra l'altro si adattano tutti molto bene al mondo Mac, senza essere
limitati ad esso.
Se vuoi seguire il consiglio di Francesco B. (studiare qualcosa sia di
alto che di basso livello), trovo comunque una buona idea partire con
roba di alto livello, per non fondere subito il cervello, e passare poi
alla roba tosta.


 Python
Provero' con questo...
Hai un sito da segnalare che offra tutorial per gente come me?ovvero che
parta da zero?
Grazie...


 parta da zero?
Puoi provare 
python.it
, io personalmente non ho mai fatto uso di
tutorial online perche` preferisco (non) applicarmi su quelli cartacei
:P


Beh oggi quello che va di piu' e ' l'object oriented.
Un buon linguaggioper gli oggetti io direi che e' java,
e una volta all'universita' ho visto questo programma :
blueJ.org che e' mezzo open, gratuito e permette un approccio
molto veloce.
Non ti devi preoccupare di classpath, crei gli oggetti al volo, puoi
testarli, ottimo per imparare.
Ci sono anche degli esempi..
..per poi pian piano muoverti a qualcosa di piu' serio come xcode,
Eclipse, NetBeans,
intelliJ, JBuilder, o un semplice texteditor come jEdit, vi(m),emacs,.
che supportano tutti
syntax highlight e compila da programma e varie migliaia di altre
funzioni piu' o meno utili.
Java ' ottimizzato su osx, anche lato gui, e avresti applicazioni che
qui sembrano fatte per mac
e su windows si vedrebbero normali.
Certo anche il python e' un gran bel linguaggio, solo, non so se
velocemente si possono fare GUI.
Ci dovrebbero essere degli widget.
Pero' non so se python ha bisogno di un runtime su windows.
Saluti!

 parta da zero?
Si, ti consiglio "pensare da informatico con Python", lo trovi qui:
http://www.python.it/doc/Howtothink/Howtothink-html-it/index.htm
ma in generale tutta la sezione per newbie
http://www.python.it/doc/newbie.html
ps. iscriviti anche al NG it.comp.lang.python
-- 
Lawrence - 
http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 Pero' non so se python ha bisogno di un runtime su windows.
Come tutti i linguaggi con VM si. E` appena uscito Python 2.5 (l'altro
ieri) e puoi trovare il pacchetto per Windows o per OSX su 
python.org


 Voi che mi consigliate?
Python.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 
Mc Osten e' deciso! ;)
... condivido.

 
prima di iniziare a studiarti un linguaggio, io passerei un pò di tempo 
leggendo documentazioni sulle basi della programmazione. algoritmi base 
dati programmazione orientati agli oggetti ecc... successivamente 
sceglierei il linguaggio. imparare un linguaggio è la cosa più semplice, 
e poi a lungua andare la sintassi è sempre la stessa.
-- 
jamba.altervista.org

 e poi a lungua andare la sintassi è sempre la stessa.
Io gli ho consigliato il libro "pensare da informatico con Python"
apposta. Python li è solo lo strumento per spiegare una serie di nozioni
base fondamentali. Ne esiste anche una versione in Java volendo, mi
pare.


 ieri) 
'stardi
Io e` quasi un anno e mezzo che ho in programma di studare un libro su
Python 2.3, pensavo mi avrebbero aspettato!
:D


 base fondamentali. 
Infatti. Partire dalla roba astratta è il modo migliore per rompersi le
palle e non andare avanti.
Inoltre per avere una comprensione *buona* di molti argomenti teorici è
bene avere una qualche forma di educazione matematica che non tutti
hanno. Tipicamente una facoltà come ingegneria o corsi di laurea
scientifici come matematica, fisica o proprio informatica le danno. Ma
altrimenti...


 Python 2.3, pensavo mi avrebbero aspettato!
Python 2.3 è decisamente "vecchio" :P (temporalmente parlando, ma anche
in quanto a prestazioni). Ti consiglio di acquistare il Nutshell di Alex
(seconda edizione) che trovi su Amazon per 26 dollari.
http://www.amazon.com/gp/product/0596100469/103-6822184-3036615?ie=UTF8


 (seconda edizione) che trovi su Amazon per 26 dollari.
Io ho la seconda edizione del Learning Python di Lutz & Ascher (che tra
l'altro vedo che e` ancora l'ultima in commercio); visto che pero` mi
starei sul cazzo a non usarlo dopo averci speso bei soldi, pensavo di
iniziare con quello e poi acquisire il Programming Python (che sarebbe
il suo naturale seguito) terza edizione, uscito ad Agosto 2006, quindi
decisamente aggiornato.


 decisamente aggiornato.
Io ti sconsiglio il Programming Python perchč:
- č un mattone
- non ho ancora visto recensioni, né sentito nessuno che l'ha letto
- Valentino ha fatto il revisore di una stesura e aveva non pochi errori
(ora non si sa)
- il Nutshell č il libro che ti serve se vuoi imparare davvero Python.
Costa anche di meno mi pare...
Comincia dal libro che ti pare ma evitare il Nutshell di Alex ha poco
senso dato che č il reference piů completo e non č una sbrodolata in
stile libri MS Press.


 Costa anche di meno mi pare...
Costa la meta`, in effetti
Cmq grazie delle tue opinioni, puo` essere una idea


 Voi che mi consigliate?
Quoto quello che ti hanno detto gli altri.
Impara la "forma mentis" della programmazione con Python, e poi
immergiti nel C (o in quello che vuoi).
Ciao
-- 
Riccardo Campana
pabel...@gmail.com
"Physics is like sex: sure, it may give some practical
results, but that's not why we do it"  (Richard Feynman)

 Voi che mi consigliate?
Ah. una mente vergine.
Decisamente Ruby, puro object-oriented senza compromessi.
-- 
And I feel like I'm naked in front of the crowd
Cause these words are my diary screamin' out aloud
And I know that you'll use them however you want to.

 Pero' non so se python ha bisogno di un runtime su windows.
Come Java. E comunque puoi distribuire exe che contengono tutto belllo
pronto senza bisogno di runtime (nel senso che il runtime finisce
nell'exe).


 ieri) e puoi trovare il pacchetto per Windows o per OSX su 
python.org
Consigli di installare il pacchetto prefabbricato oppure di aggiornare
il bagaglio dei darwin ports?
BTW, il pacchetto per OS X è un Framework o è "classico"?
Come si integra con la versione "nativa"?


 Come si integra con la versione "nativa"?
E` con framework e si integra bene, lui si installa in /usr/local/ e la
versione nativa sta tranquilla in /usr/bin.
Basta mettere nel PATH davanti a tutto
/Library/Frameworks/Python.framework/Versions/2.5/bin
e quando darai python o /usr/bin/env python partira` la 2.5.
Mai avuto problemi e ormai sono quasi 2 anni che uso questo metodo.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 Come si integra con la versione "nativa"?
La ignora :-)


 Mai avuto problemi e ormai sono quasi 2 anni che uso questo metodo.
Infatti. All'epoca le cose erano già state superate. Le incertezze
c'erano prima (specie fra /Library/Frameworks e
/System/Library/Frameworkd), ma i dettagli non li ricordo. Comunque
assolutamente nulla di davvero problematico eh.


 La ignora :-)
ok.


 bisogna fare tutto da 0.
li vede installati cosa? :)


 li vede installati cosa? :)
Mi chiedevo in base a quale criterio scegliesse in quale python
installare i pacchetti py-qualcosa quando ne ha più di uno. 
Quello che dico è che anche facendo un port upgrade installed, non credo
che lui aggiunga i pacchetti python che ho installato anche al 2.5c1 (e
quando uscirà al 2.5). Non credo di essere stato molto chiaro.


 quando uscirà al 2.5). Non credo di essere stato molto chiaro.
Non ne ho idea ma io non li terro` installati entrambi :). Quando
supporteranno per bene py2.5 togliero` il 2.4 a darwinports e mettero`
il 2.5. :)


 nell'exe).
Si`, ma la preparazione di tali exe per Windows e` agevole su Windows,
meno se uno svuole sviluppare PER Windows usando un'altra piattaforma
(MacOSX o che).  Comunque, visto che per rilasciare per Windows sarebbe
poco professionale non testare su Windows almeno un pochetto, si puo`
usare la macchina (o sessione Parallels;-) di test anche per fare la
pacchettizzazione, semplificando le cose.
Alex

 pacchettizzazione, semplificando le cose.
Esatto :)


 il 2.5. :)
Anche io. Immaginavo una breve transizione :)


 è castrata. 
Cos'è il "Mixin"?
Ciao


Se no dai un'occhiata a Ruby e fai prima. Li ovviamente ci sono si usano
parecchio.


 parecchio.
Grazie, ma non č che abbia capito molto :(
Mi sembra di aver capito che sono qualcosa che ricorda le interfacce di 
Java (o i protocolli di Objective-C). Se si, qual'č la differenza effettiva?
Ciao,
Fabrizio

 Java (o i protocolli di Objective-C). Se si, qual'è la differenza effettiva?
Non so cosa siano i protocolli perchè non conosco ObjC ma c'azzeccano
poco con le interfacce Java.
Java è un linguaggio con ereditarietà singola e ovvia al "problema" di
poter ereditare da più di una classe padre usando l'interfaccia che è
una specie di dichiarazione in cui tu attesti che la tua classe si
comportare come specificato in IPippo, blah blah (insomma che supporta
quei metodi)
Python è un linguaggio con ereditarietà multipla quindi devi
semplicemente elencare le classi da cui vuoi ereditare
Ruby invece sta a metà: ereditarietà singola con Mixin. Un Mixin ha il
vantaggio di portarsi dietro l'implementazione (al contrario delle
interfacce). In pratica tu dichiari che la tua classe ha anche il
comportamento della classe Mixin e a runtime la tua classe magicamente
eredita il comportamento da te specificato nel sorgente.
Questo permette di avere una gerarchia più semplice rispetto ad una
situazione massiva di ereditarietà multipla ma non perdere i
comportamenti.
Quindi (con una finta sintassi):
class B(A):
   include mixin C
qui hai una classe che eredita da A (quindi rispetta is-a) ma che
include anche i comportamenti di C senza modificare la sua gerarchia.
Ci sarebbe altro da dire ma direi che per capire è ok, no?


 proprio dai protocolli di Objective-C.
Ma questo è visibile, al di la delle leggende. Diciamo che se anche
avessero negato, avrei trovato una netta somiglianza con i protocolli
formali di Objective C.
Solo Lawrence (e io concordo con lui) diceva che i Mixin non c'entrano
con le interfacce (e manco con i protocolli). Sono anzi l'altra faccia
della medaglia.


 proprio dai protocolli di Objective-C.
Scusa, il soggetto era "mixin", avrei dovuto essere più esplicito.


 
Perfetto grazie, così è molto piu' chiaro. In realtà non mi è mai capitato 
di avere tale necessità (...o forse non l'ho mai fatto capitare), però ora 
capisco l'utilità e la praticità dei Mixin.
Grazie,
Fabrizio

 di avere tale necessità (...o forse non l'ho mai fatto capitare),
Ugh... basisco. Io posso dirti che nella mia esperienza è parecchio
frequente l'uso di Mixin. Ed è una cosa che annoia immediatamente
lavorando in Java (dove bisogna ricorrere ad acrocchi bestiali per avere
una parte della funzionalità).


 Scusa, il soggetto era "mixin", avrei dovuto essere più esplicito.
A chieder scusa devo io per essermi intromesso frettolosamente
nel mezzo del thread. E' che avevo appena ripulito la cache dei
messaggi e Unison purtroppo non è in grado di riannodare
i sottofili dei discorsi.

 
Basisco io! Non per polemizzare e difendere Java e gli altri linguaggi che 
non supportano questi Mixin, ma c'è sempre una soluzione, anche semplice, 
senza acrocchi bestiali, basta osservare il problema attentamente e con 
intelligenza.
Magari quello che sembra risolvibile semplicemente con i Mixin, lo è 
altrettanto con altri strumenti.
Ovviamente questa è una mia opinione basata sulla mia esperienza, quindi 
posso sbagliarmi.
Ora ti chiedo, mi fai un esempio effettivo e pratico dei Mixin?
Ciao,
Fabrizio

 Java (o i protocolli di Objective-C). Se si, qual'č la differenza effettiva?
Tutt'altro. Non sono affatto le interfacce di Java. Sono la cosa che
manca alle interfacce di Java per rendere la programmazione in Java
agevole.
I Mixin risolvono il problema della condivisione di un implementazione
sulla base di un (sotto)insieme dell'interfaccia. Sono assolutamente
implementabili sia in ambito dinamico che in ambito statico (ovvero non
hanno problemi con la tipizzazione statica, anzi).
Java non č un linguaggio dinamico. Questo rende in genere (a meno di
barbatrucchi con la delegazione e tutto). Forse se ho tempo scrivo
qualcosa sull'argomento.


 Ora ti chiedo, mi fai un esempio effettivo e pratico dei Mixin?
L'esempio più cretino e banale che esiste (cretino perchè in pratica se
ne fa a meno) è quello sulle comparazioni. 
In Java un oggetto viene comparato se si attiene a Comparable (e quindi
implementa int compareTo(Object o)).
Bene. Ogni classe che implementa l'interfaccia Comparable implementerà i
vari metodi greaterThan, greaterOrEqualThan, equalTo etc nello stesso
identico modo, semplicemente in base a quello che ritorna compareTo.
Non importa quanto diverse siano le classi: qualunque classe per cui è
definito compareTo potrebbe definire i suddetti metodi esattamente nello
stesso modo, basandosi esclusivamente su compareTo. 
Un Mixin ti permetterebbe di farlo gratis: potresti "iniettare" quei
metodi in qualunque oggetto che supporta Comparable. Chiaramente puoi
cavartela con la delegazione: scrivi un sacco di codice in più, ma
funzionare funziona (ovviamente nessuno lo fa, appunto perchè aggiungere
il codice a mano è più o meno equivalente a scrivere il codice
necessario per fare la delegazione).
Ora se vuoi vedere esempi più significativi, puoi dare un occhio al
codice di Rails. Un'altro esempio potrebbe essere questo. 
Immaginati una semplicissima interfaccia CharStreamReader che ha un solo
metodo: char read();
Sulla base di quel metodo puoi costruire un String read(int n) che legge
n caratteri, o un String readline(), o un String read_to(char m) che
legge fino a quando non ha incontrato tale carattere (o tale stringa con
opportuna modifica).
Bene: tutti questi metodi possono essere implementati nella stessa
maniera sulla base del semplicissimo read originario. Potresti definirli
in un mixin e semplicemente iniettare gratis la funzionalità ovunque ne
hai bisogno.
Ci sono esempi migliori (immagina un driver sql che ha metodi per i vari
comandi che in effetti non fanno altro che comporre e passare un comando
ad un metodo execute che lo gira direttamente al db... chiaramente
execute potrebbe cambiare con il resto del driver che effettivamente
gestisce la connessione, ma la costruzione di molte stringhe standard --
nell'ipotesi che siano db SQL standard -- potrebbe essere in molti casi
la stessa ). E così via.


 identico modo, semplicemente in base a quello che ritorna compareTo.
Ottimo esempio: ci si potrebbero imperniare su almeno un paio d'ore di
lezione a Linguaggi di Programmazione, mostrando anche l'approccio
funzionale di Haskell con le sue meravigliose 'typeclass' -- quelli che
"OO e` l'unico paradigma valido" dovrebbero vedere la differenza fra le
interfacce (che sono in pratica pura sintassi) e le typeclass (che
possono aggiungere semantica alla sintassi, e, se occorre, farlo
*non-invasivamente* senza perdere la possibilita` di "override").
La "protocol adaptation" della PEP 246 e` ampiamente ispirata alle
typeclass di Haskell (con adaptation esplicita e a runtime, come i cast
di Java, invece che statica compile-time basata su type inferencing,
come in Haskell) -- il "rule-based dispatch" di PEAK (piu` simile ai
meccanismi di Common Lisp e Dylan) ha potenza equivalente (si puo`
implementare in termini di adaptation, com'e` in PEAK oggi, o anche piu`
comodamente viceversa, si puo` agevolmente implementare l'adaptation
come caso particolare di rule-based dispatch).
Il problema della monocultura, in informatica, e` legato alla mancanza
di questo tipo di prospettive: studiare (che so) Haskell, Python, Ruby,
C++, Boo, Lisp, e Dylan, e` utile, in primo luogo, non tanto per la
possibilita` di _usare_ questi linguaggi (che in certi casi puo`
comunque far comodo), ma anche a chi comunque dovesse guadagnar pane e
salame in Java o C#, perche` essere pienamente cosciente delle
alternative lo rende comunque *un programmatore migliore* (tante delle
"design pattern" piu` importanti per i diffusi linguaggi OO statici
esistono proprio solo per aggirare limitazioni dei linguaggi stessi...).
Alex

 ...e C#, giusto?
Si, il modello OOP è identico. 


 esistono proprio solo per aggirare limitazioni dei linguaggi stessi...).
Sigh. Quoto anche qui. Al momento attuale ho in mente un capitolo di Bob
Martin sul classico esempio della lampada e dell'interruttore. Alla fine
per avere la stessa flessibilità che in Python si ha avendo
semplicemente le classi Switch e Lamp che fanno la cosa ovvia, tira a
mano una gerarchia di svariate classi e interfacce.
Eppure è così semplice...


 hack con forwardInvocation....etc...etc...
Che dire, grazie di tutto!
Ultimissima domanda: mi sapresti consigliare un buon libro di 
programmazione a oggetti, indipendente dal linguaggio?
Tutti quelli che ho trovato la spiegano prendendo come base Java, ma sembra 
che quest'ultimo non sia proprio il piu' adeguato.
Ciao,
Fabrizio

 che quest'ultimo non sia proprio il piu' adeguato.
Java è anche diventata una mezza moda :P
Che ne dici di una guida online?


 che quest'ultimo non sia proprio il piu' adeguato.
Uhm... ti confesso che è una domanda "difficile". Mi spiego... non mi
viene in mente un libro come quello che chiedi, totalmente indipendente
dal linguaggio. IMHO la cosa migliore è prendere libri "teorici" di
programmazione ad oggetti *e* libri per specifici linguaggi (oltre che
usare tali linguaggi).
Potresti scegliere di guardare Ruby o Python per esempio. Quindi il
Pickaxe di Dave Thomas oppure il Python in a Nutshell di Martelli
(esattamente quell'Alex Martelli che ha partecipato anche a questo
thread).
Poi magari un testo sulle metodologie di sviluppo agile (magari Agile
Software Development di Martins). E soprattutto (prima ancora)
frequentare comunità di sviluppatori avanzati tecnicamente. Per esempio
it.comp.lang.python. Oppure vari siti di programmazione agile, extreme
programming, o ancora programmazione ad oggetti.
Ricorda quello che diceva Alex: imparare tanti linguaggi (anche
linguaggi che non userai), apre la mente. Ti insegna "per confronto" di
cosa puoi avere bisogno, ti stimola a creare costrutti tipici (e buoni)
di un linguaggio in un altro linguaggio, scoprire come problemi simili
vengono risolti in ambienti diversi.
Non è una strada "semplice". Ci vuole passione e interesse. Ed è una
strada che non finisce mai. Ma da molte soddisfazioni. Per un libro
specifico... non so aiutarti. Ci sono "tanti" titoli che vanno letti
(beh, anche i libri, non solo i titoli :) )


 Che ne dici di una guida online?
Certo puo` far risparmiare rispetto al libro;-)
Alex

 vengono risolti in ambienti diversi.
Oppure singoli linguaggi come Scheme, Mozart, o Lisp, che (a parte la
sintassi un po' goffa;-) sono "universali" in termini di paradigmi ecc
(scomodo per l'uso reale, ma buono per apprendere;-).
Alex

 scolastici/universitari!-).
Per andare un pò OT ma sempre riguardante la diffusione dei linguaggi.
Hai visto che l'indice di TIOBE ha piazzato Python sopra C# questo mese
:-) ?
Michael Foord ha fatto qualche ricerca in merito: 
http://www.voidspace.org.uk/python/weblog/arch_d7_2006_09_23.shtml#e476


 
http://www.voidspace.org.uk/python/weblog/arch_d7_2006_09_23.shtml#e476
Divertente. :)
Devo dire molto interessante quello su PHP. Sinceramente anche io per
certi versi avrei trovato molto meglio se Jani avesse smesso per
questioni di "PHP Sucks". Divertente perchč uno sviluppatore che lascia
un progetto che io considero pessimo per le stesse ragioni mi diverte.
Le motivazioni che sembrano apparire dal log su irc sono invece piů
drammatiche. Nel senso che sono mosse da sofferenza e non toccano
l'aspetto tecnico di PHP.
Detto questo francamente neanche a me piace la politica di Israele e
rispetto un uomo che abbandona un lavoro (buono?) per le sue idee. Dopo
di che io non la minima idea se in questo caso  abbia fatto bene (ovvero
il "peso della compagnia israeliana"). Mi dispiace solo leggere molto
odio che porta a drammatiche generalizzazioni: per quanto ribadisco
trovi deprecabile la politica israeliana penso che scrivere "Fuck you
jews." sia inaccettabile (se non come momento di stizza, e su IRC ci puň
stare, IMHO č come dire qualcosa di forte al bar). Il fatto di essere di
religione ebraica (c'č scritto jews, non israelis) non c'entra con
l'avere a che fare con Israle (anche se non tutte le persone di
religione ebraica si comportano in tal senso).


 (scomodo per l'uso reale, ma buono per apprendere;-).
Vero anche questo. Io ti confesso che di Lisp ho qua in scaffale il
manuale di Guy Steel, ma lo trovo inquietante. Prima di Python stavo
lavorandoci (un po' per giocherellare con Emacs, un po' perchè cercavo
qualcosa di dinamico e comodo -- perl mi falliva sulla comodità).


 qualcosa di dinamico e comodo -- perl mi falliva sulla comodità).
Io sono arrivato al capitolo 5 di Practical Common Lisp se ti può
interessare :-)


 interessare :-)
Respect! :)


 Alex
Lisp lo conosco, ma esiste anche una versione ad oggetti?
Fabrizio

 Lisp lo conosco, ma esiste anche una versione ad oggetti?
Lisp è un linguaggio multi-paradigma. Tra le sue tante virtù ha quella
di essere facilmente estendibile grazie a macro e altri meccanismi. CLOS
è l'object system sviluppato sopra Common Lisp.
Per informazioni: 
http://en.wikipedia.org/wiki/CLOS


 ha vari puntatori a buoni paper su
CLOS.  Riassumendo, CLOS dispone di feature molto potenti, a tutt'oggi
assenti nei linguaggi "mainstream" come C++, Java, C#, ma anche in
Python, Ruby, Eiffel, Smalltalk (se siamo fortunati Python 3000 potrebbe
finalmente introdurre l'aspetto fondamentale di queste feature, il
"multiple dispatch" imperniato sulle "generic function" [in un senso
diverso da quello in cui lo stesso termine e` usato in C++ o Java]). Gli
stessi concetti, con sintassi infissa e quindi un po' piu` mainstream,
si trova[va]no in Dylan, un linguaggio che fu sviluppato (e poi
purtroppo abbandonato) da Apple: non ha tutta la potenza di Lisp, ma per
l'apprendimento del paradigma a oggetti imperniato sulle GF puo`
risultare piu` semplice.
Alex