Newsgroup: it.lavoro.informatica
Titolo: linguaggio ADA

Sto studiando qualcosa su questo interessante linguaggio.  C'è
qualcuno nel gruppo che lo usa regolarmente? Nel caso è vero che il
compilatore Ada intercetta molti più errori logico/formali, rispetto
ad altri linguaggi?


ADA è il linguaggio della NASA, già da alcuni decenni. E' nato 
procedurale ma presumo che poi è stato ampliato per renderlo ad oggetti, 
altrimenti non sarebbe sopravissuto.
 
Su wiki si legge che "Ada is strongly typed and compilers are validated 
for reliability in mission-critical applications such as avionics 
software."
 
inoltre : "Notable features of Ada include: strong typing, modularity 
mechanisms (packages), run-time checking, parallel processing (tasks, 
synchronous Message passing, protected objects and nondeterministic 
select statements), exception handling, and generics. Ada 95 added 
support for object-oriented programming, including dynamic dispatch."
 
Se fossei più giovane un po' di tempo per 'giocarci' ce lo perderei 
volentieri....

 volentieri....
 
Non guardare la carta d'identità, allora, e perdici tempo! :-) Io so
che è molto usato anche nell'industria aerospaziale e ferroviaria,
oltrechè alla NASA. Bisogna capire se questo accade principalmente per
motivi storici, causa enorme eredità di codice pronto e testato (come
Cobol e Fortran in altri ambiti), oppure se tuttora presenta dei
vantaggi rispetto ad altri linguaggi più giovani.

 vantaggi rispetto ad altri linguaggi più giovani.
 
Il motivo storico e' sicuramente preponderante anche se qualche 
vantaggio rispetto ad altri linguaggi in ambienti critici c'e' l'ha.
Nasce in ambiente militare su iniziativa del DOD per appunto eliminare 
alcune criticità degli altri linguaggi per progetti molto critici dove 
un errore puo' costare molto caro.
 
Qui un documento di comparazione fra java e ada anche se chiaramente la 
fonte potrebbe non essere neutra:)
 
http://www.adacore.com/wp-content/uploads/2006/07/PaperPresentationAE2006-Brosgol.pdf
 
 


 
Mi sembra che le conclusioni favoriscano  visibilmente Ada.
Come dicevo, mi piacerebbe giocarci, (se è gratis)... :-)))
 
 
 

 Come dicevo, mi piacerebbe giocarci, (se è gratis)... :-)))
 
Sto usando la versione aggratis chiamata Gnat Ada, la trovi sul sito:
http://libre.adacore.com/libre/
 
 
La versione professional mi sa che è un pochino costosa... :-)

 
http://www.adacore.com/wp-content/uploads/2006/07/PaperPresentationAE.
..
 
Grazie, interessante.

 Mi sembra che le conclusioni favoriscano  visibilmente Ada.
 
ti sembra bene. però attenzione a non perdere di vista l'ambito in cui
è stata fatta quella valutazione perché il real-time non è applicato e/
o applicabile solo ai sistemi safety-critical.  non mi farei cogliere
da eccessivo entusiasmo, insomma... :)
 


..vabbè, ma come si suol dire  'se va bene per loro <cioè per i 
safety-critical> va bene anche per me...  :-)
 

 safety-critical> va bene anche per me...  :-)
 
mi sembra una affermazione quantomeno discutibile.

 ad altri linguaggi?
 
Anche questo non saprei dirtelo.
 
Ciao,
Marco
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 


Se ti interessa la caratteristica di un linguaggio di intercettare errori 
logico/formali, dai anche una occhiata ad Haskell e Standard ML.
 
 
 
 
Ciao  Manlio

 qualcuno nel gruppo che lo usa regolarmente?
 
Avevo comprato un libro su ADA ad una fiera, ma...
davvero c'è qualcuno che lo usa a livello professionale ??
In Italia ???
 
Shift
 

 controllo del vettore.
 
scusa ma la caratteristica di intercettare errori logico/formali non è
a livello di compilazione? che c'entra l'overflow a runtime?


E quindi?

 Prevedi di andare a lavorare nel settore aerospaziale :-) ?
 
