Newsgroup: it.comp.programmare
Titolo: quale linguaggio?

Ragazzi (e ragazze, of course) considerate un attimo questa situazione:
Dovrei scrivere un software la cui parte predominante e' un motore GIS,
cioe' l'integrazione tra grafica e database. Questo significa che l'utente
potra' visualizzare un file grafico, ad esempio la piantina di un quartiere
metropolitano, e poi cliccando su un edificio andare a pescare la relativa
tupla che identifica quell'edificio all'interno di un database.
Sapendo che:
(1) il file grafico di input e' nello standard dxf di autocad
(2) l'applicazione deve girare rigorosamente ed esclusivamente in ambiente
micro$oft
(3) conosco java
(4) conosco pascal, ma non delphi
(5) non conosco visual basic
(6) ho il tempo di imparare un linguaggio da zero per lo sviluppo del
progetto
secondo voi, qual'e' il linguaggio che fa al caso mio???


wrote:

problematiche del genere sono già state affrontate ...
personalmente conosco delle persone che hanno già fatto una cosa del
genere .. (in parte la dovevo fare pure io per ambiente windows però
dovevo trattare intere particelle catastali)..
avevo un'alternativa semplice ...
usare delphi e Vecad (un componente delphi sviluppato da una azienda
russa che tratta immagini dxf e ... grazie a bde era possibile
interagire rapidamente con un database access)...
oppure usare c++ e vecad ...
oppure vb e vecad ...
in ogni caso guardati prima vecad (
http://www.altavista.com
 cerca
vecad .. l'url non lo ricordo)
spero di essere stato d'aiuto
cod

Essenzialmente ci sono due strade a seconda se (A) puoi usare un motore GIS
'già pronto' oppure (B) devi scrivere tu anche il motore GIS.
(A)
In questo caso estistono diversi strumenti per implementare un Sistema
Informativo Territoriale.
Ognuno dei quali ha un suo linguaggio interno.
Tra questi in ambiente Win spiccano per la loro potenza e per la loro
diffusione (nonchè per il costo abbastanza ridotto) ESRI ArcView ed Autodesk
AutocadMap.
Entrambi importano tranquillamente DXF e DWG +tutti i formati raster piu'
comuni utilizzati nei GIS (es. TIFF).
Hanno già al loro interno strumenti adatti per il collegamento a basi di
dati (relazionali), un linguaggio di sviluppo (nel caso di AutocadMap si
tratta di VBA) utile anche alla scrittura di macro, la possibilità di
collegarsi a librerie esterne (es. di tipo ActiveX o DLL) per
l'implementazione di funzionalità particolari, la possibilità di pubblicare
il GIS mediante moduli opzionali sul web (intranet/internet) dando la
possibilità di consultarlo (a volte anche modificarlo) via plug-in (per lo
+in Java).
Trovi maggiori info sul sito dei rispettivi produttori.
ESRI ha il vantaggio di avere un collegamento nativo con dati in arrivo da
Oracle Spatial Engine (SDO- Oracle Spatial Database) e di avere la
possibilità di un upsizing dell'intero GIS su di un motore +potente, ESRI
ArcInfo (Unix).
In questo caso A utilizzi prodotti professionali e stracollaudati.
Se usati in modo 'tranquillo' ti permettono di concentrarti sui contenuti e
non sulla realizzazione del motore (operazione tutt'altro che banale in
quanto coinvolge molti aspetti, dal trattamento delle immagini raster, dei
poligoni vettoriali e delle entità grafiche, fino alla base di dati ed alla
interazione con essa).
Se usati in modo 'approfondito' ti permettono volendo personalizzare in modo
radicale l'ambiente, cambiando ogni piccolo particolare della interfaccia
grafica, etc.
(B)
In questo caso la cosa migliore è prendere come ti è già stato proposto una
libreria di terze parti da utilizzare con un linguaggio di programmazione.
Ti trovi a dover scrivere tu il motore del GIS e quindi meglio affidarsi a
componenti già pronti e testati (a meno che la tua necessità non sia proprio
quella di scrivere un nuovo 'motore GIS' da rilasciare magari sotto forma di
libreria).
Ovviamente in questo caso devi codificare tutto tu (interazione con il
database, interazione con la cartografia, etc.).
Per esperienza personale ti posso consigliare la libreria tutta italiana
DbCAD dev di Abaco che trovi su 
http://www.abacogroup.com/
.
E' una libreria molto ben fatta, disponibile sia a 16 che a 32 bit, sia
sotto forma di ActiveX che di DLL, ben documentata e supportata.
La versione riservata agli sviluppatori viene rilasciata con numerosi esempi
di integrazione con vari linguaggi tra cui sicuramente VB e DELPHI.
Di questi esempi viene dato anche il codice sorgente.
Da non sottovalutare poi sono le librerie rilasciate dalla stessa ESRI
(anche in questo caso DLL e ActiveX).
Sono molto costose ma ti permettono di includere nella tua applicazione il
motore GIS che sta alla base di ArcView.
Spero di esserti stato utile
Buon Lavoro
luca



 secondo voi, qual'e' il linguaggio che fa al caso mio???
salvo che tu non sia obbligato ad usare un dato linguaggio perchè è
quello supportato dalla libreria o dal tool preesistente scelto in base
alle altre risposte, io direi che, soprattutto in considerazione dei
punti (2) e (6) e sottolineando (5), potresti prendere la strada del C#
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 punti (2) e (6) e sottolineando (5), potresti prendere la strada del
C#
Senza trascurare le alternative python e smalltalk (o anche
smallscript). Soprattutto nelle loro versioni per .NET (per ora,
ovviamente, in beta).


potresti prendere la strada del C#
Cosa ne pensi del C#?
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di it.comp.lang (per i linguaggi di
programmazione senza un gruppo apposito e per i confronti fra i
linguaggi) partecipa alla discussione sul manifesto su it.news.gruppi.

Grazie a tutti per le utilissime risposte, mi siete stati veramente di
grande aiuto.

 Cosa ne pensi del C#?
ammetto di non avere la stessa autorevolezza di Andrea, cmq esprimo 
anche il mio parere.
In primis ero abbastanza scettico per quel che riguardava C#, dato che 
avevo sentito dire che era la scopiazzatura di Java; poi ho letto le 
specifiche pubblicate da M$ ed in effetti e' un linguaggio che gli 
assomiglia molto, pero' ha anche alcune features interessanti e 
notevoli, ma anche molti difetti. Tra i migliori pregi (ovviamente 
IMHO) ci sono:
1) introduzione del concetto di variabile "definitely assigned": in 
pratica il linguaggio proibisce di utilizzare una variabile prima che 
sia stata inizializzata
2) conseguenza diretta di (1) sono i modificatori "out" e "ref" nel 
passaggio di parametri alle funzioni.
3) il meccanismo di boxing-unboxing permette una discreta integrazione 
tra tipi built-in e oggetti (sicuramente meglio di quello di Java, 
anche se non lo conosco abbastanza da esprimere un parere in merito).
4) Ridefindendo un operatore aritmetico di una classe (ad esempio '+') 
vengono automaticamente ridefiniti anche gli operatori += ecc. Discorso 
analogo per l'operatore ++: esiste una sola versione sia per prefisso 
che postfisso, e' il compilatore a preoccuparsi di restituire 
l'eventuale temporaneo necessario dal postfisso.
Tra i difetti (che grosso modo sono poi gli stessi di Java):
1) e' mono paradigma (OO) ma con alcune imperfezioni; sinceramente non 
riesco proprio a trovare il senso di dover definire una funzione 
statica Main all'interno di una classe; avrebbe piu' senso un approccio 
simil-C++ (funzione globale) oppure simil-framework (del tipo: derivare 
da una classe "Application" e ridefinire un metodo "Run").
2) Non supporta la programmazione generica ne' l'ereditarieta' 
multipla; questo porta ad avere una gerarchia di oggetto derivati da 
Object e IMHO ci sono numerosissimi svantaggi con questo approccio se 
usato in un linguaggio a tipizzazione statica.
3) Ha il garbage collector: questo rende impossibile utilizzare 
l'idioma RAII (molto utilizzato in C++) e rende anche il codice piu' 
facilmente non exception-safe.
4) I tipi built-in non sono integrati nel typesystem OO: avrebbe avuto 
piu' senso una classe int derivata da Object; il meccanismo 
boxing-unboxing risolve il problema in maniera migliore che non in 
Java, ma non e' certo la soluzione migliore in assoluto.
Sicuramente mi dimentico qualcosa, cmq direi che puo' bastare.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 Java, ma non e' certo la soluzione migliore in assoluto.
Concordo.


