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.
Oh bah, j'ai les idées plutôt claires sur ce qu'ils racontent (je suis payé pour ça après tout), c'est juste que je trouve le "débat" absolument pathétique.
C'est marrant : ici tout le monde est payé pour savoir plein de choses. Y'en a qui sont payés pour comprendre des choses ?
Y'en a qui sont payés pour avoir autre chose qu'une vision dogmatique et prétentieuse soutenue par aucun argument autre que "vous êtes tous des dinosaures doublés de cons". Mais au fond je ne m'en fais pas pour vous, vous avez découvert caml lundi, hier vous postiez ici au sujet du C, aujourd'hui vous avez passé votre temps à insulter un nombre incalculable de gens, demain en retournant à votre travail vous retomberez sans doute sur Terre.
-- Irvin
On 2005-03-09, Tom <tom@tom.com> wrote:
Oh bah, j'ai les idées plutôt claires sur ce qu'ils racontent (je suis
payé pour ça après tout), c'est juste que je trouve le "débat" absolument
pathétique.
C'est marrant : ici tout le monde est payé pour savoir plein de choses.
Y'en a qui sont payés pour comprendre des choses ?
Y'en a qui sont payés pour avoir autre chose qu'une vision dogmatique et
prétentieuse soutenue par aucun argument autre que "vous êtes tous des
dinosaures doublés de cons".
Mais au fond je ne m'en fais pas pour vous, vous avez découvert caml
lundi, hier vous postiez ici au sujet du C, aujourd'hui vous avez
passé votre temps à insulter un nombre incalculable de gens, demain
en retournant à votre travail vous retomberez sans doute sur Terre.
Oh bah, j'ai les idées plutôt claires sur ce qu'ils racontent (je suis payé pour ça après tout), c'est juste que je trouve le "débat" absolument pathétique.
C'est marrant : ici tout le monde est payé pour savoir plein de choses. Y'en a qui sont payés pour comprendre des choses ?
Y'en a qui sont payés pour avoir autre chose qu'une vision dogmatique et prétentieuse soutenue par aucun argument autre que "vous êtes tous des dinosaures doublés de cons". Mais au fond je ne m'en fais pas pour vous, vous avez découvert caml lundi, hier vous postiez ici au sujet du C, aujourd'hui vous avez passé votre temps à insulter un nombre incalculable de gens, demain en retournant à votre travail vous retomberez sans doute sur Terre.
-- Irvin
Eric Jacoboni
Richard Delorme writes:
Non, 1 n'est pas premier, et il manque 2 qui est premier.
Les avis là-dessus sont partagés...
-- Éric Jacoboni, né il y a 1413832817 secondes
Richard Delorme <abulmo@nospam.fr> writes:
Non, 1 n'est pas premier, et il manque 2 qui est premier.
Non, 1 n'est pas premier, et il manque 2 qui est premier.
Les avis là-dessus sont partagés...
-- Éric Jacoboni, né il y a 1413832817 secondes
Thierry
Joe Cool wrote:
[snip]
N'importe quel assembleur est plus portable et plus sûr que le C. Il
Comment portes-tu la routine suivante de x86 vers HC12 ?
.text
.globl essai
essai: movl %eax,%ebx ret
Tiens, d'ailleurs, ça donne quoi comme résultat ? Ah bon, ça dépend de la valeur de %eax ? Mince, alors, ce n'est pas très déterministe. Et puis c'est dans quel sens déjà : movl %eax,%ebx ou mov ebx,eax ? Ah bon, ça dépend de l'assembleur ? Mince alors, pas terrible ...
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.)
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.)
(tu n'as pas le droit de répondre 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 :-)
Plus sérieusement, le C a des inconvénients, mais il a aussi beaucoup d'avantages.
Que tu n'aimes pas le C, pourquoi pas, mais pourquoi vouloir absolument insulter des "millions" de programmeurs ? 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.
Honnétement, c'est un troll ?
-- Thierry
Joe Cool wrote:
[snip]
N'importe quel assembleur est plus portable et plus sûr que le C. Il
Comment portes-tu la routine suivante de x86 vers HC12 ?
.text
.globl essai
essai:
movl %eax,%ebx
ret
Tiens, d'ailleurs, ça donne quoi comme résultat ?
Ah bon, ça dépend de la valeur de %eax ?
Mince, alors, ce n'est pas très déterministe.
Et puis c'est dans quel sens déjà :
movl %eax,%ebx
ou
mov ebx,eax
?
Ah bon, ça dépend de l'assembleur ?
Mince alors, pas terrible ...
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.)
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.)
(tu n'as pas le droit de répondre 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 :-)
Plus sérieusement, le C a des inconvénients, mais il a aussi beaucoup
d'avantages.
Que tu n'aimes pas le C, pourquoi pas, mais pourquoi vouloir absolument
insulter des "millions" de programmeurs ? 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.
N'importe quel assembleur est plus portable et plus sûr que le C. Il
Comment portes-tu la routine suivante de x86 vers HC12 ?
.text
.globl essai
essai: movl %eax,%ebx ret
Tiens, d'ailleurs, ça donne quoi comme résultat ? Ah bon, ça dépend de la valeur de %eax ? Mince, alors, ce n'est pas très déterministe. Et puis c'est dans quel sens déjà : movl %eax,%ebx ou mov ebx,eax ? Ah bon, ça dépend de l'assembleur ? Mince alors, pas terrible ...
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.)
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.)
(tu n'as pas le droit de répondre 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 :-)
Plus sérieusement, le C a des inconvénients, mais il a aussi beaucoup d'avantages.
Que tu n'aimes pas le C, pourquoi pas, mais pourquoi vouloir absolument insulter des "millions" de programmeurs ? 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.
Honnétement, c'est un troll ?
-- Thierry
Irvin Probst
On 2005-03-09, Tom wrote:
Et ceci quelque soit le langage. La seule manière d'éviter un maximum d'erreur est de tester abondamment.
Permettez moi de vomir. Beuaaaaaaaaaaa Ah ça va mieux. Non mais. Tester un programme pour voir si il est valide. C'est bien digne d'un programmeur en C.
Bon puisque vous êtes si fort expliquez moi quelque-chose. Je connais au moins quatre thésards qui sont/étaient dans le labo ou je travaille et qui planchaient justement sur la manière de prouver qu'un code est correct. Alors dites moi, vous avez trouvé une méthode révolutionnaire pour prouver le bon fonctionnement de tout type de code possible et imaginable et nous sommes tous des cons comme vous le prétendez ou vous êtes un guignol qui passe le temps entre deux TDs de caml ?
-- Irvin
On 2005-03-09, Tom <tom@tom.com> wrote:
Et ceci quelque soit le langage. La seule manière d'éviter un maximum
d'erreur est de tester abondamment.
Permettez moi de vomir. Beuaaaaaaaaaaa
Ah ça va mieux. Non mais. Tester un programme pour voir si il est
valide. C'est bien digne d'un programmeur en C.
Bon puisque vous êtes si fort expliquez moi quelque-chose. Je connais au
moins quatre thésards qui sont/étaient dans le labo ou je travaille et
qui planchaient justement sur la manière de prouver qu'un code est
correct. Alors dites moi, vous avez trouvé une méthode révolutionnaire
pour prouver le bon fonctionnement de tout type de code possible et
imaginable et nous sommes tous des cons comme vous le prétendez ou vous
êtes un guignol qui passe le temps entre deux TDs de caml ?
Et ceci quelque soit le langage. La seule manière d'éviter un maximum d'erreur est de tester abondamment.
Permettez moi de vomir. Beuaaaaaaaaaaa Ah ça va mieux. Non mais. Tester un programme pour voir si il est valide. C'est bien digne d'un programmeur en C.
Bon puisque vous êtes si fort expliquez moi quelque-chose. Je connais au moins quatre thésards qui sont/étaient dans le labo ou je travaille et qui planchaient justement sur la manière de prouver qu'un code est correct. Alors dites moi, vous avez trouvé une méthode révolutionnaire pour prouver le bon fonctionnement de tout type de code possible et imaginable et nous sommes tous des cons comme vous le prétendez ou vous êtes un guignol qui passe le temps entre deux TDs de caml ?
-- Irvin
Blaise Potard
Joe Cool wrote:
Joe Cool , dans le message <422f2845$0$18054$, a
Je suis désolé mais cette erreur vient de votre système.
Non, cette erreur est tout à fait normale, c'est juste toi qui dis des conneries sur Caml comme sur le C.
Je voudrais bien savoir pourquoi ce programme qui est sensé planter me renvoie une gentille exception Stack_overflow aussi bien en version code-octet qu'en version native.
Sur les deux machines que j'ai devant moi, sur l'une ça fait ce que tu dis, sur l'autre ça me fait "incident de segmentation" (en non-opt ou en interprété ça me fait une Stack_overflow). C'est de toute évidence uniquement un problème du compilo (sur archi x86-64 sur la machine qui plante chez moi).
Joe Cool wrote:
Joe Cool , dans le message <422f2845$0$18054$636a15ce@news.free.fr>, a
Je suis désolé mais cette erreur vient de votre système.
Non, cette erreur est tout à fait normale, c'est juste toi qui dis des
conneries sur Caml comme sur le C.
Je voudrais bien savoir pourquoi ce programme qui est sensé planter me
renvoie une gentille exception Stack_overflow aussi bien en version
code-octet qu'en version native.
Sur les deux machines que j'ai devant moi, sur l'une ça fait ce que tu
dis, sur l'autre ça me fait "incident de segmentation" (en non-opt ou en
interprété ça me fait une Stack_overflow). C'est de toute évidence
uniquement un problème du compilo (sur archi x86-64 sur la machine qui
plante chez moi).
Je suis désolé mais cette erreur vient de votre système.
Non, cette erreur est tout à fait normale, c'est juste toi qui dis des conneries sur Caml comme sur le C.
Je voudrais bien savoir pourquoi ce programme qui est sensé planter me renvoie une gentille exception Stack_overflow aussi bien en version code-octet qu'en version native.
Sur les deux machines que j'ai devant moi, sur l'une ça fait ce que tu dis, sur l'autre ça me fait "incident de segmentation" (en non-opt ou en interprété ça me fait une Stack_overflow). C'est de toute évidence uniquement un problème du compilo (sur archi x86-64 sur la machine qui plante chez moi).
Joe Cool
Joe Cool wrote:
La machine vérifie le type et le devine en observant la manière dont le programme utilise ses données. On évite les erreurs de typage dues au programmeur et on certifie que le programme ne peut en aucun cas générer d'erreur d'exécution : un programme typé statiquement ne peut pas planter.
On ne certifie certainement pas cela.
Ben si.
Une récursion mal écrite et ton programme plante.
Non, il lève une exception, et on ne peut pas lui en demander plus car la complexité en espace d'un programme caml n'est pas calculable en général.
Et ne me dit pas que c'est du à la limitation des ressources de la machine, de toute façon un tel programme va être faux, donc qu'il plante ce n'est pas plus mal.
Il ne plante pas car le programme sait agir en conséquence.
D'autre part, là tu parles des avantage de l'inférence de type et du typage fort, pas du typage statique. Un bon programme en C est typé statiquement (avec un typage faible, certes).
Ce n'est pas du typage mais de l'annotation de code.
Tu vois, je suis tout à fait d'accord que pour beaucoup de choses le langage caml est très largement supérieur au C, mais pas à cause du fait que le typage soit statique. Le typage statique des objets est un avantage par rapport à d'autres langages OO par contre ; mais c'est un autre débat (d'ailleurs, maintenant que j'y pense, ce débat n'a pas grand chose à voir avec linux, mais bon).
La gestion des types en caml est supérieure à celle du C car sa cohérence est prouvée.
Non car le système de type du C est incohérent. Le système de typage de caml génère pour chaque programme la preuve qu'il utilise ses données de manière cohérente : il génère la preuve que le programme ne peut pas planter. Du moins si il plante, ce n'est pas de sa faute mais celle du système d'exploitation ou du matériel.
Ou surtout du programmeur qui programme comme un manche...
Il n'y a pas de bon programmeur. Savoir si un programmeur est bon est un problème indécidable. Si un programmeur se croit sans faille, je lui conseille de jeter un coup d'oeil au second théorème de Gödel.
Le système de type du C n'est pas incohérent. Le typage est faible, il y a des conversions implicites qui sont parfois gênantes, mais c'est tout. Évidemment, la permissivité du C permet de faire un peu n'importe quoi sans nécessairement le signaler, et du coup on ne peut effectivement pas garantir la cohérence du typage des données (mais ça, dès que l'on utilise des pointeurs, ce n'est de toute façon pas possible).
« Le système de type du C n'est pas incohérent. »
« on ne peut effectivement pas garantir la cohérence du typage des données »
Bizarre.
Honnêtement, pour quelqu'un qui programme depuis longtemps, les erreurs de typage sont assez rares. Par contre, les dépassements de mémoire ça arrive bien souvent, mais ça, aucun compilateur n'est encore capable de le détecter,
Ni maintenant ni jamais.
et ça n'a strictement rien à voir avec le typage.
Certes, mais ce n'est pas considéré comme un bug, car on ne peut pas forcer un programme à utiliser moins de mémoire qu'il en a besoin. Cela dépend de la machine, pas du langage.
La plupart des erreurs, c'est encore au niveau des calculs que l'on effectue qu'elles se situent (oubli d'appeler une sous-fonction, erreur d'indice,...).
Ce sont des erreurs algorithmiques, pas des bugs.
Évidemment, si tu n'as qu'une confiance relative dans les capacités de ton programmeur, ne le laisse surtout pas programmer en C, c'est la meilleur chance d'avoir un truc illisible et non portable, en plus de buggué.
Je suis mon propre programmeur et je ne me fait pas confiance car je me sait faillible. Tout Homme est faillible.
-- Joe Cool
Joe Cool wrote:
La machine vérifie le type et le devine en observant la manière dont
le programme utilise ses données. On évite les erreurs de typage dues
au programmeur et on certifie que le programme ne peut en aucun cas
générer d'erreur d'exécution : un programme typé statiquement ne peut
pas planter.
On ne certifie certainement pas cela.
Ben si.
Une récursion mal écrite et ton programme plante.
Non, il lève une exception, et on ne peut pas lui en demander plus car
la complexité en espace d'un programme caml n'est pas calculable en général.
Et ne me dit pas que c'est du à la limitation des
ressources de la machine, de toute façon un tel programme va être faux,
donc qu'il plante ce n'est pas plus mal.
Il ne plante pas car le programme sait agir en conséquence.
D'autre part, là tu parles des
avantage de l'inférence de type et du typage fort, pas du typage
statique. Un bon programme en C est typé statiquement (avec un typage
faible, certes).
Ce n'est pas du typage mais de l'annotation de code.
Tu vois, je suis tout à fait d'accord que pour beaucoup
de choses le langage caml est très largement supérieur au C, mais pas à
cause du fait que le typage soit statique. Le typage statique des objets
est un avantage par rapport à d'autres langages OO par contre ; mais
c'est un autre débat (d'ailleurs, maintenant que j'y pense, ce débat n'a
pas grand chose à voir avec linux, mais bon).
La gestion des types en caml est supérieure à celle du C car sa
cohérence est prouvée.
Non car le système de type du C est incohérent. Le système de typage
de caml génère pour chaque programme la preuve qu'il utilise ses
données de manière cohérente : il génère la preuve que le programme ne
peut pas planter. Du moins si il plante, ce n'est pas de sa faute mais
celle du système d'exploitation ou du matériel.
Ou surtout du programmeur qui programme comme un manche...
Il n'y a pas de bon programmeur. Savoir si un programmeur est bon est un
problème indécidable. Si un programmeur se croit sans faille, je lui
conseille de jeter un coup d'oeil au second théorème de Gödel.
Le système de type du C n'est pas incohérent. Le typage est faible, il y
a des conversions implicites qui sont parfois gênantes, mais c'est tout.
Évidemment, la permissivité du C permet de faire un peu n'importe quoi
sans nécessairement le signaler, et du coup on ne peut effectivement pas
garantir la cohérence du typage des données (mais ça, dès que l'on
utilise des pointeurs, ce n'est de toute façon pas possible).
« Le système de type du C n'est pas incohérent. »
« on ne peut effectivement pas garantir la cohérence du typage des données »
Bizarre.
Honnêtement, pour quelqu'un qui programme depuis longtemps, les erreurs
de typage sont assez rares. Par contre, les dépassements
de mémoire ça arrive bien souvent, mais ça, aucun compilateur n'est
encore capable de le détecter,
Ni maintenant ni jamais.
et ça n'a strictement rien à voir avec le typage.
Certes, mais ce n'est pas considéré comme un bug, car on ne peut pas
forcer un programme à utiliser moins de mémoire qu'il en a besoin. Cela
dépend de la machine, pas du langage.
La plupart des erreurs, c'est encore au niveau des calculs que
l'on effectue qu'elles se situent (oubli d'appeler une sous-fonction,
erreur d'indice,...).
Ce sont des erreurs algorithmiques, pas des bugs.
Évidemment, si tu n'as qu'une confiance relative
dans les capacités de ton programmeur, ne le laisse surtout pas
programmer en C, c'est la meilleur chance d'avoir un truc illisible et
non portable, en plus de buggué.
Je suis mon propre programmeur et je ne me fait pas confiance car je me
sait faillible. Tout Homme est faillible.
La machine vérifie le type et le devine en observant la manière dont le programme utilise ses données. On évite les erreurs de typage dues au programmeur et on certifie que le programme ne peut en aucun cas générer d'erreur d'exécution : un programme typé statiquement ne peut pas planter.
On ne certifie certainement pas cela.
Ben si.
Une récursion mal écrite et ton programme plante.
Non, il lève une exception, et on ne peut pas lui en demander plus car la complexité en espace d'un programme caml n'est pas calculable en général.
Et ne me dit pas que c'est du à la limitation des ressources de la machine, de toute façon un tel programme va être faux, donc qu'il plante ce n'est pas plus mal.
Il ne plante pas car le programme sait agir en conséquence.
D'autre part, là tu parles des avantage de l'inférence de type et du typage fort, pas du typage statique. Un bon programme en C est typé statiquement (avec un typage faible, certes).
Ce n'est pas du typage mais de l'annotation de code.
Tu vois, je suis tout à fait d'accord que pour beaucoup de choses le langage caml est très largement supérieur au C, mais pas à cause du fait que le typage soit statique. Le typage statique des objets est un avantage par rapport à d'autres langages OO par contre ; mais c'est un autre débat (d'ailleurs, maintenant que j'y pense, ce débat n'a pas grand chose à voir avec linux, mais bon).
La gestion des types en caml est supérieure à celle du C car sa cohérence est prouvée.
Non car le système de type du C est incohérent. Le système de typage de caml génère pour chaque programme la preuve qu'il utilise ses données de manière cohérente : il génère la preuve que le programme ne peut pas planter. Du moins si il plante, ce n'est pas de sa faute mais celle du système d'exploitation ou du matériel.
Ou surtout du programmeur qui programme comme un manche...
Il n'y a pas de bon programmeur. Savoir si un programmeur est bon est un problème indécidable. Si un programmeur se croit sans faille, je lui conseille de jeter un coup d'oeil au second théorème de Gödel.
Le système de type du C n'est pas incohérent. Le typage est faible, il y a des conversions implicites qui sont parfois gênantes, mais c'est tout. Évidemment, la permissivité du C permet de faire un peu n'importe quoi sans nécessairement le signaler, et du coup on ne peut effectivement pas garantir la cohérence du typage des données (mais ça, dès que l'on utilise des pointeurs, ce n'est de toute façon pas possible).
« Le système de type du C n'est pas incohérent. »
« on ne peut effectivement pas garantir la cohérence du typage des données »
Bizarre.
Honnêtement, pour quelqu'un qui programme depuis longtemps, les erreurs de typage sont assez rares. Par contre, les dépassements de mémoire ça arrive bien souvent, mais ça, aucun compilateur n'est encore capable de le détecter,
Ni maintenant ni jamais.
et ça n'a strictement rien à voir avec le typage.
Certes, mais ce n'est pas considéré comme un bug, car on ne peut pas forcer un programme à utiliser moins de mémoire qu'il en a besoin. Cela dépend de la machine, pas du langage.
La plupart des erreurs, c'est encore au niveau des calculs que l'on effectue qu'elles se situent (oubli d'appeler une sous-fonction, erreur d'indice,...).
Ce sont des erreurs algorithmiques, pas des bugs.
Évidemment, si tu n'as qu'une confiance relative dans les capacités de ton programmeur, ne le laisse surtout pas programmer en C, c'est la meilleur chance d'avoir un truc illisible et non portable, en plus de buggué.
Je suis mon propre programmeur et je ne me fait pas confiance car je me sait faillible. Tout Homme est faillible.
-- Joe Cool
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
JKB avait énoncé :
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou "non"
Ou peut-être.
"peut etre" ? Un systeme qui fait de la logique floue ? Ah ?
C'est windows ? ;-)
Non, plusieurs Unices.
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
JustMe écrivait dans fr.comp.os.linux.debats :
JKB avait énoncé :
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou
"non"
Ou peut-être.
"peut etre" ? Un systeme qui fait de la logique floue ? Ah ?
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
JKB avait énoncé :
Le 09-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
Il se trouve que Tom a formulé :
Ah ? Un programme qui plante c'est la faute du systeme maintenant :-D
Le programme ne gère pas la mémoire.
Tom
Le programme demande de la mémoire au systeme qui lui repond "oui" ou "non"
Ou peut-être.
"peut etre" ? Un systeme qui fait de la logique floue ? Ah ?
C'est windows ? ;-)
Non, plusieurs Unices.
JKB
Izaho Ihany
Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme ...
C'est ça le problème en C :
En fait, il n'y a pas qu'en C. Osons le parallèle : nous écrivons tous ici en D (grosso modo la "netiquette").
il faut s'efforcer de respecter la norme.
C'est vrai, c'est insupportable...
Ce qui veut dire qu'il faut le vouloir de respecter la norme.
...carrément au dessus des forces.
Ca veut dire quoi ça ?
Oui, on se le demande.
Que l'on peut faire des programmes ne respectant pas les normes ?
Oui, par exemple en D, c'est très facile...
Donc que les compilateurs ne les respectent pas
.... dans le parallèle osé, il eût fallu que le compilo (Thunderbird à ce qu'il semble) "coredumpe" sur un programme (post) du genre <422eb4cb$0$18060$
ou n'arrivent pas à forcer le programmeur à les respecter.
Comment y rémédier, greffer ce qu'il faut au programmeur ?
Il y a forcément un problème quelque part avant même que le programmeur ne tape une ligne de code.
Oui, mais c'est quoi la solution ? Mais serait-il vraiment humain d'exiger du programmeur (posteur) de savoir lire (la netiqette) comme pré-requis, avant de coder (poster) ?
Tom
Et je peux t'assurer que je m'efforce de suivre scrupuleusement la
norme ...
C'est ça le problème en C :
En fait, il n'y a pas qu'en C. Osons le parallèle : nous écrivons
tous ici en D (grosso modo la "netiquette").
il faut s'efforcer de respecter la norme.
C'est vrai, c'est insupportable...
Ce qui veut dire qu'il faut le vouloir de respecter la norme.
...carrément au dessus des forces.
Ca veut dire quoi ça ?
Oui, on se le demande.
Que l'on peut faire des programmes ne respectant pas les normes ?
Oui, par exemple en D, c'est très facile...
Donc que les compilateurs ne les respectent pas
.... dans le parallèle osé, il eût fallu que le compilo (Thunderbird à
ce qu'il semble) "coredumpe" sur un programme (post) du genre
<422eb4cb$0$18060$636a15ce@news.free.fr>
ou n'arrivent pas à forcer le programmeur à les respecter.
Comment y rémédier, greffer ce qu'il faut au programmeur ?
Il y a forcément un problème quelque part avant même que le
programmeur ne tape une ligne de code.
Oui, mais c'est quoi la solution ? Mais serait-il vraiment humain
d'exiger du programmeur (posteur) de savoir lire (la netiqette)
comme pré-requis, avant de coder (poster) ?
Et je peux t'assurer que je m'efforce de suivre scrupuleusement la norme ...
C'est ça le problème en C :
En fait, il n'y a pas qu'en C. Osons le parallèle : nous écrivons tous ici en D (grosso modo la "netiquette").
il faut s'efforcer de respecter la norme.
C'est vrai, c'est insupportable...
Ce qui veut dire qu'il faut le vouloir de respecter la norme.
...carrément au dessus des forces.
Ca veut dire quoi ça ?
Oui, on se le demande.
Que l'on peut faire des programmes ne respectant pas les normes ?
Oui, par exemple en D, c'est très facile...
Donc que les compilateurs ne les respectent pas
.... dans le parallèle osé, il eût fallu que le compilo (Thunderbird à ce qu'il semble) "coredumpe" sur un programme (post) du genre <422eb4cb$0$18060$
ou n'arrivent pas à forcer le programmeur à les respecter.
Comment y rémédier, greffer ce qu'il faut au programmeur ?
Il y a forcément un problème quelque part avant même que le programmeur ne tape une ligne de code.
Oui, mais c'est quoi la solution ? Mais serait-il vraiment humain d'exiger du programmeur (posteur) de savoir lire (la netiqette) comme pré-requis, avant de coder (poster) ?
Tom
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Joe Cool écrivait dans fr.comp.os.linux.debats :
Bien sûr, une preuve ça ne sert à rien.
Quand je doit démontrer un truc sur les entiers, je me dis à quoi bon me fatiquer à faire une preuve qui ne sert à rien : je vais la tester sur les 8 premiers entiers, c'est bien suffisant.
1 est premier
Ah bon ?
Oui, car il n'est divisible que par 1 et par lui même.
1 n'est pas premier (cf. la théorie des nombres). Le plus petit nombre premier est 2.
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Joe Cool écrivait dans fr.comp.os.linux.debats :
Bien sûr, une preuve ça ne sert à rien.
Quand je doit démontrer un truc sur les entiers, je me dis à quoi bon me
fatiquer à faire une preuve qui ne sert à rien : je vais la tester sur
les 8 premiers entiers, c'est bien suffisant.
1 est premier
Ah bon ?
Oui, car il n'est divisible que par 1 et par lui même.
1 n'est pas premier (cf. la théorie des nombres). Le plus petit
nombre premier est 2.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Joe Cool écrivait dans fr.comp.os.linux.debats :
Bien sûr, une preuve ça ne sert à rien.
Quand je doit démontrer un truc sur les entiers, je me dis à quoi bon me fatiquer à faire une preuve qui ne sert à rien : je vais la tester sur les 8 premiers entiers, c'est bien suffisant.
1 est premier
Ah bon ?
Oui, car il n'est divisible que par 1 et par lui même.
1 n'est pas premier (cf. la théorie des nombres). Le plus petit nombre premier est 2.
JKB
JustMe
Nicolas George a émis l'idée suivante :
JustMe , dans le message , a
Donc la "Preuve Mathématique" n'est pas forcément possible
Oui.
Merci
Ce qui doit etre prouvé c'est la proposition "Le programme correspond exactement au but X" Le fait que X existe ne rend pas la proposition en question décidable pour autant.
Effectivement.
Re-merci
Mais justement, si tu n'arrives pas à prouver que ton programme marche, c'est _probablement_ parce qu'il ne marche pas. Quand tu
attention, une "preuve" mathématique c'est du sur, pas du "sans doute".
Mais merci de me donner raison ;-)
écris le programme, tu l'écris pour qu'il marche, ce qui signifie que tu as une vue intuitive des grandes lignes de la preuve. C'est donc se placer _a priori_ dans un cas qui est décidable.
Cette affirmation est loin d'etre evidente, tres tres loin...
D'autant que X n'est pas forcément correctement defini. Mais là c'est un autre probleme... ;-)
Tout à fait.
;-)
Nicolas George a émis l'idée suivante :
JustMe , dans le message <mn.4c5e7d53db902913.15643@merci.beaucoup>, a
Donc la "Preuve Mathématique" n'est pas forcément possible
Oui.
Merci
Ce qui doit etre prouvé c'est la proposition "Le programme correspond
exactement au but X"
Le fait que X existe ne rend pas la proposition en question décidable
pour autant.
Effectivement.
Re-merci
Mais justement, si tu n'arrives pas à prouver que ton
programme marche, c'est _probablement_ parce qu'il ne marche pas. Quand tu
attention, une "preuve" mathématique c'est du sur, pas du "sans doute".
Mais merci de me donner raison ;-)
écris le programme, tu l'écris pour qu'il marche, ce qui signifie que tu as
une vue intuitive des grandes lignes de la preuve. C'est donc se placer _a
priori_ dans un cas qui est décidable.
Cette affirmation est loin d'etre evidente, tres tres loin...
D'autant que X n'est pas forcément correctement defini. Mais là c'est
un autre probleme... ;-)
Donc la "Preuve Mathématique" n'est pas forcément possible
Oui.
Merci
Ce qui doit etre prouvé c'est la proposition "Le programme correspond exactement au but X" Le fait que X existe ne rend pas la proposition en question décidable pour autant.
Effectivement.
Re-merci
Mais justement, si tu n'arrives pas à prouver que ton programme marche, c'est _probablement_ parce qu'il ne marche pas. Quand tu
attention, une "preuve" mathématique c'est du sur, pas du "sans doute".
Mais merci de me donner raison ;-)
écris le programme, tu l'écris pour qu'il marche, ce qui signifie que tu as une vue intuitive des grandes lignes de la preuve. C'est donc se placer _a priori_ dans un cas qui est décidable.
Cette affirmation est loin d'etre evidente, tres tres loin...
D'autant que X n'est pas forcément correctement defini. Mais là c'est un autre probleme... ;-)
