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.
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux, par exemple, est bourré de cas qui sont implementation defined ou undefined. Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas du C. Pour exactement la même raison que :
int a[10], b; a[10] = 42;
n'est pas du C.
Ben oui, c'est du LISP, ça ce voit au premier coup d'oeil.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler !
Où est le problème ? Tant qu'on s'assure de ne jamais dépasser l'intervalle de validité des entiers, ce sont bien les mêmes entiers, il n'y a aucun problème. Et comme justement la transition va dans le sens d'un élargissement des valeurs, il n'y a pas de problème.
Sauf si on utilise de l'arithmétique modulo la valeur maximale des données, ce qui est permis par la norme. Je rapelle que détecter un dépassement de capacité en C est un problème indécidable. Vous savez résoudre de tête des problèmes indécidables, c'est trivial pour vous, vous êtes très fort.
Je peux dire autrement : qu'on me montre un code utilisant int et long de DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du C.
« An example of undefined behavior is the behavior on integer overflow. »
#include <stdlib.h>
int main(int argc, char **argv) { int a;
a = 65535; if (a + 1 == 0) { return EXIT_SUCCESS; } else { return EXIT_FAILURE; } }
-- Joe Cool
JKB , dans le message <slrnd2rs7q.mkg.knatschke@rayleigh.systella.fr>, a
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C
valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux,
par exemple, est bourré de cas qui sont implementation defined ou undefined.
Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit
bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas
du C. Pour exactement la même raison que :
int a[10], b;
a[10] = 42;
n'est pas du C.
Ben oui, c'est du LISP, ça ce voit au premier coup d'oeil.
Maintenant, portez moi un code utilisant int et long de DOS à
sparc64 pour rigoler !
Où est le problème ? Tant qu'on s'assure de ne jamais dépasser l'intervalle
de validité des entiers, ce sont bien les mêmes entiers, il n'y a aucun
problème. Et comme justement la transition va dans le sens d'un
élargissement des valeurs, il n'y a pas de problème.
Sauf si on utilise de l'arithmétique modulo la valeur maximale des
données, ce qui est permis par la norme. Je rapelle que détecter un
dépassement de capacité en C est un problème indécidable. Vous savez
résoudre de tête des problèmes indécidables, c'est trivial pour vous,
vous êtes très fort.
Je peux dire autrement : qu'on me montre un code utilisant int et long de
DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du
C.
« An example of undefined behavior is
the behavior on integer overflow. »
#include <stdlib.h>
int main(int argc, char **argv)
{
int a;
a = 65535;
if (a + 1 == 0) { return EXIT_SUCCESS; }
else { return EXIT_FAILURE; }
}
Exemples. Et avec en prime le pourquoi du comment ce n'est pas du C valide.
Je suis en train de pinailler sur ce qui est du C ou pas. Le noyau Linux, par exemple, est bourré de cas qui sont implementation defined ou undefined. Ça passe parce qu'on le compile avec un compilateur bien précis, qui fournit bien plus de garanties que ne le fait le C, mais stricto sensu ce n'est pas du C. Pour exactement la même raison que :
int a[10], b; a[10] = 42;
n'est pas du C.
Ben oui, c'est du LISP, ça ce voit au premier coup d'oeil.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler !
Où est le problème ? Tant qu'on s'assure de ne jamais dépasser l'intervalle de validité des entiers, ce sont bien les mêmes entiers, il n'y a aucun problème. Et comme justement la transition va dans le sens d'un élargissement des valeurs, il n'y a pas de problème.
Sauf si on utilise de l'arithmétique modulo la valeur maximale des données, ce qui est permis par la norme. Je rapelle que détecter un dépassement de capacité en C est un problème indécidable. Vous savez résoudre de tête des problèmes indécidables, c'est trivial pour vous, vous êtes très fort.
Je peux dire autrement : qu'on me montre un code utilisant int et long de DOS qui ne marche pas sur sparc64, et je montrerai en quoi ce n'est pas du C.
« An example of undefined behavior is the behavior on integer overflow. »
#include <stdlib.h>
int main(int argc, char **argv) { int a;
a = 65535; if (a + 1 == 0) { return EXIT_SUCCESS; } else { return EXIT_FAILURE; } }
-- Joe Cool
JKB
Le 08-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 :
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code écrit en C qui ne comporte pas à un endroit ou un autre un truc qui n'est pas implementation defined.
J'en ai vu pas mal, au contraire. Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme dans la plupart de mes programmes, même dans ses exigences qui ne risquent pas de poser problème sur des implémentations existantes (je pense au particulier à l'interdiction de calculer un pointeur invalide, même si on ne le déréférence pas). En général, je pense n'y arriver pas si mal avec l'aide d'outils de vérification assez évolués pour me dénicher les erreurs d'innatention.
Ouaips...
Sauf que dès qu'on met ça dans un tableau, on a des surprises ! Parce que l'élément suivant n'est pas du tout où le compilo s'attend à le trouver.
Gnî ? L'élément suivant, il est à p + 1, toujours.
Pas quand on travaille en bits où il y a des offsets dans les cases du tableau.
Par ailleurs, lorsqu'un code est écrit par plusieurs personnes, il y a toujours des casts malheureux qui ne dérange pas _sauf_ lorsqu'on change d'architecture où tout se casse la gueule (sjmea).
Ah ça, les programmeurs qui font les choses correctement sont rares, alors en trouver deux au même endroit...
Dommage. J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs. Le truc est sur mon PS/2 à 500 km d'ici et compilé avec Borland C sous IBM DOS 5.00. Note bien : code écrit par moi. J'ai passé des jours à le compiler sur une Sun tournant sous Solaris 2.5 (gcc 2.7.2.1), parce que tous les calculs se faisaient en utilisant les bits des entiers à grands coups de décalages. Et comme la taille de ces trucs change, il y a des tas de données qui passaient à l'as et mes matrices étaient nulles par bloc ! Un C parfaitement à la norme peut ne pas être portable.
Même de mémoire, pas moyen de voir le genre de construction qui pose problème ?
Dès que je remets la main sur ce bout de code, je te l'envoie !
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2ruab.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code
écrit en C qui ne comporte pas à un endroit ou un autre un truc qui
n'est pas implementation defined.
J'en ai vu pas mal, au contraire. Et je peux t'assurer que je m'efforce de
suivre scrupuleusement la norme dans la plupart de mes programmes, même dans
ses exigences qui ne risquent pas de poser problème sur des implémentations
existantes (je pense au particulier à l'interdiction de calculer un pointeur
invalide, même si on ne le déréférence pas). En général, je pense n'y
arriver pas si mal avec l'aide d'outils de vérification assez évolués pour
me dénicher les erreurs d'innatention.
Ouaips...
Sauf que dès qu'on met ça dans un tableau, on a des surprises !
Parce que l'élément suivant n'est pas du tout où le compilo s'attend
à le trouver.
Gnî ? L'élément suivant, il est à p + 1, toujours.
Pas quand on travaille en bits où il y a des offsets dans les cases
du tableau.
Par ailleurs, lorsqu'un code est écrit par plusieurs
personnes, il y a toujours des casts malheureux qui ne dérange pas
_sauf_ lorsqu'on change d'architecture où tout se casse la gueule
(sjmea).
Ah ça, les programmeurs qui font les choses correctement sont rares, alors
en trouver deux au même endroit...
Dommage. J'avais écrit un code de division de polynôme dans
GF(2**256) pour faire du décodage souple de codes en blocs. Le truc
est sur mon PS/2 à 500 km d'ici et compilé avec Borland C sous IBM
DOS 5.00. Note bien : code écrit par moi. J'ai passé des jours à le
compiler sur une Sun tournant sous Solaris 2.5 (gcc 2.7.2.1), parce
que tous les calculs se faisaient en utilisant les bits des entiers
à grands coups de décalages. Et comme la taille de ces trucs change,
il y a des tas de données qui passaient à l'as et mes matrices
étaient nulles par bloc ! Un C parfaitement à la norme peut ne pas
être portable.
Même de mémoire, pas moyen de voir le genre de construction qui pose
problème ?
Dès que je remets la main sur ce bout de code, je te l'envoie !
Le 08-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 :
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code écrit en C qui ne comporte pas à un endroit ou un autre un truc qui n'est pas implementation defined.
J'en ai vu pas mal, au contraire. Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme dans la plupart de mes programmes, même dans ses exigences qui ne risquent pas de poser problème sur des implémentations existantes (je pense au particulier à l'interdiction de calculer un pointeur invalide, même si on ne le déréférence pas). En général, je pense n'y arriver pas si mal avec l'aide d'outils de vérification assez évolués pour me dénicher les erreurs d'innatention.
Ouaips...
Sauf que dès qu'on met ça dans un tableau, on a des surprises ! Parce que l'élément suivant n'est pas du tout où le compilo s'attend à le trouver.
Gnî ? L'élément suivant, il est à p + 1, toujours.
Pas quand on travaille en bits où il y a des offsets dans les cases du tableau.
Par ailleurs, lorsqu'un code est écrit par plusieurs personnes, il y a toujours des casts malheureux qui ne dérange pas _sauf_ lorsqu'on change d'architecture où tout se casse la gueule (sjmea).
Ah ça, les programmeurs qui font les choses correctement sont rares, alors en trouver deux au même endroit...
Dommage. J'avais écrit un code de division de polynôme dans GF(2**256) pour faire du décodage souple de codes en blocs. Le truc est sur mon PS/2 à 500 km d'ici et compilé avec Borland C sous IBM DOS 5.00. Note bien : code écrit par moi. J'ai passé des jours à le compiler sur une Sun tournant sous Solaris 2.5 (gcc 2.7.2.1), parce que tous les calculs se faisaient en utilisant les bits des entiers à grands coups de décalages. Et comme la taille de ces trucs change, il y a des tas de données qui passaient à l'as et mes matrices étaient nulles par bloc ! Un C parfaitement à la norme peut ne pas être portable.
Même de mémoire, pas moyen de voir le genre de construction qui pose problème ?
Dès que je remets la main sur ce bout de code, je te l'envoie !
JKB
Joe Cool
Joe Cool , dans le message <422de975$0$27862$, a
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
Je vais faire comme si je n'avais rien lu.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur 68000 sur une plateforme intel qu'on rigole.
Sans problème, un simple compilateur, ou interpréteur suffit.
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
-- Joe Cool
Joe Cool , dans le message <422de975$0$27862$626a14ce@news.free.fr>, a
Un langage qui permet explicitement de faire planter une machine a
forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
Je vais faire comme si je n'avais rien lu.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur
68000 sur une plateforme intel qu'on rigole.
Sans problème, un simple compilateur, ou interpréteur suffit.
Contrairement à ce que l'on croit, la portabilité d'un langage est
uniquement déterminée par la qualité de sa spécification. Un langage
d'assemblage est portable car sa sémantique est univoque, alors que la
liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
Je vais faire comme si je n'avais rien lu.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur 68000 sur une plateforme intel qu'on rigole.
Sans problème, un simple compilateur, ou interpréteur suffit.
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
-- Joe Cool
Joe Cool
On 2005-03-08, Joe Cool wrote:
On ne peut pas sérieusement programmer avec un langage bricolé à la va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne méritent pas le nom d'informaticien.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement des cons" ?
Si il ne s'agissait que de moi, ce serait vrai, mais il s'agit de plus de 40 années de recherches en informatique qui sont royalement ignorées par ces soi disants informaticiens.
-- Joe Cool
On 2005-03-08, Joe Cool <zierouhli_@d_free.fr> wrote:
On ne peut pas sérieusement programmer avec un langage bricolé à la
va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne
méritent pas le nom d'informaticien.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement
des cons" ?
Si il ne s'agissait que de moi, ce serait vrai, mais il s'agit de plus
de 40 années de recherches en informatique qui sont royalement ignorées
par ces soi disants informaticiens.
On ne peut pas sérieusement programmer avec un langage bricolé à la va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne méritent pas le nom d'informaticien.
Ouais, en gros, "ceux qui ne sont pas d'accord avec moi sont forcement des cons" ?
Si il ne s'agissait que de moi, ce serait vrai, mais il s'agit de plus de 40 années de recherches en informatique qui sont royalement ignorées par ces soi disants informaticiens.
-- Joe Cool
Nicolas George
Joe Cool , dans le message <422dfdae$0$1508$, a écrit :
Voilà une sémantique d'une précison toute littéraire.
Je suis mathématicien, pas sémanticien, je ne connais pas le jargon de ces gens.
Voilà maitenant que ça ne compile plus ! Alors ce void, c'est out ou c'est rien ? C'est surtout n'importe quoi.
Beau sophisme, mais ça ne prouve rien.
Ça compile sans un mot
Ça n'est pas pour autant du C.
Ça s'exécute sans un mot
Ça n'en fait toujours pas du C. Tu montres juste que ton environnement de compilation/exécution est plus tolérant que la norme.
Le C est un langage démagogique qui a du succès car il fait croire au programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait jamais d'erreur. Un véritable informaticien sait qu'un système, quel qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est erroné. Si il le croit, c'est qu'il est incohérent, car seul un être incohérent peut se croire sans défaut.
Tiens, encore quelqu'un qui n'a pas compris le théorème d'incomplétude.
Et bien ce n'est rien que des mensonges. Un programmeur se plante souvent et n'a aucun moyen de savoir ou et quand il se plante dans le cas général.
Il y a des outils pour ça. C'est encore expérimental, car le problème est très complexe, mais ça en vient servir pour prouver des programmes dans l'industrie aéronautique.
Joe Cool , dans le message <422dfdae$0$1508$636a15ce@news.free.fr>, a
écrit :
Voilà une sémantique d'une précison toute littéraire.
Je suis mathématicien, pas sémanticien, je ne connais pas le jargon de ces
gens.
Voilà maitenant que ça ne compile plus ! Alors ce void, c'est out ou
c'est rien ? C'est surtout n'importe quoi.
Beau sophisme, mais ça ne prouve rien.
Ça compile sans un mot
Ça n'est pas pour autant du C.
Ça s'exécute sans un mot
Ça n'en fait toujours pas du C. Tu montres juste que ton environnement de
compilation/exécution est plus tolérant que la norme.
Le C est un langage démagogique qui a du succès car il fait croire au
programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait
jamais d'erreur. Un véritable informaticien sait qu'un système, quel
qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est
erroné. Si il le croit, c'est qu'il est incohérent, car seul un être
incohérent peut se croire sans défaut.
Tiens, encore quelqu'un qui n'a pas compris le théorème d'incomplétude.
Et bien ce n'est rien que des mensonges. Un programmeur se plante
souvent et n'a aucun moyen de savoir ou et quand il se plante dans le
cas général.
Il y a des outils pour ça. C'est encore expérimental, car le problème est
très complexe, mais ça en vient servir pour prouver des programmes dans
l'industrie aéronautique.
Joe Cool , dans le message <422dfdae$0$1508$, a écrit :
Voilà une sémantique d'une précison toute littéraire.
Je suis mathématicien, pas sémanticien, je ne connais pas le jargon de ces gens.
Voilà maitenant que ça ne compile plus ! Alors ce void, c'est out ou c'est rien ? C'est surtout n'importe quoi.
Beau sophisme, mais ça ne prouve rien.
Ça compile sans un mot
Ça n'est pas pour autant du C.
Ça s'exécute sans un mot
Ça n'en fait toujours pas du C. Tu montres juste que ton environnement de compilation/exécution est plus tolérant que la norme.
Le C est un langage démagogique qui a du succès car il fait croire au programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait jamais d'erreur. Un véritable informaticien sait qu'un système, quel qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est erroné. Si il le croit, c'est qu'il est incohérent, car seul un être incohérent peut se croire sans défaut.
Tiens, encore quelqu'un qui n'a pas compris le théorème d'incomplétude.
Et bien ce n'est rien que des mensonges. Un programmeur se plante souvent et n'a aucun moyen de savoir ou et quand il se plante dans le cas général.
Il y a des outils pour ça. C'est encore expérimental, car le problème est très complexe, mais ça en vient servir pour prouver des programmes dans l'industrie aéronautique.
Joe Cool
Le C est un langage démagogique qui a du succès car il fait croire au programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait jamais d'erreur. Un véritable informaticien sait qu'un système, quel qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est erroné. Si il le croit, c'est qu'il est incohérent, car seul un être incohérent peut se croire sans défaut.
Tiens, encore quelqu'un qui n'a pas compris le théorème d'incomplétude.
Tiens, encore un qui croit avoir compris le théorème d'incomplétude.
Et bien ce n'est rien que des mensonges. Un programmeur se plante souvent et n'a aucun moyen de savoir ou et quand il se plante dans le cas général.
Il y a des outils pour ça. C'est encore expérimental, car le problème est très complexe, mais ça en vient servir pour prouver des programmes dans l'industrie aéronautique.
Le problème est complexe, certes, il est même indécidable. Bon courage.
-- Joe Cool
Le C est un langage démagogique qui a du succès car il fait croire au
programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait
jamais d'erreur. Un véritable informaticien sait qu'un système, quel
qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est
erroné. Si il le croit, c'est qu'il est incohérent, car seul un être
incohérent peut se croire sans défaut.
Tiens, encore quelqu'un qui n'a pas compris le théorème d'incomplétude.
Tiens, encore un qui croit avoir compris le théorème d'incomplétude.
Et bien ce n'est rien que des mensonges. Un programmeur se plante
souvent et n'a aucun moyen de savoir ou et quand il se plante dans le
cas général.
Il y a des outils pour ça. C'est encore expérimental, car le problème est
très complexe, mais ça en vient servir pour prouver des programmes dans
l'industrie aéronautique.
Le problème est complexe, certes, il est même indécidable. Bon courage.
Le C est un langage démagogique qui a du succès car il fait croire au programmeur qu'il est le meilleur, qu'il est parfait et qu'il ne fait jamais d'erreur. Un véritable informaticien sait qu'un système, quel qu'il soit, machine ou programmeur, n'a aucun moyen de savoir si il est erroné. Si il le croit, c'est qu'il est incohérent, car seul un être incohérent peut se croire sans défaut.
Tiens, encore quelqu'un qui n'a pas compris le théorème d'incomplétude.
Tiens, encore un qui croit avoir compris le théorème d'incomplétude.
Et bien ce n'est rien que des mensonges. Un programmeur se plante souvent et n'a aucun moyen de savoir ou et quand il se plante dans le cas général.
Il y a des outils pour ça. C'est encore expérimental, car le problème est très complexe, mais ça en vient servir pour prouver des programmes dans l'industrie aéronautique.
Le problème est complexe, certes, il est même indécidable. Bon courage.
-- Joe Cool
Joe Cool
Joe Cool a exposé le 08/03/2005 :
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Un langage qui interdirait de planter une machine ne permet pas la réalisation d'un systeme d'exploitation
Le plantage fait donc parti des fonctonnalités de tout bon OS (ce qui est faux, bien sûr).
-- Joe Cool
Joe Cool a exposé le 08/03/2005 :
Un langage qui permet explicitement de faire planter une machine a
forcément été conçu pour faire planter la machine.
Un langage qui interdirait de planter une machine ne permet pas la
réalisation d'un systeme d'exploitation
Le plantage fait donc parti des fonctonnalités de tout bon OS (ce qui
est faux, bien sûr).
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Un langage qui interdirait de planter une machine ne permet pas la réalisation d'un systeme d'exploitation
Mais pourtant il y a Ada et AdaOS ;-)
http://www.adaos.net/ http://www.gnat.com/
Nicolas George
Joe Cool , dans le message <422e0118$0$27859$, a écrit :
Sauf si on utilise de l'arithmétique modulo la valeur maximale des données, ce qui est permis par la norme.
Si on ne s'est pas assuré à l'avance de la taille sur laquelle on fait cette arithmétique, c'est une erreur, c'est tout.
Je rapelle que détecter un dépassement de capacité en C est un problème indécidable. Vous savez résoudre de tête des problèmes indécidables, c'est trivial pour vous, vous êtes très fort.
Je sais me placer dans les cas où c'est décidable, ce qui est beaucoup plus simple.
« An example of undefined behavior is the behavior on integer overflow. »
Ben oui, et alors ?
Joe Cool , dans le message <422e0118$0$27859$626a14ce@news.free.fr>, a
écrit :
Sauf si on utilise de l'arithmétique modulo la valeur maximale des
données, ce qui est permis par la norme.
Si on ne s'est pas assuré à l'avance de la taille sur laquelle on fait cette
arithmétique, c'est une erreur, c'est tout.
Je rapelle que détecter un
dépassement de capacité en C est un problème indécidable. Vous savez
résoudre de tête des problèmes indécidables, c'est trivial pour vous,
vous êtes très fort.
Je sais me placer dans les cas où c'est décidable, ce qui est beaucoup plus
simple.
« An example of undefined behavior is
the behavior on integer overflow. »
Joe Cool , dans le message <422e0118$0$27859$, a écrit :
Sauf si on utilise de l'arithmétique modulo la valeur maximale des données, ce qui est permis par la norme.
Si on ne s'est pas assuré à l'avance de la taille sur laquelle on fait cette arithmétique, c'est une erreur, c'est tout.
Je rapelle que détecter un dépassement de capacité en C est un problème indécidable. Vous savez résoudre de tête des problèmes indécidables, c'est trivial pour vous, vous êtes très fort.
Je sais me placer dans les cas où c'est décidable, ce qui est beaucoup plus simple.
« An example of undefined behavior is the behavior on integer overflow. »
Ben oui, et alors ?
Richard Delorme
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs.
Mais non.
Ce fameux "void" : c'est quoi cette abomination de la programmation ?
C'est marrant, « abomination » est le terme exact employé par Dennis Ritchie pour qualifier void.
Il n'y a aucune sémantique valable là derrière.
Void sert à expliciter quelquechose qui serait implicitement évident sans lui, c'est donc une complexité inutile. Mais si c'est le seul reproche à faire au langage C, il n'est pas bien gros.
D'ailleurs les types en C n'ont de type que le nom.
Hu ? Un type en C sert à déterminer la signification que l'on prête à une valeur.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas.
Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser.
C'est un langage qui fait confiance au programmeur, nuance !
Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ?
Cette chose n'étant pas possible, personne n'a imaginé qu'elle puisse être voulue par le programmeur.
Je pense que vous avez déjà vu du JAVA.
Oui.
Mais c'est à gerber cet emboîtement de new, cette masse colossale de classes à faire pour faire trois fois rien !
L'intérêt des classes, c'est quand on fait beaucoup de choses, et non trois fois rien, justement.
J'ose même pas imaginer la quantité de calculs inutiles faits par la machine pour gérer ces merdes.
Pas beaucoup, ce n'est pas pour ça que Java est lent.
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.
On dit une « fuite » de mémoire. Le trou de mémoire est plus cérébral comme problème. Il existe des logiciels pour les détecter. (valgrind par exemple).
En JAVA : il y a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Au prix de la barette de mémoire, ce n'est plus bien grave en effet.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
Oui, mais s'ils sont compliqués c'est qu'il font des choses compliquées.
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.
Si les langages se copient, c'est que chacun reprend ce qu'il estime de meilleur dans l'autre langage, et y ajoute ce qu'il pense manquer.
Et c'est une manière de penser qui pousse à faire des fautes.
Hu ? Je crois qu'il est à peu près admis que le nombre de fautes ne dépend pas du langage. Les artifices pour soi-disant protéger le programmeur ne fonctionne pas contre la majorité des erreurs, et seule une phase intensive de tests permet de limiter les erreurs.
Bref l'informatique ne va pas fort.
Mais si, mais si.
-- Richard
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs.
Mais non.
Ce fameux "void" : c'est quoi cette abomination de la programmation ?
C'est marrant, « abomination » est le terme exact employé par Dennis
Ritchie pour qualifier void.
Il n'y a aucune sémantique valable là derrière.
Void sert à expliciter quelquechose qui serait implicitement évident
sans lui, c'est donc une complexité inutile. Mais si c'est le seul
reproche à faire au langage C, il n'est pas bien gros.
D'ailleurs les types en C n'ont de type que le nom.
Hu ? Un type en C sert à déterminer la signification que l'on prête à
une valeur.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments.
On ne peut pas.
Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser.
C'est un langage qui fait confiance au programmeur, nuance !
Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Cette chose n'étant pas possible, personne n'a imaginé qu'elle puisse
être voulue par le programmeur.
Je pense que vous avez déjà vu du JAVA.
Oui.
Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien !
L'intérêt des classes, c'est quand on fait beaucoup de choses, et non
trois fois rien, justement.
J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes.
Pas beaucoup, ce n'est pas pour ça que Java est lent.
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.
On dit une « fuite » de mémoire. Le trou de mémoire est plus cérébral
comme problème. Il existe des logiciels pour les détecter. (valgrind par
exemple).
En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Au prix de la barette de mémoire, ce n'est plus bien grave en effet.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
Oui, mais s'ils sont compliqués c'est qu'il font des choses compliquées.
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.
Si les langages se copient, c'est que chacun reprend ce qu'il estime de
meilleur dans l'autre langage, et y ajoute ce qu'il pense manquer.
Et c'est une manière de penser qui pousse à faire des fautes.
Hu ? Je crois qu'il est à peu près admis que le nombre de fautes ne
dépend pas du langage. Les artifices pour soi-disant protéger le
programmeur ne fonctionne pas contre la majorité des erreurs, et seule
une phase intensive de tests permet de limiter les erreurs.
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs.
Mais non.
Ce fameux "void" : c'est quoi cette abomination de la programmation ?
C'est marrant, « abomination » est le terme exact employé par Dennis Ritchie pour qualifier void.
Il n'y a aucune sémantique valable là derrière.
Void sert à expliciter quelquechose qui serait implicitement évident sans lui, c'est donc une complexité inutile. Mais si c'est le seul reproche à faire au langage C, il n'est pas bien gros.
D'ailleurs les types en C n'ont de type que le nom.
Hu ? Un type en C sert à déterminer la signification que l'on prête à une valeur.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas.
Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser.
C'est un langage qui fait confiance au programmeur, nuance !
Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ?
Cette chose n'étant pas possible, personne n'a imaginé qu'elle puisse être voulue par le programmeur.
Je pense que vous avez déjà vu du JAVA.
Oui.
Mais c'est à gerber cet emboîtement de new, cette masse colossale de classes à faire pour faire trois fois rien !
L'intérêt des classes, c'est quand on fait beaucoup de choses, et non trois fois rien, justement.
J'ose même pas imaginer la quantité de calculs inutiles faits par la machine pour gérer ces merdes.
Pas beaucoup, ce n'est pas pour ça que Java est lent.
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.
On dit une « fuite » de mémoire. Le trou de mémoire est plus cérébral comme problème. Il existe des logiciels pour les détecter. (valgrind par exemple).
En JAVA : il y a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Au prix de la barette de mémoire, ce n'est plus bien grave en effet.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
Oui, mais s'ils sont compliqués c'est qu'il font des choses compliquées.
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.
Si les langages se copient, c'est que chacun reprend ce qu'il estime de meilleur dans l'autre langage, et y ajoute ce qu'il pense manquer.
Et c'est une manière de penser qui pousse à faire des fautes.
Hu ? Je crois qu'il est à peu près admis que le nombre de fautes ne dépend pas du langage. Les artifices pour soi-disant protéger le programmeur ne fonctionne pas contre la majorité des erreurs, et seule une phase intensive de tests permet de limiter les erreurs.
