[Linux-bruxelles] Thème pour les =?iso-8859-1?q?d=E9veloppeurs?=.

[Ludovic Brenta]

"Cabuzel Thierry" <Thierry.Cabuzel at gial.be> writes:

> Avant propos:
> Je suis de l'avis de Brenta sur les grandes ligne et je ne suis pas
> anti-C tant qu'il reste la ou de mon avis personnel il doit rester:
> Un langage d'assemblage de haut niveau. Mon avis à été construit de
> part ma formation d'ingénieur en génie logiciel (conception et
> architecture de systèmes logiciels) et de mon expérience dans
> l'industrie (7 ans).

Merci pour ton soutien.  Pour la petite histoire, je suis arrivé à ma
conclusion principalement anti-C par le même chemin (ingénieur
industriel + 8 ans d'expérience en programmation sur 4 systèmes
d'exploitation avec 7 langages différents).  J'ai écrit trop de bugs
pour aimer le C (ou le C++, d'ailleurs).

J'ajouterais que l'un des buts principaux poursuivis par les
concepteurs du C était la facilité d'implémentation, c'est-à-dire que
le langage devait être très simple pour pouvoir écrire un compilateur
rapidement (d'où la notion d'assembleur de haut niveau).  Si vous
pensez à GCC et à ses 1,6 millions de lignes de code, vous n'avez
aucune idée de ce que pouvait être un compilateur C en 1972.  Il y a
dans Debian un "tiny C compiler" (paquet "tcc") qui tient en 11000
lignes de code.  Il faut aussi se rappeler que le public visé par le
langage C était constitué de gourous qui avaient pour habitude de
programmer des systèmes d'exploitation en langage machine, sur des
ordinateurs incapables de faire tourner de gros programmes.  10 000
lignes de code, à l'époque, c'était déjà une très grosse application.

Le but poursuivi par les concepteurs d'Ada était exactement l'inverse:
le langage devait permettre au compilateur d'offrir le plus de
services possible aux développeurs, en particulier pour améliorer la
fiabilité et la maintenabilité des programmes et pour aider des
équipes entières à écrire de très grosses applications, et surtout à
prouver (au sens mathématique, quand c'était possible) que leurs
programmes étaient corrects.  Résultat, en Ada on programme deux fois
plus vite qu'en C, et on produit 10 fois moins de bugs (voir l'étude
exhaustive de Ziegler, dont j'ai donné l'URL dans mon précédent mail).

Je n'aime pas beaucoup le Java parce qu'il n'a pas de génériques
(templates) et donc sacrifie son typage fort, qui n'est que théorique,
au profit d'un polymorphisme omniprésent.  Comment contrôler
statiquement le type des données quand tout est un Object, en
particulier dans les conteneurs?  Ceci a en outre un impact non
négligeable sur la performance, puce Java ou pas, car toutes les
méthodes sont virtuelles et donnent lieu à plusieurs indirections à
chaque appel.  Au moins, en C++ ou en Ada, on a le choix de rendre les
méthodes virtuelles ou non.  Comment contrôler statiquement les
valeurs possibles d'une variable numérique, quand on n'a que "float",
"double", "int" et "long", qui reflètent l'architecture interne de la
machine virtuelle mais pas le problème à résoudre?  En Ada et dans
certains dialectes Pascal, on peut spécifier l'intervalle des valeurs
autorisées au moment de la déclaration du type.  Comment garantir que
le programme tourne avec moins de X kilo-octets de mémoire?
Impossible en Java.  Comment garantir un temps de réponse?  Impossible
en Java.  Comment garantir la cohérence d'une application, quand le
compilateur ne contrôle pas les dépendances entre classes
transitivement?  Impossible en Java: le seul moyen est de tout
recompiler (tout compilateur Ada gère parfaitement bien ce problème,
parce que les règles de cohérence ont été incluses dans la définition
du langage - pas besoin de Makefile). Etc.

-- 
Ludovic Brenta.