Io non escludo mai niente. Come si dice, da cosa nasce cosa. Mi è
capitato di mettere su internet alcune pagine con qualche programma
demo fatto per divertimento in computer grafica e computer vision, e
poi di essere contattato direttamente da clienti (uno inglese)  che mi
hanno commissionato dei lavori (e soprattutto mi hanno pagato :-).
Ada può essere la classica nicchia ad alto ritorno, come può non
essere niente, solo un interessante diversivo.

 logico/formali, dai anche una occhiata ad Haskell e Standard ML.
 
Haskell l'ho guardato, lo trovo eccessivamente complicato. Della
famiglia ML sto approfondendo OCaml, effettivamente è un altro
candidato per applicazioni "a prova di errore" (perlomeno logico :-)),
un pò meno ostico di Haskell.


Mah, se c'è un linguaggio che intercetta più errori logici in fase di
compilazione, cioè aumenta la produttività, penso sia utile valutarne
l'uso. Indipendentemente se è nato per i classici missili sulla Luna o
per i giochini di qualche store.
Nel documento comunque sostiene anche che Java ha una sintassi più
complessa di quella di Ada, non più semplice. Cosa interessante.

 che ti sta portando in vacanza: in Ada o in C?
 
Francamente penso che il C sia il peggior candidato che potevi trovare
per parlare di linguaggio più "controllabile" di Ada.
 
 

 che lavora in quegli ambiti.
 
 
Ai miei tempi (dal 1970 al 1996 all'ESA si usava di tutto meno che 
l'ADA, che era sì conosciuto, ma lo usavano solo quelli che 
'importavano' qualcosa dalla NASA.
 
ALl'ESA si è sempre usato per la maggior parte il FORTRAN (tutte le 
versioni susseguitesi negli anni) e fino agli anni 90 il C/C++ anche sui 
Sun Workstations. Oggigiorno ancora si usa prettamnte il C/C++
e Java. Isolatamente, c'è qualcuno che usa l'ADA.
Parlo dello stailimento ESOC di Darmstadt, che è il Control Center 
dell'ESA (equivalente di Houston della NASA).
In altri stabilimenti (ESTEC di Noordwijk, ESRIN di Frascati) non so.

 ostico di Haskell.
 
Di OCaml sto leggendo il manuale.
Peccato che alcune scelte sintattiche non mi piacciano, ed io sulla 
sintassi sono abbastanza pignolo (a causa di questo non ho mai voluto 
imparare seriamente Erlang).
 
Ora sto vedendo SML perchè mi sembra che sia un pò più elegante di OCaml.
 
 
Ciao  Manlio

 runtime checking?
 
Concordo.

 Proprio quello!
 
Si l'altro....

 runtime checking?
 
Io la vedo così: se c'è un linguaggio (potrebbe essere Ada, ma non è
detto) che mi consente di avere programmi con più elevata probabilità
di girare senza errori al primo run, ci rinuncio in tutti i casi, solo
perchè mi chiede di scrivere un pò di codice in più? (cosa non
necessariamente vera, vedi OCaml che è molto più stringato di Ada). In
altri termini, per me il bug non è accettabilissimo solo perchè se si
verifica non muore nessuno (per fortuna).

 "controllabilità") di Ada?
 
E' quel che dici tu, secondo te con C il programma può continuare a
girare anche in caso di overflow numerico non gestito, invece con Ada
no (cosa che risulta anche a me). Spiegaci come un programma C può
controllare correttamente un overflow non gestito dal programmatore,
non mi è chiaro.
 
 

 overflow su downward-convertion blocchi l'esecuzione del programma?
 
Mi sembra che la frase che ho scritto è chiarissima, Ada non c'entra
assolutamente nulla, c'entra il C. Rileggitela.

 ragione è buono per gli altri", affermazione quantomeno discutibile.
 
Diciamo che forse ci possono essere buone idee da "traghettare" in
altri ambiti, magari in modo circoscritto.

 del flusso di esecuzione.
 
in c come in altri linguaggi una assegnazione del genere provoca il
troncamento del dato (a meno che non ce lo copi via puntatore in tal
caso hai un buffer overflow). in ogni caso un bug. stai dicendo che
probabilmente l'arianne avrebbe fatto il botto di un altro colore?
 

 qual'è il linguaggio più diffuso
 
In quel settore ho visto spesso usare il C.

 stato distrutto lo stesso, ma avrebbe continuato a volare."
 
bah, se lo dici te. fra l'altro leggo su wikipedia che la trap era
stata disabilitata.
 

 E quindi?
 
