language

Stéphane CARPENTIER <stef.carpentier@gratuit.fr.invalid> writes:

Qu'apporte le langage 'Ada'?

Je suis sûr qu'on pourra te répondre ici...

Je ne connais pas. D'après ce que j'en sais, c'est un truc qui est
surtout utilisé pour l'embarqué. C'est chiant à programmer, mais
si ça compile, ça ne plante pas.

Faut dire que le compilateur ADA dépasse les limitations des machines
de Turing grâce aux technologies quantiques exploitaant le
parallélisme entre univers découvertes dans la bibliothèque des
Anciens sur P2X437.

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

"stephane@unices.org" <stephane@unices.org> writes:

On 2006-05-06, Marilyn Dubois <mari.lyn@skynet.be> wrote:

Bien que j'osasses poser des questions et bien que vous approuvassiez de
ne pas me faire des commentaires, permettez-moi de vous mettre en garde.
Car en espéranto il n'y a pas de chinoiseries !
En effet, savez-vous que vous m'épatâtes lors de vos explications si
minutieuses et pertinentes à souhait sur les divers langages de progrs.
Un seul reproche cependant, j'eusse aimé que vous n'oubliassiez
l'ASSAMBLEUR. Oubli, volontaire..., s'il en est.
Merci de vos compétences grandioses et subliminals.

heu.....subliminal(l)es

Heu, "Assembleur".

Langage d'assemblage, d'ailleurs.

MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

1/ http://www.memtest.org

J'ai commencé mais le sagouin m'a pris 20 mn pour faire l'un des 10
tests. Je le laisserai batifoler la nuit prochaine s'il n'y a aps de
de contre indication.

Le Fri, 05 May 2006 22:42:57 +0200, SL a écrit :

On fait un bon technologique démentiel et ça nous sort à peine de
la pénibilité des conneries de la vie.

Il y a un moyen simple : ne pas acheter du matériel à vil prix. Dès
que tu mets un peu d'argent dans les pièces détachées, les problèmes
en question cessent généralement de se manifester...

Voilà qui me coupe le sifflet.

Stéphane Carpentier a écrit:

Qu'apporte le langage 'Ada'?

Par rapport au langage C: tu écris ton programme deux fois plus vite,
et tu produis 10 fois moins de bogues. C'est prouvé, voir [1]. En
plus, tu passes 90% de temps en moins dans un débogueur, bien que ce
chiffre soit une estimation à vue de nez.

