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

[Cabuzel Thierry]

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).

> -----Original Message-----
> From: Frederic Peters [mailto:fpeters at entrouvert.be]
> 
> Ludovic Brenta écrivait:
> 
> > sont développées en Python.  Les problèmes du C sont bien connus:
> > buffer overflows, fuites de mémoire, manque de portabilité, pas de
> > multitâche dans le langage, pas d'exceptions, pas orienté 
> objet, etc.
> 
> Propos à nuancer.

Le C facilite le buffer overflow si on y prete pas une attention très particulière. Attention de tout les instants et grosse consomatrice d'énérgie. 
Le C facilite les fuites de mémoire si on y prete pas une attention très particulière. Attention de tout les instants et grosse consomatrice d'énérgie.
Ces 2 points sont dus car le programmeur C à la tache de manuellement allouer/désalouer la mémoire pour la moindre manipulation d'information (stuctures, chaines...)

Le C manque de portabilitée (et je vais être méchant) dès que l'on sort de <stdio.h>. Oui le C est portable si on utilise aucune bibliothèque un certain set de biblothèques standards. Quasiment toutes les bibliothèques intéressantes sont liées à l'architecture du système sur lequel on est (multitache, graphisme, ...). Un programme C écris sous windows ne se recompile pas sans retouche sous linux et inversement.

Le C n'a pas d'exceptions, n'est pas orienté objet. Il n'y a pas de nuance sur ce point. Ou alors avec le fils batard du C qu'est le C++ qui apporte un certain nombre de nouveautées tout en gardant les défaut de son père et en apportant un nouveau set.

> > (comme Python ou Perl).  Avec ces langages, on développe vite, avec
> > peu de bugs, mais la performance est mauvaise et les programmes
> > difficiles à maintenir sur le long terme.  Pour les applications
> 
> Propos à nuancer.

Des langages comme SmallTalk, Lisp, Python, et dans une moindre mesure Perl (cf commentaire en fin de mail) te libères d'un certains nombre de problèmes d'implémentation de bas niveau (allocation/désalocation mémoire, gestion de structures de données pour les plus courantes, ...). On étés pensé objet dès le départ. 
Les bug les plus courants qu'il te restera à résoudre se trouvent dans ton algorithme et non sur un problème d'allocation mémoire, de pointeur ou autre...
Pour le difficile à maintenir sur le long terme, cet argument est nul et non avenus. Ce problème existe quelque soit le langage, le secret réside dans la planification :)

> > solides, un langage compilé, avec typage statique très strict, est
> > plus indiqué.  Comme ça, sans sacrifier la performance, on peut
> 
> Propos à nuancer.

Java est un langage compilé avec typage statique très strict. Est t'il indiqué pour (ré)écrire le noyaux linux ? Je ne pense pas :) Oui oui, java est compilé. On le fais juste tourner sur un émulateur de processeur java et ces processeurs existent bels et bien aussi sous la forme de puces.
Le seul point sur lequel je suis d'accord c'est d'utiliser un langage compilé si on a besoin de performance et encore... Je vais écrire mon programme en python et la partie sensible demandant une puissance de calcul importante sera réecrite dans un langage compilé et interfacé avec mon programme originel. 
Et j'utiliserai peut être Fortran si c'est du calcul scientifique, Pascal si c'est du traitement de fichiers... La palette des langages est vastes. Ils ont chacun leurs avantages/inconvénient, j'aime quand j'en ai le choix/possibilitée choisir le meilleur langage, celui qui as le plus d'avantages que d'inconvénients pour un travail donné.

>         Frédéric, pas suffisamment de connexion que pour détailler

Voici un p'tit exemple de perl qui me fais frémir sur toute la longueur de l'échine:

$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=( $m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t^=(72, at z=(64,72,$a^=12*($_%16 -2?0:$m&17)),$b^=$_%64?12:0, at z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h =5;$_=unxb24,join"", at b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$ d=unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d8^($f=$t&($d12^$d4^ $d^$d/8))<<17,$e=$e8^($t&($g=($q=$e14&7^$e)^$q*8^$q<<6))<<9,$_=$t[$_]^ (($h=8)+=$f+(~$g&$t))for at a[128..$#a]}print+x"C*", at a}';s/x/pack+/g;eval

Non, non, ca n'a pas été produit par un générateur de caractères aléatoires :)

Thierry
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: </pipermail/linux-bruxelles/attachments/20031007/633e527c/attachment-0002.html>