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.
Que fais tu du théorème de Godel ? Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le fait est que tu cites le Théorème de Gödel sans visiblement savoir ce que c'est et sans même savoir pourquoi. Qu'y a t il de détaillé, objectif et argumenté à dire là dessus ?
Tom
Nicolas George a exprimé avec précision :
JustMe , dans le message <mn.4a5f7d533da24a14.15643@merci.beaucoup>, a
Que fais tu du théorème de Godel ?
Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le fait est que tu cites le Théorème de Gödel sans visiblement savoir ce
que c'est et sans même savoir pourquoi. Qu'y a t il de détaillé,
objectif et argumenté à dire là dessus ?
Que fais tu du théorème de Godel ? Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le fait est que tu cites le Théorème de Gödel sans visiblement savoir ce que c'est et sans même savoir pourquoi. Qu'y a t il de détaillé, objectif et argumenté à dire là dessus ?
Tom
JustMe
Tom a exposé le 09/03/2005 :
Nicolas George a exprimé avec précision :
JustMe , dans le message , a
Que fais tu du théorème de Godel ? Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le fait est que tu cites le Théorème de Gödel sans visiblement savoir ce que c'est et sans même savoir pourquoi. Qu'y a t il de détaillé, objectif et argumenté à dire là dessus ?
J'ai précisé pourquoi je citais ce théoreme. Vous et vos camarades de classe n'avez su que sautiller en disant "c'est pas vrai, c'est pas vrai"
dont acte
Tom a exposé le 09/03/2005 :
Nicolas George a exprimé avec précision :
JustMe , dans le message <mn.4a5f7d533da24a14.15643@merci.beaucoup>, a
Que fais tu du théorème de Godel ?
Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le fait est que tu cites le Théorème de Gödel sans visiblement savoir ce que
c'est et sans même savoir pourquoi. Qu'y a t il de détaillé, objectif et
argumenté à dire là dessus ?
J'ai précisé pourquoi je citais ce théoreme. Vous et vos camarades de
classe n'avez su que sautiller en disant "c'est pas vrai, c'est pas
vrai"
Que fais tu du théorème de Godel ? Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le fait est que tu cites le Théorème de Gödel sans visiblement savoir ce que c'est et sans même savoir pourquoi. Qu'y a t il de détaillé, objectif et argumenté à dire là dessus ?
J'ai précisé pourquoi je citais ce théoreme. Vous et vos camarades de classe n'avez su que sautiller en disant "c'est pas vrai, c'est pas vrai"
dont acte
Thierry Boudet
On 2005-03-09, Joe Cool wrote:
La détection des fuites de mémoire l'est peut être, mais la prévention des fuites est on ne peut plus décidable. On appelle ça des ramasse-miettes.
Ayez confiance, positive atitioude, toussa...
-- _/°< coin
On 2005-03-09, Joe Cool <zierouhli_@d_free.fr> wrote:
La détection des fuites de mémoire l'est peut être, mais la prévention
des fuites est on ne peut plus décidable. On appelle ça des ramasse-miettes.
Si l'implémentation est pourrie, ce n'est pas la faute du langage non plus, mais des programmeurs de l'implémentation.
C'est tres beau un mlangage thériquement bien écrit dont les implémentations sont pouraves.
Ca me rappelle "eiffel" au début des années 90 ca ;-D
Tom
Oui, et ? Un programme en C peut tout autant être pvouvé qu'un programme en Caml ou en n'importe quel autre langage. Il n'y a absolument aucune différence de fond : dans tous les cas l'environnement de compilation/exécution aide le programmeur dans la mesure de ses moyens à faire cette preuve, et dans tous les cas avoir une preuve complète est infiniment trop fastidieux pour qu'on prenne le temps de le faire globalement et explicitement pour les programmes courants.
Selon le langage la preuve est plus facile à faire ou pas. Les méthodes de preuves diffèrent aussi. Voir les autres posts.
De plus, l'idée de preuve mathématique d'un programme se heurte à une objection fondamentale : une preuve mathématique porte sur des objets mathématiques, alors que l'utilité d'un programme est en général dans le domaine réel (images, sons, paquets réseau). La correspondance entre le théorème qui a été prouvé et la réalité pratique qu'il est censé recouvrir ne peut pas être prouvée.
Une image est une matrice (voire plusieures). Un son est un vecteur si on considère qu'il est digitalisé. Un paquet réseau est un ensemble d'entiers d'un nombre fixé, un type somme en fait. Voilà tout est modélisé. Ca a été dûr.
Tom
Oui, et ? Un programme en C peut tout autant être pvouvé qu'un programme en
Caml ou en n'importe quel autre langage. Il n'y a absolument aucune
différence de fond : dans tous les cas l'environnement de
compilation/exécution aide le programmeur dans la mesure de ses moyens à
faire cette preuve, et dans tous les cas avoir une preuve complète est
infiniment trop fastidieux pour qu'on prenne le temps de le faire
globalement et explicitement pour les programmes courants.
Selon le langage la preuve est plus facile à faire ou pas. Les méthodes
de preuves diffèrent aussi. Voir les autres posts.
De plus, l'idée de preuve mathématique d'un programme se heurte à une
objection fondamentale : une preuve mathématique porte sur des objets
mathématiques, alors que l'utilité d'un programme est en général dans le
domaine réel (images, sons, paquets réseau). La correspondance entre le
théorème qui a été prouvé et la réalité pratique qu'il est censé recouvrir
ne peut pas être prouvée.
Une image est une matrice (voire plusieures). Un son est un vecteur si
on considère qu'il est digitalisé. Un paquet réseau est un ensemble
d'entiers d'un nombre fixé, un type somme en fait. Voilà tout est
modélisé. Ca a été dûr.
Oui, et ? Un programme en C peut tout autant être pvouvé qu'un programme en Caml ou en n'importe quel autre langage. Il n'y a absolument aucune différence de fond : dans tous les cas l'environnement de compilation/exécution aide le programmeur dans la mesure de ses moyens à faire cette preuve, et dans tous les cas avoir une preuve complète est infiniment trop fastidieux pour qu'on prenne le temps de le faire globalement et explicitement pour les programmes courants.
Selon le langage la preuve est plus facile à faire ou pas. Les méthodes de preuves diffèrent aussi. Voir les autres posts.
De plus, l'idée de preuve mathématique d'un programme se heurte à une objection fondamentale : une preuve mathématique porte sur des objets mathématiques, alors que l'utilité d'un programme est en général dans le domaine réel (images, sons, paquets réseau). La correspondance entre le théorème qui a été prouvé et la réalité pratique qu'il est censé recouvrir ne peut pas être prouvée.
Une image est une matrice (voire plusieures). Un son est un vecteur si on considère qu'il est digitalisé. Un paquet réseau est un ensemble d'entiers d'un nombre fixé, un type somme en fait. Voilà tout est modélisé. Ca a été dûr.
Tom
Nicolas George
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; 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.
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;
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.
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; 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.
Tom
( Tue, 08 Mar 2005 17:39:13 +0100 ) Tom :
Bonjour, à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
On dira peut être "bon élève, peut faire mieux". J'ai pas dit entre la peste et le choléra, mais la peste et la grippe. Bien sûr que je suis quand même content de l'avoir mon nunux. Mais si on passe son temps à exprimer son admiration bêtement ça ne fera rien avancer. Il ne faut pas avoir peur de dire que les choses vont mal quand elles vont mal. Il n'y a même pas besoin d'avoir du courage pour ça. Ca sort tout seul :-)
Tom
( Tue, 08 Mar 2005 17:39:13 +0100 ) Tom :
Bonjour,
à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
On dira peut être "bon élève, peut faire mieux". J'ai pas dit entre la
peste et le choléra, mais la peste et la grippe. Bien sûr que je suis
quand même content de l'avoir mon nunux. Mais si on passe son temps à
exprimer son admiration bêtement ça ne fera rien avancer.
Il ne faut pas avoir peur de dire que les choses vont mal quand elles
vont mal. Il n'y a même pas besoin d'avoir du courage pour ça. Ca sort
tout seul :-)
Bonjour, à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
On dira peut être "bon élève, peut faire mieux". J'ai pas dit entre la peste et le choléra, mais la peste et la grippe. Bien sûr que je suis quand même content de l'avoir mon nunux. Mais si on passe son temps à exprimer son admiration bêtement ça ne fera rien avancer. Il ne faut pas avoir peur de dire que les choses vont mal quand elles vont mal. Il n'y a même pas besoin d'avoir du courage pour ça. Ca sort tout seul :-)
Tom
Tom
"Dieu a inventé les nombres entiers, tout le reste est l'invention de l'homme".
Kronecker
Je la ressortirai :-)
Tom
"Dieu a inventé les nombres entiers, tout le reste est l'invention
de l'homme".
"Dieu a inventé les nombres entiers, tout le reste est l'invention de l'homme".
Kronecker
Je la ressortirai :-)
Tom
JustMe
Tom a exprimé avec précision :
( Tue, 08 Mar 2005 17:39:13 +0100 ) Tom :
Bonjour, à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
On dira peut être "bon élève, peut faire mieux". J'ai pas dit entre la peste et le choléra, mais la peste et la grippe. Bien sûr que je suis quand même content de l'avoir mon nunux. Mais si on passe son temps à exprimer son admiration bêtement ça ne fera rien avancer. Il ne faut pas avoir peur de dire que les choses vont mal quand elles vont mal. Il n'y a même pas besoin d'avoir du courage pour ça. Ca sort tout seul :-)
Tom
Et qu'attends tu pour *faire* du constructif au lieu de critiquer ? ;-)
Tom a exprimé avec précision :
( Tue, 08 Mar 2005 17:39:13 +0100 ) Tom :
Bonjour,
à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
On dira peut être "bon élève, peut faire mieux". J'ai pas dit entre la peste
et le choléra, mais la peste et la grippe. Bien sûr que je suis quand même
content de l'avoir mon nunux. Mais si on passe son temps à exprimer son
admiration bêtement ça ne fera rien avancer.
Il ne faut pas avoir peur de dire que les choses vont mal quand elles vont
mal. Il n'y a même pas besoin d'avoir du courage pour ça. Ca sort tout seul
:-)
Tom
Et qu'attends tu pour *faire* du constructif au lieu de critiquer ? ;-)
Bonjour, à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
On dira peut être "bon élève, peut faire mieux". J'ai pas dit entre la peste et le choléra, mais la peste et la grippe. Bien sûr que je suis quand même content de l'avoir mon nunux. Mais si on passe son temps à exprimer son admiration bêtement ça ne fera rien avancer. Il ne faut pas avoir peur de dire que les choses vont mal quand elles vont mal. Il n'y a même pas besoin d'avoir du courage pour ça. Ca sort tout seul :-)
Tom
Et qu'attends tu pour *faire* du constructif au lieu de critiquer ? ;-)
Tom
Si un programme dépend de la structure de l'entier, c'est que le programmeur s'est chié dessus.
En gros un type en C c'est le nombre de bits utilisés. Ils auraient du faire le type unbit (le fameux booléen qui n'existe pas), le deuxbit etc. Ca serait portable.
Tom
Si un programme dépend de la structure de l'entier, c'est que le programmeur
s'est chié dessus.
En gros un type en C c'est le nombre de bits utilisés. Ils auraient du
faire le type unbit (le fameux booléen qui n'existe pas), le deuxbit
etc. Ca serait portable.
Si un programme dépend de la structure de l'entier, c'est que le programmeur s'est chié dessus.
En gros un type en C c'est le nombre de bits utilisés. Ils auraient du faire le type unbit (le fameux booléen qui n'existe pas), le deuxbit etc. Ca serait portable.
