Newsgroup: it.comp.ia
Titolo: C e IA

computer, non avrò mai risultati considerevoli.
Gradirei una vosta opinione.
Grazie.

 wrote in message
7jlE6.70844$s93.7...@news.infostrada.it...


 un suo utilizzo nei progetti di IA.
Il C e' il linguaggio di alto livello piu' generale e performante che 
esista.
Il C++ supporta la programmazione OO.
Fino a un decennio fa si parlava solo di linguaggi ad alto e basso 
livello, secondo la distanza che tali linguaggi avevano dal "codice 
macchina".
Ora al grafico si aggiunge una dimensione, e cioe' la vicinanza al 
problema da descrivere e risolvere.
Se il C e il C++ sono quasi alla stessa distanza dalla macchina, il C++ 
e' senz'altro piu' vicino "al problema".
La somma di due numeri si fa allo stesso modo in C e in C++. Non e' 
questo il punto. E' l'impostazione del programma ad essere diversa.
O meglio, ad essere "probabilmente" diversa. Infatti nulla impedisce a 
un programmatore C di programmare ad oggetti, solo che il programma che 
viene fuori e' piu' "bruttino".
A mio parere, non esistono motivi concettuali assoluti per preferire il 
C al C++, tuttavia possono esistere dei motivi pratici: ad esempio, su 
una certa piattaforma, il compilatore C++ puo' essere fatto male o 
mancare del tutto, oppure ci puo' essere una applicazione di AI talmente 
"performance critical" da rendere inaccettabile il leggerissimo degrado 
di prestazioni che si ha col C++.
Ritengo pero' doveroso specificare che il degrado non e' dovuto "al 
linguaggio in quanto tale" ma alle cose che si fanno con quel linguaggio 
ed eventualmente ai compilatori.
Una chiamata a un metodo virtuale e' certamente piu' lenta di una 
chiamata a funzione, ma, per scrivere codice C corrispondente, si 
sarebbe costretti come minimo a fare dei confronti prima della chiamata 
a funzione, ecc. ecc. Quindi il degrado non e' cosi' grande come a volte 
si vuol far credere, e il miglioramento in termini di manutenibilita' e 
leggibilita' e' notevole.
I compilatori attuali, purtroppo, non sono ancora perfetti, e non e' 
raro scoprire che il Visual C++ 6 della Microsoft ottimizza male del 
codice C++, laddove il corrispondente codice C viene ottimizzato bene. 
Questo, tuttavia, non e' un problema concettuale legato al linguaggio.
Un altro elemento che potrebbe far decidere per il C rispetto al C++ e' 
"i programmatori conoscono il C ma non il C++, e i costi necessari a 
insegnar loro il nuovo linguaggio o cambiare programmatori sono 
insostenibili"... in questo caso... pace!
Ricordo ancora una volta che, con un po' di attenzione, e' possibile 
scrivere codice C++ in cui i rallentamenti dovuti alla struttura del 
codice sono veramente minimi e generalmente irrilevanti.
Quando tutto manca, e' sempre possibile inserire codice C "critico" in 
un programma C++, lasciando pero' la struttura globale in C++ e 
documentando bene le parti "critiche".
Ciao,
  Gio

Ringrazio per quanto detto, ma la domanda non era riferita esplicitamente ad
un linguaggio, bensì si riferiva al pensiero esposto da questo esperto
programmatore che sostiene che per costituire un IA efficiente dobbiamo
lavorare al più alto livello possibile dalla macchina, appoggiando i
linguaggi che rispettano tali requisiti, in quanto un computer rimarrà
sempre uno strumento e sempre una stupidissima macchina.
Io sostengo l'esatto contrario e sono convinto che si possa arrivare a
qualcosa di decente solamente riunendo le due filosofie - la mia con la
sua -, ma utilizzando come base il ragionamento "puro" della macchina.
Per questo facevo l'esempio del conteggio 2 +2 , che non era affatto
riferito alla possibilità di un linguaggio, ma era semplicemente una specie
di metafora per quello che potrebbe essere un discorso simile con i
computer.
Se uno non riesce a capire perché faccio 2 + 2 con i numeri, ma può capire
la medesima operazione con le mele, perché allora non posso abbassare il mio
ragionamento di un livello, lasciando perdere per un po' di tempo
l'astrattismo, ed insegnarli l'operazione con le mele e successivamente,
quando ne ha capito la logica, insegnarli cosa sono i numeri?
Il mio "avversario" sostiene che dovrei cominciare subito con i numeri
perché è tale persona, essendo ritardata, che si deve adattare al mio
ragionamento e non sono io che devo deprezzarmi con lui.
Ciao.

 sempre uno strumento e sempre una stupidissima macchina.
