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.
Quelle idée est passée par la tête des informaticiens théoriciens de tenter de prouver des programmes ? Les gens aiment les bugs, les
Quels informaticiens théoriciens?
programmes pourris jusqu'à la moelle. Laissons les dans leur merde. Les maths : aaaahrg c'est trop compliqué, faut pas toucher ! Faut laisser ça aux mathématiciens.
Oui, moi je fais des maths dans mon boulot et j'appelle pas maths les sombres merdes qu'on fait en "informatique théorique". Bouillie pour chat serait beaucoup trop gentil.
--
Michel TALON
Tom <tom@tom.com> wrote:
Quelle idée est passée par la tête des informaticiens théoriciens de
tenter de prouver des programmes ? Les gens aiment les bugs, les
Quels informaticiens théoriciens?
programmes pourris jusqu'à la moelle. Laissons les dans leur merde.
Les maths : aaaahrg c'est trop compliqué, faut pas toucher ! Faut
laisser ça aux mathématiciens.
Oui, moi je fais des maths dans mon boulot et j'appelle pas maths les sombres
merdes qu'on fait en "informatique théorique". Bouillie pour chat serait
beaucoup trop gentil.
Quelle idée est passée par la tête des informaticiens théoriciens de tenter de prouver des programmes ? Les gens aiment les bugs, les
Quels informaticiens théoriciens?
programmes pourris jusqu'à la moelle. Laissons les dans leur merde. Les maths : aaaahrg c'est trop compliqué, faut pas toucher ! Faut laisser ça aux mathématiciens.
Oui, moi je fais des maths dans mon boulot et j'appelle pas maths les sombres merdes qu'on fait en "informatique théorique". Bouillie pour chat serait beaucoup trop gentil.
--
Michel TALON
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Le Wed, 09 Mar 2005 09:19:17 +0100, Joe Cool a écrit :
Le C n'est pas portable car ce n'est pas un langage déterministe. N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une architecture matérielle donnée. Il est donc rigoureusement non portable, à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
Et comment se fait-il que je puisse compiler mes codes écrits en assembleur VAX (CISC tordu) sur alpha ev6 (RISC encore plus tordu) ? Il suffit d'avoir un soft quelque part qui compile les instructions de l'assembleur VAX en assembleur alpha... J'ai aussi un truc qui me permet de faire tourner des codes assemblés pour 6809 sous systèmes POSIX et ça fonctionne très bien. Je ne vois vraiment pas où est le problème.
Seule la spécification du langage est liée à une architecture matérielle. Maintenant, pourquoi ne pas l'exécuter sur une autre architecture ?
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Le Wed, 09 Mar 2005 09:19:17 +0100, Joe Cool a écrit :
Le C n'est pas portable car ce n'est pas un langage déterministe.
N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une
architecture matérielle donnée. Il est donc rigoureusement non portable,
à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou
émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
Et comment se fait-il que je puisse compiler mes codes écrits en
assembleur VAX (CISC tordu) sur alpha ev6 (RISC encore plus tordu) ?
Il suffit d'avoir un soft quelque part qui compile les instructions
de l'assembleur VAX en assembleur alpha... J'ai aussi un truc qui me
permet de faire tourner des codes assemblés pour 6809 sous systèmes
POSIX et ça fonctionne très bien. Je ne vois vraiment pas où est le
problème.
Seule la spécification du langage est liée à une architecture
matérielle. Maintenant, pourquoi ne pas l'exécuter sur une autre
architecture ?
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Emmanuel Florac écrivait dans fr.comp.os.linux.debats :
Le Wed, 09 Mar 2005 09:19:17 +0100, Joe Cool a écrit :
Le C n'est pas portable car ce n'est pas un langage déterministe. N'importe quel l'angage d'assemblage est plus portable que le C
Un langage d'assemblage est par définition totalement lié à une architecture matérielle donnée. Il est donc rigoureusement non portable, à part quelques exception (genre compatibilité 8080/Z80, 80x86, ou émulation genre M68k sur PowerPC ou FX!32 sur Alpha/NT).
Et comment se fait-il que je puisse compiler mes codes écrits en assembleur VAX (CISC tordu) sur alpha ev6 (RISC encore plus tordu) ? Il suffit d'avoir un soft quelque part qui compile les instructions de l'assembleur VAX en assembleur alpha... J'ai aussi un truc qui me permet de faire tourner des codes assemblés pour 6809 sous systèmes POSIX et ça fonctionne très bien. Je ne vois vraiment pas où est le problème.
Seule la spécification du langage est liée à une architecture matérielle. Maintenant, pourquoi ne pas l'exécuter sur une autre architecture ?
JKB
Joe Cool
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.
Objective Caml version 3.08.2
# let t = Array.make 10 0;; val t : int array = [|0; 0; 0; 0; 0; 0; 0; 0; 0; 0|] # t.(10) <- 1;; Exception: Invalid_argument "index out of bounds". #
C'est quoi le problème ? J'essaie d'écrire dans la 10ème cas, qui n'existe pas. Ocaml me génère une exception pour m'en avertir. C'est forcément un mauvais comportement : ocaml devrait planter, comme tout bon programme.
-- Joe Cool
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.
Objective Caml version 3.08.2
# let t = Array.make 10 0;;
val t : int array = [|0; 0; 0; 0; 0; 0; 0; 0; 0; 0|]
# t.(10) <- 1;;
Exception: Invalid_argument "index out of bounds".
#
C'est quoi le problème ? J'essaie d'écrire dans la 10ème cas, qui
n'existe pas. Ocaml me génère une exception pour m'en avertir. C'est
forcément un mauvais comportement : ocaml devrait planter, comme tout
bon programme.
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.
Objective Caml version 3.08.2
# let t = Array.make 10 0;; val t : int array = [|0; 0; 0; 0; 0; 0; 0; 0; 0; 0|] # t.(10) <- 1;; Exception: Invalid_argument "index out of bounds". #
C'est quoi le problème ? J'essaie d'écrire dans la 10ème cas, qui n'existe pas. Ocaml me génère une exception pour m'en avertir. C'est forcément un mauvais comportement : ocaml devrait planter, comme tout bon programme.
-- Joe Cool
Tom
Avec un minimum d'effort, ça marche aussi pour le C : http://www.cl.cam.ac.uk/~mn200/PhD/
"I chose to develop my own model for C using a structural operational semantics."
Déjà il fait son propre C, ce n'est plus les normes foireuses critiquées ici. Ensuite bien sûr avec une sémantique opérationnelle on peut faire une syntaxe impérative déterministe. Ca donnerait déjà de la crédibilité au C. Ce qui n'est pas le cas actuellement. Donc oui : on peut bricoler le C pour qu'au moins syntaxiquement il soit cohérent. Est-ce que ça va être utilisé ? Ce n'est pas sûr.
Tom
Avec un minimum d'effort, ça marche aussi pour le C :
http://www.cl.cam.ac.uk/~mn200/PhD/
"I chose to develop my own model for C using a structural operational
semantics."
Déjà il fait son propre C, ce n'est plus les normes foireuses critiquées
ici. Ensuite bien sûr avec une sémantique opérationnelle on peut faire
une syntaxe impérative déterministe. Ca donnerait déjà de la crédibilité
au C. Ce qui n'est pas le cas actuellement.
Donc oui : on peut bricoler le C pour qu'au moins syntaxiquement il soit
cohérent. Est-ce que ça va être utilisé ? Ce n'est pas sûr.
Avec un minimum d'effort, ça marche aussi pour le C : http://www.cl.cam.ac.uk/~mn200/PhD/
"I chose to develop my own model for C using a structural operational semantics."
Déjà il fait son propre C, ce n'est plus les normes foireuses critiquées ici. Ensuite bien sûr avec une sémantique opérationnelle on peut faire une syntaxe impérative déterministe. Ca donnerait déjà de la crédibilité au C. Ce qui n'est pas le cas actuellement. Donc oui : on peut bricoler le C pour qu'au moins syntaxiquement il soit cohérent. Est-ce que ça va être utilisé ? Ce n'est pas sûr.
Tom
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Blaise Potard écrivait dans fr.comp.os.linux.debats :
Joe Cool wrote:
Bof, à une fusée Ariane pour chaque essai, à combien peut s'élever le déboguage d'un programme de contrôle en C ?
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
Faux. Je travaillais dans la boîte qui travaillait justement sur le truc en question (quelque part sur les falaises de la vallée de la Seine pour ceux qui connaissent).
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é...
C'est justement parce que quelqu'un a dit "ADA, c'est moisi", que le problème a surgi. Dépassement de capacité dans un registre, ADA travaillant sur 6 bits, le C sur 8 et boum... Le C ne sait pas gérer une exception...
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Blaise Potard écrivait dans fr.comp.os.linux.debats :
Joe Cool wrote:
Bof, à une fusée Ariane pour chaque essai, à combien peut s'élever le
déboguage d'un programme de contrôle en C ?
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
Faux. Je travaillais dans la boîte qui travaillait justement sur le
truc en question (quelque part sur les falaises de la vallée de la
Seine pour ceux qui connaissent).
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é...
C'est justement parce que quelqu'un a dit "ADA, c'est moisi", que le
problème a surgi. Dépassement de capacité dans un registre, ADA
travaillant sur 6 bits, le C sur 8 et boum... Le C ne sait pas
gérer une exception...
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Blaise Potard écrivait dans fr.comp.os.linux.debats :
Joe Cool wrote:
Bof, à une fusée Ariane pour chaque essai, à combien peut s'élever le déboguage d'un programme de contrôle en C ?
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
Faux. Je travaillais dans la boîte qui travaillait justement sur le truc en question (quelque part sur les falaises de la vallée de la Seine pour ceux qui connaissent).
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é...
C'est justement parce que quelqu'un a dit "ADA, c'est moisi", que le problème a surgi. Dépassement de capacité dans un registre, ADA travaillant sur 6 bits, le C sur 8 et boum... Le C ne sait pas gérer une exception...
JKB
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Thierry Boudet écrivait dans fr.comp.os.linux.debats :
On 2005-03-09, Tom wrote:
La philosophie du C est dépassée depuis vingt à trente ans.
Ben tant mieux. Je suis aussi dépassé depuis vingt ans.
Mais non, mais non...
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Thierry Boudet écrivait dans fr.comp.os.linux.debats :
On 2005-03-09, Tom <tom@tom.com> wrote:
La philosophie du C est dépassée depuis vingt à trente ans.
Ben tant mieux. Je suis aussi dépassé depuis vingt ans.
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Thierry Boudet écrivait dans fr.comp.os.linux.debats :
On 2005-03-08, JKB wrote:
Montre-moi un seul bout de code où il n'y a pas en C une seule instruction à comportement indéfini (au moins sur un ensemble).
a = 0;
On ne va pas loin, avec ça...
Alors partons de l'hypothèse d'une machine à zéro signé.
En cherchant bien, je vais t'en trouver une... De toute façon, on n'ira pas beaucoup plus loin...
JKB
-- _/°< gniark-o-troll PAN !
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Benjamin FRANCOIS écrivait dans fr.comp.os.linux.debats :
Tom s'est exprimé en ces termes:
Et après ce sont mes propos qui n'ont rien à faire ici. Vous voulez quoi que je vienne dire toute mon admiration sur linux, c'est ça un débat ? J'aime bien Linux. Mais c'est loin d'être bien foutu. Et pour être bien foutu ça devrait être fait dans un langage bien foutu.
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
Bliss ?
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Benjamin FRANCOIS écrivait dans fr.comp.os.linux.debats :
Tom s'est exprimé en ces termes:
Et après ce sont mes propos qui n'ont rien à faire ici. Vous voulez quoi
que je vienne dire toute mon admiration sur linux, c'est ça un débat ?
J'aime bien Linux. Mais c'est loin d'être bien foutu. Et pour être bien
foutu ça devrait être fait dans un langage bien foutu.
Vient donc la question: dans quel langage devrait-on le récrire, à ton
avis, pour que ça devienne bien foutu ?
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Benjamin FRANCOIS écrivait dans fr.comp.os.linux.debats :
Tom s'est exprimé en ces termes:
Et après ce sont mes propos qui n'ont rien à faire ici. Vous voulez quoi que je vienne dire toute mon admiration sur linux, c'est ça un débat ? J'aime bien Linux. Mais c'est loin d'être bien foutu. Et pour être bien foutu ça devrait être fait dans un langage bien foutu.
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
Bliss ?
JKB
Tom
Ca s'appelle un langage bas niveau.
Si tu prend bas niveau au sens mal foutu je suis d'accord.
C'est vrai qu'avec des programmes entierement ecrits en caml, tout serait different. Il suffit de regarder mldonkey, pour lequel on se demande pourquoi ils ont creer une mailling list mldonkey-bugs : http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs A peine une centaine de messages par mois, ca doit surement etre pour dire qu'en Caml, il n'y a pas de bugs possibles. C'est à l'interfaçage avec le C que ça merde. Dès qu'on se rapproche du
système ça devient instable. C'est dommage, parce que des gens tentent de faire de bonnes choses.
Oui, ca fait quelques lignes. Et ? C'est sur, si tu veux te contenter d'un HelloWorld, Java est pas forcement le langage le plus adapte. Si un programme simple n'est pas simple quelle gueule a un programme
compliqué ? A moins que plus ton programme fait de trucs et plus il est simple. Dans ce cas c'est magique comme langage ça !
Est ce que tu as deja essaie de prouver un programme qui fait autre chose qu'un hello world ? La fonction d'Ackermann par exemple.
Mais tu veux des exemples de programmes spécifiés ? L'élection du leader dans un réseau firewire, l'algorithme de prim, etc. Ca se prouve.
Toi aussi t'es comme luc2 ? Le sauveur qui vient nous sauver de cet abominable piege qu'est le C ?
Je ne connais pas ce personnage. Mais il a l'air d'avoir des choses intéressantes à dire. si vous prenez pour un con quelqu'un qui vous met en garde contre les méfaits d'un langage comme le C, visibles dans la vie de tous les jours ce n'est plus mon problème. Si vous êtes arrivés au point où c'est normal d'avoir des bugs dans ses programmes, c'est pas mon problème. Je veux juste que quelqu'un vous ait dit un jour que ce n'est pas normal. Après vous êtes majeurs et vaccinés (enfin je le suppose sinon votre maman vous fera un mot) et vous pouvez choisir ce que vous voulez. Si vous voulez rester dans la matrice du C faites, j'en ai rien à battre. Ca m'empêchera pas de dormir ce soir.
Tom
Ca s'appelle un langage bas niveau.
Si tu prend bas niveau au sens mal foutu je suis d'accord.
C'est vrai qu'avec des programmes entierement ecrits en caml, tout serait
different. Il suffit de regarder mldonkey, pour lequel on se demande
pourquoi ils ont creer une mailling list mldonkey-bugs :
http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs
A peine une centaine de messages par mois, ca doit surement etre pour
dire qu'en Caml, il n'y a pas de bugs possibles.
C'est à l'interfaçage avec le C que ça merde. Dès qu'on se rapproche du
système ça devient instable. C'est dommage, parce que des gens tentent
de faire de bonnes choses.
Oui, ca fait quelques lignes. Et ? C'est sur, si tu veux te contenter
d'un HelloWorld, Java est pas forcement le langage le plus adapte.
Si un programme simple n'est pas simple quelle gueule a un programme
compliqué ? A moins que plus ton programme fait de trucs et plus il est
simple. Dans ce cas c'est magique comme langage ça !
Est ce que tu as deja essaie de prouver un programme qui fait autre
chose qu'un hello world ?
La fonction d'Ackermann par exemple.
Mais tu veux des exemples de programmes spécifiés ? L'élection du leader
dans un réseau firewire, l'algorithme de prim, etc. Ca se prouve.
Toi aussi t'es comme luc2 ? Le sauveur qui vient nous sauver de cet
abominable piege qu'est le C ?
Je ne connais pas ce personnage. Mais il a l'air d'avoir des choses
intéressantes à dire. si vous prenez pour un con quelqu'un qui vous met
en garde contre les méfaits d'un langage comme le C, visibles dans la
vie de tous les jours ce n'est plus mon problème. Si vous êtes arrivés
au point où c'est normal d'avoir des bugs dans ses programmes, c'est pas
mon problème. Je veux juste que quelqu'un vous ait dit un jour que ce
n'est pas normal. Après vous êtes majeurs et vaccinés (enfin je le
suppose sinon votre maman vous fera un mot) et vous pouvez choisir ce
que vous voulez. Si vous voulez rester dans la matrice du C faites, j'en
ai rien à battre. Ca m'empêchera pas de dormir ce soir.
Si tu prend bas niveau au sens mal foutu je suis d'accord.
C'est vrai qu'avec des programmes entierement ecrits en caml, tout serait different. Il suffit de regarder mldonkey, pour lequel on se demande pourquoi ils ont creer une mailling list mldonkey-bugs : http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs A peine une centaine de messages par mois, ca doit surement etre pour dire qu'en Caml, il n'y a pas de bugs possibles. C'est à l'interfaçage avec le C que ça merde. Dès qu'on se rapproche du
système ça devient instable. C'est dommage, parce que des gens tentent de faire de bonnes choses.
Oui, ca fait quelques lignes. Et ? C'est sur, si tu veux te contenter d'un HelloWorld, Java est pas forcement le langage le plus adapte. Si un programme simple n'est pas simple quelle gueule a un programme
compliqué ? A moins que plus ton programme fait de trucs et plus il est simple. Dans ce cas c'est magique comme langage ça !
Est ce que tu as deja essaie de prouver un programme qui fait autre chose qu'un hello world ? La fonction d'Ackermann par exemple.
Mais tu veux des exemples de programmes spécifiés ? L'élection du leader dans un réseau firewire, l'algorithme de prim, etc. Ca se prouve.
Toi aussi t'es comme luc2 ? Le sauveur qui vient nous sauver de cet abominable piege qu'est le C ?
Je ne connais pas ce personnage. Mais il a l'air d'avoir des choses intéressantes à dire. si vous prenez pour un con quelqu'un qui vous met en garde contre les méfaits d'un langage comme le C, visibles dans la vie de tous les jours ce n'est plus mon problème. Si vous êtes arrivés au point où c'est normal d'avoir des bugs dans ses programmes, c'est pas mon problème. Je veux juste que quelqu'un vous ait dit un jour que ce n'est pas normal. Après vous êtes majeurs et vaccinés (enfin je le suppose sinon votre maman vous fera un mot) et vous pouvez choisir ce que vous voulez. Si vous voulez rester dans la matrice du C faites, j'en ai rien à battre. Ca m'empêchera pas de dormir ce soir.
Tom
Miguel Moquillon
nicolas vigier wrote:
On 2005-03-09, Tom wrote:
Après le simili Gödel, le simili Bach. Non sans rire, vous avez bien avalé ce qu'on vous a dit en apprenant le C. Vous croyez au père noël aussi ? Faut arrêter les conneries 5 minutes. Le C n'est pas proche de la machine. Il est juste une surcouche au dessus des langages d'assemblages qui constituent les instructions d'une grosse partie des processeurs actuels.
Ce qui pour resumer, s'appelle un langage proche de la machine.
Donc, on peut dire alors qu'Ada est proche aussi de la machine.
nicolas vigier wrote:
On 2005-03-09, Tom <tom@tom.com> wrote:
Après le simili Gödel, le simili Bach.
Non sans rire, vous avez bien avalé ce qu'on vous a dit en apprenant le
C. Vous croyez au père noël aussi ? Faut arrêter les conneries 5
minutes. Le C n'est pas proche de la machine. Il est juste une surcouche
au dessus des langages d'assemblages qui constituent les instructions
d'une grosse partie des processeurs actuels.
Ce qui pour resumer, s'appelle un langage proche de la machine.
Donc, on peut dire alors qu'Ada est proche aussi de la machine.
Après le simili Gödel, le simili Bach. Non sans rire, vous avez bien avalé ce qu'on vous a dit en apprenant le C. Vous croyez au père noël aussi ? Faut arrêter les conneries 5 minutes. Le C n'est pas proche de la machine. Il est juste une surcouche au dessus des langages d'assemblages qui constituent les instructions d'une grosse partie des processeurs actuels.
Ce qui pour resumer, s'appelle un langage proche de la machine.
Donc, on peut dire alors qu'Ada est proche aussi de la machine.
