Curiosità sui linguaggi...

Lucia De Pasqual lucia@arsie.net
Dom 30 Dic 2007 15:57:03 CET


Chiaramente c'e` il lato pratico (sintassi e uso quotidiano), come c'e`
> quello teorico, il quale invece poggia su considerazioni di dimostrabilita`
> matematica (correttezza ed efficienza).
> Alcuni linguaggi non sono affatto utilizzabili dall'utente-programmatore
> senza una certa conoscenza della grammatica e dell'implementazione del
> parser. Mi riferisco per esempio a quella bestiaccia di Smalltalk, o a
> Lisp, ma la considerazione resta validissima, anche se meno stretta, anche
> per affari come C++ (che non si conosce mai abbastanza a fondo).
> Tanto per dire e restare in tema C++, conoscendo come funziona il garbage 
> collector, che C++ non ha :), si puo` capire come dichiarare un array
> con dimensioni specificate da un'espressione non-costante costringa il
> compilatore a generare codice che piazza un puntatore sullo stack, che 
> punta ad un'area dell'heap in cui questo array dalle dimensioni 
> misteriose (conosciute solo a tempo di esecuzione) puo` trovare 
> spazio senza problemi; d'altronde g++ non puo` fare diversamente, onde 
> evitare eventuali problemi di linking. Eccetera, eccetera.
>
>   
ma scusa questo non e' semplicemente C? e per estensione ereditato dal C++?
Qui sono stati introdotti apposta i container che hanno una loro 
gestione della memoria, un pochino diversa da quella del semplice array.

Non capisco cosa c'entra con un garbage collector, che appunto in C/C++ 
non c'e' visto che non ci sono virtual machine:
il compilatore non puo' sapere quello che vuoi fare tu quando hai 
dichiarato un array di dimensione incognita e quindi non puo' sapere 
quanta memoria mettere nella sezione data del tuo eseguibile compilato, 
deve per forza di cose tenersi nella sezione data  la definizione di un 
puntatore che poi sara' associato ad un'area che verra' allocata al 
runtime nello heap (cioe' quando si sapra' esattamente quanto spazio serve).
Certo, allocazione e deallocazione continua rendono meno efficiente un 
programma (ah, l'efficienza di un buon fortran 77 dove dovevi sapere tu 
quanto grande doveva essere il tuo array perche' andava tutto nella 
sezione data e dove si sfruttavano i trucchetti dell'unroll manuale dei 
loop in base al processore su cui deve girare...), ma sta al 
programmatore gestire correttamente la memoria o scegliere un linguaggio 
in base a quello che deve fare, efficienza, dimensione dell'eseguibile, 
portabilita'...

Non credo che ci siano molte persone che si fanno una pagina web in c++, 
come non ci potranno essere tante applicazioni realmente embedded 
(aggeggi con minimo hardware e alta affidabilita') basate su virtual 
machines.

Poi ci sono cose tipo i decoder digitali che contengono la virtual 
machine Java (minimale, non certo una della Sun scricabile dal loro 
sito), che serve essenzialmente a far girare le applicazioni che vengono 
giu' dall'aria (non so se qualcuno ha idea delle eccezioni che vengono 
sparate fuori da queste applicazioni) o a mostrare banner di vario tipo, 
ma dove tutta la sintonia, la decodifica e la grafica dei menu del 
decoder viene fatta in C.

Qualche mail fa c'era una nota riguardo all'uso del C++ nei dispositivi 
embedded: in effetti il limite di questo linguaggio non sta tanto nel 
peso, non c'e' molta differenza rispetto al C, specie se paragonato alla 
manutenibilita' del codice generato, quanto spesso alla mancanza di un 
compilatore per il SO installato.
> Non conosco approfonditamente come e` implementato l'interprete Python,
> ahime`, so solo come funziona quello di Smalltalk (per alcuni versi
> simile a quello Ruby), in sostanza qui la lezione e`: "Non puoi ottenere
> qualcosa per niente", cioe` aspettati di dover pagare un certo prezzo per 
> la duttilita` estrema del paradigma OO puro ( != Java). Il prezzo e`
> quello, non avendo i tipi statici che fanno la differenza, di un maggior
> costo (cpu, memoria) in termini di rappresentazione run-time del programma.
>   
Uno dell'ISIB (cnr) qualche anno fa ha tenuto un corso di oo con 
particolare focus su smalltalk e, oltre a spiegarci che si tratta 
dell'unico linguaggio eticamente utilizzabile da un programmatore oo, ne 
ha dimostrato le potenzialita' nel calcolo con i numeri grandi: alla 
fine della lezione ha dovuto spegnere tutto perche' dovevamo andare a 
casa ^_^






Maggiori informazioni sulla lista blug