Java, ma non e' certo la soluzione migliore in assoluto.
Perché? Per le prestazioni?


 Perché? Per le prestazioni?
Perchè è meglio se i tipi predefiniti sono integrati nel sistema a tutti
gli effetti!


gli effetti!
Perché? Puoi spiegarmi meglio questo punto? Ad esempio in smalltalk i
tipi built-in sono esattamente come quelli definiti dall'utente.


 Puoi spiegarmi meglio questo punto?
RAII e' un acronimo che sta per "Resource Acquisition Is 
Initialization"; in pratica per gestire ogni risorsa la acquisisci in 
un costruttore e la rilasci nel distruttore corrispondente; esempio 
classico in C++ sono gli stream su file e gli auto_ptr:
        void foo() {
                std::ofstream f("pippo.txt") // apre il file nel ctor, lo chiude nel 
dtor
                std::auto_ptr<int> p = new int; // aquisisce la mem nel ctor, la 
rilascia nel dtor
        }
Il grosso vantaggio e' che la gestione delle risorse e' automatizzata e 
il programmatore non si deve preoccupare di liberarle (e rischiare di 
dimenticarsene); nota che questo e' anche exception safe, perche' in 
C++ i distruttori vengono richiamati anche in caso di eccezione non 
gestita.
Nei linguaggi che hanno la garbage collection non e' possibile 
applicare il RAII: infatti non esiste alcuna garanzia riguardo al 
momento esatto dell'esecuzione del distruttore: esso verra' richiamato 
quando il gc distruggera' l'oggetto; ma se per la memoria questo e' un 
approccio fattibile per molte altre risorse non lo e' (chi di voi 
vorrebbe lasciare aperto un file in scrittura, magari esclusiva, sino 
ad un tempo indeterminato?).


 allocazioni.
