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.
Le 08-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
JKB a exposé le 08/03/2005 :
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a
Votre code en tant que tel ne donnera pas le même résultat en fonction des architectures.
Ce n'est pas ce qu'on entend par portable. Par portable, on entend que le code donne un résultat _correct_ sur toutes les architectures, c'est à dire conforme à ses spécifications. Il est en particulier tout à fait légitime qu'une architecture plus « puissante » permette de pousser le calcul plus loin. Après tout, on n'attend pas non plus que le code se termine en le même temps sur toutes les architectures.
Et moi, j'entends par portable : « qui doit donner le _même_ résultat ».
Tu fais comment quand la vitesse du pricesseur augmente ?
Je ne m'intéresse pas à la vitesse mais au résultat, comprendre les données générées par le code.
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
JustMe écrivait dans fr.comp.os.linux.debats :
JKB a exposé le 08/03/2005 :
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2s3tk.mkg.knatschke@rayleigh.systella.fr>, a
Votre code en tant que tel ne donnera pas le même résultat en
fonction des architectures.
Ce n'est pas ce qu'on entend par portable. Par portable, on entend que le
code donne un résultat _correct_ sur toutes les architectures, c'est à dire
conforme à ses spécifications. Il est en particulier tout à fait légitime
qu'une architecture plus « puissante » permette de pousser le calcul plus
loin. Après tout, on n'attend pas non plus que le code se termine en le même
temps sur toutes les architectures.
Et moi, j'entends par portable : « qui doit donner le _même_
résultat ».
Tu fais comment quand la vitesse du pricesseur augmente ?
Je ne m'intéresse pas à la vitesse mais au résultat, comprendre les
données générées par le code.
Le 08-03-2005, à propos de Re: a-t-on le choix ?, JustMe écrivait dans fr.comp.os.linux.debats :
JKB a exposé le 08/03/2005 :
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a
Votre code en tant que tel ne donnera pas le même résultat en fonction des architectures.
Ce n'est pas ce qu'on entend par portable. Par portable, on entend que le code donne un résultat _correct_ sur toutes les architectures, c'est à dire conforme à ses spécifications. Il est en particulier tout à fait légitime qu'une architecture plus « puissante » permette de pousser le calcul plus loin. Après tout, on n'attend pas non plus que le code se termine en le même temps sur toutes les architectures.
Et moi, j'entends par portable : « qui doit donner le _même_ résultat ».
Tu fais comment quand la vitesse du pricesseur augmente ?
Je ne m'intéresse pas à la vitesse mais au résultat, comprendre les données générées par le code.
JKB
Nicolas Le Scouarnec
Pas dit ca ;-) Relire, comprendre :-D UN système d'exploitation doit utiliser un langage qui peut faire
planter la machine, c'est donc pour la faire planter, sinon on en choisirais un qui ne peut pas faire planter la machine.
Doit utiliser un langage qui permet d'acceder au matériel ?
un while(1); dans une section ininterruptible suffit. Et si tu n'as pas de notion d'ininterruptibilité, tu vas avoir du mal a faire un OS... Qui à besoin d'un while ? Ceux qui ne connaissent rien d'autre que le C
et les langages du même tonneau.
Et récursivité infinie, dans un langage fonctionelle, ca fait un peu la meme chose, et le compilateur ne crie pas... Donc on peut aussi avoir des problemes dans des langages d'un autre tonneau.
Sinon, pour le C, il a des particularités, il plante avec en général un seul message d'erreur: segfault, mais il y a un petit "paquet" d'applications existant en C. Les compilateurs C existent pour pleins d'archi (pas seulement x86) et je vois mal comment manipuler un microprocesseur avec du CAML. Ca ne veut pas dire que le CAML est mauvais, ca veut juste dire qu'il faut choisir le langage le plus adapté a un probleme. En passant, il paraitrait aussi, que dans certains cas, la programmation itérative est beaucoup plus rapide que de la programmation récursive pure.
-- Nicolas Le Scouarnec
Pas dit ca ;-) Relire, comprendre :-D
UN système d'exploitation doit utiliser un langage qui peut faire
planter la machine, c'est donc pour la faire planter, sinon on en
choisirais un qui ne peut pas faire planter la machine.
Doit utiliser un langage qui permet d'acceder au matériel ?
un while(1); dans une section ininterruptible suffit. Et si tu n'as pas
de notion d'ininterruptibilité, tu vas avoir du mal a faire un OS...
Qui à besoin d'un while ? Ceux qui ne connaissent rien d'autre que le C
et les langages du même tonneau.
Et récursivité infinie, dans un langage fonctionelle, ca fait un peu la
meme chose, et le compilateur ne crie pas... Donc on peut aussi avoir
des problemes dans des langages d'un autre tonneau.
Sinon, pour le C, il a des particularités, il plante avec en général
un seul message d'erreur: segfault, mais il y a un petit "paquet"
d'applications existant en C. Les compilateurs C existent pour pleins
d'archi (pas seulement x86) et je vois mal comment manipuler un
microprocesseur avec du CAML. Ca ne veut pas dire que le CAML est
mauvais, ca veut juste dire qu'il faut choisir le langage le plus
adapté a un probleme. En passant, il paraitrait aussi, que dans
certains cas, la programmation itérative est beaucoup plus rapide que
de la programmation récursive pure.
Pas dit ca ;-) Relire, comprendre :-D UN système d'exploitation doit utiliser un langage qui peut faire
planter la machine, c'est donc pour la faire planter, sinon on en choisirais un qui ne peut pas faire planter la machine.
Doit utiliser un langage qui permet d'acceder au matériel ?
un while(1); dans une section ininterruptible suffit. Et si tu n'as pas de notion d'ininterruptibilité, tu vas avoir du mal a faire un OS... Qui à besoin d'un while ? Ceux qui ne connaissent rien d'autre que le C
et les langages du même tonneau.
Et récursivité infinie, dans un langage fonctionelle, ca fait un peu la meme chose, et le compilateur ne crie pas... Donc on peut aussi avoir des problemes dans des langages d'un autre tonneau.
Sinon, pour le C, il a des particularités, il plante avec en général un seul message d'erreur: segfault, mais il y a un petit "paquet" d'applications existant en C. Les compilateurs C existent pour pleins d'archi (pas seulement x86) et je vois mal comment manipuler un microprocesseur avec du CAML. Ca ne veut pas dire que le CAML est mauvais, ca veut juste dire qu'il faut choisir le langage le plus adapté a un probleme. En passant, il paraitrait aussi, que dans certains cas, la programmation itérative est beaucoup plus rapide que de la programmation récursive pure.
-- Nicolas Le Scouarnec
Jerome Lambert
(...)
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Allez raconter ça sur fr.comp.lang.c, qu'on rigole un peu...
(...)
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Allez raconter ça sur fr.comp.lang.c, qu'on rigole un peu...
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Allez raconter ça sur fr.comp.lang.c, qu'on rigole un peu...
Nicolas Le Scouarnec
Si on ne s'est pas assuré à l'avance de la taille sur laquelle on fait cette arithmétique, c'est une erreur, c'est tout. Non, car la norme ne dit pas que c'est une erreur, elle dit que le
comportement est à la discretion de l'implémentation.
Pourquoi utiliser cela ? Si on veut faire un tel calcul, on le remplace par a % 65536, c'est plus "sur", je ne vois pas l'interet de se baser sur un comportement non determiné, surtout quand on veut faire un code portable. Si on a choisit de faire du code non portable, on peut mettre de l'assembleur directement dans le source, en C, en CAML, ... comme ca, on est sur que cela ne sera pas portable...
Ben oui, et alors ? Alors utiliser de l'arithmétique modulo la valeur maximale des
données n'est pas une erreur, c'est un comportement indéfini.
Et il faut donc essayer pour vérifier que cela marche avec le compilateur, n'est-ce pas acrobatique ?
Si tu veux un autre exemple, je n'ai pas vérifié, on m'a juste expliqué que ce n'était pas une bonne idée. Si tu définis un champ de bit, tu ne sais pas dans quel sens il sera stocké (poids fort ou poid faible en premier). Pourtant, on peut trouver plus facilement une utilité pour un champ de bit...
-- Nicolas Le Scouarnec
Si on ne s'est pas assuré à l'avance de la taille sur laquelle on
fait cette arithmétique, c'est une erreur, c'est tout.
Non, car la norme ne dit pas que c'est une erreur, elle dit que le
comportement est à la discretion de l'implémentation.
Pourquoi utiliser cela ? Si on veut faire un tel calcul, on le remplace
par a % 65536, c'est plus "sur", je ne vois pas l'interet de se baser
sur un comportement non determiné, surtout quand on veut faire un code
portable. Si on a choisit de faire du code non portable, on peut mettre
de l'assembleur directement dans le source, en C, en CAML, ... comme
ca, on est sur que cela ne sera pas portable...
Ben oui, et alors ?
Alors utiliser de l'arithmétique modulo la valeur maximale des
données n'est pas une erreur, c'est un comportement indéfini.
Et il faut donc essayer pour vérifier que cela marche avec le
compilateur, n'est-ce pas acrobatique ?
Si tu veux un autre exemple, je n'ai pas vérifié, on m'a juste expliqué
que ce n'était pas une bonne idée. Si tu définis un champ de bit, tu ne
sais pas dans quel sens il sera stocké (poids fort ou poid faible en
premier). Pourtant, on peut trouver plus facilement une utilité pour un
champ de bit...
Si on ne s'est pas assuré à l'avance de la taille sur laquelle on fait cette arithmétique, c'est une erreur, c'est tout. Non, car la norme ne dit pas que c'est une erreur, elle dit que le
comportement est à la discretion de l'implémentation.
Pourquoi utiliser cela ? Si on veut faire un tel calcul, on le remplace par a % 65536, c'est plus "sur", je ne vois pas l'interet de se baser sur un comportement non determiné, surtout quand on veut faire un code portable. Si on a choisit de faire du code non portable, on peut mettre de l'assembleur directement dans le source, en C, en CAML, ... comme ca, on est sur que cela ne sera pas portable...
Ben oui, et alors ? Alors utiliser de l'arithmétique modulo la valeur maximale des
données n'est pas une erreur, c'est un comportement indéfini.
Et il faut donc essayer pour vérifier que cela marche avec le compilateur, n'est-ce pas acrobatique ?
Si tu veux un autre exemple, je n'ai pas vérifié, on m'a juste expliqué que ce n'était pas une bonne idée. Si tu définis un champ de bit, tu ne sais pas dans quel sens il sera stocké (poids fort ou poid faible en premier). Pourtant, on peut trouver plus facilement une utilité pour un champ de bit...
-- Nicolas Le Scouarnec
Guillaume L.
En passant, il paraitrait aussi, que dans certains cas, la programmation itérative est beaucoup plus rapide que de la programmation récursive pure.
Si tu parles de la rapidité de programmation, je ne pense pas, c'est une question d'habitude.
Si tu parles de la rapidité du programme, alors dans certains cas (rares) seulement alors.
Il suffit que le compilateur soit un peu intelligent et le programmeur pas trop stupide. Le programmeur utilise alors la récursion terminale, et le compililateur met ceci sous forme de JMP, et non CALL, lors du passage à l'assembleur (mettre les instructions idoines, selon l'archi). Ce qui revient à une boucle.
Guillaume Leconte.
-- You're not a beautiful and unique snowflake.
En passant, il paraitrait aussi, que dans
certains cas, la programmation itérative est beaucoup plus rapide que
de la programmation récursive pure.
Si tu parles de la rapidité de programmation, je ne pense pas, c'est une
question d'habitude.
Si tu parles de la rapidité du programme, alors dans certains cas (rares)
seulement alors.
Il suffit que le compilateur soit un peu intelligent et le programmeur pas
trop stupide.
Le programmeur utilise alors la récursion terminale, et le compililateur met
ceci sous forme de JMP, et non CALL, lors du passage à l'assembleur (mettre
les instructions idoines, selon l'archi). Ce qui revient à une boucle.
En passant, il paraitrait aussi, que dans certains cas, la programmation itérative est beaucoup plus rapide que de la programmation récursive pure.
Si tu parles de la rapidité de programmation, je ne pense pas, c'est une question d'habitude.
Si tu parles de la rapidité du programme, alors dans certains cas (rares) seulement alors.
Il suffit que le compilateur soit un peu intelligent et le programmeur pas trop stupide. Le programmeur utilise alors la récursion terminale, et le compililateur met ceci sous forme de JMP, et non CALL, lors du passage à l'assembleur (mettre les instructions idoines, selon l'archi). Ce qui revient à une boucle.
Et est ce que l'un de vous deux a des arguments ? À part traiter l'autre d'abruti qui n'a rien compris je ne vois pas grand chose.
:-)
Essaie de suivre tu verras que derriere tous ça il y a deux grands esprits. Il y a de la philosophie, beaucoup d'exemples, et des explications. Ils ne s'entendent tout simplement pas sur les détails de la signification exacte de 2 ou trois mots. Sinon, c'est digne de fcold...
-- 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)
Et est ce que l'un de vous deux a des arguments ? À part traiter l'autre
d'abruti qui n'a rien compris je ne vois pas grand chose.
:-)
Essaie de suivre tu verras que derriere tous ça il y a deux grands
esprits.
Il y a de la philosophie, beaucoup d'exemples, et des explications.
Ils ne s'entendent tout simplement pas sur les détails de la
signification exacte de 2 ou trois mots. Sinon, c'est digne de fcold...
--
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)
Et est ce que l'un de vous deux a des arguments ? À part traiter l'autre d'abruti qui n'a rien compris je ne vois pas grand chose.
:-)
Essaie de suivre tu verras que derriere tous ça il y a deux grands esprits. Il y a de la philosophie, beaucoup d'exemples, et des explications. Ils ne s'entendent tout simplement pas sur les détails de la signification exacte de 2 ou trois mots. Sinon, c'est digne de fcold...
-- 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)
Rakotomandimby (R12y) Mihamina
( Tue, 08 Mar 2005 21:51:30 +0000 ) Nicolas Le Scouarnec :
Et récursivité infinie, dans un langage fonctionelle, [...] le compilateur ne crie pas.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
-- 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 21:51:30 +0000 ) Nicolas Le Scouarnec :
Et récursivité infinie, dans un langage fonctionelle, [...]
le compilateur ne crie pas.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une
suite de fabionacci (donc pas grand chose) en OCaml. D'une manière
recursive j'entends.
--
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 21:51:30 +0000 ) Nicolas Le Scouarnec :
Et récursivité infinie, dans un langage fonctionelle, [...] le compilateur ne crie pas.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
-- 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)
Nicolas George
R12y, dans le message , a écrit :
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
De manière récursive, mais pas récursive terminale.
R12y, dans le message <pan.2005.03.08.22.41.58.11179@mail.rktmb.org>, a
écrit :
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une
suite de fabionacci (donc pas grand chose) en OCaml. D'une manière
recursive j'entends.
De manière récursive, mais pas récursive terminale.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
De manière récursive, mais pas récursive terminale.
Guillaume L.
( Tue, 08 Mar 2005 21:51:30 +0000 ) Nicolas Le Scouarnec :
Et récursivité infinie, dans un langage fonctionelle, [...] le compilateur ne crie pas.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
Ahem, tu es certain que c'est le compilateur qui hurlait ?
Guillaume Leconte.
-- You're not a beautiful and unique snowflake.
( Tue, 08 Mar 2005 21:51:30 +0000 ) Nicolas Le Scouarnec :
Et récursivité infinie, dans un langage fonctionelle, [...]
le compilateur ne crie pas.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une
suite de fabionacci (donc pas grand chose) en OCaml. D'une manière
recursive j'entends.
Ahem, tu es certain que c'est le compilateur qui hurlait ?
( Tue, 08 Mar 2005 21:51:30 +0000 ) Nicolas Le Scouarnec :
Et récursivité infinie, dans un langage fonctionelle, [...] le compilateur ne crie pas.
Si si ... j'ai dejà eu un stack overflow en calculant les termes d'une suite de fabionacci (donc pas grand chose) en OCaml. D'une manière recursive j'entends.
Ahem, tu es certain que c'est le compilateur qui hurlait ?
Guillaume Leconte.
-- You're not a beautiful and unique snowflake.
Irvin Probst
On 2005-03-08, Rakotomandimby (R12y) Mihamina wrote:
Essaie de suivre tu verras que derriere tous ça il y a deux grands esprits. Il y a de la philosophie, beaucoup d'exemples, et des explications. Ils ne s'entendent tout simplement pas sur les détails de la signification exacte de 2 ou trois mots. Sinon, c'est digne de fcold...
Oh bah, j'ai les idées plutôt claires sur ce qu'ils racontent (je suis payé pour ça après tout), c'est juste que je trouve le "débat" absolument pathétique.
-- Irvin
On 2005-03-08, Rakotomandimby (R12y) Mihamina <mihamina@mail.rktmb.org> wrote:
Essaie de suivre tu verras que derriere tous ça il y a deux grands
esprits.
Il y a de la philosophie, beaucoup d'exemples, et des explications.
Ils ne s'entendent tout simplement pas sur les détails de la
signification exacte de 2 ou trois mots. Sinon, c'est digne de fcold...
Oh bah, j'ai les idées plutôt claires sur ce qu'ils racontent (je suis
payé pour ça après tout), c'est juste que je trouve le "débat" absolument
pathétique.
On 2005-03-08, Rakotomandimby (R12y) Mihamina wrote:
Essaie de suivre tu verras que derriere tous ça il y a deux grands esprits. Il y a de la philosophie, beaucoup d'exemples, et des explications. Ils ne s'entendent tout simplement pas sur les détails de la signification exacte de 2 ou trois mots. Sinon, c'est digne de fcold...
Oh bah, j'ai les idées plutôt claires sur ce qu'ils racontent (je suis payé pour ça après tout), c'est juste que je trouve le "débat" absolument pathétique.
