On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
Un programme est portable si, sur toutes les implémentations conformes, le même programme donne des résultats conformes à ses spécifications utiles. Prière définir "utiles" - stop
C'est laissé à la discrétion de celui qui écrit les spécifications, justement. On me donne des spécifications, j'écris un programme portable qui les remplit (ou alors je dis que ça m'emmerde, ça m'arrive aussi, et je fais autre chose).
En l'occurence, j'ai précisé « utile » pour laisser entendre que les spécifications n'avaient pas à spécifier totalement tout. Il est acceptable de dire par exemple « écrire un programme qui, donné n, calcule ceci, ou affiche un message d'erreur si n est trop grand et que le calcul ne peut être mené à bien sur le matériel disponible », en laissant un flou sur « trop grand », ce n'est pas « utile ».
JKB , dans le message <slrnd2u9co.ugg.knatschke@rayleigh.systella.fr>, a
écrit :
Un programme est portable si, sur toutes les implémentations conformes, le
même programme donne des résultats conformes à ses spécifications utiles.
Prière définir "utiles" - stop
C'est laissé à la discrétion de celui qui écrit les spécifications,
justement. On me donne des spécifications, j'écris un programme portable qui
les remplit (ou alors je dis que ça m'emmerde, ça m'arrive aussi, et je fais
autre chose).
En l'occurence, j'ai précisé « utile » pour laisser entendre que les
spécifications n'avaient pas à spécifier totalement tout. Il est acceptable
de dire par exemple « écrire un programme qui, donné n, calcule ceci, ou
affiche un message d'erreur si n est trop grand et que le calcul ne peut
être mené à bien sur le matériel disponible », en laissant un flou sur
« trop grand », ce n'est pas « utile ».
Un programme est portable si, sur toutes les implémentations conformes, le même programme donne des résultats conformes à ses spécifications utiles. Prière définir "utiles" - stop
C'est laissé à la discrétion de celui qui écrit les spécifications, justement. On me donne des spécifications, j'écris un programme portable qui les remplit (ou alors je dis que ça m'emmerde, ça m'arrive aussi, et je fais autre chose).
En l'occurence, j'ai précisé « utile » pour laisser entendre que les spécifications n'avaient pas à spécifier totalement tout. Il est acceptable de dire par exemple « écrire un programme qui, donné n, calcule ceci, ou affiche un message d'erreur si n est trop grand et que le calcul ne peut être mené à bien sur le matériel disponible », en laissant un flou sur « trop grand », ce n'est pas « utile ».
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Non. Réfléchissez un peu (sur les architectures "octet", rien que les problèmes de petit/grand boutistes).
Pour un programme correctement écrit, ça n'est pas pertinent.
Le nombre de fois où j'ai
La majorité des programmeurs sont des brêles, ce n'est pas nouveau. Il en va de même de la majorité des livres qui parlent de C, hélas.
long long li; // comprendre sur 64 bits unsigned char c[8];
c = li;
Ça ne veut rien dire, c n'est pas une lvalue affectable. Je suppose qu'il fallait lire quelque chose du style :
long long li; unsigned char c[8]; memcpy(c, &li, 8);
Évidemment c'est mauvais. C'est d'ailleurs précisément ce que je dis : le programmeur s'est chié dessus. La bonne manière d'écrire ça est :
c[0] = (li / 0x100000000000000) % 0x100;
Si vous voulez _vraiment_ écrire un tel truc, ça s'écrit de façon portable comme ça :
c[0] = (li / ((unsigned long long) 0x100000000000000)) % 0x100;
pour la sournoise raison que la plupart des compilo C voient une constante entière comme un _int_. Si l'int fait 32 bits, 0x100000000000000 dépasse du cadre ! On peut se retrouver avec un modulo (cf. compilo Sun de Solaris 2.5.1), un 0 (Borland) ou n'importe quoi...
c[1] = (li / 0x1000000000000) % 0x100; c[2] = (li / 0x10000000000) % 0x100; c[3] = (li / 0x100000000) % 0x100; c[4] = (li / 0x1000000) % 0x100; c[5] = (li / 0x10000) % 0x100; c[6] = (li / 0x100) % 0x100; c[7] = (li / 0x1) % 0x100;
(en s'assurant évidemment que li est positif, sinon il faut faire un peu plus) (on peut évidemment rédiger ça avec une boucle ou de toute autre manière plus pratique).
La syntaxe du C permet d'écrire des comportements indéfinis, personne ne le conteste, et il est en général impossible de décider statiquement si telle ou telle construction est un comportement indéfini ou pas. Mais un bon programmeur est conscient de ces limites, et des manières de faire la même chose de manière définie.
Un bon programmeur C n'existe pas, c'est une vue de l'esprit, ou alors, c'est un type qui a appris Fortran ou Ada avant et qui est passé au C ensuite.
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2u9ae.ugg.knatschke@rayleigh.systella.fr>, a
écrit :
Non. Réfléchissez un peu (sur les architectures "octet", rien que
les problèmes de petit/grand boutistes).
Pour un programme correctement écrit, ça n'est pas pertinent.
Le nombre de fois où j'ai
La majorité des programmeurs sont des brêles, ce n'est pas nouveau. Il en va
de même de la majorité des livres qui parlent de C, hélas.
long long li; // comprendre sur 64 bits
unsigned char c[8];
c = li;
Ça ne veut rien dire, c n'est pas une lvalue affectable. Je suppose qu'il
fallait lire quelque chose du style :
long long li;
unsigned char c[8];
memcpy(c, &li, 8);
Évidemment c'est mauvais. C'est d'ailleurs précisément ce que je dis : le
programmeur s'est chié dessus. La bonne manière d'écrire ça est :
c[0] = (li / 0x100000000000000) % 0x100;
Si vous voulez _vraiment_ écrire un tel truc, ça s'écrit de façon
portable comme ça :
c[0] = (li / ((unsigned long long) 0x100000000000000)) % 0x100;
pour la sournoise raison que la plupart des compilo C voient une
constante entière comme un _int_. Si l'int fait 32 bits,
0x100000000000000 dépasse du cadre ! On peut se retrouver avec un
modulo (cf. compilo Sun de Solaris 2.5.1), un 0 (Borland) ou
n'importe quoi...
c[1] = (li / 0x1000000000000) % 0x100;
c[2] = (li / 0x10000000000) % 0x100;
c[3] = (li / 0x100000000) % 0x100;
c[4] = (li / 0x1000000) % 0x100;
c[5] = (li / 0x10000) % 0x100;
c[6] = (li / 0x100) % 0x100;
c[7] = (li / 0x1) % 0x100;
(en s'assurant évidemment que li est positif, sinon il faut faire un peu
plus) (on peut évidemment rédiger ça avec une boucle ou de toute autre
manière plus pratique).
La syntaxe du C permet d'écrire des comportements indéfinis, personne ne le
conteste, et il est en général impossible de décider statiquement si telle
ou telle construction est un comportement indéfini ou pas. Mais un bon
programmeur est conscient de ces limites, et des manières de faire la même
chose de manière définie.
Un bon programmeur C n'existe pas, c'est une vue de l'esprit, ou
alors, c'est un type qui a appris Fortran ou Ada avant et qui est
passé au C ensuite.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Non. Réfléchissez un peu (sur les architectures "octet", rien que les problèmes de petit/grand boutistes).
Pour un programme correctement écrit, ça n'est pas pertinent.
Le nombre de fois où j'ai
La majorité des programmeurs sont des brêles, ce n'est pas nouveau. Il en va de même de la majorité des livres qui parlent de C, hélas.
long long li; // comprendre sur 64 bits unsigned char c[8];
c = li;
Ça ne veut rien dire, c n'est pas une lvalue affectable. Je suppose qu'il fallait lire quelque chose du style :
long long li; unsigned char c[8]; memcpy(c, &li, 8);
Évidemment c'est mauvais. C'est d'ailleurs précisément ce que je dis : le programmeur s'est chié dessus. La bonne manière d'écrire ça est :
c[0] = (li / 0x100000000000000) % 0x100;
Si vous voulez _vraiment_ écrire un tel truc, ça s'écrit de façon portable comme ça :
c[0] = (li / ((unsigned long long) 0x100000000000000)) % 0x100;
pour la sournoise raison que la plupart des compilo C voient une constante entière comme un _int_. Si l'int fait 32 bits, 0x100000000000000 dépasse du cadre ! On peut se retrouver avec un modulo (cf. compilo Sun de Solaris 2.5.1), un 0 (Borland) ou n'importe quoi...
c[1] = (li / 0x1000000000000) % 0x100; c[2] = (li / 0x10000000000) % 0x100; c[3] = (li / 0x100000000) % 0x100; c[4] = (li / 0x1000000) % 0x100; c[5] = (li / 0x10000) % 0x100; c[6] = (li / 0x100) % 0x100; c[7] = (li / 0x1) % 0x100;
(en s'assurant évidemment que li est positif, sinon il faut faire un peu plus) (on peut évidemment rédiger ça avec une boucle ou de toute autre manière plus pratique).
La syntaxe du C permet d'écrire des comportements indéfinis, personne ne le conteste, et il est en général impossible de décider statiquement si telle ou telle construction est un comportement indéfini ou pas. Mais un bon programmeur est conscient de ces limites, et des manières de faire la même chose de manière définie.
Un bon programmeur C n'existe pas, c'est une vue de l'esprit, ou alors, c'est un type qui a appris Fortran ou Ada avant et qui est passé au C ensuite.
JKB
Tom
C'est comme l'ISO 9001 qui permet de faire de la m*rde lorsqu'on l'a spécifié ;-)
JKB
Le C c'est la liberté... de faire des non programmes, des trucs qui n'ont aucune signification. Mais c'est dans les normes du C alors c'est bon ça compile. On serre les fesses à l'exécution et si c'est bien rustiné (un néologisme ? très utile en tout cas) ça passe plus ou moins bien.
Tom
C'est comme l'ISO 9001 qui permet de faire de la m*rde lorsqu'on l'a
spécifié ;-)
JKB
Le C c'est la liberté... de faire des non programmes, des trucs qui
n'ont aucune signification. Mais c'est dans les normes du C alors c'est
bon ça compile. On serre les fesses à l'exécution et si c'est bien
rustiné (un néologisme ? très utile en tout cas) ça passe plus ou moins
bien.
C'est comme l'ISO 9001 qui permet de faire de la m*rde lorsqu'on l'a spécifié ;-)
JKB
Le C c'est la liberté... de faire des non programmes, des trucs qui n'ont aucune signification. Mais c'est dans les normes du C alors c'est bon ça compile. On serre les fesses à l'exécution et si c'est bien rustiné (un néologisme ? très utile en tout cas) ça passe plus ou moins bien.
Tom
Nicolas George
Joe Cool , dans le message <422f274a$0$30326$, a écrit :
Voilà une définition de la protabilité qui rend portable tout et n'importe quoi, puisque cette notion ne dépend que de la conformité des implémentations : si les implémentations sont conformes à leurs propres normes, alors le langage est portable.
Précisément. Ça prouve essentiellement que la notion de langage portable, ça ne veut rien dire. Merci d'abonder dans mon sens.
Joe Cool , dans le message <422f274a$0$30326$626a14ce@news.free.fr>, a
écrit :
Voilà une définition de la protabilité qui rend portable tout et
n'importe quoi, puisque cette notion ne dépend que de la conformité des
implémentations : si les implémentations sont conformes à leurs propres
normes, alors le langage est portable.
Précisément. Ça prouve essentiellement que la notion de langage portable, ça
ne veut rien dire. Merci d'abonder dans mon sens.
Joe Cool , dans le message <422f274a$0$30326$, a écrit :
Voilà une définition de la protabilité qui rend portable tout et n'importe quoi, puisque cette notion ne dépend que de la conformité des implémentations : si les implémentations sont conformes à leurs propres normes, alors le langage est portable.
Précisément. Ça prouve essentiellement que la notion de langage portable, ça ne veut rien dire. Merci d'abonder dans mon sens.
Tom
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Un programme est portable si, sur toutes les implémentations conformes, le même programme donne des résultats conformes à ses spécifications utiles. Prière définir "utiles" - stop
C'est laissé à la discrétion de celui qui écrit les spécifications, justement. On me donne des spécifications, j'écris un programme portable qui les remplit (ou alors je dis que ça m'emmerde, ça m'arrive aussi, et je fais autre chose).
En l'occurence, j'ai précisé « utile » pour laisser entendre que les spécifications n'avaient pas à spécifier totalement tout. Il est acceptable de dire par exemple « écrire un programme qui, donné n, calcule ceci, ou affiche un message d'erreur si n est trop grand et que le calcul ne peut être mené à bien sur le matériel disponible », en laissant un flou sur « trop grand », ce n'est pas « utile ».
Toi, tu devrais faire une étude comparative des normes Fortran95, ADA95 et C99.
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2u9co.ugg.knatschke@rayleigh.systella.fr>, a
écrit :
Un programme est portable si, sur toutes les implémentations conformes, le
même programme donne des résultats conformes à ses spécifications utiles.
Prière définir "utiles" - stop
C'est laissé à la discrétion de celui qui écrit les spécifications,
justement. On me donne des spécifications, j'écris un programme portable qui
les remplit (ou alors je dis que ça m'emmerde, ça m'arrive aussi, et je fais
autre chose).
En l'occurence, j'ai précisé « utile » pour laisser entendre que les
spécifications n'avaient pas à spécifier totalement tout. Il est acceptable
de dire par exemple « écrire un programme qui, donné n, calcule ceci, ou
affiche un message d'erreur si n est trop grand et que le calcul ne peut
être mené à bien sur le matériel disponible », en laissant un flou sur
« trop grand », ce n'est pas « utile ».
Toi, tu devrais faire une étude comparative des normes Fortran95,
ADA95 et C99.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Un programme est portable si, sur toutes les implémentations conformes, le même programme donne des résultats conformes à ses spécifications utiles. Prière définir "utiles" - stop
C'est laissé à la discrétion de celui qui écrit les spécifications, justement. On me donne des spécifications, j'écris un programme portable qui les remplit (ou alors je dis que ça m'emmerde, ça m'arrive aussi, et je fais autre chose).
En l'occurence, j'ai précisé « utile » pour laisser entendre que les spécifications n'avaient pas à spécifier totalement tout. Il est acceptable de dire par exemple « écrire un programme qui, donné n, calcule ceci, ou affiche un message d'erreur si n est trop grand et que le calcul ne peut être mené à bien sur le matériel disponible », en laissant un flou sur « trop grand », ce n'est pas « utile ».
Toi, tu devrais faire une étude comparative des normes Fortran95, ADA95 et C99.
JKB
Tom
Tom , dans le message <422ef396$0$12532$, a Lui ne se permet pas d'insulter ceux qui ont écrit un système en C.
Je n'ai insulté personne. A moins que C est votre deuxième prénom.
Tom
Tom , dans le message <422ef396$0$12532$636a15ce@news.free.fr>, a
Lui ne se permet pas d'insulter ceux qui ont écrit un système en C.
Je n'ai insulté personne. A moins que C est votre deuxième prénom.
« évidemment possible », c'est à dire possible d'une manière assez simple pour que le compilateur la voie.
Eric Dorino
On Wed, 09 Mar 2005 15:42:12 +0100, Joe Cool wrote:
Aucun typage ne peut garantir dans le cas général d'un langage universel qu'on adresse pas une cas inexistante d'un tableau. C'est pourquoi Caml ne peut en aucun cas gérérer une erreur à la compilation. Il fait la seule chose possible en l'absence d'algorithme exact : il envoie une exception pour signaler l'erreur. Tout bon programmeur Caml, si il n'a pas prouvé la validité de son algorithme, doit enrober son code d'un try...with pour traiter ce cas.
La première phrase est fausse, bien entendu.
Dans le cas général d'un langage typé universel:
$ cat boom.adb procedure boom is type index is range 0..9; tab: array (index) of integer; begin tab(10) := 42; end boom;
$ gnatmake boom.adb gcc -c boom.adb boom.adb:5:13: warning: value not in range of type "index" defined at line 2 boom.adb:5:13: warning: "constraint_error" will be raised at run time gnatbind -x boom.ali gnatlink boom.ali $ ./boom
raised CONSTRAINT_ERROR : boom.adb:5 range check failed $
Le troll est intéressant, bien qu'inégal par moment.
-- Eric
On Wed, 09 Mar 2005 15:42:12 +0100, Joe Cool wrote:
Aucun typage ne peut garantir dans le cas général d'un langage universel
qu'on adresse pas une cas inexistante d'un tableau. C'est pourquoi Caml ne
peut en aucun cas gérérer une erreur à la compilation. Il fait la seule
chose possible en l'absence d'algorithme exact : il envoie une exception
pour signaler l'erreur. Tout bon programmeur Caml, si il n'a pas prouvé
la validité de son algorithme, doit enrober son code d'un try...with pour
traiter ce cas.
La première phrase est fausse, bien entendu.
Dans le cas général d'un langage typé universel:
$ cat boom.adb
procedure boom is
type index is range 0..9;
tab: array (index) of integer;
begin
tab(10) := 42;
end boom;
$ gnatmake boom.adb
gcc -c boom.adb
boom.adb:5:13: warning: value not in range of type "index" defined at line 2
boom.adb:5:13: warning: "constraint_error" will be raised at run time
gnatbind -x boom.ali
gnatlink boom.ali
$ ./boom
raised CONSTRAINT_ERROR : boom.adb:5 range check failed
$
Le troll est intéressant, bien qu'inégal par moment.
On Wed, 09 Mar 2005 15:42:12 +0100, Joe Cool wrote:
Aucun typage ne peut garantir dans le cas général d'un langage universel qu'on adresse pas une cas inexistante d'un tableau. C'est pourquoi Caml ne peut en aucun cas gérérer une erreur à la compilation. Il fait la seule chose possible en l'absence d'algorithme exact : il envoie une exception pour signaler l'erreur. Tout bon programmeur Caml, si il n'a pas prouvé la validité de son algorithme, doit enrober son code d'un try...with pour traiter ce cas.
La première phrase est fausse, bien entendu.
Dans le cas général d'un langage typé universel:
$ cat boom.adb procedure boom is type index is range 0..9; tab: array (index) of integer; begin tab(10) := 42; end boom;
$ gnatmake boom.adb gcc -c boom.adb boom.adb:5:13: warning: value not in range of type "index" defined at line 2 boom.adb:5:13: warning: "constraint_error" will be raised at run time gnatbind -x boom.ali gnatlink boom.ali $ ./boom
raised CONSTRAINT_ERROR : boom.adb:5 range check failed $
Le troll est intéressant, bien qu'inégal par moment.