quindi sei a favore di RAII e di conseguenza contro i GC, no?


 tipi built-in sono esattamente come quelli definiti dall'utente.
Dobbiamo fare un distinguo. Cosa intendi per tipo builtin o per tipo
predefinito? Se un dato tipo è definito in una libreria che è sempre
parte del linguaggio, lo consideri predefinito? In smalltalk tutti i
tipi (anzi tutto in assoluto) è un oggetto e pertento è una istanza di
una classe. Inoltre, in generale, di tutte le classi e di tutti i loro
metodi sono forniti i sorgenti. Questo vale anche per tutti i tipi.
Nel caso peggiore il sorgente di un metodo non è altro che una chiamata
ad una primitiva (il che significa che quel metodo è implementato in C o
in assembler). Ma il numero di primitive necessarie al linguaggio è
veramente minimale. In quasi tutti i sistemi smalltalk seri però molti
metodi sono implementati come primitive per motivi di efficienza. Ma per
questi metodi viene dato anche il sorgente smaltalk (in pratica il
sorgente smalltalk prima chiama la primitiva, poi verifica se la
primitiva ha ritornato un errore e nel caso esegue il codice smalltalk.
In questo modo di fatto il metodo è implementato come primitiva, ma se
tu "sostituisci" il core delle primitive con uno minimale scritto da te
che supporta solo le primitive che sono veramente tali, tutto il resto
continua a funzionare). Un altro caso sono metodi implementati in parte
come primitiva ed in parte in Smalltalk. In generale però ti troverai ad
avere a che fare con metodi implementati come primitiva in pochi casi
banali (per esempio le operazioni aritmetiche fra numeri di solito sono
primitive in assembler per ovvi motivi di efficienza) o quando il
produttore vuole proteggere alcune tecniche proprietarie (in pratica
alcuni metodi del compilatore sono primitivi: ricorda che tutto é un
oggetto, compreso il compilatore e l'ambiente di sviluppo. Buona parte
dei quali sono forniti come sorgenti e che puoi modificare "on the
fly"!).
Ci sono però, va ammesso, due tipi che sono di fatto gestiti in maniere
diversa: Character e SmallInteger (che non è uno short, come molti
pensano!). Questi tipi, per come sono implementati, non possono essere
in alcun modo passati per reference (ovviamente puoi sempre usare una
tecnica di boxing). Ma in generale tutti i tipi aritmetici sono gestiti
in maniera da funzionare con passaggio per valore quindi la cosa in
realtà cambia poco (inoltre puoi sempre vedere Character e SmallInteger
come classi astratte aventi delle classi derivate singleton
rappresentanti ciascuno dei valori possibili, solo che di queste ultime
non sono forniti i sorgenti e delle prime i metodi sono perlopiù
primitivi).


oggetto quando esce dallo scope.
Ma il gc non può fare in modo che l'oggetto venga distrutto appena
esce dal suo scope?
ad es in un linguaggio inesistente:
funzione f(){
    mio_file = apri_file("pippo.txt")
}
appena la funzione esce il file aperto può essere immediatamente
chiuso dal distruttore poiché nessuna variabile si riferisce ad esso.


 quindi sei a favore di RAII e di conseguenza contro i GC, no?
Non del tutto. Rileggi la mia frase.


 quindi sei a favore di RAII e di conseguenza contro i GC, no?
che storia, io avevo capito il contrario...
Scusa un attimo ma se dice che i problemi dovuti alla gestione diretta 
dei puntatori (risolti da una GC quindi) sono più frequenti di quelli 
risolvibili da una RAII mi pare di capire che una GC è più UTILE, nel 
senso che risolvendo più problemi rende più facile l'uso del linguaggio. 
Adesso cosa mi è sfuggito?
Maurizio
-- 
Maurizio Sambati
Skice Software
E-mail: 
gsm...@inwind.it
--------------------------

 Adesso cosa mi è sfuggito?
Solo il fatto che potresti non essere tu ad aver capito male!
Infatti, la mia opinione è che "dipende" da cosa devi fare. Ma che in
generale conviene un linguaggio con GC. Ovvero che in generale conviene
lavorare in Python o smalltalk invece che in C++ (anche se in C++ si può
"aggiungere" la GC, non è mai la stessa cosa che avresti con un
linguaggio in cui è built-in).
Ma come sempre: dipende da cosa devi fare.


 chiuso dal distruttore poiché nessuna variabile si riferisce ad esso.
Per farlo bisogna presumere che all'uscita da f venga eseguito del
codice. Ma nei linguaggi gc non č cosě. Supponi di lavorare in C++ e che
il C++ abbia un gc builtin. Supponi che il codice sia:
void f(){
    int *p=new int[5];
    // usa p;
}
come fa il gc a sapere che la memoria non ha piů riferimenti nel preciso
istante in cui termina la funzione f?


codice. Ma nei linguaggi gc non č cosě.
Premetto che non so esattamente come funziona la gc in Python ma in
casi *semplici* come quello che ti ho mostrato l'interprete dovrebbe
rilasciare l'oggetto nel momento esatto in cui niente si riferisce piů
ad esso, cioč se ho:
class C:
    def __del__(self):
        print "C.__del__ č stato chiamato"
e faccio:
c = C()
c = 0
ottengo immediatamente a video la scritta "C.__del__ č stato
chiamato".


 Non del tutto. Rileggi la mia frase.
hai ragione, avevo letto male. Io sono di questa opinione:
- il gc risolve i problemi di gestione della memoria, ma quelli 
relativi alla gestione delle altre risorse
- RAII aiuta a risolvere il problema della gestione di tutte le 
risorse, tra cui la memoria; basta utilizzare esclusivamente smart 
pointer per evitare memory leaks, no?
conclusione: il RAII risolve tutti i problemi risolti dal gc ed anche 
altri, quindi e' migliore.
Unico dubbio: non ho mai sviluppato un progetto facendo uso estensivo 
di smart pointer, quindi non sono sicuro che rappresentino una panacea 
(anzi, sono sicuro del contrario, dato che non esistono panacee); quali 
sono i contro nell'usare gli smart pointer rispetto al gc?


 sono i contro nell'usare gli smart pointer rispetto al gc?
hehe. Ma non hai neanche mai fatto un progetto con il GC. Quindi ...


 c = 0
Mumble. Per curiosità: prova a scrivere una funzione nella quale metti
le righe:
c = C()
c = 0
print "azzerato"
e poi prova a chiamare la funzione.
Domanda: quale dei due print viene eseguito prima?


Domanda: quale dei due print viene eseguito prima?
prima quello nel __del__ e poi viene stampato "azzerato".
Non ho ancora provato a cercare nella documentazione di Python ma mi
pare che la gc non sia garantita ma che nell'attuale implementazione
la gc sia basata su reference count e quindi l'oggetto venga distrutto
automaticamente (a meno in cui vi siano dei "riferimenti circolari").


 automaticamente (a meno in cui vi siano dei "riferimenti circolari").
Quindi in pratica invece che un vero GC hai un sistema misto fra GC e
reference counting. Interessante. In pratica ti permette di usare RAII
ma nello stesso tempo di fregartene dei puntatori. Anche se alla fine è
prestazionalmente inferiore rispetto al meccanismo del GC puro.
Suppongo che dovendo disegnare ex novo un linguaggio si potrebbe trarre
qualche spunto. E poi non per nulla Python è un linguaggio nuovo che non
ha come target le alte prestazioni, quindi direi che è un'ottima idea.


ma nello stesso tempo di fregartene dei puntatori.
Tieni presente che non è garantito quindi in teoria da una certa
versione potrebbero cambiare completamente il comportamento del GC, ma
conoscendo come vengono fatti i cambiamenti in Python non penso che
verrebbe fatto nel giro di poco tempo per non creare problemi al
codice esistente.


 codice esistente.
Se NON è garantito ... allora è come se fosse un GC normale. Non puoi
usare RAII.


 sia così e non sono sicuro al 100%.
quali sono i problemi dovuti al semplice reference counting?


 quali sono i problemi dovuti al semplice reference counting?
Link circolari e overhead in esecuzione ad ogni assegnamento.


usare RAII.
Si ma non č come il C++ per cui esistono 1000 compilatori!
Penso (e sottolineo penso) che non sia garantito anche perché jython
potrebbe avere qualche problema a fare lo stesso ma non ne sono
sicuro. Se cosě fosse chi scrive un programma in python usando delle
librerie non presenti in jython potrebbe essere abbastanza sicuro che
la gc viene effettuata nel momento in cui il reference count va a 0.
Domani proverň a chiedere sulla ml di python maggiori informazioni.


quali sono i problemi dovuti al semplice reference counting?
Penso che questo codice sia facilmente comprensibile anche se non
conosci Python:
class C:
    def __del__(self):
            print "C.__del__"
def f():
    c = C()
    c.attributo = c
Quando f viene chiamata e termina il conto dei riferimenti di c non
sarà a 0 perché qualcosa altro si riferisce a c, il semplice reference
count non può sapere che è lo stesso c a riferirsi a se stesso e
quindi non lo distrugge.


 sia cosě e non sono sicuro al 100%.
dal 2.0, sull'arg ho un vecchio link di quel periodo:
http://www.enme.ucalgary.ca/~nascheme/python/gc.html
--
saluti
f.riccardo


http://www.enme.ucalgary.ca/~nascheme/python/gc.html
Le cose stanno più o meno come immaginavo comunque ho chiesto sulla ml
di python e vi farò sapere quando mi rispondono.


 smartpointer o un GC "aggiunto" per aiutarti nella gestione dei leaks.
se me lo dici tu mi fido.


tipi. 
Scusa, non vorrei farlo ma mi sto perplimendo di nuovo. Cose come i 
semplicissimi, stupidi interi come fai a definirli come classi, senza 
usare da qualche parte interi che interi-classe non sono? E' possibile? 
Davvero basta il linguaggio? Alla fine non deve sempre metterci lo 
zampino il deus-ex-machina che è il compilatore, in qualche modo? 
facendo passare le espressioni numeriche costanti per corsie 
preferenziali?
Mi pare di aver visto una risposta nelle righe seguenti:
[...]
Ma sono stupido e le ho cancellate. E sono stanco. Abbi pazienza per 
questa volta
-- 
Nato nel vizio, morto nel supplizio
Nato nel peccato, ad entrare sia invitato

quali sono i problemi dovuti al semplice reference counting?
Oggetti che si tengono in vita artificialmente afferrandosi e tenendosi 
appesi per una maniglia dell'amore. Coppie od orgastici grovigli di 
oggetti che circolarmente si toccano l'un l'altro. Chi non viene toccato 
da nessuno č fuori. In quel caso come decidi chi ha finito di giocare, 
di chi sbarazzarti, solo basandoti su quanti toccano ogni oggetto? e se 
un oggetto si tocca da sč? ricorda che tu puoi solo contare quante mani 
toccano un oggetto, non hai alcuna informazione sul braccio a cui quella 
mano č attaccata, nč tantomeno sull'oggetto alla fine del braccio
Questo dilemma, da solo, fu forse la causa principale del mio abbandono 
del Visual Basic, in cui ogni singolo fottuto assegnamento di 
riferimenti ad oggetti era reference counted, anche quando non ce n'era 
alcun bisogno, anche quando poteva essere dannoso (e non vi sto a 
raccontare la "soluzione" a questo problema, ma c'entrano un martello e 
molta forza bruta)


 wow, adesso si che ho l'acquolina in bocca :-)
La mia era una risposta provocatoria ad una domanda provocatoria.
Occhio a non illuderti troppo perchè di prodotti commerciali sviluppati
in smalltalk non ce ne sono molti (viene di solito usato per sistemi
complessi di dimensioni medio-grandi). E naturalmente estendere un
prodotto in quella maniera lo puoi fare se hai il prodotto caricato
nell'environment (che di solito avviene se ne hai il sorgente, benchè
non sia necessario, ma di fatto il sorgente non ti serve neppure
guardarlo). Però vedi la cosa non come un meccanismo per estendere word
ma bensì come un meccanismo per estendere/personalizzare un TUO prodotto
di dimensioni medio grandi. Mi dirai che teoricamente lo puoi fare anche
in C++ se hai il sorgente del prodotto. Ma in realtà non è proprio così.
Prova a giocarci e te ne renderai conto.
Una cosa curiosa di smalltalk è che se scrivi una applicazione e la
distribuisci/installi in maniera "aperta", puoi poi aggiornarla online.
Mi spiego.
Smalltalk è interpretato (in realtà è un p-code tipo Java o Python). Una
cosa particolare è che in smalltalk è che il compilatore, l'editor, il
browser di classi, il debugger etc. etc. sono scritti in smalltalk e
girano nella stessa VM del tuo programma. Anzi: il sistema di sviluppo
di smalltalk è una applicazione smalltalk. Comprende un numero X di
classi e di routine. Tutte sono compilate e presenti all'interno del
sistema di sviluppo stesso. Tu NON scrivi il tuo programma ma bensì
scrivi delle altre classi e delle altre routine che compilate vanno ad
aggiungersi a quelle esistenti. Quando esegui il tuo programma in realtà
stai ancora eseguendo il sistema di sviluppo. Se cambi una routine o una
classe di libreria (hai il sorgente di quasi tutto) fra quelle che il
compilatore e/o in generale il sistema di sviluppo usa, il sistema di
sviluppo comincia a usare la tua da quel momento in poi. In pratica stai
lavorando con un sistema in cui puoi cambiare il codice ... del sistema
stesso.
Quando hai finito l'applicazione puoi fare due cose: distribuzione
"aperta" (in pratica installi l'environment smalltalk completo incluo il
tuo programma) oppure distribuzione "chiusa" (rimuovi tutti i sorgenti
nonchè il pcode delle classi e dei metodi che non usi, incluso il
compilatore, l'editor, il debugger etc. e installi solo quello che
resta, che poi è il tuo programma).
Supponi di aver scritto un applicativo di gestione bancaria e di averlo
installato in maniera "aperta". Supponi di aver preparato un
aggiornamento (naturalmente testato a dovere e tutto il resto. Esporti
dalla nuova versione tutti i sorgenti che sono cambiati, li porti dal
cliente e ... MENTRE IL SISTEMA GIRA fai aprire una finestra di "load"
dei sorgenti, li carichi, il compilatore (che di fatto fa parte del tuo
prodotto) li compila, sostituisce il PCODE risultante a quello vecchio e
voilà: upgrade del SW fatto al volo mentre il sistema continua a
funzionare.
Meglio ancora: il tuo programma è scritto in maniera da gestire bene gli
errori? Quindi anche in caso di baco non si ferma e tutte le
funzionalità che non sono affette dal baco continuano ad andare. Il
cliente ti chiama e dice che una data operazione gli da sempre errore.
Vai a vedere e ispezionando il sorgente noti un errore stupido (una i
invece che 1 per esempio). Semplice: se sei assolutamente certo di cosa
stai facendo non fai altro che modificare quella lettera MENTRE IL
PROGRAMMA GIRA. E appena l'hai modificata, l'operazione che non andava
si mette ad andare.


 preferenziali?
Che i compilatori usino meccanismi built-in per ottimizzare (e quindi
implementino le corsie preferenziali) è persino auspicabile. Il concetto
di espressione numerica costante non esiste in smalltalk. Esiste una
espressione numerica. Che naturalmente il compilatore può ottimizzare se
è il caso e se è sicuro che la cosa si può fare. Il fatto che gli interi
siano classi non significa che tu possa modificare il comportamento
predefinito di un intero (in realtà puoi, ma è facile che ti si impalli
l'environment). Però puoi decidere di aggiungere un operatore al tipo
intero. Per esempio puoi dire che si può scrivere 2 @ 4 e che questo ha
un significato (tra parentesi l'operatore @ e veramente definito in
smalltalk!). Oppure puoi derivare da intero e crearti un intero "esteso"
in qualche maniera. Ovvio che ad un certo livello c'è qualche primitiva.
Ma questo non significa nulla. Che la somma fra interi sia un metodo
della classe degli interi e che questo metodo sia una primitiva (ovvero
implementato in assembler) non influisce minimamente sul resto del
sistema. Così come ti servono dei 'mattoni' primitivi per implementare
gli oggetti. In smalltalk la strutturazione in memoria di ogni oggetto
segue uno di 4 diversi meccanismi di layout. I primi due meccanismi sono
usati solo ed esclusivamente da due tipi semplici (Character, che è un
byte, e SmallInteger che è un intero "base"). Un altro meccanismo è
usato da stringhe e altri tipi simili (in pratica un array di byte).
L'ultimo meccanismo è usato da tutti gli altri tipi (in pratica un array
di "riferimenti" ad altri oggetti). Ma di questo in realtà a te importa
veramente molto poco. Un tipo che definisci tu quasi certamente deriva
da un tipo preesistente. E usa il meccanismo definito da quel tipo.


 è prestazionalmente inferiore rispetto al meccanismo del GC puro.
mi sono sempre chiesto come cavolo fa a funzionare un gc: usa dei bit 
per marcare quali parole sono usate e quali no? E come si fa a sapere 
quando non esistono piu' riferimenti ad un dato indirizzo?


 online. Mi spiego.
[cut]
giuro che appena ne ho il tempo vado a darci un'occhiata.
Ma perche' non e' diffusissimo se ha tutti questi pregi? Solo questioni 
storiche/di marketing/culturali oppure ci sono anche ragioni tecniche?
ciao anto


 storiche/di marketing/culturali oppure ci sono anche ragioni tecniche?
1) fino a non molti anni fa le interfacce grafiche dei programmi
smalltalk non erano del tutto conformi allo standard delle varie
piattaforme (però erano identiche sia che girassero su unix sia che
girassero su mac sia che girassero su dos sia che girassero su windows.
La cosa sta migliorando.
2) in generale dovevi pagare una royalty al produttore del sistema
smalltalk per ogni installazione che fai. Anche questo sta migliorando,
e comunque per studiare oggi trovi anche sistemi scaricabili gratis.
3) fino a circa l'inizio degli anni 90 smalltalk era abbastanza
inefficiente. Oggi questo è migliorato molto (in certe cose è meglio di
C++). Ci sono stati grossi investimenti in ricerca sulle ottimizzazioni
delle VM. Java stesso nasce ha ereditato molto dalle ricerche sulle VM
fatte per smalltalk e linguaggi derivati. Inoltre oggi la potenza di
calcolo è molto aumentata. Se combini una VM non del tutto efficiente
con la potenza di calcolo che avevi 10 anni fa, capisci che C era molto
più diffuso per molte applicazioni. Il C++ è diffuso perchè assomiglia
al C. Java perchè è esploso internet. Se C++ avesse permesso a chi
conosce il C di lavorare da subito sarebbe molto meno diffuso (salvo che
poi lavora "in modo C", ma questo è un altro discorso: chi conosce il C
ha molte più ragioni di affrontare l'OO poco alla volta usando il C++
che di passare a smalltalk, e il management è molto più facile che vieti
di passare ad un nuovo linguaggio che non semplicemente ad un nuovo
compilatore che compila "better C"). E se non ci fosse il web quanto
pensi sarebbe diffuso Java?
4) Salvo che in italia è poco conosciuto, guarda che smalltalk è
diffusissimo. L'OO è nata e si è sviluppata intorno a smalltalk. Buona
parte del discorso sui template ha come base smalltalk. La XP è nata e
si è diffusa principalmente in ambienti in cui viene usato smalltalk.