e quindi ciò che ha originato il disastro è stato un arithmetic overflow 
sollevato dall'hardware, niente di diverso da quello che sarebbe successo 
ad un programma c di fronte allo stesso bug. 
 
 
 


AFAIK, e proprio non sono un esperto, negli apparecchi medici conta 
piu' il sistema operativo che il linguaggio, per questo si usa C.
 
  ngw
 
-- 
http://stylej.am
 
 

 Un programma in C che provoca un overflow, cessa per questo l'esecuzione?
 
va in segmentation fault
 
E comunque state discutendo di lana caprina.
ADA, C, C++, Java non c'entrano nulla o poco. Se il software ha un bug,
perché chi l'ha scritto è un cane o è semplicemente un essere umano, è
sempre un bug. Se un linguaggio me lo definite più "robusto" perché in
un caso in presenza di un bug continua a funzionare senza battere
ciglio, nell'altro no... allora state dicendo che nel primo caso... non
è un bug :)
Ogni linguaggio ha delle peculiarità, pro e contro. In ogni linguaggio
c'è la possibilità di scrivere vaccate. Discutere della robustezza di un
linguaggio su come gestisce un buffer overflow o la divisione per zero è
riduttivo e inutile.
Si può invece discutere del fatto di come un linguaggio ti metta nelle
condizioni di scrivere codice il più possibile privo di "sviste", la
facilità di debug, trace, log, etc.
Scrivere vaccate con C/C++ è molto più "facile" che non con Java, ma di
contro C/C++ è molto più potente e performante, in molti ambiti (es.
sistemi operativi embedded).
Il problema non è tanto nel linguaggio, ma nella persona che sviluppa.
Il software dell'Arianne è stato scritto in ADA? Ok, sarebbe stato
possibile scriverlo anche in Java (?), o in C (magari con un 3x nei
tempi di sviluppo) o in assembler (con un 6x nei tempi di sviluppo).
Java, C e soprattutto assembler avrebbero "introdotto" la possibilità di
scrivere insidiosi bug? Può darsi, ma alla fine dei conti il linguaggio
è un strumento in mano allo sviluppatore: se lo sviluppatore scrive una
vaccata... non c'è linguaggio che tenga.
 
M.

 Si, è chiarissimo che non hai capito una ceppa.
 
Ho capito che sto perdendo tempo a rispondere ad uno che ritiene che
non gestire gli overflow fa volare i missili :-))


Piu' che il sistema operativo direi la piattaforma nel suo complesso.

 facilità di debug, trace, log, etc.
 
Infatti, linguaggi come Ada ed altri più moderni tentano (o dichiarano
di ...) di intrappolare errori logici in una fase preventiva rispetto
all'esecuzione. Magari per altri linguaggi questo si ottiene
ugualmente con appositi tools esterni di analisi del codice sorgente,
personalmente ritengo più pulito un linguaggio progettato
appositamente per evitare certi errori.
 
 
 

 Un programma in C che provoca un overflow, cessa per questo l'esecuzione?
 
anche si, non conosci il segmentation fault?
se l'eccezione viene sollevata dal sistema che ci sta sotto io direi
che a quel punto non dipende più tanto dal programma se cessa o meno
l'esecuzione. più in generale si tratta del più classico
"unpredictable behaviour" per cui anche nel caso l'exploit andasse a
sovrascrivere un'area di memoria permessa *comunque* altererebbe dei
valori (a cominciare dal risultato di quella conversione) e l'unica
certezza sarebbe la non-certezza del comportamento per cui è stato
programmato. da qui mi chiedo da cosa deriva la tua certezza  "avrebbe
continuato a volare". tutto qui.

"ispas"  ha scritto nel messaggio 
news:6aa786e4-f183-44e0...@s7g2000yqa.googlegroups.com...

Te lo spiego io, ma poi non mi dire "si ma che esempio e', e' scritto male, 
io parlavo di codice scritto bene!" perche' se il codice e' scritto bene di 
overflow non ne dovrebbe proprio fare.
 
Non ti e' chiaro probabilmente perche' non ci lavori. 99 su 100 viene fuori 
un macello e il segmentation fault ti *avvisa* che da qualche parte c'e' un 
problema, ma raramente accade che sovrascrivi zone di memoria lecite e senza 
provocare danni (magari perche' quelle variabili non sono piu' usate). Salvo 
poi bestemmiare in aramaico quando rimetti mano al codice per una modifica, 
non funziona piu' niente e non sai perche'.
 