Par rapport à Java: Ada est normalisé ISO tandis que Java est
propriétaire. Ada n'impose pas de machine virtuelle ni de
ramasse-miettes, donc la performance et la consommation mémoire sont
sous contrôle du programmeur. Ada ne t'oblige pas à faire de la
programmation objet si ce n'est pas approprié (pas besoin d'une classe
pour Hello World). (Il existe pourtant des compilateurs Ada qui
produisent du bytecode Java ou C#, si c'est ce que tu veux).

Par rapport à C++: Ada est plus simple et plus fiable mais tout aussi
puissant. La norme ISO est publiquement disponible tandis que celle
de C++ coûte pas mal d'argent. Tu passes 90% de temps en moins dans
un débogueur, comme en C. Ada est nativement multitâche, quand l e C++
a besoin de bibliothèques externes ou d'extensions.

Par rapport à Python: Ada vérifie statiquement (à la compila tion) et
non dynamiquement (à l'exécution) les contraintes de type spà ©cifiées
par le programmeur.

Ada n'est pas un langage de script. Il n'est pas conçu pour le petits
programmes "jetables". Il est conçu pour écrire des programmes q ui
vont durer longtemps. Il est d'ailleurs conçu pour aider ces
programmes à durer longtemps.

Je ne connais pas. D'après ce que j'en sais, c'est un truc qui est
surtout utilisé pour l'embarqué. C'est chiant à programmer , mais si
ça compile, ça ne plante pas.

Ada aide le programmeur à ne pas écrire de bogues. Pour ceux qui
aiment écrire des bogues, c'est chiant, effectivement. Pour ceux qui
aiment la fiabilité et qui veulent avoir confiance dans leur
programme, c'est au contraire très agréable.

Les concepteurs d'Ada sont partis de quelques principes de bon sens:

- les programmeurs sont des humains, ils font des erreurs. Donc, Ada
prévient les erreurs quand c'est possible (grâce entre autres à une
syntaxe simple et non ambigüe), et détecte les erreurs a poster iori
quand nécessaire (en insérant automatiquement des contrôle s dans le
programme exécutable). Les dépassements de tampons en Ada, à §a
n'existe pas. (faire le contraste avec C, qui part explicitement du
principe que "le programmeur est une personne responsable qui sait
ce qu'elle fait", dixit K&R).

- la plupart des programmes sont écrits par des équipes. Donc, A da
est *modulaire* (compilation séparée sans Makefiles, ni configu re,
ni autoconf, ni automake, ni aucune autre horreur de cette sorte).

- au cours du cycle de vie d'un programme, on écrit le programme une
fois mais on le relit de nombreuses fois. Donc, Ada est *lisible*.

- au cours du cycle de vie d'un programme, on modifie le programme de
nombreuses fois mais on ne veut pas d'effets en cascade
imprévisibles. Donc, Ada permet *l'encapsulation*.

- au cours du cycle de vie d'un programme, on change souvent
d'architecture cible. Donc, Ada est *portable* au niveau du source:
une simple recompilation suffit le plus souvent, voir [2].

- dans les applications critiques où la vie humaine ou la survie de
l'entreprise est en jeu, on veut avoir confiance dans le
compilateur. Donc, les compilateurs sont *certifiés* par une suite
de tests de conformité à la norme ISO (cette suite de tests est elle
aussi une norme ISO appelée ACATS).

- dans ces mêmes applications, on veut en général pouvoir ce rtifier le
programme exécutable (le binaire, pas le source). Ada possède de
nombreuses fonctions qui aident les programmeurs à vérifier bit à
bit que leur binaire est conforme à leurs intentions.

- pour la programmation de bas niveau, on veut parfois insérer du code
machine dans le programme ("assembleur en ligne"). Ada permet cela.

- bien souvent, on a besoin d'appeler des bibliothèques écrites d ans
d'autres langages. Ada prend cela en charge et la norme ISO
spécifie comment. Donc, Ada est *ouvert*. Ainsi, on peut appeler
n'importe quelle bibliothèque écrite en C, par exemple, depuis un
programme Ada.

- Ada est *multitâche*, sans avoir recours à une bibliothèqu e externe
ni à des extensions. Le multitâche est réalisé au mo yen de
mots-clés intégrés au langage. Avec les processeurs multi core, cela
va devenir de plus en plus intéressant.

- Ada est *distribué*, avec une bibliothèque externe mais intà ©grée au
langage puisque faisant partie de la norme ISO. Il est ainsi
possible d'écrire des programmes répartis sur plusieurs machines
exactement de la même façon qu'un programme non distribué. Il
suffit d'ajouter quelques pragmas dans le code source et le tour est
joué: les appels de sous-programmes distants et les objets partagà ©s
sont transparents pour le programmeur. Avec les clusters, cela
devient très intéressant.

Traditionnellement, Ada est très utilisé dans l'avionique, les tr ains,
les missiles, les satellites, les fusées, le contrôle aérien , le
pilotage de centrales nucléaires, les appareils médicaux, la banq ue.
Pourtant, c'est un langage généraliste. On peut faire des
applications web, des jeux, des programmes de bureautique et même des
applets en Ada.

Les caractéristiques de lisibilité et d'encapsulation font qu'Ada est
particulièrement bien adapté aux logiciels libres. Il est trà ¨s
facile, en lisant les sources d'un programme, d'en comprendre le
fonctionnement: la syntaxe est claire et non ambigüe. Il est facile
également de modifier le programme sans avoir peur d'effets pervers en
cascade. Pas plus tard qu'avant-hier, j'ai fait des modifications
dans GPS, un logiciel libre de 488.000 lignes que je n'ai pas écrit.
Je n'ai recompilé qu'une seule fois et mes modifications ont
fonctionné du premier coup. Pas besoin de débogueur. Bilan: 3 h eures
passées, 3 bogues mineurs corrigés.

Ada est donc multitâche, orienté objet, procédural, structur é, ouvert,
lisible, fiable et maintenable. Il prend en charge les génériques
(équivalents des templates du C++), les exceptions, la programmation
de bas niveau (au niveau du bit), la programmation de haut niveau
(génériques et classes), les petits programmes et les gros progra mmes.

Pour plus d'informations voici une petite sélection de sites web:

[1] http://www.adaic.com/whyada/ada-vs-c/cada_art.html
[2] http://www.cs.kuleuven.ac.be/~dirk/papers/sa03cfmu-paper.pdf
[3] http://www.adaic.com
[4] http://www.adaworld.com
[5] http://libre.adacore.com
[6] http://www.adacore.com
[7] http://www.adalog.fr (en français)
[8] http://d.feneuille.free.fr (en français)

--
Ludovic Brenta.

Le Fri, 05 May 2006 22:42:57 +0200, SL a écrit :

On fait un bon technologique démentiel et ça nous sort à peine de
la pénibilité des conneries de la vie.

Il y a un moyen simple : ne pas acheter du matériel à vil prix. Dès
que tu mets un peu d'argent dans les pièces détachées, les problèmes
en question cessent généralement de se manifester...

Voilà qui me coupe le sifflet.

Euh, c'était pas ironique hein, je voulais dire ça me proprement un
terme à mes élucubrations.

Sinon, autre question bête : c'est vrai que ce qui est le plus nocif
pour un ordinateur (ou un autre appareil électronique) c'est
l'allumage, tandis qu'une fois mise en route il ne se déteriore pas à
rester sous tension ?

SL <nospam@nospam.com> writes:

[...]

Sinon, autre question bête : c'est vrai que ce qui est le plus nocif
pour un ordinateur (ou un autre appareil électronique) c'est
l'allumage, tandis qu'une fois mise en route il ne se déteriore pas
à rester sous tension ?

Ben, c'est un sujet à troll aussi :)

Indubitablement, allumer et éteindre un appareil électrique est
dommageable pour le matériel (appel de courant principalement).

Maintenant, un circuit intégré qui fonctionne en permanence s'use
aussi (c'est mécanique : le passage du courant érode la circuiterie,
sans compter les couches basses). D'ailleurs, plus la techno avance et
plus la durée de vie des circuits intégrés diminue¹...

Bref, comme toujours, c'est histoire de compromis...

PK


¹ : penser que son AMD64 durera aussi longtemps que son 486 est une
sérieuse illusion... la durée de vie de ce genre de circuit ne doit
pas dépasser 5 à 8 ans. Dépend de l'usage et de la façon dont ils ont
été gravé...

--
      |      _,,,---,,_       Patrice KARATCHENTZEFF
ZZZzz /,`.-'`'    -.  ;-;;,_   mailto:p.karatchentzeff@free.fr
     |,4-  ) )-,_. , (  `'-'  http://p.karatchentzeff.free.fr
    '---''(_/--'  `-'_)       

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:

Stéphane Carpentier a écrit:

Qu'apporte le langage 'Ada'?

Par rapport au langage C: tu écris ton programme deux fois plus vite,
et tu produis 10 fois moins de bogues. C'est prouvé, voir [1]. En
plus, tu passes 90% de temps en moins dans un débogueur, bien que ce
chiffre soit une estimation à vue de nez.

....

Ada est donc multitâche, orienté objet, procédural, structuré, ouvert,
lisible, fiable et maintenable. Il prend en charge les génériques
(équivalents des templates du C++), les exceptions, la programmation
de bas niveau (au niveau du bit), la programmation de haut niveau
(génériques et classes), les petits programmes et les gros programmes.

Et donc comme il est prouvé que les programmeurs sont des masochistes, qui
aiment faire des programmes pleins de bugs, deux fois plus lentement, passer
leur vie dans gdb, faire des programmes monolithiques qui ne sont ni petits ni
gros, il s'ensuit que tout le monde programme en C (C++, Java, Perl, Python,
etc.) et personne en Ada. En fait je ne sais pas si les prémisses sont vraies,
mais la conclusion l'est certainement.