diffusissimo.
Ci sono ragioni particolari per cui in Italia č cosě meno diffuso
rispetto ad altri paesi?


 quando non esistono piu' riferimenti ad un dato indirizzo?
Un thread in background segue questo algoritmo:
1) marca come "unused" tutti gli oggetti allocati
2) parti dallo stack-frame attuale e cammina all'indietro fino al primo
stack frame. Per ogni puntatore che trovi nello stack (sullo stack
stanno le variabili locali alle funzioni) marca gli oggetti puntati come
"used"
3) per ogni puntatore che fa parte di un oggetto marcato, marca
l'oggetto puntato "come usato"
4) ripeti 3 fino a che non esegui un intero passaggio senza marcare
alcun oggetto
5) elimina tutti gli oggetti marcati come unused
Questa è l'idea base generale. Ci sono poi molte variazioni in base al
tipo di linguaggio, al cosa significa "stack", a cosa significa
"puntatore" etc. Nonchè alcune variazioni relative al processo di
"marcatura" e al concetto di "thread di background".
Ma l'idea base è quella.


 si č diffusa principalmente in ambienti in cui viene usato smalltalk.
ah, non lo sapevo.
ciao Anto


 immagino volessi dire: "Se il C++ *non* avesse permesso..."
immagini bene, ovviamente.