Un punto _essenziale_ del mio post era che non ha piu' senso misurare il 
livello "alto" o "basso" come distanza dalla macchina, ma bisogna invece 
valutarlo come distanza dal problema. In questo senso il C++ fornisce 
un'ottima base, come qualunque linguaggio OO e, in aggiunta permette 
anche ottime prestazioni (migliori di qualunque altro linguaggio OO 
corrente) che sono necessarie ad applicazioni complesse.
Il discorso della somma di due numeri e' troppo semplicistico e, a mio 
modo di vedere, conduce ad un approccio sbagliato al problema.
Se scrivo un programma di AI _vero_ non andro' certo a modellare ogni 
singolo task affrontabile: il mio "problema" non e' "fare questo" o 
"fare quello", ma gestire una base di conoscenza e farla reagire in modo 
automatico a certe classi di input.
Invece di parlare di somme di interi, parliamo di applicazioni reali.
Creare una libreria per la fuzzy logic in C e' possibile, ma realizzarla 
in C++ da' risultati sicuramente piu' soddisfacenti e produttivi. Per 
convincersi di questo non e' necessario dissertare sui massimi sistemi: 
basta guardarsi un po' intorno - anni fa su Dev o Computer Programming 
venne pubblicata una libreria di classi per la logica sfumata, 
nell'articolo introduttivo erano spiegati i vantaggi del C++ nella 
realizzazione del progetto.
Non ho a disposizione la rivista, che giace a casa dei miei genitori, a 
circa 1700 Km da qui, ma probabilmente qualcun'altro, tra i 
frequentatori del newsgroup puo' farlo.
Un'ultima nota: non tutti usano il tuo stesso programma e connessione. 
Quando rispondi a un messaggio, indica chiaramente a quale messaggio 
rispondi e "quota" i punti essenziali a cui rispondi, altrimenti e' 
difficile, per persone come me, riuscire a capire a cosa ti riferisci.
Ciao,
  Gio

 realizzazione del progetto.
Non vorrei offenderti, ma č risaputo che le riviste da te menzionate sono
piene di errori e di strafalcioni.
Per le fuzzy logic sono d'accordo che il C++ sia piů utile per realizzare
l'applicativo. Ma non sono altrettanto d'accordo che si debba utilizzare una
sola filosofia per realizzare un progetto.
Un mio pensiero personale č che sia piů produttivo programmare seguendo la
filosofia di quello a cui voglio insegnare. Costruite le basi, continuare a
costruirci sopra.
Indipendentemente dal fatto che si utilizzi la OOP o la programmazione
strutturata il codice viene ridotto a linguaggio macchina, pertanto un
oggetto per un computer non ha alcun significato, serve a te per rederti il
lavoro piů facile dal punto di vista di programmazione.
Se la struttura del computer impedisce tale approccio non posso ostinarmi a
tentare di fargliela capire.
Io vedo l'oggetto non come inutile ma come un passo successivo.
Secondo alcuni nuovi progetti, sicuramente ne avete sentito parlare, si
pensa di realizzare delle nuove reti neurali che non si limitino a gestire
nel modo consueto l'informazione e a restituirla ma la modificano, la
distorcono utilizzando le proprie conoscenze.
Per intenderci il risultato che si vuole conseguire č la messa a punto sotto
forma di algoritmo di una fantasia umana.
Io non ne ho conoscenza diretta, forse voi mi direte qualcosa di piů.
Ciao.

 forma di algoritmo di una fantasia umana.
Questo e' tutto da vedere e dimostrare. Ci sono decine di campi di 
applicazione PRATICI dell'AI che non coinvolgono l'emulazione della 
fantasia.
Ciao,
  Gio

