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.
La sûreté d'Ada n'a pas empêché Ariane d'exploser. Un programme non testé n'est pas sûr, quelque soit le langage.
Mais bon sang arrêtez avec vos tests. C'est grâce à ces tests qu'elle a explosé Ariane. Parce qu'on a testé dans quelques situations. Si ça n'a pas planté en simulation c'est que ça ne plantera pas. Et crac. Mais savez vous seulement ce qui s'est passé avec Ariane ? Ils ont tout simplement repris le programme de la fusée précédente. Or dans l'ancien programme une certaine valeur ne dépassait jamais un seuil. Sur la nouvelle fusée ça dépassait. Donc une alarme s'est déclenchée alors qu'il n'y avait rien de grave, et ça a conduit à l'explosion de l'engin. Comment on s'est rendu compte de ça ? En spécifiant le programme, et pas en le testant bêtement comme un informaticien des années 70.
Tom
La sûreté d'Ada n'a pas empêché Ariane d'exploser. Un programme non
testé n'est pas sûr, quelque soit le langage.
Mais bon sang arrêtez avec vos tests. C'est grâce à ces tests qu'elle a
explosé Ariane. Parce qu'on a testé dans quelques situations. Si ça n'a
pas planté en simulation c'est que ça ne plantera pas. Et crac.
Mais savez vous seulement ce qui s'est passé avec Ariane ? Ils ont tout
simplement repris le programme de la fusée précédente. Or dans l'ancien
programme une certaine valeur ne dépassait jamais un seuil. Sur la
nouvelle fusée ça dépassait. Donc une alarme s'est déclenchée alors
qu'il n'y avait rien de grave, et ça a conduit à l'explosion de l'engin.
Comment on s'est rendu compte de ça ? En spécifiant le programme, et pas
en le testant bêtement comme un informaticien des années 70.
La sûreté d'Ada n'a pas empêché Ariane d'exploser. Un programme non testé n'est pas sûr, quelque soit le langage.
Mais bon sang arrêtez avec vos tests. C'est grâce à ces tests qu'elle a explosé Ariane. Parce qu'on a testé dans quelques situations. Si ça n'a pas planté en simulation c'est que ça ne plantera pas. Et crac. Mais savez vous seulement ce qui s'est passé avec Ariane ? Ils ont tout simplement repris le programme de la fusée précédente. Or dans l'ancien programme une certaine valeur ne dépassait jamais un seuil. Sur la nouvelle fusée ça dépassait. Donc une alarme s'est déclenchée alors qu'il n'y avait rien de grave, et ça a conduit à l'explosion de l'engin. Comment on s'est rendu compte de ça ? En spécifiant le programme, et pas en le testant bêtement comme un informaticien des années 70.
Tom
Joe Cool
Ah. Que peut-on faire en C qui serait impossible en Caml ?
Faire planter le PC.
-- Joe Cool
Ah. Que peut-on faire en C qui serait impossible en Caml ?
Ah. Que peut-on faire en C qui serait impossible en Caml ?
Faire planter le PC.
-- Joe Cool
Tom
Pour revenir sur les langages fonctionnels, le concept est aussi vieux, quasiment, que la naissance d'unix (années 70), or on est en 2005, et toujours avec des langages impératifs. Les premiers langages impératifs sont venus en même temps que les
premiers langages fonctionnels.
Si les langages fonctionnels étaient 'La Réponse', il me semble que les choses auraient bougées depuis 30 ans. Ah bon : regardez comme les gens ont envie de découvrir autre chose ici
: ils ont le C dans le sang et ils seraient prets à donner leur vi pour le défendre !
Si ce n'est pas le cas, c'est bien que la programmation impérative est parfaitement adaptée à des situations qui ne sont pas gérables avec un langages comme CAML par exemple. Et l'inverse est vraie aussi, aucun des deux n'est inutile. Ah. Que peut-on faire en C qui serait impossible en Caml ?
Les contextes d'utilisation sont différents. La grande idée serait d'arriver à fusionner les avantages des deux styles, mais est-ce possible? Comment developper un driver en CAML? Si ça devient possible, alors oui, on peut remettre les choses en question. Ca existe malheureusement car il y a des for et des while en Caml. Et
certains ont la faiblesse de les utiliser. Et pourquoi pas un driver en Caml ?
Tom
Pour revenir sur les langages fonctionnels, le concept est aussi vieux,
quasiment, que la naissance d'unix (années 70), or on est en 2005, et
toujours avec des langages impératifs.
Les premiers langages impératifs sont venus en même temps que les
premiers langages fonctionnels.
Si les langages fonctionnels étaient 'La Réponse', il me semble que
les choses auraient bougées depuis 30 ans.
Ah bon : regardez comme les gens ont envie de découvrir autre chose ici
: ils ont le C dans le sang et ils seraient prets à donner leur vi pour
le défendre !
Si ce n'est pas le cas, c'est bien que la programmation
impérative est parfaitement adaptée à des situations qui ne sont pas
gérables avec un langages comme CAML par exemple. Et l'inverse est vraie
aussi, aucun des deux n'est inutile.
Ah. Que peut-on faire en C qui serait impossible en Caml ?
Les contextes d'utilisation sont différents. La grande idée serait
d'arriver à fusionner les avantages des deux styles, mais est-ce
possible? Comment developper un driver en CAML? Si ça devient
possible, alors oui, on peut remettre les choses en question.
Ca existe malheureusement car il y a des for et des while en Caml. Et
certains ont la faiblesse de les utiliser.
Et pourquoi pas un driver en Caml ?
Pour revenir sur les langages fonctionnels, le concept est aussi vieux, quasiment, que la naissance d'unix (années 70), or on est en 2005, et toujours avec des langages impératifs. Les premiers langages impératifs sont venus en même temps que les
premiers langages fonctionnels.
Si les langages fonctionnels étaient 'La Réponse', il me semble que les choses auraient bougées depuis 30 ans. Ah bon : regardez comme les gens ont envie de découvrir autre chose ici
: ils ont le C dans le sang et ils seraient prets à donner leur vi pour le défendre !
Si ce n'est pas le cas, c'est bien que la programmation impérative est parfaitement adaptée à des situations qui ne sont pas gérables avec un langages comme CAML par exemple. Et l'inverse est vraie aussi, aucun des deux n'est inutile. Ah. Que peut-on faire en C qui serait impossible en Caml ?
Les contextes d'utilisation sont différents. La grande idée serait d'arriver à fusionner les avantages des deux styles, mais est-ce possible? Comment developper un driver en CAML? Si ça devient possible, alors oui, on peut remettre les choses en question. Ca existe malheureusement car il y a des for et des while en Caml. Et
certains ont la faiblesse de les utiliser. Et pourquoi pas un driver en Caml ?
Tom
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
Sous DOS (Borland C) : short = 16 bits int = 16 bits long = 32 bits
Sous Linux i386 (gcc) : short = 16 bits int = 32 bits long = 32 bits
Sous Linux alpha (gcc) : short = 16 bits int = 32 bits long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je code en C, et pour l'instant, je n'ai pas trouvé mieux et plus portable que des grands coups de typedef conditionnés par un script configure.
Ben, il faut arrêter les trucs d'il y a vingt ans.
#include <stdint.h> ou sur les systèmes Unix un peu vieillot #include <inttypes.h>
Dedans on trouve des types à taille garantie : int8_t int16_t int32_t int64_t etc.
D'accord. Pas portable pour un sou. J'ai essayé. Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Richard Delorme écrivait dans fr.comp.os.linux.debats :
Sous DOS (Borland C) :
short = 16 bits
int = 16 bits
long = 32 bits
Sous Linux i386 (gcc) :
short = 16 bits
int = 32 bits
long = 32 bits
Sous Linux alpha (gcc) :
short = 16 bits
int = 32 bits
long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à
sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les
integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je
code en C, et pour l'instant, je n'ai pas trouvé mieux et plus
portable que des grands coups de typedef conditionnés par un script
configure.
Ben, il faut arrêter les trucs d'il y a vingt ans.
#include <stdint.h>
ou sur les systèmes Unix un peu vieillot
#include <inttypes.h>
Dedans on trouve des types à taille garantie :
int8_t
int16_t
int32_t
int64_t
etc.
D'accord. Pas portable pour un sou. J'ai essayé. Au passage, ce truc
ne vous garantit jamais la structure même de l'entier.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Richard Delorme écrivait dans fr.comp.os.linux.debats :
Sous DOS (Borland C) : short = 16 bits int = 16 bits long = 32 bits
Sous Linux i386 (gcc) : short = 16 bits int = 32 bits long = 32 bits
Sous Linux alpha (gcc) : short = 16 bits int = 32 bits long = 64 bits
Sous sparc64, idem.
Maintenant, portez moi un code utilisant int et long de DOS à sparc64 pour rigoler ! Là, on commence à apprécier sérieusement les integer*8 (un peu hors norme) du Fortran ! Ça fait vingt ans que je code en C, et pour l'instant, je n'ai pas trouvé mieux et plus portable que des grands coups de typedef conditionnés par un script configure.
Ben, il faut arrêter les trucs d'il y a vingt ans.
#include <stdint.h> ou sur les systèmes Unix un peu vieillot #include <inttypes.h>
Dedans on trouve des types à taille garantie : int8_t int16_t int32_t int64_t etc.
D'accord. Pas portable pour un sou. J'ai essayé. Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
JKB
Tom
Ben tu reviendras quand t'auras ecrit un OS en caml. Ca devrait etre super simple et aller vite, puisqu'apparement il n'y a aucun bug possible.
Non car contrairement au C le plus gros du temps de déveoppement en Caml n'est pas dans le débuggage. Et toi t'as écris un système en C ? -> si oui montre le moi -> si non, selon ta logique C n'est pas adapté pour faire un OS et donc je n'ai même pas à chercher à argumenter.
Tom
Ben tu reviendras quand t'auras ecrit un OS en caml. Ca devrait etre
super simple et aller vite, puisqu'apparement il n'y a aucun bug
possible.
Non car contrairement au C le plus gros du temps de déveoppement en Caml
n'est pas dans le débuggage.
Et toi t'as écris un système en C ?
-> si oui montre le moi
-> si non, selon ta logique C n'est pas adapté pour faire un OS et donc
je n'ai même pas à chercher à argumenter.
Ben tu reviendras quand t'auras ecrit un OS en caml. Ca devrait etre super simple et aller vite, puisqu'apparement il n'y a aucun bug possible.
Non car contrairement au C le plus gros du temps de déveoppement en Caml n'est pas dans le débuggage. Et toi t'as écris un système en C ? -> si oui montre le moi -> si non, selon ta logique C n'est pas adapté pour faire un OS et donc je n'ai même pas à chercher à argumenter.
Tom
Sam Hocevar
On Wed, 09 Mar 2005 11:11:34 +0100, Tom wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
En Caml, pour commencer.
Voyons voir ...
% cat foo.ml let a = Array.create 10 0;; a.(10) <- 1 % ocamlc foo.ml -o foo %
Tiens ? Le compilateur me laisse écrire dans la 11e case d'un tableau de 10 éléments... Ça me semble un peu pourri, Caml.
Voyons voir... Peut-être que je n'ai pas mis tous les warnings, en fait...
-w <flags> Enable or disable warnings according to <flags>: A/a enable/disable all warnings
% ocamlc -w A foo.ml -o foo %
Pas un bruit ! Bon, c'est que mon programme doit être correct, finalement. Allez, demain on parlera de l'option -unsafe de ocamlc, si elle est là c'est qu'elle doit bien servir à quelque chose.
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 11:11:34 +0100, Tom wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton
avis, pour que ça devienne bien foutu ?
En Caml, pour commencer.
Voyons voir ...
% cat foo.ml
let a = Array.create 10 0;;
a.(10) <- 1
% ocamlc foo.ml -o foo
%
Tiens ? Le compilateur me laisse écrire dans la 11e case d'un
tableau de 10 éléments... Ça me semble un peu pourri, Caml.
Voyons voir... Peut-être que je n'ai pas mis tous les warnings, en
fait...
-w <flags> Enable or disable warnings according to <flags>:
A/a enable/disable all warnings
% ocamlc -w A foo.ml -o foo
%
Pas un bruit ! Bon, c'est que mon programme doit être correct,
finalement. Allez, demain on parlera de l'option -unsafe de ocamlc, si
elle est là c'est qu'elle doit bien servir à quelque chose.
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/
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
En Caml, pour commencer.
Voyons voir ...
% cat foo.ml let a = Array.create 10 0;; a.(10) <- 1 % ocamlc foo.ml -o foo %
Tiens ? Le compilateur me laisse écrire dans la 11e case d'un tableau de 10 éléments... Ça me semble un peu pourri, Caml.
Voyons voir... Peut-être que je n'ai pas mis tous les warnings, en fait...
-w <flags> Enable or disable warnings according to <flags>: A/a enable/disable all warnings
% ocamlc -w A foo.ml -o foo %
Pas un bruit ! Bon, c'est que mon programme doit être correct, finalement. Allez, demain on parlera de l'option -unsafe de ocamlc, si elle est là c'est qu'elle doit bien servir à quelque chose.
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/
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Joe Cool écrivait dans fr.comp.os.linux.debats :
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
À mon avis, non, mais celle-là, je vais l'encadrer ;-)
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Joe Cool écrivait dans fr.comp.os.linux.debats :
Contrairement à ce que l'on croit, la portabilité d'un langage est
uniquement déterminée par la qualité de sa spécification. Un
langage d'assemblage est portable car sa sémantique est univoque,
alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la
portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
À mon avis, non, mais celle-là, je vais l'encadrer ;-)
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Joe Cool écrivait dans fr.comp.os.linux.debats :
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
À mon avis, non, mais celle-là, je vais l'encadrer ;-)
JKB
Tom
L'objectif de Linux est d'être un Unix, ce qui impose l'utilisation du langage C, pour des raisons historiques. Écrire un OS dans un autre langage est sans doute possible, mais ce ne sera plus un Unix, mais autre chose.
Si on fait une nouvelle cathédrale aujourd'hui tu pense qu'on utilisera des esclaves ? Pour des raisons historiques on serait obligé. Serait-ce pour celà qu'on ne fait plus de cathédrales ?
Tom
L'objectif de Linux est d'être un Unix, ce qui impose l'utilisation du
langage C, pour des raisons historiques.
Écrire un OS dans un autre langage est sans doute possible, mais ce ne
sera plus un Unix, mais autre chose.
Si on fait une nouvelle cathédrale aujourd'hui tu pense qu'on utilisera
des esclaves ? Pour des raisons historiques on serait obligé. Serait-ce
pour celà qu'on ne fait plus de cathédrales ?
L'objectif de Linux est d'être un Unix, ce qui impose l'utilisation du langage C, pour des raisons historiques. Écrire un OS dans un autre langage est sans doute possible, mais ce ne sera plus un Unix, mais autre chose.
Si on fait une nouvelle cathédrale aujourd'hui tu pense qu'on utilisera des esclaves ? Pour des raisons historiques on serait obligé. Serait-ce pour celà qu'on ne fait plus de cathédrales ?
Tom
Blaise Potard
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. Caml est très bien parce qu'il calcule automatiquement les types et qu'il y a un typage fort, certes. Mais alors, le "typage statique", je vois *vraiment* pas. Parce que, je sens que je vais t'apprendre un truc là, il n'y a pas plus statique que le typage du C. À un point que les casts sont bien souvent indispensables (et un cast, c'est faire appel à une fonction qui convertit un objet d'un certain type vers un autre objet d'un autre type). Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe.
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. J'ai un collègue qui travaille là-dessus, qui prouve des propriétés pour des fonction d'arithmétique d'intervalle (il cherche à prouver la correction des différentes fonctions de la bibliothèque d'arithmétique d'intervalle de Boost, qu'il maintient). Et ben, rien que pour prouver que suivant le mode d'arrondi on aura pas de couille, je peux t'affirmer que c'est pas de la tarte. 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.
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. Caml est très bien
parce qu'il calcule automatiquement les types et qu'il y a un typage
fort, certes. Mais alors, le "typage statique", je vois *vraiment* pas.
Parce que, je sens que je vais t'apprendre un truc là, il n'y a pas plus
statique que le typage du C. À un point que les casts sont bien souvent
indispensables (et un cast, c'est faire appel à une fonction qui
convertit un objet d'un certain type vers un autre objet d'un autre
type). Alors que OCaml, comme tout langage objet, a des types dynamiques
à cause de l'héritage de classe.
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. J'ai un collègue qui travaille là-dessus, qui
prouve des propriétés pour des fonction d'arithmétique d'intervalle (il
cherche à prouver la correction des différentes fonctions de la
bibliothèque d'arithmétique d'intervalle de Boost, qu'il maintient). Et
ben, rien que pour prouver que suivant le mode d'arrondi on aura pas de
couille, je peux t'affirmer que c'est pas de la tarte. 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. Caml est très bien parce qu'il calcule automatiquement les types et qu'il y a un typage fort, certes. Mais alors, le "typage statique", je vois *vraiment* pas. Parce que, je sens que je vais t'apprendre un truc là, il n'y a pas plus statique que le typage du C. À un point que les casts sont bien souvent indispensables (et un cast, c'est faire appel à une fonction qui convertit un objet d'un certain type vers un autre objet d'un autre type). Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe.
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. J'ai un collègue qui travaille là-dessus, qui prouve des propriétés pour des fonction d'arithmétique d'intervalle (il cherche à prouver la correction des différentes fonctions de la bibliothèque d'arithmétique d'intervalle de Boost, qu'il maintient). Et ben, rien que pour prouver que suivant le mode d'arrondi on aura pas de couille, je peux t'affirmer que c'est pas de la tarte. 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.
Tom
C'est marrant que tu dises ça, la première fusée ariane 5 avait justement explosé à cause d'un bout de programme ADA pourri, qui avait déclenché une exception non rattrapée (un dépassement de capacité dans le capteur d'accélération horizontale, prévu pour ariane 4, si mes souvenirs sont bons), qui a fait pété tout le système. Si le bout de programme en question avait été écrit en C, cela n'aurait probablement strictement rien provoqué...
si : un segmentation fault. Ca aurait changé l'histoire.
Tom
C'est marrant que tu dises ça, la première fusée ariane 5 avait
justement explosé à cause d'un bout de programme ADA pourri, qui avait
déclenché une exception non rattrapée (un dépassement de capacité dans
le capteur d'accélération horizontale, prévu pour ariane 4, si mes
souvenirs sont bons), qui a fait pété tout le système. Si le bout de
programme en question avait été écrit en C, cela n'aurait probablement
strictement rien provoqué...
si : un segmentation fault. Ca aurait changé l'histoire.
C'est marrant que tu dises ça, la première fusée ariane 5 avait justement explosé à cause d'un bout de programme ADA pourri, qui avait déclenché une exception non rattrapée (un dépassement de capacité dans le capteur d'accélération horizontale, prévu pour ariane 4, si mes souvenirs sont bons), qui a fait pété tout le système. Si le bout de programme en question avait été écrit en C, cela n'aurait probablement strictement rien provoqué...
si : un segmentation fault. Ca aurait changé l'histoire.
