[Linux-bruxelles] Thème pour les développeurs.

[Vincent Blondel]

Je voudrais quand-même préciser une petite chose, et ceci indépendemment du 
langage que tu choisiras pour le développement de ton application :

Comme l'a précisé Thierry, le C a ce fantastique avantage de te donner une 
entière maîtrsise sur la gestion mémoire de ton application ( ce qu'aucun 
autre langage ne permet de faire , du moins de tous les langages que j'ai pu 
découvrir et/ou utiliser jusqu'à présent ).

Mais plus encore, je voudrais insister sur le fait que la programmation 
orientée objet n'a rien de spécifique à un langage ou un autre. Comprenez une 
fois pour toute que la programmation orientée objet est avant tout une 
question d'optique de programmation. On peut aussi bien programmer orienté 
objet en C que même en Korn Shell si bon te plait. 
Mon expérience en programmation C et  Unix Shell m'a prouvé depuis longtemps 
qu'il est aussi facile de développer des torchons en C++ autant que dans tous 
les autres langages. J'ai déjà vu au bureau des programmes écrit en C++ qui 
ne sont ni plus ni moins que du code procédural . C'est totalement illisible 
et non maintenable.


On Tuesday 07 October 2003 18:23, Ludovic Brenta wrote:
> "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.