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.
"Typage statique" ? Qu'est-ce que tu veux dire par là ?
Je voulais dire typage dynamique. Je me suis trompé. L'important c'est l'idée : c'est Caml qui génère le type. Ce qui fait des types de Caml de *vrais* types et pas juste des récorations pense-bête pour le programmeur pour qu'il se souvienne de ce que contient son espace mémoire.
Ce n'est pas du typage dynamique. Tu peux appeler ça inférence ou calcul de type, mais le typage dynamique c'est autre chose (google te l'expliquera beaucoup mieux que moi).
À 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).
Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Où ai-je parlé de *changement* de type ? J'ai parlé de *conversion*. Les variables ne changent pas de type en C, elles sont converties (parfois la conversion est extrèmement simple, certes ; par exemple pour les conversions de pointeurs). L'un des problèmes du C, ce sont les conversions de types implicites, mais en général il y a des warnings pour éviter les ennuis.
Lol. T'en as beaucoup des comme ça ?
Allez lire des livres sur les lambda-calculs typés et on en reparlera. Visiblement vous ne savez pas de quoi vous parlez.
Ah, tu parlais de lambda-calcul ? Il faudrait le préciser, mon ami. Ce que moi j'appelle "preuve" de programme, comme beaucoup (mais qui s'appelle aussi vérification de programme, je le reconnais), c'est la "preuve" que le programme fait bien ce pourquoi on l'a conçu. Les lambda, pi, rho, machins-calculs, j'en ai bouffé merci ; et honnêtement, j'ai encore du mal à comprendre comment on formalise avec ces machins une addition (en arithmétique IEEE 754, par exemple) simplement. Le fait est que ces trucs là ne sont pas adaptés à la vraie vie (ce que le monsieur veut prouver, c'est que les erreurs d'arrondis qu'il fait ne vont pas balancer son missile patriot à 500 mètres de sa cible[1], et il ne veut pas non plus passer 2 ans à prouver en Coq que ses 500 lignes de code pondues en 1 semaine font bien ce qu'il faut).
[1]: http://www.ima.umn.edu/~arnold/disasters/
Tom wrote:
"Typage statique" ? Qu'est-ce que tu veux dire par là ?
Je voulais dire typage dynamique. Je me suis trompé. L'important c'est
l'idée : c'est Caml qui génère le type. Ce qui fait des types de Caml de
*vrais* types et pas juste des récorations pense-bête pour le
programmeur pour qu'il se souvienne de ce que contient son espace mémoire.
Ce n'est pas du typage dynamique. Tu peux appeler ça inférence ou calcul
de type, mais le typage dynamique c'est autre chose (google te
l'expliquera beaucoup mieux que moi).
À 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).
Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Où ai-je parlé de *changement* de type ? J'ai parlé de *conversion*. Les
variables ne changent pas de type en C, elles sont converties (parfois
la conversion est extrèmement simple, certes ; par exemple pour les
conversions de pointeurs). L'un des problèmes du C, ce sont les
conversions de types implicites, mais en général il y a des warnings
pour éviter les ennuis.
Lol. T'en as beaucoup des comme ça ?
Allez lire des livres sur les lambda-calculs typés et on en reparlera.
Visiblement vous ne savez pas de quoi vous parlez.
Ah, tu parlais de lambda-calcul ? Il faudrait le préciser, mon ami. Ce
que moi j'appelle "preuve" de programme, comme beaucoup (mais qui
s'appelle aussi vérification de programme, je le reconnais), c'est la
"preuve" que le programme fait bien ce pourquoi on l'a conçu. Les
lambda, pi, rho, machins-calculs, j'en ai bouffé merci ; et honnêtement,
j'ai encore du mal à comprendre comment on formalise avec ces machins
une addition (en arithmétique IEEE 754, par exemple) simplement. Le fait
est que ces trucs là ne sont pas adaptés à la vraie vie (ce que le
monsieur veut prouver, c'est que les erreurs d'arrondis qu'il fait ne
vont pas balancer son missile patriot à 500 mètres de sa cible[1], et il
ne veut pas non plus passer 2 ans à prouver en Coq que ses 500 lignes de
code pondues en 1 semaine font bien ce qu'il faut).
"Typage statique" ? Qu'est-ce que tu veux dire par là ?
Je voulais dire typage dynamique. Je me suis trompé. L'important c'est l'idée : c'est Caml qui génère le type. Ce qui fait des types de Caml de *vrais* types et pas juste des récorations pense-bête pour le programmeur pour qu'il se souvienne de ce que contient son espace mémoire.
Ce n'est pas du typage dynamique. Tu peux appeler ça inférence ou calcul de type, mais le typage dynamique c'est autre chose (google te l'expliquera beaucoup mieux que moi).
À 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).
Changer de type c'est comme changer de sexe : ça n'a pas de sens.
Où ai-je parlé de *changement* de type ? J'ai parlé de *conversion*. Les variables ne changent pas de type en C, elles sont converties (parfois la conversion est extrèmement simple, certes ; par exemple pour les conversions de pointeurs). L'un des problèmes du C, ce sont les conversions de types implicites, mais en général il y a des warnings pour éviter les ennuis.
Lol. T'en as beaucoup des comme ça ?
Allez lire des livres sur les lambda-calculs typés et on en reparlera. Visiblement vous ne savez pas de quoi vous parlez.
Ah, tu parlais de lambda-calcul ? Il faudrait le préciser, mon ami. Ce que moi j'appelle "preuve" de programme, comme beaucoup (mais qui s'appelle aussi vérification de programme, je le reconnais), c'est la "preuve" que le programme fait bien ce pourquoi on l'a conçu. Les lambda, pi, rho, machins-calculs, j'en ai bouffé merci ; et honnêtement, j'ai encore du mal à comprendre comment on formalise avec ces machins une addition (en arithmétique IEEE 754, par exemple) simplement. Le fait est que ces trucs là ne sont pas adaptés à la vraie vie (ce que le monsieur veut prouver, c'est que les erreurs d'arrondis qu'il fait ne vont pas balancer son missile patriot à 500 mètres de sa cible[1], et il ne veut pas non plus passer 2 ans à prouver en Coq que ses 500 lignes de code pondues en 1 semaine font bien ce qu'il faut).
[1]: http://www.ima.umn.edu/~arnold/disasters/
Nicolas George
JKB , dans le message , a écrit :
Dites... Est-ce que vous avez déjà vu dans la _vraie_ vie un programmeur qui s'arrête aux warnings donnés par un compilo ?
Oui : tous ceux qui m'entourent.
Et il y a quand même pas mal de logiciels libres qui circulent qui compilent proprement avec gcc sans warnings, même avec les options pédantes activées.
JKB , dans le message <slrnd2tugq.ugg.knatschke@rayleigh.systella.fr>, a
écrit :
Dites... Est-ce que vous avez déjà vu dans la _vraie_ vie un
programmeur qui s'arrête aux warnings donnés par un compilo ?
Oui : tous ceux qui m'entourent.
Et il y a quand même pas mal de logiciels libres qui circulent qui compilent
proprement avec gcc sans warnings, même avec les options pédantes activées.
Dites... Est-ce que vous avez déjà vu dans la _vraie_ vie un programmeur qui s'arrête aux warnings donnés par un compilo ?
Oui : tous ceux qui m'entourent.
Et il y a quand même pas mal de logiciels libres qui circulent qui compilent proprement avec gcc sans warnings, même avec les options pédantes activées.
Rakotomandimby (R12y) Mihamina
( Tue, 08 Mar 2005 17:39:13 +0100 ) Tom :
Bonjour,
à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ... -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
( Tue, 08 Mar 2005 17:39:13 +0100 ) Tom :
Bonjour,
à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ...
--
L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses
activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance)
Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
à ce rythme, dans quelques heures on aura explosé "linux=mauvais" ... -- L'ASPO a pour but de démocratiser l'acces a l'informatique. Une de ses activité est l'infogerance (http://aspo.rktmb.org/activites/infogerance) Tél: + 33 2 38 04 26 04 ou + 33 6 33 26 13 14 (France)
Joe Cool
Tom , dans le message <422eb41f$0$18060$, a
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Tiens, qu'on rigole un peu :
let a = 1000000000;; print_int (a * 2);; print_newline ();;
Ça donne quoi sur les machines de travail des développeurs de Caml, ça ?
Tout dépend si elles sont en 32bits ou 64bits.
Plus sérieusement, ce genre d'argument est digne de la cour de récré : les défauts minimes de caml (qui n'est pas la panacée, on peut mieux faire) n'effacent en rien les failles béantes du C. Je ne comprend pas en quoi cela serait un argument en faveur du C.
-- Joe Cool
Tom , dans le message <422eb41f$0$18060$636a15ce@news.free.fr>, a
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un
comportement défini. Certains compilateurs vont incrémenter avant,
d'autres après l'affectation. Quel exemple de portabilité ! :-)
Tiens, qu'on rigole un peu :
let a = 1000000000;;
print_int (a * 2);;
print_newline ();;
Ça donne quoi sur les machines de travail des développeurs de Caml, ça ?
Tout dépend si elles sont en 32bits ou 64bits.
Plus sérieusement, ce genre d'argument est digne de la cour de récré :
les défauts minimes de caml (qui n'est pas la panacée, on peut mieux
faire) n'effacent en rien les failles béantes du C. Je ne comprend pas
en quoi cela serait un argument en faveur du C.
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Tiens, qu'on rigole un peu :
let a = 1000000000;; print_int (a * 2);; print_newline ();;
Ça donne quoi sur les machines de travail des développeurs de Caml, ça ?
Tout dépend si elles sont en 32bits ou 64bits.
Plus sérieusement, ce genre d'argument est digne de la cour de récré : les défauts minimes de caml (qui n'est pas la panacée, on peut mieux faire) n'effacent en rien les failles béantes du C. Je ne comprend pas en quoi cela serait un argument en faveur du C.
-- Joe Cool
Nicolas George
Tom , dans le message <422eb41f$0$18060$, a écrit :
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Tiens, qu'on rigole un peu :
let a = 1000000000;; print_int (a * 2);; print_newline ();;
Ça donne quoi sur les machines de travail des développeurs de Caml, ça ?
Tom , dans le message <422eb41f$0$18060$636a15ce@news.free.fr>, a
écrit :
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un
comportement défini. Certains compilateurs vont incrémenter avant,
d'autres après l'affectation. Quel exemple de portabilité ! :-)
Tiens, qu'on rigole un peu :
let a = 1000000000;;
print_int (a * 2);;
print_newline ();;
Ça donne quoi sur les machines de travail des développeurs de Caml, ça ?
Tom , dans le message <422eb41f$0$18060$, a écrit :
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Tiens, qu'on rigole un peu :
let a = 1000000000;; print_int (a * 2);; print_newline ();;
Ça donne quoi sur les machines de travail des développeurs de Caml, ça ?
JustMe
Joe Cool a présenté l'énoncé suivant :
Nicolas George a exprimé avec précision :
JustMe , dans le message , a
Que fais tu du théorème de Godel ?
Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le théorème de Gôdel possède une preuve de sa validité.
Et alors ?
Joe Cool a présenté l'énoncé suivant :
Nicolas George a exprimé avec précision :
JustMe , dans le message <mn.4a5f7d533da24a14.15643@merci.beaucoup>, a
Que fais tu du théorème de Godel ?
Mauvaise objection, changer d'objection.
Quelle reponse détaillée, objective et argumentée ;-D
Le théorème de Gôdel possède une preuve de sa validité.