--

Michel TALON

[En-tête "Followup-To:" positionné à fr.comp.os.linux.debats.]
Le 06-05-2006, à propos de
Re: language,
Ludovic Brenta écrivait dans fr.comp.os.linux.debats :

Stéphane Carpentier a écrit:

Qu'apporte le langage 'Ada'?

Par rapport au langage C: tu écris ton programme deux fois plus vite,
et tu produis 10 fois moins de bogues. C'est prouvé, voir [1]. En
plus, tu passes 90% de temps en moins dans un débogueur, bien que ce
chiffre soit une estimation à vue de nez.

[snip]

Mais il a un seul défaut... Lorsqu'on parle ADA ou Fortran, on passe
toujours pour des vieux schoques. Les langages en question ont beau
être très bien ficelés, il devient très difficile de trouver un bon
programmeur Fortran ou ADA, alors que des bidouilleurs C, C++, C# et
java, on en trouve à la pelle !

JKB, adepte de la vieuschnoquattitude

[En-tête "Followup-To:" positionné à fr.comp.os.linux.debats.]
Le 06-05-2006, à propos de
Re: language,
Michel Talon écrivait dans fr.comp.os.linux.debats :

Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:

Stéphane Carpentier a écrit:

Qu'apporte le langage 'Ada'?

Par rapport au langage C: tu écris ton programme deux fois plus vite,
et tu produis 10 fois moins de bogues. C'est prouvé, voir [1]. En
plus, tu passes 90% de temps en moins dans un débogueur, bien que ce
chiffre soit une estimation à vue de nez.