Se posso dire la mia ritengo che la scelta del linguaggio di alto o basso
livello sia un fattore di comodo solo per il programmatore...
Se si ha la pazienza e la capacità di farlo si potrebbe programmare anche
tutto in assembler ma non è questo il problema..
Prima della efficienza del linguaggio i miei studi e la mia esperianza mi
hanno insegnato che è fondamentale una efficienza struttrale del programma..
Vale a dire che bisogna assicurarsi che prima di tutto gli algoritmi scelti
siano i più efficienti possibili..
Riguardo poi alla scelta del linguaggio in cui codificare tutto si devono
tentere presenti molti fattori.
Prima di tutto bisogna vedere quale tipo di linguaggio si adatta meglio agli
algoritmi scelti..
Se ad esempio vogliamo fare un programmino che tratta delle stringhe io
difficilmente sceglierei il C o il C++ ma mi orienterei su qualcosa tipo
perl (tanto per dirne una..)
Inoltre bisogna sempre tenere presente il problema della riusabilità del
codice, che sicuramente favorisce la scelta di un linuaggio Object Oriented.
Per concludere dico soltanto che nel problema della costruzione di una IA,
dal punto di vista del computer, poco importa se il linguaggio è vicino al
modo di pensare umano o vicino al funzionamento della macchina.. Non è
questo il fattore che influenza il risultato finale in quanto il computer
non ragiona e quindi per lui poco importa se gli "insegnamo a ragionare"
(costruendo una IA) con uno o con l'altro linguaggio..
La grossa differenza invece c'è dal punto di vista del programmatore che ,
ripeto, ha il compito di scegliere il linguaggio in base al tipo di
algoritmi usati e in base alle sue conoscenze...
-- 
Posted from 
smtp1.libero.it
 [193.70.192.51] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 algoritmi usati e in base alle sue conoscenze...
Gli algoritmi non sono tutto. Se un software e' impostato in maniera 
fortemente algoritmica, non c'e' ragione di preoccuparsi di OO.
Tuttavia ormai gli algoritmi sono, ripeto, solo una parte del programma.
In ogni caso vorrei puntualizzare, a scanso di equivoci, che un 
linguaggio non si sceglie in base alle istruzioni "potenti" che 
fornisce. Un linguaggio con le istruzioni potenti integrate e', anzi, 
generalmente un linguaggio limitato. 20 anni fa si guardava come un 
linguaggio avesse questa o quest'altra istruzione per formattare 
l'output a schermo... oggi questi concetti sono superati: l'importante 
e' il controllo di flusso, il paradigma di programmazione, la 
flessibilita'. Il resto si fa con le librerie (chi usa ancora writeln, 
in Pascal?).
Ciao,
  Gio

   Gio
Ciao.

 progetti IA.
Non conosco questo tipo di argomenti, quindi mi fermo qui.
Ciao,
  Gio


Ciao.

 devessere obbligatoriamente definita all'interno della stessa.
Aridaje... embe'? ;)
In che modo questo e' in contrasto con lo scrivere codice strutturato? 
(non imperativo).
Il paradigma di programmazione strutturata prevede alcune semplici 
regole sul controllo di flusso.
Tutte queste regole possono (e dovrebbero) essere seguite in un buon 
programma OO. Applicare le regole della programmazione strutturata a un 
programma OO non vuol dire renderlo meno OO, quindi non c'e' nessun 
contrasto tra i due paradigmi.
La strutturazione riguarda gli algoritmi, non la relazione dato<->azione 
che e' alla base del paradigma ad oggetti. Il fatto che tu scriva Azione
(dato) o dato.Azione non modifica la strutturazione dell'algoritmo.
Ho l'impressione che tu usi la parola "strutturato" per intendere 
"imperativo", che e' cosa ben diversa.
Ciao,
  Gio

 "imperativo", che e' cosa ben diversa.
Sta tranquillo, non ho l'abitudine di confondere un paradigma con un
metaparadigma.
Sicuramente conosci i fondamenti su cui si basa il metaparadigma
strutturato, ovvero vincolato dalla presenza dei tre schemi (sequenza,
selezione ed iterativo o ciclo).
Per molto tempo abbiamo considerato, peraltro giustificato, l'esclusione del
BASIC dalla programmazione strutturata in quanto mancava un ciclo
fondamentale.  Ebbene molti linguaggi si sono sviluppati su questa
caratteristica e vi hanno aggiunto la OOP, quindi, in un certo senso, si
potrebbe enunciare che non č possibile applicare pienamente il concetto
strutturato in taluni casi.
Per il resto non ho nulla da obiettare dato che concordo con te.
Perň sussiste anche il discorso che la OOP, oltre ad essere implementata in
parecchi modi differenti, puň essere basata sia sul modello funzionale sia
su quello imperativo sia su quello logico. Con il modello funzionale la
programmazione strutturata presenta numerose carenze, tant'č vero che alcuni
non la considerano piů tale in concomitanza con lo stesso.
Ciao.

 non la considerano piů tale in concomitanza con lo stesso.
E qui intervengono un buon analista e un buon progettista.

 Grazie.