Ad esempio questo:
 
int    pippo()
{
int    *x;
int    buffer[100];
char y;
int    buffer1[100];
 
    // lavora con buffer e buffer1
 
    x = (int *)&y;
    *x = 1;    // intero!
 
    // qua uno dei due buffer e' cambiato!
 
    return 1;
}
 
e' sbagliato ma funziona, piu' o meno sempre e dappertuto (e l'ariane non si 
schianta), ma se ti serve lavorare su buffer o buffer1 DOPO l'istruzione 
errata va a finire che non ci capisci piu' niente. 
 

 Shift
 
Andrea 
 
 

 errata va a finire che non ci capisci piu' niente.
 
Ok, mi stai dicendo che *per puro caso* questo od altro programma
funziona correttamente, cioè dà risultati validi (cosa che, pensa un
pò che scoperta, già sapevo che può accadere :-)) . Al che si pone il
quesito: meglio che il programma si interrompa causa errore non
gestito, oppure continui ad andare avanti, così abbiamo una
probabilità su qualche milione che  finisca correttamente
l'elaborazione? Nel caso specifico, meglio programmare l'Ariane in
Ada, così è scoppiato con certezza (ironia della sorte per un
linguaggio di alta predicibilità!), oppure in C, con il quale *per
puro caso* avrebbe potuto completare bene il volo? Non saprei.
 

 La domanda rimane non risposta.
 
stai rispondendo sempre allo stesso messaggio, chissà magari c'entra
qualcosa :P
 

 il linguaggio non dovrebbe permetterlo?
 
ma probabilmente lo permette, solo non in quel modo. d'altra parte se
lo sviluppatore vuole coscientemente troncare un floating point da 64
bit in un intero da 16 bit si dovrà pure porre il problema di cosa
cazzo farne dei bit d'avanzo se l'intero risultante è più di 16 bit,
ti pare?

 formato pure? In C non si può troncare un valore?
 
certo si può fare.
 
#include <stdio.h>
int main() {
	unsigned short qtaCarburante;
	double distanza, consumo;
 
	distanza = 10000;
	consumo = 50;
	qtaCarburante = distanza * consumo;
	printf("wow, che culo, mi servono solo %u litri di carburante!\n",
qtaCarburante);
}
 
per carità tutto può essere, ma a me non sembra un comportamento che
un programmatore possa desiderare.

 non si è posto il problema di questo comportamento di Ada...
 
sicuramente qualcuno non si è posto un problema che si doveva porre.
però ribadisco, non è che in c questa cosa passa come acqua fresca: se
la conversione produce un valore intero che non sta in 16 bit lui lo
tronca prendendo solo i primi 16 bit. il fatto che il programma
formalmente vada avanti non toglie che il risultato di quella
operazione sia una estrazione del lotto. poni che andando avanti quel
numero sbagliato perlappunto faccia deviare il vettore verso terra,
forse sarà meglio che si blocchi tutto e si inneschi la procedura di
emergenza no?
 
 
 

 sicuramente qualcuno non si è posto un problema che si doveva porre.
 
 
Fra l'altro sembra che alcune variabili nelle righe precedenti fossero 
state protette mentre queste misteriosamente no.
Probabilmetne non hanno neanche  testato il modulo con dati simulati.
 
qui un report sull'incidente
 
http://www.di.unito.it/~damiani/ariane5rep.html
 
 
Interessante la sezione 2.2.

 }
 
Questa è mitica :-))
Attenzione però, con questo software bacato puoi causare perdite di
vite umane (per le risate) :-))
 

 emergenza no?
 
Forse netstat preferiva che dopo il bug  l'Ariane puntasse
direttamente sulla scrivania del programmatore beota, togliendolo di
mezzo :-))

 Interessante la sezione 2.2.
 
Come minimo "strano", ragionando di sicurezza, che lo stesso identico
software girasse su entrambi i computers del controllo di guida ed
assetto, uno primario ed uno di backup. Come dire, non mi fido
dell'hardware e così lo raddoppio, mentre mi fido ciecamente del
software e di chi lo produce. Mah.

 della fede Ada-mitica! :D
 
http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=328