....

Ada est donc multitâche, orienté objet, procédural, structuré, ouvert,
lisible, fiable et maintenable. Il prend en charge les génériques
(équivalents des templates du C++), les exceptions, la programmation
de bas niveau (au niveau du bit), la programmation de haut niveau
(génériques et classes), les petits programmes et les gros programmes.

Et donc comme il est prouvé que les programmeurs sont des masochistes, qui
aiment faire des programmes pleins de bugs, deux fois plus lentement, passer
leur vie dans gdb, faire des programmes monolithiques qui ne sont ni petits ni
gros, il s'ensuit que tout le monde programme en C (C++, Java, Perl, Python,
etc.) et personne en Ada. En fait je ne sais pas si les prémisses sont vraies,
mais la conclusion l'est certainement.

Montre-moi un seul de tes programmes écrit en C, que je le critique.
Je ne connais pas beaucoup de personnes qui récupèrent les codes
renvoyés par une fonction intrinsèque C (que ce soit malloc() ou un
simple fprintf()). Le simple fait qu'un truc comme :

fprintf(fp, "%sn", chaine);

compile est une absurdité. fprintf renvoie un int et non un void !
Lorsqu'on travaille sur des programmes complexes de plusieurs
centaines de milliers de lignes de codes en C et qu'on essaye de
tracer un segfault aléatoires sur un tel problème, on peste et on y
passe du temps.

Personnellement, j'ai rarement ouvert un debugger en ADA, très
rarement en Fortran, mais alors en C, même en programmant
correctement, je commence toujours par un sigaction() histoire de
faire planter le programme à la première allocation ou utilisation
de mémoire foireuse, ce qui avec les chaînes de caractères est assez
vite faite par buffer overflow). Sans compter les routines
récursives qui ne peuvent suivre la pile système que si on gère
soi-même la pile système avec une seconde pile en cas de
dépassement, ni les dépassements de capacité en virgule fixe ou
flottante.

JKB