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.
Cela dit, je m'en fous, je ne suis pas matheux. Le seul moment où j'ai
ca se voit :-)
Ah ? Pourquoi ?
Ben...
Si je dit 1 + 1 ca fait peutr etre 2 ou peut etre 3, je m'en fous. Je suis pas matheux.
En plus, d'un point de vue pratique, ça m'arrange assez de commencer à 2.
pauvres eleves...
C'est juste pour tenter une bonne répartie, ou tu peux argumenter ?
donner comme exemple des trucs avec des présupposés bancals (bancaux ?), c'est franchement risible chez un enseignant. Mais c'est pas grave, le ridicule ne tue plus :-D
plus sérieusement, lorsqu'un enseignant sort des conneries dans un domaine qu'il ne maitrise pas (et qu'il sait ne pas maitriser, circonstance agravante), sa credibilité en prend un coup et l'attention portée par les élèves en diminue, au detriment de la qualité de leur formation. Pauvres eleves, donc
JustMe <pasdespam@merci.beaucoup> writes:
Cela dit, je m'en fous, je ne suis pas matheux. Le seul moment où j'ai
ca se voit :-)
Ah ? Pourquoi ?
Ben...
Si je dit 1 + 1 ca fait peutr etre 2 ou peut etre 3, je m'en fous. Je
suis pas matheux.
En plus, d'un point de vue
pratique, ça m'arrange assez de commencer à 2.
pauvres eleves...
C'est juste pour tenter une bonne répartie, ou tu peux argumenter ?
donner comme exemple des trucs avec des présupposés bancals (bancaux
?), c'est franchement risible chez un enseignant. Mais c'est pas grave,
le ridicule ne tue plus :-D
plus sérieusement, lorsqu'un enseignant sort des conneries dans un
domaine qu'il ne maitrise pas (et qu'il sait ne pas maitriser,
circonstance agravante), sa credibilité en prend un coup et l'attention
portée par les élèves en diminue, au detriment de la qualité de leur
formation. Pauvres eleves, donc
Cela dit, je m'en fous, je ne suis pas matheux. Le seul moment où j'ai
ca se voit :-)
Ah ? Pourquoi ?
Ben...
Si je dit 1 + 1 ca fait peutr etre 2 ou peut etre 3, je m'en fous. Je suis pas matheux.
En plus, d'un point de vue pratique, ça m'arrange assez de commencer à 2.
pauvres eleves...
C'est juste pour tenter une bonne répartie, ou tu peux argumenter ?
donner comme exemple des trucs avec des présupposés bancals (bancaux ?), c'est franchement risible chez un enseignant. Mais c'est pas grave, le ridicule ne tue plus :-D
plus sérieusement, lorsqu'un enseignant sort des conneries dans un domaine qu'il ne maitrise pas (et qu'il sait ne pas maitriser, circonstance agravante), sa credibilité en prend un coup et l'attention portée par les élèves en diminue, au detriment de la qualité de leur formation. Pauvres eleves, donc
Blaise Potard
Joe Cool wrote:
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.
C'est quoi pour toi la différence entre une exception non-prévue et un plantage complet ? Pour moi, la seule différence, c'est que l'erreur peut-être éventuellement plus facile à trouver s'il y a un message d'erreur explicite, mais ça n'en reste pas moins un plantage (surtout du point de vue de l'utilisateur, qui se fiche pas mal de savoir qu'il y a une "sortie dans l'espace à la ligne 3129 dans robert.ml"). D'autre part, tu peux avoir exactement le même comportement en C en utilisant des bibliothèques appropriées ; mais bon, de toute façon, après un bon debuggage, tous ces bugs là disparaissent.
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.
Oui, il sait envoyer un message du style "Stack_overflow" si l'on n'a pas rattrapé le truc, ou "oulah ! Je suis sorti du tableau, ça va mal !" si on l'a rattrapé. Super.
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 racontes n'impote quoi. Ce n'est pas parce que les types sont explicitement donnés par le programmeur que ça n'est pas du typage : toutes les données sont typées, et le compilateur vérifie la cohérence des différents types. Enfin, tout dépend bien évidemment de ta définition de "typage", que je suis bien curieux de lire :
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.
Oui, je suis d'accord. Il n'y a aucun doute là-dessus.
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.
Je ne pense pas qu'il existe des programmeurs qui se croient sans faille. Bien sûr, il est assez difficile de savoir s'il s'agit d'un bon programmeur, mais il y a des indices : - si le code est clair et bien commenté - si le code compile sans warning - s'il a l'air de tourner Alors il y a de grandes chances qu'il s'agisse d'un bon programmeur.
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.
Tu vas dire que je joue sur les mots, mais tu parlait du "sytème de type du C", et tu parlais de son incohérence. Je dis que la définition des différents types du C est cohérente. Après, je parle du typages des données d'un programme écrit par un programmeur. L'expressivité du langage permet d'écrire des choses incohérentes que le compilateur ne repère pas forcément, parce qu'il fait confiance au programmeur, ce couillon. Ça me rappelle les vieux macs, sur lesquels il n'y avait pour ainsi dire pas de protection mémoire, et du coup un programme qui plantait emportait tout la machine avec. Étrangement, les programmes (et donc la machine) plantaient nettement moins que n'importe quel bouzin d'aujourd'hui. L'impression que ça me donne, c'est que tous ces langages "évolués" donnent au programmeur encore plus de raisons de faire mal son boulot, puisque "la machine rattrape les erreurs".
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,
Je voulais parler des sorties de tableaux, ce genre de choses...
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.
?? C'est quoi un bug pour toi ? Pour moi c'est une erreur dans le programme, point. Que je reçoive un jolie message du type "Stack_overflow" ou "Segmentation fault" ou tout simplement un résultat faux, pour moi, les résultat est le même : il y a un bug.
É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.
Mais certains sont plus faillibles que d'autres. Je suis loin de me faire confiance également, mais j'essaye de prendre quelques précautions. En général je programme très vite et de façon efficace (au sens où le programme fera ce qu'il faut) mais je ne me considère pas comme un bon programmeur pour autant, parce que je me fiche pas mal de savoir si le programme respecte bien la norme, du moment qu'il tourne sur ma machine et que j'arrive à le relire (donc quelques commentaires) - ce qui est mal. Et (mais c'est sûrement une question d'habitude) je fais beaucoup moins d'erreurs et je vais beaucoup plus vite quand je programme en C qu'en caml. N'y vois pas là un jugement sur les mérites des deux langages, il s'agit juste d'une expérience personnelle. Au contraire, j'ai tendance à préférer caml pour la beauté et la clarté du code, et pour débugger un programme - le mode interactif est vraiment idéal pour ça. Mais bon, je suis probablement déformé par mon apprentissage (j'ai appris à programmer en assembleur bien avant de faire des maths, puis j'ai appris le C tout seul, puis le caml en prépa).
Joe Cool wrote:
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.
C'est quoi pour toi la différence entre une exception non-prévue et un
plantage complet ? Pour moi, la seule différence, c'est que l'erreur
peut-être éventuellement plus facile à trouver s'il y a un message
d'erreur explicite, mais ça n'en reste pas moins un plantage (surtout du
point de vue de l'utilisateur, qui se fiche pas mal de savoir qu'il y a
une "sortie dans l'espace à la ligne 3129 dans robert.ml"). D'autre
part, tu peux avoir exactement le même comportement en C en utilisant
des bibliothèques appropriées ; mais bon, de toute façon, après un bon
debuggage, tous ces bugs là disparaissent.
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.
Oui, il sait envoyer un message du style "Stack_overflow" si l'on n'a
pas rattrapé le truc, ou "oulah ! Je suis sorti du tableau, ça va mal !"
si on l'a rattrapé. Super.
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 racontes n'impote quoi. Ce n'est pas parce que les types sont
explicitement donnés par le programmeur que ça n'est pas du typage :
toutes les données sont typées, et le compilateur vérifie la cohérence
des différents types. Enfin, tout dépend bien évidemment de ta
définition de "typage", que je suis bien curieux de lire :
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.
Oui, je suis d'accord. Il n'y a aucun doute là-dessus.
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.
Je ne pense pas qu'il existe des programmeurs qui se croient sans
faille. Bien sûr, il est assez difficile de savoir s'il s'agit d'un bon
programmeur, mais il y a des indices :
- si le code est clair et bien commenté
- si le code compile sans warning
- s'il a l'air de tourner
Alors il y a de grandes chances qu'il s'agisse d'un bon programmeur.
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.
Tu vas dire que je joue sur les mots, mais tu parlait du "sytème de type
du C", et tu parlais de son incohérence. Je dis que la définition des
différents types du C est cohérente. Après, je parle du typages des
données d'un programme écrit par un programmeur. L'expressivité du
langage permet d'écrire des choses incohérentes que le compilateur ne
repère pas forcément, parce qu'il fait confiance au programmeur, ce
couillon. Ça me rappelle les vieux macs, sur lesquels il n'y avait pour
ainsi dire pas de protection mémoire, et du coup un programme qui
plantait emportait tout la machine avec. Étrangement, les programmes (et
donc la machine) plantaient nettement moins que n'importe quel bouzin
d'aujourd'hui. L'impression que ça me donne, c'est que tous ces langages
"évolués" donnent au programmeur encore plus de raisons de faire mal son
boulot, puisque "la machine rattrape les erreurs".
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,
Je voulais parler des sorties de tableaux, ce genre de choses...
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.
?? C'est quoi un bug pour toi ? Pour moi c'est une erreur dans le
programme, point. Que je reçoive un jolie message du type
"Stack_overflow" ou "Segmentation fault" ou tout simplement un résultat
faux, pour moi, les résultat est le même : il y a un bug.
É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.
Mais certains sont plus faillibles que d'autres. Je suis loin de me
faire confiance également, mais j'essaye de prendre quelques
précautions. En général je programme très vite et de façon efficace (au
sens où le programme fera ce qu'il faut) mais je ne me considère pas
comme un bon programmeur pour autant, parce que je me fiche pas mal de
savoir si le programme respecte bien la norme, du moment qu'il tourne
sur ma machine et que j'arrive à le relire (donc quelques commentaires)
- ce qui est mal. Et (mais c'est sûrement une question d'habitude) je
fais beaucoup moins d'erreurs et je vais beaucoup plus vite quand je
programme en C qu'en caml. N'y vois pas là un jugement sur les mérites
des deux langages, il s'agit juste d'une expérience personnelle. Au
contraire, j'ai tendance à préférer caml pour la beauté et la clarté du
code, et pour débugger un programme - le mode interactif est vraiment
idéal pour ça. Mais bon, je suis probablement déformé par mon
apprentissage (j'ai appris à programmer en assembleur bien avant de
faire des maths, puis j'ai appris le C tout seul, puis le caml en
prépa).
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.
C'est quoi pour toi la différence entre une exception non-prévue et un plantage complet ? Pour moi, la seule différence, c'est que l'erreur peut-être éventuellement plus facile à trouver s'il y a un message d'erreur explicite, mais ça n'en reste pas moins un plantage (surtout du point de vue de l'utilisateur, qui se fiche pas mal de savoir qu'il y a une "sortie dans l'espace à la ligne 3129 dans robert.ml"). D'autre part, tu peux avoir exactement le même comportement en C en utilisant des bibliothèques appropriées ; mais bon, de toute façon, après un bon debuggage, tous ces bugs là disparaissent.
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.
Oui, il sait envoyer un message du style "Stack_overflow" si l'on n'a pas rattrapé le truc, ou "oulah ! Je suis sorti du tableau, ça va mal !" si on l'a rattrapé. Super.
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 racontes n'impote quoi. Ce n'est pas parce que les types sont explicitement donnés par le programmeur que ça n'est pas du typage : toutes les données sont typées, et le compilateur vérifie la cohérence des différents types. Enfin, tout dépend bien évidemment de ta définition de "typage", que je suis bien curieux de lire :
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.
Oui, je suis d'accord. Il n'y a aucun doute là-dessus.
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.
Je ne pense pas qu'il existe des programmeurs qui se croient sans faille. Bien sûr, il est assez difficile de savoir s'il s'agit d'un bon programmeur, mais il y a des indices : - si le code est clair et bien commenté - si le code compile sans warning - s'il a l'air de tourner Alors il y a de grandes chances qu'il s'agisse d'un bon programmeur.
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.
Tu vas dire que je joue sur les mots, mais tu parlait du "sytème de type du C", et tu parlais de son incohérence. Je dis que la définition des différents types du C est cohérente. Après, je parle du typages des données d'un programme écrit par un programmeur. L'expressivité du langage permet d'écrire des choses incohérentes que le compilateur ne repère pas forcément, parce qu'il fait confiance au programmeur, ce couillon. Ça me rappelle les vieux macs, sur lesquels il n'y avait pour ainsi dire pas de protection mémoire, et du coup un programme qui plantait emportait tout la machine avec. Étrangement, les programmes (et donc la machine) plantaient nettement moins que n'importe quel bouzin d'aujourd'hui. L'impression que ça me donne, c'est que tous ces langages "évolués" donnent au programmeur encore plus de raisons de faire mal son boulot, puisque "la machine rattrape les erreurs".
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,
Je voulais parler des sorties de tableaux, ce genre de choses...
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.
?? C'est quoi un bug pour toi ? Pour moi c'est une erreur dans le programme, point. Que je reçoive un jolie message du type "Stack_overflow" ou "Segmentation fault" ou tout simplement un résultat faux, pour moi, les résultat est le même : il y a un bug.
É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.
Mais certains sont plus faillibles que d'autres. Je suis loin de me faire confiance également, mais j'essaye de prendre quelques précautions. En général je programme très vite et de façon efficace (au sens où le programme fera ce qu'il faut) mais je ne me considère pas comme un bon programmeur pour autant, parce que je me fiche pas mal de savoir si le programme respecte bien la norme, du moment qu'il tourne sur ma machine et que j'arrive à le relire (donc quelques commentaires) - ce qui est mal. Et (mais c'est sûrement une question d'habitude) je fais beaucoup moins d'erreurs et je vais beaucoup plus vite quand je programme en C qu'en caml. N'y vois pas là un jugement sur les mérites des deux langages, il s'agit juste d'une expérience personnelle. Au contraire, j'ai tendance à préférer caml pour la beauté et la clarté du code, et pour débugger un programme - le mode interactif est vraiment idéal pour ça. Mais bon, je suis probablement déformé par mon apprentissage (j'ai appris à programmer en assembleur bien avant de faire des maths, puis j'ai appris le C tout seul, puis le caml en prépa).
JustMe
Nicolas George avait soumis l'idée :
JustMe , dans le message , a
Non ca n'est pas pareil. Dans le second cas on quitte une appli dans un état aléatoire, dans le second on peut passer par une phase de nettoyage/rollback pour revenir à un etat connu (sur des fichiers de données par ex).
On peut parfaitement rattraper tout à fait fiablement une segmentation fault.
oui, "on peut". Un langage de qualité devrait *obliger* le programmeur a le faire. Donc caml a encore du chemin à faire
Nicolas George avait soumis l'idée :
JustMe , dans le message <mn.4cba7d5365423811.15643@merci.beaucoup>, a
Non ca n'est pas pareil. Dans le second cas on quitte une appli dans un
état aléatoire, dans le second on peut passer par une phase de
nettoyage/rollback pour revenir à un etat connu (sur des fichiers de
données par ex).
On peut parfaitement rattraper tout à fait fiablement une segmentation
fault.
oui, "on peut". Un langage de qualité devrait *obliger* le programmeur
a le faire. Donc caml a encore du chemin à faire
Non ca n'est pas pareil. Dans le second cas on quitte une appli dans un état aléatoire, dans le second on peut passer par une phase de nettoyage/rollback pour revenir à un etat connu (sur des fichiers de données par ex).
On peut parfaitement rattraper tout à fait fiablement une segmentation fault.
oui, "on peut". Un langage de qualité devrait *obliger* le programmeur a le faire. Donc caml a encore du chemin à faire
Nicolas George
Joe Cool , dans le message <422f496c$0$9523$, a écrit :
Moi les seuls arguments en faveur du C que j'ai vu sont :
- troll ! - faites donc un OS en trucmuch !
Il faut voir que les arguments auxquels ils répondent ne font que démontrer une profonde incompréhension du C, de l'informatique et des mathématiques tout à la fois.
Joe Cool , dans le message <422f496c$0$9523$636a15ce@news.free.fr>, a
écrit :
Moi les seuls arguments en faveur du C que j'ai vu sont :
- troll !
- faites donc un OS en trucmuch !
Il faut voir que les arguments auxquels ils répondent ne font que démontrer
une profonde incompréhension du C, de l'informatique et des mathématiques
tout à la fois.
Joe Cool , dans le message <422f496c$0$9523$, a écrit :
Moi les seuls arguments en faveur du C que j'ai vu sont :
- troll ! - faites donc un OS en trucmuch !
Il faut voir que les arguments auxquels ils répondent ne font que démontrer une profonde incompréhension du C, de l'informatique et des mathématiques tout à la fois.
