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.
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable.
Ah ? Source ?
C'est le principe fondamental de l'overcommit.
--
Michel TALON
Nicolas George
Eric Dorino , dans le message , a écrit :
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. Dans le cas général d'un langage typé universel:
On appelle ça un exemple, pas un cas général. Savoir si après tel ou tel calcul, le résultat sera dans un intervalle donné quelle que soit l'entrée fixée à l'avance peut se ramener à la preuve de n'importe quel théorème d'arithmétique, et est donc indécidable.
Eric Dorino , dans le message
<pan.2005.03.09.17.17.47.785002@invalid.org>, a écrit :
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.
Dans le cas général d'un langage typé universel:
On appelle ça un exemple, pas un cas général. Savoir si après tel ou tel
calcul, le résultat sera dans un intervalle donné quelle que soit l'entrée
fixée à l'avance peut se ramener à la preuve de n'importe quel théorème
d'arithmétique, et est donc indécidable.
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. Dans le cas général d'un langage typé universel:
On appelle ça un exemple, pas un cas général. Savoir si après tel ou tel calcul, le résultat sera dans un intervalle donné quelle que soit l'entrée fixée à l'avance peut se ramener à la preuve de n'importe quel théorème d'arithmétique, et est donc indécidable.
Nicolas George
Joe Cool , dans le message <422f2b1f$0$25589$, a écrit :
Les rares qui sont suffisamment intelligents pour faire du caml à la place du C n'ont pas forcément assez de main d'oeuvre pour faire ce genre de chose.
On s'approche dangereusement de la théorie du complot.
De plus, en suivant ce raisonnement, on en conclus que le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux dernier cri.
Je ne vois pas comment tu peux déduire ça.
Joe Cool , dans le message <422f2b1f$0$25589$626a14ce@news.free.fr>, a
écrit :
Les rares qui sont suffisamment intelligents pour faire du caml à la
place du C n'ont pas forcément assez de main d'oeuvre pour faire ce
genre de chose.
On s'approche dangereusement de la théorie du complot.
De plus, en suivant ce raisonnement, on en conclus que
le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux
dernier cri.
Joe Cool , dans le message <422f2b1f$0$25589$, a écrit :
Les rares qui sont suffisamment intelligents pour faire du caml à la place du C n'ont pas forcément assez de main d'oeuvre pour faire ce genre de chose.
On s'approche dangereusement de la théorie du complot.
De plus, en suivant ce raisonnement, on en conclus que le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux dernier cri.
Je ne vois pas comment tu peux déduire ça.
Richard Delorme
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Stephane TOUGARD écrivait dans fr.comp.os.linux.debats :
Benjamin FRANCOIS wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
Je propose le Cobol.
Fortran ?
JKB, fortraneux irréductible frappant les maniaques du C qui osent faire en C du calcul scientifique avec le K&R
C'est après avoir essayé Fortran, que Thompson a créé le langage B, qui allait donner ensuite le C : http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
« After a rapidly scuttled attempt at Fortran, he created instead a language of his own, which he called B. »
-- Richard
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Stephane TOUGARD écrivait dans fr.comp.os.linux.debats :
Benjamin FRANCOIS wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton
avis, pour que ça devienne bien foutu ?
Je propose le Cobol.
Fortran ?
JKB, fortraneux irréductible frappant les maniaques du C qui osent
faire en C du calcul scientifique avec le K&R
C'est après avoir essayé Fortran, que Thompson a créé le langage B, qui
allait donner ensuite le C :
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
« After a rapidly scuttled attempt at Fortran, he created instead a
language of his own, which he called B. »
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Stephane TOUGARD écrivait dans fr.comp.os.linux.debats :
Benjamin FRANCOIS wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
Je propose le Cobol.
Fortran ?
JKB, fortraneux irréductible frappant les maniaques du C qui osent faire en C du calcul scientifique avec le K&R
C'est après avoir essayé Fortran, que Thompson a créé le langage B, qui allait donner ensuite le C : http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
« After a rapidly scuttled attempt at Fortran, he created instead a language of his own, which he called B. »
-- Richard
JustMe
Michel Talon a couché sur son écran :
JustMe wrote:
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable.
Ah ? Source ?
C'est le principe fondamental de l'overcommit.
Ok, je decouvre. Super dangeureux. Heureusement que c'est desactivé par defaut sur les machines que j'ai sous la main. Je vais verifier sur les autres et le virer si par hasard cette horreur est active !
Michel Talon a couché sur son écran :
JustMe <pasdespam@merci.beaucoup> wrote:
Et personne n'assure que si malloc() renvoie un pointeur non NULL,
la mémoire est utilisable.
Ah ? Source ?
C'est le principe fondamental de l'overcommit.
Ok, je decouvre. Super dangeureux. Heureusement que c'est desactivé par
defaut sur les machines que j'ai sous la main. Je vais verifier sur les
autres et le virer si par hasard cette horreur est active !
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable.
Ah ? Source ?
C'est le principe fondamental de l'overcommit.
Ok, je decouvre. Super dangeureux. Heureusement que c'est desactivé par defaut sur les machines que j'ai sous la main. Je vais verifier sur les autres et le virer si par hasard cette horreur est active !
Joe Cool
Joe Cool , dans le message <422f274a$0$30326$, a
Voilà une définition de la protabilité qui rend portable tout et n'importe quoi, puisque cette notion ne dépend que de la conformité des implémentations : si les implémentations sont conformes à leurs propres normes, alors le langage est portable.
Précisément. Ça prouve essentiellement que la notion de langage portable, ça ne veut rien dire. Merci d'abonder dans mon sens.
Ça prouve seulement que votre définition ne veut rien dire. Vous avez beau critiquer la mienne (en fait vous la rejettez sans justification), au moins elle veut dire quelque chose.
-- Joe Cool
Joe Cool , dans le message <422f274a$0$30326$626a14ce@news.free.fr>, a
Voilà une définition de la protabilité qui rend portable tout et
n'importe quoi, puisque cette notion ne dépend que de la conformité des
implémentations : si les implémentations sont conformes à leurs propres
normes, alors le langage est portable.
Précisément. Ça prouve essentiellement que la notion de langage portable, ça
ne veut rien dire. Merci d'abonder dans mon sens.
Ça prouve seulement que votre définition ne veut rien dire. Vous avez
beau critiquer la mienne (en fait vous la rejettez sans justification),
au moins elle veut dire quelque chose.
Voilà une définition de la protabilité qui rend portable tout et n'importe quoi, puisque cette notion ne dépend que de la conformité des implémentations : si les implémentations sont conformes à leurs propres normes, alors le langage est portable.
Précisément. Ça prouve essentiellement que la notion de langage portable, ça ne veut rien dire. Merci d'abonder dans mon sens.
Ça prouve seulement que votre définition ne veut rien dire. Vous avez beau critiquer la mienne (en fait vous la rejettez sans justification), au moins elle veut dire quelque chose.
-- Joe Cool
Eric Jacoboni
Joe Cool writes:
De plus, en suivant ce raisonnement, on en conclus que le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux dernier cri.
Et bien oui, Cobol est meilleur que le C pour ce qui est de programmer des applications de gestion et Windows 3.1 est meilleur que Linux pour faire tourner Word 2 for Windows.
Ça ne vole vraiment pas haut.
Non, effectivement, mais à jouer à celui qui a la plus grosse, ça ne peut guère aller plus loin. -- Éric Jacoboni, né il y a 1413830958 secondes
Joe Cool <zierouhli_@d_free.fr> writes:
De plus, en suivant ce raisonnement, on en conclus que le Cobol est
meilleur que le C et que Windows 3.1 est meilleur que Linux dernier
cri.
Et bien oui, Cobol est meilleur que le C pour ce qui est de programmer
des applications de gestion et Windows 3.1 est meilleur que Linux pour
faire tourner Word 2 for Windows.
Ça ne vole vraiment pas haut.
Non, effectivement, mais à jouer à celui qui a la plus grosse, ça ne
peut guère aller plus loin.
--
Éric Jacoboni, né il y a 1413830958 secondes
De plus, en suivant ce raisonnement, on en conclus que le Cobol est meilleur que le C et que Windows 3.1 est meilleur que Linux dernier cri.
Et bien oui, Cobol est meilleur que le C pour ce qui est de programmer des applications de gestion et Windows 3.1 est meilleur que Linux pour faire tourner Word 2 for Windows.
Ça ne vole vraiment pas haut.
Non, effectivement, mais à jouer à celui qui a la plus grosse, ça ne peut guère aller plus loin. -- Éric Jacoboni, né il y a 1413830958 secondes
Irvin Probst
On 2005-03-09, Joe Cool wrote:
le C (d'après vous) est une horreur
C'est objectivement une horreur, cela ne dépend pas de moi, le C est une abomination tout seul.
D'après mon objectivité le C est joli. Je peux en conclure que nos objectivités respectives sont subjectives ?
-- Irvin
On 2005-03-09, Joe Cool <zierouhli_@d_free.fr> wrote:
le C (d'après vous) est une horreur
C'est objectivement une horreur, cela ne dépend pas de moi, le C est une
abomination tout seul.
D'après mon objectivité le C est joli.
Je peux en conclure que nos objectivités respectives sont subjectives ?
C'est objectivement une horreur, cela ne dépend pas de moi, le C est une abomination tout seul.
D'après mon objectivité le C est joli. Je peux en conclure que nos objectivités respectives sont subjectives ?
-- Irvin
Irvin Probst
On 2005-03-09, Tom wrote:
Lâchez les trolls!
Quand on n'a rien d'autre à dire y'a que ça à faire.
Ou alors on peut envoyer je ne sais combien de posts pour insulter à tout va ses contradicteurs, mépriser leur travail et se poser en grand manitou de l'Informatique du XXIe siècle.
-- Irvin
On 2005-03-09, Tom <tom@tom.com> wrote:
Lâchez les trolls!
Quand on n'a rien d'autre à dire y'a que ça à faire.
Ou alors on peut envoyer je ne sais combien de posts pour insulter à
tout va ses contradicteurs, mépriser leur travail et se poser en grand
manitou de l'Informatique du XXIe siècle.
Quand on n'a rien d'autre à dire y'a que ça à faire.
Ou alors on peut envoyer je ne sais combien de posts pour insulter à tout va ses contradicteurs, mépriser leur travail et se poser en grand manitou de l'Informatique du XXIe siècle.
-- Irvin
Nicolas George
Tom , dans le message <422f2bac$0$12549$, a écrit :
Ca n'a pas de sens.
Si. Ah, je crois que je comprends ton problème : quand tu lis char, tu penses à un dessin qui représente un caractère d'imprimerie. Effectivement, si tu penses à ça, ça n'a pas de sens. Mais c'est toi qui fais une erreur, là. char, ça veut dire un entier dans l'intervalle [CHAR_MIN, CHAR_MAX]. C'est bien un entier, et il est facile de l'ajouter à un entier, même dans un autre intervalle, il suffit de prendre le plus large des deux intervalles. La norme spécifie très clairement les conditions de promotions des types entiers, c'est un peu lourd à lire parce qu'il y a beaucoup de cas, mais c'est écrit blanc sur noir.
Je le connais, je lui ai ditbonjour ce matin même.
Alors comment oses-tu prétendre qu'on peut diviser un void par une chaîne de caractères. Et d'ailleurs, il n'y a pas de chaînes de caractères en C, tu devrais le savoir.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien lui donner. Cette phrase ne veut rien dire.
Vous ne comprenez pas cette phrase, nuance.
Elle ne veut rien dire. Et après un examen cryptologique approfondi, j'en viens à conclure qu'elle ne veut rien dire parce qu'il manque un « que » au milieu.
Ce que que le C ne permet pas.
Tu te trompes. Une implémentation conforme de C peut tout à fait afficher un message d'erreur clair et indiscutable dans ce genre de cas. Elle peut aussi ne pas le faire. Tu confonds « je ne peux pas faire » et « je peux ne pas faire », c'est une erreur classique.
Tom , dans le message <422f2bac$0$12549$636a15ce@news.free.fr>, a
écrit :
Ca n'a pas de sens.
Si. Ah, je crois que je comprends ton problème : quand tu lis char, tu
penses à un dessin qui représente un caractère d'imprimerie. Effectivement,
si tu penses à ça, ça n'a pas de sens. Mais c'est toi qui fais une erreur,
là. char, ça veut dire un entier dans l'intervalle [CHAR_MIN, CHAR_MAX].
C'est bien un entier, et il est facile de l'ajouter à un entier, même dans
un autre intervalle, il suffit de prendre le plus large des deux
intervalles. La norme spécifie très clairement les conditions de promotions
des types entiers, c'est un peu lourd à lire parce qu'il y a beaucoup de
cas, mais c'est écrit blanc sur noir.
Je le connais, je lui ai ditbonjour ce matin même.
Alors comment oses-tu prétendre qu'on peut diviser un void par une chaîne de
caractères. Et d'ailleurs, il n'y a pas de chaînes de caractères en C, tu
devrais le savoir.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien
lui donner.
Cette phrase ne veut rien dire.
Vous ne comprenez pas cette phrase, nuance.
Elle ne veut rien dire. Et après un examen cryptologique approfondi, j'en
viens à conclure qu'elle ne veut rien dire parce qu'il manque un « que » au
milieu.
Ce que que le C ne permet pas.
Tu te trompes. Une implémentation conforme de C peut tout à fait afficher un
message d'erreur clair et indiscutable dans ce genre de cas. Elle peut aussi
ne pas le faire. Tu confonds « je ne peux pas faire » et « je peux ne pas
faire », c'est une erreur classique.
Tom , dans le message <422f2bac$0$12549$, a écrit :
Ca n'a pas de sens.
Si. Ah, je crois que je comprends ton problème : quand tu lis char, tu penses à un dessin qui représente un caractère d'imprimerie. Effectivement, si tu penses à ça, ça n'a pas de sens. Mais c'est toi qui fais une erreur, là. char, ça veut dire un entier dans l'intervalle [CHAR_MIN, CHAR_MAX]. C'est bien un entier, et il est facile de l'ajouter à un entier, même dans un autre intervalle, il suffit de prendre le plus large des deux intervalles. La norme spécifie très clairement les conditions de promotions des types entiers, c'est un peu lourd à lire parce qu'il y a beaucoup de cas, mais c'est écrit blanc sur noir.
Je le connais, je lui ai ditbonjour ce matin même.
Alors comment oses-tu prétendre qu'on peut diviser un void par une chaîne de caractères. Et d'ailleurs, il n'y a pas de chaînes de caractères en C, tu devrais le savoir.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien lui donner. Cette phrase ne veut rien dire.
Vous ne comprenez pas cette phrase, nuance.
Elle ne veut rien dire. Et après un examen cryptologique approfondi, j'en viens à conclure qu'elle ne veut rien dire parce qu'il manque un « que » au milieu.
Ce que que le C ne permet pas.
Tu te trompes. Une implémentation conforme de C peut tout à fait afficher un message d'erreur clair et indiscutable dans ce genre de cas. Elle peut aussi ne pas le faire. Tu confonds « je ne peux pas faire » et « je peux ne pas faire », c'est une erreur classique.
