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

Ludovic Brenta ludovic.brenta at insalien.org
Mer 8 Oct 04:36:56 CEST 2003


Stephane Wirtel <stephane.wirtel at belgacom.net> writes:

> > Le C est un mauvais choix pour développer des applications.  Owen
> > Taylor, l'un des principaux développeurs de GTK+, a insisté lors du
> > FOSDEM 2003 sur ce point.  C'est même pour cette raison que, dès le
> > départ, GTK+ a été conçu pour permettre la programmation en plusieurs
> > langages [1].  
> GTK+ a certainement été conçu afin de permettre le binding, mais les
> seules portages qui fonctionnent et qui sont à jour, sont GTKmm (C++).

GtkAda est à jour (2.2) et très complet.  Voir
http://libre.act-europe.fr/GtkAda.  Je ne sais pas pour PyGTK.

> Les problèmes tels que le buffer overflows, sont dûs à des
> développeurs qui pensent que l'OS pourra toujours faire une
> allocation de 255 bytes.  Ce qui est faux, donc chaque programmeur
> doit vérifier son code. Auditer le code et vérifier les algorithmes
> qui semblent complexes sont des choses à faire.

Je suis d'accord, les bugs sont la faute du développeur, mais le
boulot du compilateur est d'aider le développeur à trouver ses bugs.
Un compilateur C est particulièrement mauvais à ce petit jeu, et la
syntaxe du langage rend une telle détection très difficile.  Même avec
lint, tu peux encore écrire des bugs qu'un compilateur Ada normal
trouverait en 2 secondes.

C'est aussi mieux si le langage rend difficile ou impossible
l'écriture de code illisible (voir le très bon exemple en Perl posté
par Thierry, valable aussi en C).

> Maintenant, si Redhat développe en Python, c'est parce qu'il est
> plus rapide de développer une application en Python, qu'en C ;-)
> N'oublions pas que Python est fait en C.

Justement.  La question n'est pas de savoir si tu peux développer une
application avec un langage X ou Y, mais à quel prix tu vas la
développer, et combien de bugs tu auras.

> Concernant les fuites de mémoires, le développeur DOIT checker son
> code, avec des outils adéquats, tels que gdb, ddd, memprof,
> etc... et tester son code dans des cas très rares, mais qui peuvent
> survenir afin de vérifier que celui-ci tient le coup.

Tous les outils dont tu parles agissent lors de l'exécution du
programme.  Or, pour un programme non trivial, il est impossible de
tester tous les chemins d'exécution.  En outre, en testant, tu peux
prouver la présence de bugs, mais tu ne peux pas prouver leur absence.
Tu peux tester ton programme 10 000 fois, et observer qu'il fonctionne
10 000 fois, mais tu ne peux pas garantir que la 10 001ème fois il
fonctionnera encore.

Le seul moyen de garantir la qualité de ton programme (je veux dire
garantir qu'il comporte exactement zéro bug), c'est la vérification
statique du code source.  En C, cette vérification est impraticable,
c'est pour cela que je vois tous les développeurs professionnels
passer leur temps à tester l'exécution (vrai aussi pour C++ et Java).
En Ada, le compilateur la fait en grande partie, et il existe des
outils qui vont encore plus loin (voir http://www.polyspace.com).  La
vérification par des humains est facilitée par un langage lisible
comme Pascal, Modula ou Ada.  Avec Spark (http://www.sparkada.com), il
y a même des outils pour prouver automatiquement qu'un programme est
correct.

> Portabilité ? N'oublions pas que la portabilité des langages tels
> que Java, Python, Perl, et tant d'autres, est dûe à une
> standardisation des API nécessaires à ces langages. Par exemple, la
> VM de Java est écrite en C++ si je ne me trompe pas et c'est cette
> couche qui produit cette portabilité. Le C fait de même, il suffit
> de voir BSD, GNU/Linux, et d'autres systèmes d'exploitation qui sont
> "portables" sur différentes architectures.

Non, la portabilité n'est pas seulement une affaire d'API.  J'ai une
fois observé un programme qui, compilé par deux compilateurs
différents sur HP-UX, produisait des résultats différents.  Après
vérification, il s'est avéré que les deux compilateurs avaient des
interprétations valides, mais différentes, de la norme ISO C 90.

Ensuite, regarde le nombre de #ifdef qui sont dans ces noyaux et
librairies, et tu comprendras le coût réel, pour le programmeur, de
cette prétendue portabilité.  Le C est un peu plus portable que
l'assembleur, mais sans atteindre des sommets.

Non, le mythe de la portabilité du C vient de la simplicité du
langage, qui rend facile l'écriture de compilateurs, avec pour
résultat la disponibiluté de compilateurs pour de nombreuses
plate-formes.  Mais chaque compilateur est un peu différent du voisin,
et la portabilité d'un programme au niveau du code source nécessite
énormément d'attention de la part du programmeur, donc des coûts de
développement élevés.  Je parle d'expérience.

> Multi-tache ? Linux est écrit en C, et gère le multi-tache à ce que
> je sache, et l'utilisation des librairies tels que la pthread, ou
> autres permet de faire du multi-threading. Tout comme en python.

Comme tu le dis: dans une librarie.  Donc pas dans le langage.
D'aileurs, si tu étudiais le multitâche dans Ada [1], tu comprendrais
que l'API pthread est vraiment ce qu'il y a de plus primitif dans ce
domaine et tu ne voudrais plus jamais y retourner.  A ma connaissance,
aucun langage n'a poussé le support du multitâche aussi loin qu'Ada,
mais Erlang fait un effort honorable.

[1] http://www.adaic.org/whyada/intro5.html#concurrent

> Exceptions ? Je me souviens d'un article où l'on expliquait de
> manière très détaillée la possibilité de créer un gestionnaire
> d'exceptions pour le développement C, je pense qu'il s'agit d'un
> ancien Login qui date d'environ 2 ans.

Comme je le disais, tu peux écrire absolument tout ce que tu veux en C
(ou avec d'autres langages).  La question, c'est à quel coût.  Avec
Ada, C++, Java, etc., le coût pour les exceptions est nul.  Zéro.  Si
ça t'amuse, vas-y, écris un gestionnaire d'exceptions en C.  N'oublie
pas de convertir glibc pour qu'elle utilise les exceptions.  Mon
application sera prête bien avant la tienne.

> Orienté Objet ? à l'époque cette technique n'existait pas, donc n'a
> pas été implémentée, mais GTK+ est basée sur une abstaction Objet,
> GtkWidget, GtkWindow, etc...

Justement, avec GTK+ et les bindings des langages orientés objet, tu
obtiens une facilité de programmation bien meilleure qu'en C (par
exemple, les noms de méthodes surchargés rendent le programme beaucoup
plus maintenable).  Mon application sera prête avant la tienne.

Et, au fait, le premier langage orienté objet était Simula 67,
plusieurs années avant l'invention du C.

> Chaque langage à ses avantages et ses inconvénients, certes le C est
> ancien, mais répond toujours à l'attente du développeur qui le
> connait.

C'était mon attitude il y a encore 5 ans.  Depuis, j'ai appris
plusieurs autres langages, écrit des milliers de lignes de code, et
finalement j'ai vu la lumière :) Et mon application sera prête avant
la tienne.

> Stéphane qui a pris le temps de répondre. 

Merci.  Au fait, mon application aura 10 fois moins de bugs que la
tienne, c'est prouvé :)

-- 
Ludovic Brenta.





Plus d'informations sur la liste de diffusion Linux-bruxelles