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.
Tom , dans le message <422ef396$0$12532$, a écrit :
Et toi t'as écris un système en C ?
Lui ne se permet pas d'insulter ceux qui ont écrit un système en C.
On peut formuler les choses autrement : montre un système d'exploitation en Caml, que ce soit toi qui l'as écrit ou pas.
Nicolas George
Tom , dans le message <422ef3e3$0$12532$, a écrit :
Si on fait une nouvelle cathédrale aujourd'hui tu pense qu'on utilisera des esclaves ? Pour des raisons historiques on serait obligé. Serait-ce pour celà qu'on ne fait plus de cathédrales ?
On t'a mal renseigné, les cathédrales n'ont pas été construites par des esclaves. Je te renvoie à l'excellent épisode _Les Bâtisseurs de cathédrales_, de la série de documentaires historiques _Il était une fois l'homme_ pour plus de détails.
Tom , dans le message <422ef3e3$0$12532$636a15ce@news.free.fr>, a
écrit :
Si on fait une nouvelle cathédrale aujourd'hui tu pense qu'on utilisera
des esclaves ? Pour des raisons historiques on serait obligé. Serait-ce
pour celà qu'on ne fait plus de cathédrales ?
On t'a mal renseigné, les cathédrales n'ont pas été construites par des
esclaves. Je te renvoie à l'excellent épisode _Les Bâtisseurs de
cathédrales_, de la série de documentaires historiques _Il était une fois
l'homme_ pour plus de détails.
Tom , dans le message <422ef3e3$0$12532$, a écrit :
Si on fait une nouvelle cathédrale aujourd'hui tu pense qu'on utilisera des esclaves ? Pour des raisons historiques on serait obligé. Serait-ce pour celà qu'on ne fait plus de cathédrales ?
On t'a mal renseigné, les cathédrales n'ont pas été construites par des esclaves. Je te renvoie à l'excellent épisode _Les Bâtisseurs de cathédrales_, de la série de documentaires historiques _Il était une fois l'homme_ pour plus de détails.
Joe Cool
Tom , dans le message <422ef396$0$12532$, a
Et toi t'as écris un système en C ?
Lui ne se permet pas d'insulter ceux qui ont écrit un système en C.
On peut formuler les choses autrement : montre un système d'exploitation en Caml, que ce soit toi qui l'as écrit ou pas.
Les rares qui sont suffisamment intelligents pour faire du caml à la place du C n'ont pas forcément assez de main d'oeuvre pour faire ce genre de chose. De plus, en suivant ce raisonnement, on en conclus que le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux dernier cri.
Ça ne vole vraiment pas haut.
-- Joe Cool
Tom , dans le message <422ef396$0$12532$636a15ce@news.free.fr>, a
Et toi t'as écris un système en C ?
Lui ne se permet pas d'insulter ceux qui ont écrit un système en C.
On peut formuler les choses autrement : montre un système d'exploitation en
Caml, que ce soit toi qui l'as écrit ou pas.
Les rares qui sont suffisamment intelligents pour faire du caml à la
place du C n'ont pas forcément assez de main d'oeuvre pour faire ce
genre de chose. De plus, en suivant ce raisonnement, on en conclus que
le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux
dernier cri.
Lui ne se permet pas d'insulter ceux qui ont écrit un système en C.
On peut formuler les choses autrement : montre un système d'exploitation en Caml, que ce soit toi qui l'as écrit ou pas.
Les rares qui sont suffisamment intelligents pour faire du caml à la place du C n'ont pas forcément assez de main d'oeuvre pour faire ce genre de chose. De plus, en suivant ce raisonnement, on en conclus que le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux dernier cri.
Ça ne vole vraiment pas haut.
-- Joe Cool
Joe Cool
Tom , dans le message <422f2352$0$31661$, a
#-147483648- : unit = ()
Perdu, ça afficherait 2000000000, les machines de travail des développeurs du projet Cristal sont des 64 bits.
Caml ne serait-il pas portable ?
Non, il ne l'est pas. Personne n'a prétendu le contraire. Par contre le niveau de portabilité du Caml est sans commune mesure avec celui du C.
-- Joe Cool
Tom , dans le message <422f2352$0$31661$636a15ce@news.free.fr>, a
#-147483648- : unit = ()
Perdu, ça afficherait 2000000000, les machines de travail des développeurs
du projet Cristal sont des 64 bits.
Caml ne serait-il pas portable ?
Non, il ne l'est pas. Personne n'a prétendu le contraire. Par contre le
niveau de portabilité du Caml est sans commune mesure avec celui du C.
Perdu, ça afficherait 2000000000, les machines de travail des développeurs du projet Cristal sont des 64 bits.
Caml ne serait-il pas portable ?
Non, il ne l'est pas. Personne n'a prétendu le contraire. Par contre le niveau de portabilité du Caml est sans commune mesure avec celui du C.
-- Joe Cool
Nicolas George
JKB , dans le message , a écrit :
Ouaips... Regadez déjà ce qui ressort de la compilation d'un noyau Linux, on rediscutera après.
Je n'ai pas dit tous, j'ai dit pas mal. Et concernant le noyau Linux, l'exemple n'est pas terrible, parce que justement de gros efforts sont fait dans ce sens. J'ai sous les yeux un log de compilation, c'est compilé en -Wall -Wstrict-prototypes et y a une grande majorité des fichiers sources qui compilent sans warnings. Pourtant, c'est une compilation pour ARM (architecture moins maintenue) et avec un compilateur plus récent que le noyau compilé (donc des warnings plus stricts).
JKB , dans le message <slrnd2u93c.ugg.knatschke@rayleigh.systella.fr>, a
écrit :
Ouaips... Regadez déjà ce qui ressort de la compilation d'un noyau
Linux, on rediscutera après.
Je n'ai pas dit tous, j'ai dit pas mal. Et concernant le noyau Linux,
l'exemple n'est pas terrible, parce que justement de gros efforts sont fait
dans ce sens. J'ai sous les yeux un log de compilation, c'est compilé en
-Wall -Wstrict-prototypes et y a une grande majorité des fichiers sources
qui compilent sans warnings. Pourtant, c'est une compilation pour ARM
(architecture moins maintenue) et avec un compilateur plus récent que le
noyau compilé (donc des warnings plus stricts).
Ouaips... Regadez déjà ce qui ressort de la compilation d'un noyau Linux, on rediscutera après.
Je n'ai pas dit tous, j'ai dit pas mal. Et concernant le noyau Linux, l'exemple n'est pas terrible, parce que justement de gros efforts sont fait dans ce sens. J'ai sous les yeux un log de compilation, c'est compilé en -Wall -Wstrict-prototypes et y a une grande majorité des fichiers sources qui compilent sans warnings. Pourtant, c'est une compilation pour ARM (architecture moins maintenue) et avec un compilateur plus récent que le noyau compilé (donc des warnings plus stricts).
Nicolas George
Tom , dans le message <422f2352$0$31661$, a écrit :
#-147483648- : unit = ()
Perdu, ça afficherait 2000000000, les machines de travail des développeurs du projet Cristal sont des 64 bits.
Caml ne serait-il pas portable ?
Tom , dans le message <422f2352$0$31661$636a15ce@news.free.fr>, a
écrit :
#-147483648- : unit = ()
Perdu, ça afficherait 2000000000, les machines de travail des développeurs
du projet Cristal sont des 64 bits.
Tom , dans le message <422f2352$0$31661$, a écrit :
#-147483648- : unit = ()
Perdu, ça afficherait 2000000000, les machines de travail des développeurs du projet Cristal sont des 64 bits.
Caml ne serait-il pas portable ?
Nicolas George
Joe Cool , dans le message <422f2493$0$31419$, a écrit :
Les entiers relatifs sont signés et les entiers modulo ont besoin d'un paramètre entier pour être défini.
Mais ils n'était question d'aucun de ceux-là. Il était question des entiers C, dont le petit nom est « int », et qui obéissent à des règles légèrement différentes de celles des entiers mathématiques (mais tout aussi bien spécifiées).
Joe Cool , dans le message <422f2493$0$31419$636a15ce@news.free.fr>, a
écrit :
Les entiers relatifs sont signés et les entiers modulo ont besoin d'un
paramètre entier pour être défini.
Mais ils n'était question d'aucun de ceux-là. Il était question des entiers
C, dont le petit nom est « int », et qui obéissent à des règles légèrement
différentes de celles des entiers mathématiques (mais tout aussi bien
spécifiées).
Joe Cool , dans le message <422f2493$0$31419$, a écrit :
Les entiers relatifs sont signés et les entiers modulo ont besoin d'un paramètre entier pour être défini.
Mais ils n'était question d'aucun de ceux-là. Il était question des entiers C, dont le petit nom est « int », et qui obéissent à des règles légèrement différentes de celles des entiers mathématiques (mais tout aussi bien spécifiées).
Tom
Quel est le problème ?
Ca n'a pas de sens.
Tu prouves encore que tu ne connais pas le C.
Je le connais, je lui ai ditbonjour ce matin même.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien lui donner. Cette phrase ne veut rien dire.
Vous ne comprenez pas cette phrase, nuance. Je vais détailler. Un programme n'est qu'un ensemble de lignes de code, que le programmeur écrit pour transcrire quelque chose qu'il veut faire faire par la machine. Or ce programme est un programme parmi tant d'autres parmis ceux possibles pour accomplir la tâche originale. Mais ce n'est pas de ça que je parlais. Ce que je disais c'est que le même programme peut avoir plusieurs significations. Si on prend du bas niveau vu que les gens ont l'air d'apprécier ça ici. Les multiplications sont des ensembles de décalages. Donc le programme simple qui multiplie par deux et le programme qui décale les bits d'une case mémoire vers les bits de poids fort sont le même programme. Mais ils ont une sémantique différente. Ce principe peut être extrapolé facilement à des programmes beaucoup plus compliqués. Si bien que si je vous donne un programme il n'est pas possible de dire ce qu'il fait même si on peut voir ce qu'il calcule.
Je ne pense pas qu'il y ait un intérêt aux classes. Tu ne penses pas beaucoup, on dirait.
Peut être trop en fait. Il vaut mieux utiliser le C comme un mouton. C'est très apprécié on dirait.
Ils ne devraient tout simplement pas exister. Tu as invoqué toi-même le fait que c'était un problème indécidable.
Ce n'est pas moi. Mais c'est indécidable de le décider à priori. Mais ce
n'est certainement pas indécidable de traiter ce genre de choses à l'exécution. Ce que que le C ne permet pas. Ou est indéfini là dessus en fait. Au cas où un blaireau veut faire une rustine parce que les concepteurs du C n'avaient pas que ça à fouttre.
Tom
Quel est le problème ?
Ca n'a pas de sens.
Tu prouves encore que tu ne connais pas le C.
Je le connais, je lui ai ditbonjour ce matin même.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien
lui donner.
Cette phrase ne veut rien dire.
Vous ne comprenez pas cette phrase, nuance. Je vais détailler. Un
programme n'est qu'un ensemble de lignes de code, que le programmeur
écrit pour transcrire quelque chose qu'il veut faire faire par la
machine. Or ce programme est un programme parmi tant d'autres parmis
ceux possibles pour accomplir la tâche originale. Mais ce n'est pas de
ça que je parlais. Ce que je disais c'est que le même programme peut
avoir plusieurs significations. Si on prend du bas niveau vu que les
gens ont l'air d'apprécier ça ici. Les multiplications sont des
ensembles de décalages. Donc le programme simple qui multiplie par deux
et le programme qui décale les bits d'une case mémoire vers les bits de
poids fort sont le même programme. Mais ils ont une sémantique
différente. Ce principe peut être extrapolé facilement à des programmes
beaucoup plus compliqués. Si bien que si je vous donne un programme il
n'est pas possible de dire ce qu'il fait même si on peut voir ce qu'il
calcule.
Je ne pense pas qu'il y ait un intérêt aux classes.
Tu ne penses pas beaucoup, on dirait.
Peut être trop en fait. Il vaut mieux utiliser le C comme un mouton.
C'est très apprécié on dirait.
Ils ne devraient tout simplement pas exister.
Tu as invoqué toi-même le fait que c'était un problème indécidable.
Ce n'est pas moi. Mais c'est indécidable de le décider à priori. Mais ce
n'est certainement pas indécidable de traiter ce genre de choses à
l'exécution. Ce que que le C ne permet pas. Ou est indéfini là dessus en
fait. Au cas où un blaireau veut faire une rustine parce que les
concepteurs du C n'avaient pas que ça à fouttre.
Je le connais, je lui ai ditbonjour ce matin même.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien lui donner. Cette phrase ne veut rien dire.
Vous ne comprenez pas cette phrase, nuance. Je vais détailler. Un programme n'est qu'un ensemble de lignes de code, que le programmeur écrit pour transcrire quelque chose qu'il veut faire faire par la machine. Or ce programme est un programme parmi tant d'autres parmis ceux possibles pour accomplir la tâche originale. Mais ce n'est pas de ça que je parlais. Ce que je disais c'est que le même programme peut avoir plusieurs significations. Si on prend du bas niveau vu que les gens ont l'air d'apprécier ça ici. Les multiplications sont des ensembles de décalages. Donc le programme simple qui multiplie par deux et le programme qui décale les bits d'une case mémoire vers les bits de poids fort sont le même programme. Mais ils ont une sémantique différente. Ce principe peut être extrapolé facilement à des programmes beaucoup plus compliqués. Si bien que si je vous donne un programme il n'est pas possible de dire ce qu'il fait même si on peut voir ce qu'il calcule.
Je ne pense pas qu'il y ait un intérêt aux classes. Tu ne penses pas beaucoup, on dirait.
Peut être trop en fait. Il vaut mieux utiliser le C comme un mouton. C'est très apprécié on dirait.
Ils ne devraient tout simplement pas exister. Tu as invoqué toi-même le fait que c'était un problème indécidable.
Ce n'est pas moi. Mais c'est indécidable de le décider à priori. Mais ce
n'est certainement pas indécidable de traiter ce genre de choses à l'exécution. Ce que que le C ne permet pas. Ou est indéfini là dessus en fait. Au cas où un blaireau veut faire une rustine parce que les concepteurs du C n'avaient pas que ça à fouttre.
