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.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Izaho Ihany écrivait dans fr.comp.os.linux.debats :
On 2005-03-08, JKB wrote:
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Que vient faire Naibed dans ce troll ?
Nettoyer la console pour le prochain coup?
Coup de quoi ? ;-)
JKB ----> [ ]
JustMe
Nicolas George a exprimé avec précision :
Tom , dans le message <422f2d0f$0$27244$, a
Selon le langage la preuve est plus facile à faire ou pas.
Précisément. Une différence quantitative, pas qualitative.
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.
Tu rigoles j'espère. Pars de la description humainement lisible d'un protocole, disons TCP, et traduis en langage formel ce que ça veut dire. C'est extrêment difficile.
ASN.1 est là :-D
Nicolas George a exprimé avec précision :
Tom , dans le message <422f2d0f$0$27244$636a15ce@news.free.fr>, a
Selon le langage la preuve est plus facile à faire ou pas.
Précisément. Une différence quantitative, pas qualitative.
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.
Tu rigoles j'espère. Pars de la description humainement lisible d'un
protocole, disons TCP, et traduis en langage formel ce que ça veut dire.
C'est extrêment difficile.
Selon le langage la preuve est plus facile à faire ou pas.
Précisément. Une différence quantitative, pas qualitative.
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.
Tu rigoles j'espère. Pars de la description humainement lisible d'un protocole, disons TCP, et traduis en langage formel ce que ça veut dire. C'est extrêment difficile.
ASN.1 est là :-D
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 :
Si vous voulez _vraiment_ écrire un tel truc, ça s'écrit de façon portable comme ça :
Bien vu. je n'ai pas essayé de compiler mon truc, sinon gcc m'aurait prévenu.
c[0] = (li / ((unsigned long long) 0x100000000000000)) % 0x100;
Non, c'est faux, il faut écrire « 0x100000000000000LL) » (ou même ULL, en fait, c'est mieux).
Le cast revient à la même chose sur tous les compilateurs que je connais.
Un bon programmeur C n'existe pas
J'en ai rencontré.
Ah bon ?!... Pas moi (et pourtant, moi-même, je me targue d'écrire du C correctement et portable).
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 <slrnd2ublj.ugg.knatschke@rayleigh.systella.fr>, a
écrit :
Si vous voulez _vraiment_ écrire un tel truc, ça s'écrit de façon
portable comme ça :
Bien vu. je n'ai pas essayé de compiler mon truc, sinon gcc m'aurait
prévenu.
c[0] = (li / ((unsigned long long) 0x100000000000000)) % 0x100;
Non, c'est faux, il faut écrire « 0x100000000000000LL) » (ou même ULL, en
fait, c'est mieux).
Le cast revient à la même chose sur tous les compilateurs que je
connais.
Un bon programmeur C n'existe pas
J'en ai rencontré.
Ah bon ?!... Pas moi (et pourtant, moi-même, je me targue d'écrire du C
correctement et portable).
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 :
Si vous voulez _vraiment_ écrire un tel truc, ça s'écrit de façon portable comme ça :
Bien vu. je n'ai pas essayé de compiler mon truc, sinon gcc m'aurait prévenu.
c[0] = (li / ((unsigned long long) 0x100000000000000)) % 0x100;
Non, c'est faux, il faut écrire « 0x100000000000000LL) » (ou même ULL, en fait, c'est mieux).
Le cast revient à la même chose sur tous les compilateurs que je connais.
Un bon programmeur C n'existe pas
J'en ai rencontré.
Ah bon ?!... Pas moi (et pourtant, moi-même, je me targue d'écrire du C correctement et portable).
JKB
Joe Cool
Joe Cool , dans le message <422f3883$0$15677$, a
Vous avez beau critiquer la mienne (en fait vous la rejettez sans justification), au moins elle veut dire quelque chose.
Elle veut dire quelque chose qui n'est pas une notion intéressante. Savoir ce qui est intéressant ou pas comme notion n'est pas justifiable rigoureusement, mais on peut le voir en pratique. Ta définition de portabilité donne un thread ou deux gus se ridiculisent sur fcold. « Ma » définition de portabilité donne un noyau Linux qui tourne sur vingt architectures différentes en tirant partie de leurs performances. C'est vite vu.
Essayez au moins de comprendre la différence enre « portable » et « porté ». Puis tentez ce vous rendre compte que toutes ces implémentations n'ont que le nom « Linux » en commun. Enfin vous arriverez peut-être à saisir que la portabilité n'a rien à voir avec la quantité d'implémentation qui se réclament d'une norme.
Vous voulez à tout prix prouver que Linux est portable, mais c'est faux. Linux n'est pas portable, il est porté par beaucoup de gens, il n'a de valeur que la quantité de gens qui le supporte.
-- Joe Cool
Joe Cool , dans le message <422f3883$0$15677$626a14ce@news.free.fr>, a
Vous avez
beau critiquer la mienne (en fait vous la rejettez sans justification),
au moins elle veut dire quelque chose.
Elle veut dire quelque chose qui n'est pas une notion intéressante. Savoir
ce qui est intéressant ou pas comme notion n'est pas justifiable
rigoureusement, mais on peut le voir en pratique. Ta définition de
portabilité donne un thread ou deux gus se ridiculisent sur fcold. « Ma »
définition de portabilité donne un noyau Linux qui tourne sur vingt
architectures différentes en tirant partie de leurs performances. C'est vite
vu.
Essayez au moins de comprendre la différence enre « portable » et «
porté ». Puis tentez ce vous rendre compte que toutes ces
implémentations n'ont que le nom « Linux » en commun. Enfin vous
arriverez peut-être à saisir que la portabilité n'a rien à voir avec la
quantité d'implémentation qui se réclament d'une norme.
Vous voulez à tout prix prouver que Linux est portable, mais c'est faux.
Linux n'est pas portable, il est porté par beaucoup de gens, il n'a de
valeur que la quantité de gens qui le supporte.
Vous avez beau critiquer la mienne (en fait vous la rejettez sans justification), au moins elle veut dire quelque chose.
Elle veut dire quelque chose qui n'est pas une notion intéressante. Savoir ce qui est intéressant ou pas comme notion n'est pas justifiable rigoureusement, mais on peut le voir en pratique. Ta définition de portabilité donne un thread ou deux gus se ridiculisent sur fcold. « Ma » définition de portabilité donne un noyau Linux qui tourne sur vingt architectures différentes en tirant partie de leurs performances. C'est vite vu.
Essayez au moins de comprendre la différence enre « portable » et « porté ». Puis tentez ce vous rendre compte que toutes ces implémentations n'ont que le nom « Linux » en commun. Enfin vous arriverez peut-être à saisir que la portabilité n'a rien à voir avec la quantité d'implémentation qui se réclament d'une norme.
Vous voulez à tout prix prouver que Linux est portable, mais c'est faux. Linux n'est pas portable, il est porté par beaucoup de gens, il n'a de valeur que la quantité de gens qui le supporte.
-- Joe Cool
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
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
Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
Si un programme dépend de la structure de l'entier, c'est que le programmeur s'est chié dessus.
Non. Réfléchissez un peu (sur les architectures "octet", rien que les problèmes de petit/grand boutistes). Le nombre de fois où j'ai vu des trucs du genre :
long long li; // comprendre sur 64 bits unsigned char c[8];
c = li;
Et pan, une balle dans le pied !
Cet exemple ne compile pas (c n'est pas une lvalue).
Oui, bon, je me suis gouré et j'ai donné l'exemple de tête, mais vous aviez tous compris.
Le problème de l'ordre des octets ne se pose que pour la lecture/écriture vers des entrées/sorties qui impose un ordre précis.
Et par exemple lors du passage de tableaux à plusieurs dimensions entre le C et au hasard le Fortran.
- Le problème se pose dans tous les langages. - C'est trivial à résoudre en C :
c[0] = (li & 255); c[1] = ((li >> 8) & 255); etc.
Oui, c'est trivial. Et absurde parce que la machine en question travaille peut-être sur des mots de quatorze bits.
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Richard Delorme écrivait dans fr.comp.os.linux.debats :
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 <slrnd2tsqs.u5h.knatschke@rayleigh.systella.fr>, a
Au passage, ce truc
ne vous garantit jamais la structure même de l'entier.
Si un programme dépend de la structure de l'entier, c'est que le programmeur
s'est chié dessus.
Non. Réfléchissez un peu (sur les architectures "octet", rien que
les problèmes de petit/grand boutistes). Le nombre de fois où j'ai
vu des trucs du genre :
long long li; // comprendre sur 64 bits
unsigned char c[8];
c = li;
Et pan, une balle dans le pied !
Cet exemple ne compile pas (c n'est pas une lvalue).
Oui, bon, je me suis gouré et j'ai donné l'exemple de tête, mais
vous aviez tous compris.
Le problème de l'ordre des octets ne se pose que pour la
lecture/écriture vers des entrées/sorties qui impose un ordre précis.
Et par exemple lors du passage de tableaux à plusieurs dimensions
entre le C et au hasard le Fortran.
- Le problème se pose dans tous les langages.
- C'est trivial à résoudre en C :
c[0] = (li & 255);
c[1] = ((li >> 8) & 255);
etc.
Oui, c'est trivial. Et absurde parce que la machine en question
travaille peut-être sur des mots de quatorze bits.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
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
Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
Si un programme dépend de la structure de l'entier, c'est que le programmeur s'est chié dessus.
Non. Réfléchissez un peu (sur les architectures "octet", rien que les problèmes de petit/grand boutistes). Le nombre de fois où j'ai vu des trucs du genre :
long long li; // comprendre sur 64 bits unsigned char c[8];
c = li;
Et pan, une balle dans le pied !
Cet exemple ne compile pas (c n'est pas une lvalue).
Oui, bon, je me suis gouré et j'ai donné l'exemple de tête, mais vous aviez tous compris.
Le problème de l'ordre des octets ne se pose que pour la lecture/écriture vers des entrées/sorties qui impose un ordre précis.
Et par exemple lors du passage de tableaux à plusieurs dimensions entre le C et au hasard le Fortran.
- Le problème se pose dans tous les langages. - C'est trivial à résoudre en C :
c[0] = (li & 255); c[1] = ((li >> 8) & 255); etc.
Oui, c'est trivial. Et absurde parce que la machine en question travaille peut-être sur des mots de quatorze bits.
JKB
Joe Cool
1 est premier
Non, 1 n'est pas premier, et il manque 2 qui est premier.
3 est premier 5 est premier 7 est premier donc tous les entiers impairs sont premiers
2 n'est pas impair.
-- Joe Cool
1 est premier
Non, 1 n'est pas premier, et il manque 2 qui est premier.
3 est premier
5 est premier
7 est premier
donc tous les entiers impairs sont premiers
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Stephane TOUGARD écrivait dans fr.comp.os.linux.debats :
Benjamin FRANCOIS wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
Je propose le Cobol.
Fortran ?
JKB, fortraneux irréductible frappant les maniaques du C qui osent faire en C du calcul scientifique avec le K&R
C'est après avoir essayé Fortran, que Thompson a créé le langage B, qui allait donner ensuite le C : http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
« After a rapidly scuttled attempt at Fortran, he created instead a language of his own, which he called B. »
Et alors ? Le Fortran IV (ou 66) n'a rien à voir avec la norme 95. Où veux-tu en venir ?
JKB
Joe Cool
Joe Cool wrote:
N'importe quel assembleur est plus portable et plus sûr que le C.
Comment portes-tu la routine suivante de x86 vers HC12 ?
Avec un compilateur. Voir les différents messages traitant du sujet.
suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits. C'est risible. Des langages meilleurs que le C on en trouve à la pelle, plus puissants, plus sûrs, pous simples, etc.
Des noms ! Des noms ! (mais pas : C++ c'est mieux mais c'est de la daube, Java c'est pas mal mais ca pue aussi, VB c'est super mais c'est merdique, etc.)
J'ai pas de nom en tête, mais vous pouvez aller consulter les archives de la liste de discution Debian x86_64.
Que préconises-tu comme langage super génial qui a comme caractéristiques : - d'être portable sur toute architecture passée, présente et future - d'être puissant (1 ligne de code permet de créer son OS) - d'être sûr (0 bug garanti quel que soit le programmeur) - d'être simple (1/2 journée d'apprentissage devrait suffire) - d'être rapide - d'être adapté à tout type d'application (OS, script, IA, etc.)
MultiDeskOS
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.
Hmm, on sent celui qui a eut une mauvaise note en TP de C et qui n'a jamais pu l'encaisser :-)
Damned ! Je suis démasqué !
Plus sérieusement, le C a des inconvénients, mais il a aussi beaucoup d'avantages.
N'importe qui connaissant l'état de l'art en informatique sait que le C est un langage préhistorique, et je constate avec amertume que la plupart des ingénieurs informaticiens ne maitrisent pas les bases de leur discipline.
Que tu n'aimes pas le C, pourquoi pas, mais pourquoi vouloir absolument insulter des "millions" de programmeurs ?
Je n'ai insulté personne, à part le langage C. Tant pis pour ceux qui prennent mes critiques pour des attaques personnelles. Ils ne sont pas dispensés d'argumenter.
Surtout que dans le tas je suis sûr qu'il y a une tripotée qui ont réalisé des programmes que tu serais incapable de créer.
Ceci est un argument ad hominem, donc hors propos, et mesquin de surcroit : vous ne me connaissez pas, vous ne saurez rien de moi, vous n'aurez que mes arguments.
Honnétement, c'est un troll ?
Pourquoi ? Parce que je ne suis pas politiquement correct ? Vous n'avez pas de chance, je ne fais pas de politique.
-- Joe Cool
Joe Cool wrote:
N'importe quel assembleur est plus portable et plus sûr que le C.
Comment portes-tu la routine suivante de x86 vers HC12 ?
Avec un compilateur. Voir les différents messages traitant du sujet.
suffit d'admirer les contorsions des gars charger du portage des
applis C en 64 bits. C'est risible. Des langages meilleurs que le C on
en trouve à la pelle, plus puissants, plus sûrs, pous simples, etc.
Des noms ! Des noms !
(mais pas : C++ c'est mieux mais c'est de la daube, Java c'est pas mal
mais ca pue aussi, VB c'est super mais c'est merdique, etc.)
J'ai pas de nom en tête, mais vous pouvez aller consulter les archives
de la liste de discution Debian x86_64.
Que préconises-tu comme langage super génial qui a comme caractéristiques :
- d'être portable sur toute architecture passée, présente et future
- d'être puissant (1 ligne de code permet de créer son OS)
- d'être sûr (0 bug garanti quel que soit le programmeur)
- d'être simple (1/2 journée d'apprentissage devrait suffire)
- d'être rapide
- d'être adapté à tout type d'application (OS, script, IA, etc.)
MultiDeskOS
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.
Hmm, on sent celui qui a eut une mauvaise note en TP de C et qui n'a
jamais pu l'encaisser :-)
Damned ! Je suis démasqué !
Plus sérieusement, le C a des inconvénients, mais il a aussi beaucoup
d'avantages.
N'importe qui connaissant l'état de l'art en informatique sait que le C
est un langage préhistorique, et je constate avec amertume que la
plupart des ingénieurs informaticiens ne maitrisent pas les bases de
leur discipline.
Que tu n'aimes pas le C, pourquoi pas, mais pourquoi vouloir absolument
insulter des "millions" de programmeurs ?
Je n'ai insulté personne, à part le langage C. Tant pis pour ceux qui
prennent mes critiques pour des attaques personnelles. Ils ne sont pas
dispensés d'argumenter.
Surtout que dans le tas je
suis sûr qu'il y a une tripotée qui ont réalisé des programmes que tu
serais incapable de créer.
Ceci est un argument ad hominem, donc hors propos, et mesquin de
surcroit : vous ne me connaissez pas, vous ne saurez rien de moi, vous
n'aurez que mes arguments.
Honnétement, c'est un troll ?
Pourquoi ? Parce que je ne suis pas politiquement correct ? Vous n'avez
pas de chance, je ne fais pas de politique.
N'importe quel assembleur est plus portable et plus sûr que le C.
Comment portes-tu la routine suivante de x86 vers HC12 ?
Avec un compilateur. Voir les différents messages traitant du sujet.
suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits. C'est risible. Des langages meilleurs que le C on en trouve à la pelle, plus puissants, plus sûrs, pous simples, etc.
Des noms ! Des noms ! (mais pas : C++ c'est mieux mais c'est de la daube, Java c'est pas mal mais ca pue aussi, VB c'est super mais c'est merdique, etc.)
J'ai pas de nom en tête, mais vous pouvez aller consulter les archives de la liste de discution Debian x86_64.
Que préconises-tu comme langage super génial qui a comme caractéristiques : - d'être portable sur toute architecture passée, présente et future - d'être puissant (1 ligne de code permet de créer son OS) - d'être sûr (0 bug garanti quel que soit le programmeur) - d'être simple (1/2 journée d'apprentissage devrait suffire) - d'être rapide - d'être adapté à tout type d'application (OS, script, IA, etc.)
MultiDeskOS
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.
Hmm, on sent celui qui a eut une mauvaise note en TP de C et qui n'a jamais pu l'encaisser :-)
Damned ! Je suis démasqué !
Plus sérieusement, le C a des inconvénients, mais il a aussi beaucoup d'avantages.
N'importe qui connaissant l'état de l'art en informatique sait que le C est un langage préhistorique, et je constate avec amertume que la plupart des ingénieurs informaticiens ne maitrisent pas les bases de leur discipline.
Que tu n'aimes pas le C, pourquoi pas, mais pourquoi vouloir absolument insulter des "millions" de programmeurs ?
Je n'ai insulté personne, à part le langage C. Tant pis pour ceux qui prennent mes critiques pour des attaques personnelles. Ils ne sont pas dispensés d'argumenter.
Surtout que dans le tas je suis sûr qu'il y a une tripotée qui ont réalisé des programmes que tu serais incapable de créer.
Ceci est un argument ad hominem, donc hors propos, et mesquin de surcroit : vous ne me connaissez pas, vous ne saurez rien de moi, vous n'aurez que mes arguments.
Honnétement, c'est un troll ?
Pourquoi ? Parce que je ne suis pas politiquement correct ? Vous n'avez pas de chance, je ne fais pas de politique.
-- Joe Cool
Nicolas George
JustMe , dans le message , a écrit :
Cette affirmation est loin d'etre evidente, tres tres loin...
Pour moi, au contraire, c'est complètement évident : quand j'écris un programme, je sais ce qu'il fait. Et par « savoir ce qu'il fait », je veux justement dire que j'entrevois une preuve de ce qu'il fait.
Dit autrement : les cas indécidables sont des situations artificielles, conçues précisément pour être indécidables (avec un argument diagonal par exemple). Les situations réellement utiles utilisent des constructions bien plus simples, des boucles (ou des récursions bornées).
JustMe , dans le message <mn.4c937d5329430a23.15643@merci.beaucoup>, a
écrit :
Cette affirmation est loin d'etre evidente, tres tres loin...
Pour moi, au contraire, c'est complètement évident : quand j'écris un
programme, je sais ce qu'il fait. Et par « savoir ce qu'il fait », je veux
justement dire que j'entrevois une preuve de ce qu'il fait.
Dit autrement : les cas indécidables sont des situations artificielles,
conçues précisément pour être indécidables (avec un argument diagonal par
exemple). Les situations réellement utiles utilisent des constructions bien
plus simples, des boucles (ou des récursions bornées).
Cette affirmation est loin d'etre evidente, tres tres loin...
Pour moi, au contraire, c'est complètement évident : quand j'écris un programme, je sais ce qu'il fait. Et par « savoir ce qu'il fait », je veux justement dire que j'entrevois une preuve de ce qu'il fait.
Dit autrement : les cas indécidables sont des situations artificielles, conçues précisément pour être indécidables (avec un argument diagonal par exemple). Les situations réellement utiles utilisent des constructions bien plus simples, des boucles (ou des récursions bornées).
