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.
Oui et je maintiens. D'après le rationale, qui explique les intentions de la norme du langage, les comportements indéfinis sont bien là pour facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
C'est alors un aveu d'incompétence de la part des rédacteurs de la norme.
C'est surtout le résultat d'une connaissance de la réalité. Parmi les rédacteur de la norme, beaucoup écrivent des compilateurs, savent ce qui est possible, ce qui est facile et ce qui l'est moins.
Autant faire un langage entièrement composé de undefined behavior, il sera d'autant plus portable et efficace.
Mais sans intérêt. La force du C est dans le savant dosage des comportements définis et indéfinis.
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
La belle affaire : le C est le langage soutenu majoritairement par l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur toutes les architectures. Ce n'est pas parce que tout le monde fait une chose que ce n'est pas une mauvaise chose.
Non, mais si tout le monde fait une chose, c'est sans doute qu'elle est facile à faire. Le langage C est un langage facile à implémenter, ce qui explique son succès.
Ce n'est qu'une question de politique. Un langage portable est un langage qui ne contient aucun comportement indéfini. Sinon je peux décider d'appeler « assemblage » l'ensemble des langages d'assemblage, prétendre qu'ils sont tous identiques, à quelques comportement indéfinis près, puis faire croire que ça rend « assemblage » portable, efficace, simple, sûr, etc.
C'est n'importe quoi.
Tout à fait, ce serait n'importe quoi. Mais le C n'est pas ça.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
Comme dans tout ce qui est mal défini.
Qu'est-ce qui est mal défini ? Un programme strictement conforme est parfaitement défini.
Je le répète, cette portabilité existe en C.
Non, car il existe des comportements indéfinis. Portable veut dire : un programme calcule les mêmes choses pour toutes les entrées possibles pour toutes les implémentations conformes.
Justement, la norme du langage C exige qu'un programme strictement conforme ait ce comportement : « A strictly conforming program shall use only those features of the language and library specified in this International Standard.2) It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.»
Le C n'est pas portable, inutile de faire croire le contraire en noyant le poisson.
Ben si, le C, non seulement est portable, mais en plus il est porté.
-- Richard
Oui et je maintiens. D'après le rationale, qui explique les intentions
de la norme du langage, les comportements indéfinis sont bien là pour
facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
C'est alors un aveu d'incompétence de la part des rédacteurs de la
norme.
C'est surtout le résultat d'une connaissance de la réalité. Parmi les
rédacteur de la norme, beaucoup écrivent des compilateurs, savent ce qui
est possible, ce qui est facile et ce qui l'est moins.
Autant faire un langage entièrement composé de undefined
behavior, il sera d'autant plus portable et efficace.
Mais sans intérêt. La force du C est dans le savant dosage des
comportements définis et indéfinis.
Le résultat est que qu'il existe des compilateurs C pour presque tout
ce qui a un processeur, ce qui est loin d'être le cas pour les autres
langages.
La belle affaire : le C est le langage soutenu majoritairement par
l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur
toutes les architectures. Ce n'est pas parce que tout le monde fait une
chose que ce n'est pas une mauvaise chose.
Non, mais si tout le monde fait une chose, c'est sans doute qu'elle est
facile à faire. Le langage C est un langage facile à implémenter, ce qui
explique son succès.
Ce n'est qu'une question de politique. Un langage portable est un
langage qui ne contient aucun comportement indéfini. Sinon je peux
décider d'appeler « assemblage » l'ensemble des langages d'assemblage,
prétendre qu'ils sont tous identiques, à quelques comportement indéfinis
près, puis faire croire que ça rend « assemblage » portable, efficace,
simple, sûr, etc.
C'est n'importe quoi.
Tout à fait, ce serait n'importe quoi. Mais le C n'est pas ça.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est
déterministe. La portabilité en C est possible, elle n'est pas
obligatoire.
Comme dans tout ce qui est mal défini.
Qu'est-ce qui est mal défini ? Un programme strictement conforme est
parfaitement défini.
Je le répète, cette portabilité existe en C.
Non, car il existe des comportements indéfinis. Portable veut dire : un
programme calcule les mêmes choses pour toutes les entrées possibles
pour toutes les implémentations conformes.
Justement, la norme du langage C exige qu'un programme strictement
conforme ait ce comportement :
« A strictly conforming program shall use only those features of the
language and library specified in this International Standard.2) It
shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit.»
Le C n'est pas portable, inutile de faire croire le contraire en noyant
le poisson.
Ben si, le C, non seulement est portable, mais en plus il est porté.
Oui et je maintiens. D'après le rationale, qui explique les intentions de la norme du langage, les comportements indéfinis sont bien là pour facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
C'est alors un aveu d'incompétence de la part des rédacteurs de la norme.
C'est surtout le résultat d'une connaissance de la réalité. Parmi les rédacteur de la norme, beaucoup écrivent des compilateurs, savent ce qui est possible, ce qui est facile et ce qui l'est moins.
Autant faire un langage entièrement composé de undefined behavior, il sera d'autant plus portable et efficace.
Mais sans intérêt. La force du C est dans le savant dosage des comportements définis et indéfinis.
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
La belle affaire : le C est le langage soutenu majoritairement par l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur toutes les architectures. Ce n'est pas parce que tout le monde fait une chose que ce n'est pas une mauvaise chose.
Non, mais si tout le monde fait une chose, c'est sans doute qu'elle est facile à faire. Le langage C est un langage facile à implémenter, ce qui explique son succès.
Ce n'est qu'une question de politique. Un langage portable est un langage qui ne contient aucun comportement indéfini. Sinon je peux décider d'appeler « assemblage » l'ensemble des langages d'assemblage, prétendre qu'ils sont tous identiques, à quelques comportement indéfinis près, puis faire croire que ça rend « assemblage » portable, efficace, simple, sûr, etc.
C'est n'importe quoi.
Tout à fait, ce serait n'importe quoi. Mais le C n'est pas ça.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
Comme dans tout ce qui est mal défini.
Qu'est-ce qui est mal défini ? Un programme strictement conforme est parfaitement défini.
Je le répète, cette portabilité existe en C.
Non, car il existe des comportements indéfinis. Portable veut dire : un programme calcule les mêmes choses pour toutes les entrées possibles pour toutes les implémentations conformes.
Justement, la norme du langage C exige qu'un programme strictement conforme ait ce comportement : « A strictly conforming program shall use only those features of the language and library specified in this International Standard.2) It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.»
Le C n'est pas portable, inutile de faire croire le contraire en noyant le poisson.
Ben si, le C, non seulement est portable, mais en plus il est porté.
-- Richard
talon
Tom wrote:
Merci je sais que ça existe.
Alors je ne saisis pas votre question
Il y a beaucoup d'activités qui existent uniquement pour servir de gagne pain à leurs pratiquants. En général ce sont ceux qui crient le plus fort pour prétendre que leur machin est indispensable et qu'on ne pourrait pas vivre sans. Par exemple, pour plaire à Tougard, les employés du fisc sont certainement convaincus que sans eux la fraude serait totalement généralisée et que l'état ne pourrait pas vivre. Le seul problème est que l'impôt qu'ils contrôlent rapporte moins que ce qu'ils coutent. Je te laisse le soin de raisonner par analogie pour le cas qui t'intéresse - mais j'ai peur que le raisonnement par analogie ne bénéficie pas de l'onction de messieurs les logiciens.
Tom
--
Michel TALON
Tom <tom@tom.com> wrote:
Merci je sais que ça existe.
Alors je ne saisis pas votre question
Il y a beaucoup d'activités qui existent uniquement pour servir de gagne
pain à leurs pratiquants. En général ce sont ceux qui crient le plus fort
pour prétendre que leur machin est indispensable et qu'on ne pourrait pas vivre
sans. Par exemple, pour plaire à Tougard, les employés du fisc sont
certainement convaincus que sans eux la fraude serait totalement généralisée
et que l'état ne pourrait pas vivre. Le seul problème est que l'impôt qu'ils
contrôlent rapporte moins que ce qu'ils coutent. Je te laisse le soin de
raisonner par analogie pour le cas qui t'intéresse - mais j'ai peur que
le raisonnement par analogie ne bénéficie pas de l'onction de messieurs les
logiciens.
Il y a beaucoup d'activités qui existent uniquement pour servir de gagne pain à leurs pratiquants. En général ce sont ceux qui crient le plus fort pour prétendre que leur machin est indispensable et qu'on ne pourrait pas vivre sans. Par exemple, pour plaire à Tougard, les employés du fisc sont certainement convaincus que sans eux la fraude serait totalement généralisée et que l'état ne pourrait pas vivre. Le seul problème est que l'impôt qu'ils contrôlent rapporte moins que ce qu'ils coutent. Je te laisse le soin de raisonner par analogie pour le cas qui t'intéresse - mais j'ai peur que le raisonnement par analogie ne bénéficie pas de l'onction de messieurs les logiciens.
Tom
--
Michel TALON
talon
Joe Cool wrote:
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de prouver les programmes, mais que c'est nécessaire. Je vous renvoie au discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972. Comme quoi l'idée ne date pas d'hier.
Dijkstra, 1972 : en 33 ans rien n'a changé, sinon que le C a remplacé le
Tout est dit, depuis 33 ans.
Oui, et? Tu compares Dijkstra à Einstein?
--
Michel TALON
Joe Cool <zierouhli_@d_free.fr> wrote:
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de
prouver les programmes, mais que c'est nécessaire. Je vous renvoie au
discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972.
Comme quoi l'idée ne date pas d'hier.
Dijkstra, 1972 : en 33 ans rien n'a changé, sinon que le C a remplacé le
Ca me ferait bien chier. Je n'ai pas dit que c'était toujours facile de prouver les programmes, mais que c'est nécessaire. Je vous renvoie au discours de Dijkstra a prononcé lorqu'il a recu le prix Turing en 1972. Comme quoi l'idée ne date pas d'hier.
Dijkstra, 1972 : en 33 ans rien n'a changé, sinon que le C a remplacé le
Tout est dit, depuis 33 ans.
Oui, et? Tu compares Dijkstra à Einstein?
--
Michel TALON
JustMe
Il se trouve que Tom a formulé :
ah ? Ca vient de sortir ? Au niveau machine la récursivité est gérée par une pile. J'ose espérer qu'un
compilateur sait optimiser une pile. Sinon c'est plus grâve que ce que je pensais.
Tom
Il y a une légère différence entre "dérécursivation" et "gestion de la recursivité".
Il se trouve que Tom a formulé :
ah ? Ca vient de sortir ?
Au niveau machine la récursivité est gérée par une pile. J'ose espérer qu'un
compilateur sait optimiser une pile. Sinon c'est plus grâve que ce que je
pensais.
Tom
Il y a une légère différence entre "dérécursivation" et "gestion de la
recursivité".
ah ? Ca vient de sortir ? Au niveau machine la récursivité est gérée par une pile. J'ose espérer qu'un
compilateur sait optimiser une pile. Sinon c'est plus grâve que ce que je pensais.
Tom
Il y a une légère différence entre "dérécursivation" et "gestion de la recursivité".
JustMe
Il se trouve que Joe Cool a formulé :
Joe Cool a présenté l'énoncé suivant :
La dérécursivation est le travail du compilateur, il sait le faire. ah ? Ca vient de sortir ?
Oui.
L'optimisation est aussi le travail du compilateur,
l'optimisation faite par un compilo n'est jamais tres efficiente. Pourquoi crois tu que les "profilers" existent si ce n'est pour permettre *au programmeur* de faire le plus gros de l'optimisation
Ceci pourrait ëtre automatisé sans mal, si les ingénieurs avaient un peu plus de connaissance.
un algorithme lent ou qui mange toute la mémoire fera de même quelque soit le langage.
tu te contredis, là :-D
Apprenez à faire la différence entre l'algorithmique et la réorganisation de code. La première influe sur la complexité tandis que la seconde agit sur le facteur constant néglié dans le calcul de la complexité.
Un algorithme décrit entre autres un comportement que le compilateur ne doit pas avoir le droit de modifier sous prétexte d'optimisation. Il ne doit pas remplacer des listes par des arbres sous prétexte que c'est plus rapide.
Et dérécursiver ca n'est pas modifier un comportement ? lol
Il se trouve que Joe Cool a formulé :
Joe Cool a présenté l'énoncé suivant :
La dérécursivation est le travail du compilateur, il sait le faire.
ah ? Ca vient de sortir ?
Oui.
L'optimisation est aussi le travail du compilateur,
l'optimisation faite par un compilo n'est jamais tres efficiente. Pourquoi
crois tu que les "profilers" existent si ce n'est pour permettre *au
programmeur* de faire le plus gros de l'optimisation
Ceci pourrait ëtre automatisé sans mal, si les ingénieurs avaient un peu plus
de connaissance.
un algorithme lent ou qui mange toute la mémoire fera de même quelque soit
le langage.
tu te contredis, là :-D
Apprenez à faire la différence entre l'algorithmique et la réorganisation de
code. La première influe sur la complexité tandis que la seconde agit sur le
facteur constant néglié dans le calcul de la complexité.
Un algorithme décrit entre autres un comportement que le compilateur ne doit
pas avoir le droit de modifier sous prétexte d'optimisation. Il ne doit pas
remplacer des listes par des arbres sous prétexte que c'est plus rapide.
Et dérécursiver ca n'est pas modifier un comportement ? lol
La dérécursivation est le travail du compilateur, il sait le faire. ah ? Ca vient de sortir ?
Oui.
L'optimisation est aussi le travail du compilateur,
l'optimisation faite par un compilo n'est jamais tres efficiente. Pourquoi crois tu que les "profilers" existent si ce n'est pour permettre *au programmeur* de faire le plus gros de l'optimisation
Ceci pourrait ëtre automatisé sans mal, si les ingénieurs avaient un peu plus de connaissance.
un algorithme lent ou qui mange toute la mémoire fera de même quelque soit le langage.
tu te contredis, là :-D
Apprenez à faire la différence entre l'algorithmique et la réorganisation de code. La première influe sur la complexité tandis que la seconde agit sur le facteur constant néglié dans le calcul de la complexité.
Un algorithme décrit entre autres un comportement que le compilateur ne doit pas avoir le droit de modifier sous prétexte d'optimisation. Il ne doit pas remplacer des listes par des arbres sous prétexte que c'est plus rapide.
Et dérécursiver ca n'est pas modifier un comportement ? lol
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
C'est surtout le résultat d'une connaissance de la réalité. Parmi les rédacteur de la norme, beaucoup écrivent des compilateurs, savent ce qui est possible, ce qui est facile et ce qui l'est moins.
Il vaut mieux entendre ça que d'être sourd... C'est aussi valable pour les télécoms ? Parce que là, les normes sont faites par des gens qui n'ont aucune idée de ce qu'est une télécommunication (exemple flagrant, l'UMTS).
Autant faire un langage entièrement composé de undefined behavior, il sera d'autant plus portable et efficace.
Mais sans intérêt. La force du C est dans le savant dosage des comportements définis et indéfinis.
Gnî ?
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
La belle affaire : le C est le langage soutenu majoritairement par l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur toutes les architectures. Ce n'est pas parce que tout le monde fait une chose que ce n'est pas une mauvaise chose.
Non, mais si tout le monde fait une chose, c'est sans doute qu'elle est facile à faire. Le langage C est un langage facile à implémenter, ce qui explique son succès.
Je ne vois pas en quoi un compilo C serait plus facile à implanter qu'un compilo Fortran (pour les fonctions de base).
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Richard Delorme écrivait dans fr.comp.os.linux.debats :
C'est surtout le résultat d'une connaissance de la réalité. Parmi les
rédacteur de la norme, beaucoup écrivent des compilateurs, savent ce qui
est possible, ce qui est facile et ce qui l'est moins.
Il vaut mieux entendre ça que d'être sourd... C'est aussi valable
pour les télécoms ? Parce que là, les normes sont faites par des
gens qui n'ont aucune idée de ce qu'est une télécommunication
(exemple flagrant, l'UMTS).
Autant faire un langage entièrement composé de undefined
behavior, il sera d'autant plus portable et efficace.
Mais sans intérêt. La force du C est dans le savant dosage des
comportements définis et indéfinis.
Gnî ?
Le résultat est que qu'il existe des compilateurs C pour presque tout
ce qui a un processeur, ce qui est loin d'être le cas pour les autres
langages.
La belle affaire : le C est le langage soutenu majoritairement par
l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur
toutes les architectures. Ce n'est pas parce que tout le monde fait une
chose que ce n'est pas une mauvaise chose.
Non, mais si tout le monde fait une chose, c'est sans doute qu'elle est
facile à faire. Le langage C est un langage facile à implémenter, ce qui
explique son succès.
Je ne vois pas en quoi un compilo C serait plus facile à implanter
qu'un compilo Fortran (pour les fonctions de base).
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
C'est surtout le résultat d'une connaissance de la réalité. Parmi les rédacteur de la norme, beaucoup écrivent des compilateurs, savent ce qui est possible, ce qui est facile et ce qui l'est moins.
Il vaut mieux entendre ça que d'être sourd... C'est aussi valable pour les télécoms ? Parce que là, les normes sont faites par des gens qui n'ont aucune idée de ce qu'est une télécommunication (exemple flagrant, l'UMTS).
Autant faire un langage entièrement composé de undefined behavior, il sera d'autant plus portable et efficace.
Mais sans intérêt. La force du C est dans le savant dosage des comportements définis et indéfinis.
Gnî ?
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
La belle affaire : le C est le langage soutenu majoritairement par l'industrie, qui seule à le pouvoir d'implémenter un mauvais langage sur toutes les architectures. Ce n'est pas parce que tout le monde fait une chose que ce n'est pas une mauvaise chose.
Non, mais si tout le monde fait une chose, c'est sans doute qu'elle est facile à faire. Le langage C est un langage facile à implémenter, ce qui explique son succès.
Je ne vois pas en quoi un compilo C serait plus facile à implanter qu'un compilo Fortran (pour les fonctions de base).
JKB
Richard Delorme
Un typage *est* une preuve.
Qui ne sert à rien. Lire p.ex. : http://mindview.net/WebLog/log-0025 « In fact, what we need is
*Strong testing, not strong typing.* »
-- Richard
Un typage *est* une preuve.
Qui ne sert à rien. Lire p.ex. :
http://mindview.net/WebLog/log-0025
« In fact, what we need is
Qui ne sert à rien. Lire p.ex. : http://mindview.net/WebLog/log-0025 « In fact, what we need is
*Strong testing, not strong typing.* »
-- Richard
Blaise Potard
Joe Cool wrote:
Tom wrote:
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son système de non-types que le C est un non-langage ! Sachez que c'est grâce au typage statique que Caml est un langage évolué.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Si tu me parlais de l'inférence de type ou de la force du typage, ça irait, mais là, j'ai vraiment du mal à comprendre où tu veux en venir.
Un typage est dit statique quand le type des données est décidé au moment de la compilation.
Et donc ? En C, c'est encore mieux, le type des données est décidé *avant* la compilation, ce qui, du reste, permet de comprendre ce qu'on manipule. En quoi est-ce un avantage (c'était ma question, au cas où tu n'aurais pas compris) ?
Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe.
Le typage des objets est statique en ocaml.
Tiens, c'est vrai. Apparemment au prix de certaines contorsions. Bon, passons. Vu mon expérience de la programmation objet, j'aurais pu me passer de donner un exemple pareil.
Le mécanisme de typage est une preuve du programme.
Lol. T'en as beaucoup des comme ça ? Évidemment, avoir un typage rigoureux est une des conditions pour faire une preuve de programme, mais c'est loin de suffir.
Un typage *est* une preuve.
Preuve de quoi ? De la cohérence des types ? De la correction du programme (ce qui est en générale ce qu'on appelle preuve, et qui est très difficile à faire automatiquement puisque la machine est incapable de deviner ce qu'on veut faire, et à même beaucoup de mal à comprendre quand on lui explique), certainement pas. En même temps, ça m'arrangerait, comme tout mes programmes C sont correctement typés, ça prouverait qu'ils sont corrects.
Alors quand tu racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de quoi tu parles.
Ignorance, quand tu nous tiens.
Tu parles pour toi ?
Joe Cool wrote:
Tom wrote:
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de
son système de non-types que le C est un non-langage ! Sachez que
c'est grâce au typage statique que Caml est un langage évolué.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Si tu me
parlais de l'inférence de type ou de la force du typage, ça irait,
mais là, j'ai vraiment du mal à comprendre où tu veux en venir.
Un typage est dit statique quand le type des données est décidé au
moment de la compilation.
Et donc ? En C, c'est encore mieux, le type des données est décidé
*avant* la compilation, ce qui, du reste, permet de comprendre ce qu'on
manipule. En quoi est-ce un avantage (c'était ma question, au cas où tu
n'aurais pas compris) ?
Alors que OCaml, comme tout langage objet, a des types dynamiques à
cause de l'héritage de classe.
Le typage des objets est statique en ocaml.
Tiens, c'est vrai. Apparemment au prix de certaines contorsions. Bon,
passons. Vu mon expérience de la programmation objet, j'aurais pu me
passer de donner un exemple pareil.
Le mécanisme de typage est une preuve du programme.
Lol. T'en as beaucoup des comme ça ? Évidemment, avoir un typage
rigoureux est une des conditions pour faire une preuve de programme,
mais c'est loin de suffir.
Un typage *est* une preuve.
Preuve de quoi ? De la cohérence des types ? De la correction du
programme (ce qui est en générale ce qu'on appelle preuve, et qui est
très difficile à faire automatiquement puisque la machine est incapable
de deviner ce qu'on veut faire, et à même beaucoup de mal à comprendre
quand on lui explique), certainement pas. En même temps, ça
m'arrangerait, comme tout mes programmes C sont correctement typés, ça
prouverait qu'ils sont corrects.
Alors quand tu racontes ce genre de choses, tu m'excuseras,
mais tu me fais doucement rigoler. Je pense que la seule chose que tu
prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de
quoi tu parles.
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son système de non-types que le C est un non-langage ! Sachez que c'est grâce au typage statique que Caml est un langage évolué.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Si tu me parlais de l'inférence de type ou de la force du typage, ça irait, mais là, j'ai vraiment du mal à comprendre où tu veux en venir.
Un typage est dit statique quand le type des données est décidé au moment de la compilation.
Et donc ? En C, c'est encore mieux, le type des données est décidé *avant* la compilation, ce qui, du reste, permet de comprendre ce qu'on manipule. En quoi est-ce un avantage (c'était ma question, au cas où tu n'aurais pas compris) ?
Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe.
Le typage des objets est statique en ocaml.
Tiens, c'est vrai. Apparemment au prix de certaines contorsions. Bon, passons. Vu mon expérience de la programmation objet, j'aurais pu me passer de donner un exemple pareil.
Le mécanisme de typage est une preuve du programme.
Lol. T'en as beaucoup des comme ça ? Évidemment, avoir un typage rigoureux est une des conditions pour faire une preuve de programme, mais c'est loin de suffir.
Un typage *est* une preuve.
Preuve de quoi ? De la cohérence des types ? De la correction du programme (ce qui est en générale ce qu'on appelle preuve, et qui est très difficile à faire automatiquement puisque la machine est incapable de deviner ce qu'on veut faire, et à même beaucoup de mal à comprendre quand on lui explique), certainement pas. En même temps, ça m'arrangerait, comme tout mes programmes C sont correctement typés, ça prouverait qu'ils sont corrects.
Alors quand tu racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de quoi tu parles.
Ignorance, quand tu nous tiens.
Tu parles pour toi ?
Sam Hocevar
On Wed, 09 Mar 2005 15:42:12 +0100, Joe Cool wrote:
Aucun typage ne peut garantir dans le cas général d'un langage universel qu'on adresse pas une cas inexistante d'un tableau.
Oh ! Pourtant le C c'est de la merde exactement pour cette raison.
Tout bon programmeur Caml, si il n'a pas prouvé la validité de son algorithme, doit enrober son code d'un try...with pour traiter ce cas.
Oh ! Et tout programmeur C qui testerait les bornes de son tableau serait en fait un mauvais programmeur parce qu'il n'a forcément pas prouvé la validité de son algorithme ? Finalement je ne vois aucune différence sur ce point entre le C de merde et le Caml langage miracle.
Tous pourris.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
On Wed, 09 Mar 2005 15:42:12 +0100, Joe Cool wrote:
Aucun typage ne peut garantir dans le cas général d'un langage universel
qu'on adresse pas une cas inexistante d'un tableau.
Oh ! Pourtant le C c'est de la merde exactement pour cette raison.
Tout bon programmeur Caml, si il n'a pas prouvé la validité de son
algorithme, doit enrober son code d'un try...with pour traiter ce
cas.
Oh ! Et tout programmeur C qui testerait les bornes de son tableau
serait en fait un mauvais programmeur parce qu'il n'a forcément pas
prouvé la validité de son algorithme ? Finalement je ne vois aucune
différence sur ce point entre le C de merde et le Caml langage miracle.
Tous pourris.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/
On Wed, 09 Mar 2005 15:42:12 +0100, Joe Cool wrote:
Aucun typage ne peut garantir dans le cas général d'un langage universel qu'on adresse pas une cas inexistante d'un tableau.
Oh ! Pourtant le C c'est de la merde exactement pour cette raison.
Tout bon programmeur Caml, si il n'a pas prouvé la validité de son algorithme, doit enrober son code d'un try...with pour traiter ce cas.
Oh ! Et tout programmeur C qui testerait les bornes de son tableau serait en fait un mauvais programmeur parce qu'il n'a forcément pas prouvé la validité de son algorithme ? Finalement je ne vois aucune différence sur ce point entre le C de merde et le Caml langage miracle.
Tous pourris.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
Joe Cool
Et dérécursiver ca n'est pas modifier un comportement ? lol
Non, car ça ne modifie pas la complexité, ni la sémantique du calcul.
-- Joe Cool
Et dérécursiver ca n'est pas modifier un comportement ? lol
Non, car ça ne modifie pas la complexité, ni la sémantique du calcul.