Secondo me avete semplicemente un'idea diversa di cosa sia l'Ia e di come un
computer possa apprendere. Ora, se ho ben capito tu sei l'interlocutore che
sostiene la necessita' di partire dal linguaggio macchina. Sembra che tu
definisca l'Ia piu' come un "modo per comunicare" con un "essere" gia' di
per se' potenzialmente intelligente: la sua capacita' di elaborare le
informazioni per te e' tale da contenere di gia' le capacita' per
un'intelligenza e quindi l'obiettivo della ricerca dovrebbe essere quello di
studiare il modo per far "emergere" questa intelligenza in potenza nel
computer, e il modo piu' ragionevole per farlo e' ovviamente partire dalle
sue capacita' proprie, quindi dal linguaggio macchina. Per te l'intelligenza
e' soprattutto evoluzione e interazione con l'ambiente circostante. Il tuo
interlocutore invece pensa all'Ia come ad una manifestazione di una certa
sequenza di algoritmi: poiche' l'unico agente intelligente conosciuto e'
l'essere umano una macchina e' tanto piu' intelligente quanto piu' si
uniforma agli standard umani, e visto che l'utilizzo preposto alla macchina
e' l'esecuzione di un algoritmo, tanto vale usare un approccio che ci
permetta di programmare algoritmi piu' vicini alla nostra sensibilita'
(l'OOP, appunto). Per lui l'intelligenza e' soprattutto comportamento
sofisticato ed adeguamento ad un contesto umano.
Personalmente prediligo l'idea di una intelligenza emergente nella macchina,
ma tutto sommato entrambe le posizioni sono legittime e condivisibili, si
tratta solo di mettersi d'accordo sul significato dei termini.
Ciao,
     Stefano
--
"Neither a lofty degree of intelligence nor imagination
nor both together go to the making of genius.
Love, love, love, that is  the soul of genius."
- Wolfgang A. Mozart

 ha scritto nel messaggio
news:9c9jnt$t19$2...@serv1.albacom.net...

Sinceramente, per come la vedo io, per programmare qualcosa di
"intelligente" è necessario mettere tra noi e la macchina un qualsiasi
strumento che riesca a fare da tramite, questo è poco ma sicuro. Partendo
dal presupposto che ogni linguaggio ha il suo scopo e quindi ogni linguaggio
si diversifica dagli altri per qualche caratteristica particolare, possiamo
fare piccola considerazione. Possiamo partire benissimo dai 2 estremi, cioè
dal linguaggio macchina e il linguaggio naturale. Allora ... siamo sicuri
che la macchina (tranne qualche caso superdotato, tipo LISP Machine) non è
in grado di analizzare e comprendere il significato del linguaggio ad alto
livello né di quello naturale .... ma è anche vero che a noi risulta assai
ostico leggere e comprendere il significato di ogni singola istruzione
macchina! Per questo abbiamo apportato diverse soluzioni al problema,
traducendo per passi successivi e per vie differenti il linguaggio dei
nostri macinini. Sbaglio? Insomma, da linguaggio macchina ad Assembler (che
poi non è altro che vedere il linguaggio macchina secondo un "aspetto
diverso"), da Assembler ai linguaggi imperativi ad alto livello ... poi
quelli ad oggetti ... poi quelli che simulano già di + il linguaggio
naturale, che si avvicinano, ma che non risolvono ancora il problema! Poi
quell'altra strada dei linguaggi funzionali che permette di tradurre il
linguaggio naturale in una sorta di regole matematiche. A questo punto mi
pare + ragionevole partire da un qualsiasi linguaggio di questi e se lo
strumento ci mette a disposizione tutto quel che ci serve, sappiamo che
possiamo in qualsiasi caso sviluppare il nostro programma intelligente ok?
Inoltre se utilizziamo l'Assembler siamo sicuri di aver tutto a
disposizione, ma sappiamo anche che ci dobbiamo fare un mazzo per riuscirci!
Se ricorriamo a linguaggi molto vicini a quello naturale, siamo sicuri di
fare il programma con estrema semplicità, ma non siamo sicuri di disporre di
tutto ... o almeno, fino a che non abbiamo terminato il lavoro, questo
perché + aumenta il livello del nostro linguaggio  e + perdiamo il controllo
totale della macchina! Una via di mezzo mi pare il compromesso giusto, ma
dobbiamo esser coscienti che la difficoltà autmenta man mano che il livello
diminuisce!
In conclusione, non sarebbe + giusto usare uno strumento che mi mette in
condizione di rapprensetare la realtà + da vicino e lasciare le
ottimizzazioni alle varie implementazioni del software compilatore o
dell'interprete? Linguaggi come il LISP sono stati studiati appositamente
per problemi di questo tipo, facendo ragionare il nostro cervello in un
certo modo e imponendo la macchina a ragionare allo stesso modo, mettendo
entrambi nelle stesse condizioni. Il concetto potrebbe non sembrare giusto a
prima vista, ma non dovete soffermarvi sul fatto che la macchina continua a
lavorare con i bit!

 dal linguaggio macchina e il linguaggio naturale.
Secondo me non sono "i due estremi" di una linea comune.
Il linguaggio macchina NASCE come linguaggio imperativo, cioe' per dare 
una sequenza di comandi.
Il linguaggio naturale nasce come linguaggio DESCRITTIVO, cioe' per 
definire e denotare fatti e oggetti.
Da questo punto di vista, i due linguaggi fanno parte di categorie 
diverse.
Il C++ e' un ottimo link tra i due mondi.
Ciao,
  Gio

 Il C++ e' un ottimo link tra i due mondi.
si buono, ma come tanti studiosi fanno notare, porta anche a dover pensare
allo sviluppo di altri meccanismi che non sono propri della soluzione che
vogliamo trovare (es: Garbage Collection, richiesta di memoria etc etc). Un
ottimo linguaggio che secondo me č adatto x lo sviluppo di SW in queste aree
deve "imperare & descrivere" liberando la mente umana da problemi tipici
della macchina, in modo tale da lasciar presente una sorta di "distacco-non
distacco", cioč deve permettere di allontanarsi il + possibile dal
linguaggio macchina ma permettere comunque di comandarla a dovere.

 linguaggio macchina ma permettere comunque di comandarla a dovere.
Vuoi la botte piena e la moglie ubriaca.
Io insisto che il linguaggio non deve essere troppo specifico. Quello 
che manca si aggiunge con le librerie di classi.
Ciao,
  Gio

 che manca si aggiunge con le librerie di classi.
Appunto ... non deve essere troppo specifico e quindi non dipendere da
macchina o S.O. Certo che poi la marea di funzioni specifiche le si
implementano a seconda dei casi, ma se alcune cose di base ti vengono già
fornite dal linguaggio stesso ... tanto meglio no?
botte piena e moglie ubriaca non sarebbe male ... 2 piccioni con 1 fava!!!
:-)

 fornite dal linguaggio stesso ... tanto meglio no?
No. L'esperienza ci insegna che tutte le volte che questo e' stato 
fatto, ha creato problemi alla lunga: Basic, Fortran, Pascal, Cobol, 
Clipper sono tutti linguaggi legati a "funzioni integrate" che col tempo 
sono state superate, e te lo dice qualcuno che si e' trovato, in 
passato, col problrma di trasformare un server con software scritto in 
Cobol in una macchina moderna.
Ciao,
  Gio

 Cobol in una macchina moderna.
Queste sono però dettagli del linguaggio ... ovvio che se modifichi la
struttura dati ... poi modifichi anche le specifiche che servono ...A quel
tempo il concetto era giusto!! Ma ... su questo ti posso anche dare
ragione!!!  Il mio linguaggio prevede appunto di poter implementare la
struttura base delle funzioni ... un po' come "apprendi e automodificati, in
modo da migliorarti!".

 modo da migliorarti!".
Hai mai usato il Forth?
-- 
C++U,
  Gio "FrOYd" Caturano
 
http://www.dronez.com

"> Il C e il C++ non dipendono ne' da macchina, ne' da SO.
Per quanto riguarda la dipendenza dall'OS hai ragione sui suddetti, ma per
raggiungere l'indipendenza dalla piattaforma devi ricompilare il codice C
sulla piattaforma sul quale vuoi eseguirlo.
Quando Sun ha deciso di implementare lo Star 7, prima che Gosling inventasse
Java, si era pensato di sviluppare il sistema in C++ e non in C sia perché
volevano lavorare con un linguaggio orientato agli oggetti sia per questo
particolare svantaggio del suo predecessore che poco si addiceva per un
programma portabile.
Ciao.

> Hai mai usato il Forth?
Uno dei linguaggi più flessibili della storia. Se da una parte costituiva un
suo punto di forza, dall'altra il codice poteva diventare così complicato
per un altro programmatore o per l'autore stesso, dopo un certo periodo.
Per questo si è deciso di limitare la flessibilità dei linguaggi a livelli
più ragionevoli.
Ciao.

 programma portabile.
Anche il C++ deve essere compilato. Interpretare un linguaggio porta un 
decremento di prestazioni assolutamente inaccettabile per la maggioranza 
delle applicazioni.
Cmq nulla vieta (in linea di principio) di costruire un interprete C (ad 
es. il Quincy lo e') e nulla vieterebbe di rendere questo interprete 
indipendente dalla piattaforma.
Come il C necessita' di un compilatore appropriato, Java necessita di 
una VM appropriata. La differenza e' nella semplicita' del porting, non 
nel concetto.


 Hai mai usato il Forth?
No mai usato. Spiacente. Dove posso trovare informazioni relativa?
Piuttosto, quello che dovrebbe fare il linguaggio, è questo: grazie ad un
programma *intelligente*, il computer *apprende* il funzionamento di nuove
funzioni in modo da auto-implementare il codice dell'interprete!! In questo
modo è flessibile. Facendo così, posso far fare qualsiasi cosa al programma
sfruttando al massimo il codice compilato su un linguaggio interpretato! Ad
un certo punto potremmo arrivare ad avere realmente un computer che ragiona
senza aver troppi sforzi!
Cmq il mio discorso non stava tanto a polemizzare su programmi che
richiedono velocità tipo giochi o altro. In quel caso è giustissimo
utilizzare linguaggi che ci permettono di estremizzare le cose. Quello che
intendevo io sta sul fatto che per programmi tipo Eloisa (magari migliori
dello stesso) sarebbe molto + semplice utilizzare un linguaggio che ci
permetta di fare le cose in modo semplice senza focalizzare l'attenzione su
argomenti che a mio avviso sono dipendenti dalla macchina. LA gestione della
memoria è sempre dipendente dalla macchina, ma nel senso che è legata ad un
computer e non al problema che vogliamo risolvere. Se vogliamo realmente
fare un programma intelligente (lasciando sempre sfumato questo concetto,
che poi *intelligente* è sempre relativo ad ognuno di noi) dobbiamo partire
da un codice di altissimo livello tipo LISP e poi una volta risolto,
scendere man mano di livello, il + possibile fino a raggiungere un codice
estremamente ottimizzato. Ok, c'é chi dice che sarebbe + semplice fare le
cose già giuste, ma l'esperienza ci insegna che fare un programma per
raffinamenti successivi è molto + facile ed efficiente di uno che pretende
di essere corretto fin da subito. Io purtroppo ne so qualcosa visto che
l'interprete che mi sono creato ho dovuto ri-cominciarlo una 10ina di volte.
Poi bisogna vedere anche le proprie necessità. Se il nostro programma deve
far qualcosa di particolare è assurdo perdere 1 anno di tempo a fargli fare
quella cosa in particolare quando è solo quella che fa la differenza.
Felice di aver trovato qualcuno che controbatte su argomenti seri!!! :-)

, 
Mr-Ca...@excite.it
 
says...
[...]
Abbiamo approcci completamente diversi al concetto di linguaggio. Tu 
continui a citare come "caratteristiche del linguaggio" cose che secondo 
me, nel 2001, nessuno dovrebbe nemmeno considerare.
Ad esempio parli di comunicazione in rete. Secondo me sarebbe un errore 
GRAVISSIMO inserire nel linguaggio istruzioni per la comunicazione in 
rete. Un linguaggio dev'essere quanto piu' GENERALE (non "generico") 
possibile, quindi niente istruzioni di output, niente istruzioni di 
rete, ecc.
Quanto al LISP compilato, e' assolutamente vidente che non si puo' 
compilare completamente un linguaggio non tipizzato.
Quanto alla scelta tra i linguaggi, sono completamente d'accordo che il 
C++ non sia sempre la scelta piu' azzeccata, io volevo semplicemente 
limitare i criteri di scelta ai problemi che dipendono realmente 
dall'impostazione del linguaggio. Non considero validi in nessun modo 
discorsi tipo "il compilatori LISP ha la garbage collection" - se ti 
serve la libreria in C++ che fa la garbage collection, la trovi 
facilmente... Se devo scegliere il LISP lo faccio perche' mi fa comodo 
il suo modo liberissimo di usare la logica, di gestire gli insiemi, ecc. 
ecc. Punto. Gli altri motivi sono validi solo in base a constraint (es.: 
non ho i soldi per comprare la libreria) ma non dal punto di vista di 
principio.
