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.
Joe Cool , dans le message <422f210e$0$31419$, a écrit :
La détection des fuites de mémoire l'est peut être, mais la prévention des fuites est on ne peut plus décidable. On appelle ça des ramasse-miettes.
Oui, et ça a un coût très important en efficacité, surtout au moment où la mémoire utilisée par le programme dépasse la mémoire physique de l'hôte. Dès lors, permettre une gestion plus fine, mais non décidable par le compilateur, est indispensable.
Joe Cool , dans le message <422f210e$0$31419$636a15ce@news.free.fr>, a
écrit :
La détection des fuites de mémoire l'est peut être, mais la prévention
des fuites est on ne peut plus décidable. On appelle ça des ramasse-miettes.
Oui, et ça a un coût très important en efficacité, surtout au moment où la
mémoire utilisée par le programme dépasse la mémoire physique de l'hôte. Dès
lors, permettre une gestion plus fine, mais non décidable par le
compilateur, est indispensable.
Joe Cool , dans le message <422f210e$0$31419$, a écrit :
La détection des fuites de mémoire l'est peut être, mais la prévention des fuites est on ne peut plus décidable. On appelle ça des ramasse-miettes.
Oui, et ça a un coût très important en efficacité, surtout au moment où la mémoire utilisée par le programme dépasse la mémoire physique de l'hôte. Dès lors, permettre une gestion plus fine, mais non décidable par le compilateur, est indispensable.
JustMe
Tom a pensé très fort :
Et qu'attends tu pour *faire* du constructif au lieu de critiquer ? ;-)
Je n'avais pas conscience que le monde attendait sur moi pour se débarasser du C. C'est donc ça la raison qui fait que tout le monde n'est pas passé à autre chose ? Je ne suis vraiment qu'un ingrat.
Je me lance dans Camelix ce soir :-p
bien. On attends CamelixOS avec impatience.
Tom
Tom a pensé très fort :
Et qu'attends tu pour *faire* du constructif au lieu de critiquer ? ;-)
Je n'avais pas conscience que le monde attendait sur moi pour se débarasser
du C. C'est donc ça la raison qui fait que tout le monde n'est pas passé à
autre chose ? Je ne suis vraiment qu'un ingrat.
Et qu'attends tu pour *faire* du constructif au lieu de critiquer ? ;-)
Je n'avais pas conscience que le monde attendait sur moi pour se débarasser du C. C'est donc ça la raison qui fait que tout le monde n'est pas passé à autre chose ? Je ne suis vraiment qu'un ingrat.
Je me lance dans Camelix ce soir :-p
bien. On attends CamelixOS avec impatience.
Tom
Nicolas George
Nicolas George , dans le message <d0n70j$vtj$, a écrit :
Mauvaise objection, changer d'objection.
Le théorème de Gödel (plus quelques théorèmes pour l'appliquer en informatique) te permet d'affirmer que tu ne pourras pas prouver la correction de n'importe quel programme en général. Ce n'est pas pertinent : il s'agit de prouver la correction d'un programme en particulier, celui qui vient d'écrire. Et il y a de bonnes raisons de supposer qu'il est décidable, ce programme particulier-là : tu l'as écrit en voulant faire quelque chose.
Nicolas George , dans le message <d0n70j$vtj$6@nef.ens.fr>, a écrit :
Mauvaise objection, changer d'objection.
Le théorème de Gödel (plus quelques théorèmes pour l'appliquer en
informatique) te permet d'affirmer que tu ne pourras pas prouver la
correction de n'importe quel programme en général. Ce n'est pas pertinent :
il s'agit de prouver la correction d'un programme en particulier, celui qui
vient d'écrire. Et il y a de bonnes raisons de supposer qu'il est décidable,
ce programme particulier-là : tu l'as écrit en voulant faire quelque chose.
Nicolas George , dans le message <d0n70j$vtj$, a écrit :
Mauvaise objection, changer d'objection.
Le théorème de Gödel (plus quelques théorèmes pour l'appliquer en informatique) te permet d'affirmer que tu ne pourras pas prouver la correction de n'importe quel programme en général. Ce n'est pas pertinent : il s'agit de prouver la correction d'un programme en particulier, celui qui vient d'écrire. Et il y a de bonnes raisons de supposer qu'il est décidable, ce programme particulier-là : tu l'as écrit en voulant faire quelque chose.
Richard Delorme
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a
Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
Si un programme dépend de la structure de l'entier, c'est que le programmeur s'est chié dessus.
Non. Réfléchissez un peu (sur les architectures "octet", rien que les problèmes de petit/grand boutistes). Le nombre de fois où j'ai vu des trucs du genre :
long long li; // comprendre sur 64 bits unsigned char c[8];
c = li;
Et pan, une balle dans le pied !
Cet exemple ne compile pas (c n'est pas une lvalue).
Le problème de l'ordre des octets ne se pose que pour la lecture/écriture vers des entrées/sorties qui impose un ordre précis. - Le problème se pose dans tous les langages. - C'est trivial à résoudre en C :
c[0] = (li & 255); c[1] = ((li >> 8) & 255); etc.
-- Richard
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnd2tsqs.u5h.knatschke@rayleigh.systella.fr>, a
Au passage, ce truc
ne vous garantit jamais la structure même de l'entier.
Si un programme dépend de la structure de l'entier, c'est que le programmeur
s'est chié dessus.
Non. Réfléchissez un peu (sur les architectures "octet", rien que
les problèmes de petit/grand boutistes). Le nombre de fois où j'ai
vu des trucs du genre :
long long li; // comprendre sur 64 bits
unsigned char c[8];
c = li;
Et pan, une balle dans le pied !
Cet exemple ne compile pas (c n'est pas une lvalue).
Le problème de l'ordre des octets ne se pose que pour la
lecture/écriture vers des entrées/sorties qui impose un ordre précis.
- Le problème se pose dans tous les langages.
- C'est trivial à résoudre en C :
Le 09-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a
Au passage, ce truc ne vous garantit jamais la structure même de l'entier.
Si un programme dépend de la structure de l'entier, c'est que le programmeur s'est chié dessus.
Non. Réfléchissez un peu (sur les architectures "octet", rien que les problèmes de petit/grand boutistes). Le nombre de fois où j'ai vu des trucs du genre :
long long li; // comprendre sur 64 bits unsigned char c[8];
c = li;
Et pan, une balle dans le pied !
Cet exemple ne compile pas (c n'est pas une lvalue).
Le problème de l'ordre des octets ne se pose que pour la lecture/écriture vers des entrées/sorties qui impose un ordre précis. - Le problème se pose dans tous les langages. - C'est trivial à résoudre en C :
c[0] = (li & 255); c[1] = ((li >> 8) & 255); etc.
-- Richard
Izaho Ihany
On 2005-03-08, JKB wrote:
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Que vient faire Naibed dans ce troll ?
Nettoyer la console pour le prochain coup?
On 2005-03-08, JKB <knatschke@koenigsberg.fr> wrote:
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Tom , dans le message <422f2e3f$0$27244$, a écrit :
En gros un type en C c'est le nombre de bits utilisés.
Absolument pas. Un type en C, c'est un intervalle de validité des calculs.
Ca serait portable.
Cette notion n'est pas pertinente.
JustMe
Nicolas George vient de nous annoncer :
Mauvaise objection, changer d'objection.
Le théorème de Gödel (plus quelques théorèmes pour l'appliquer en informatique) te permet d'affirmer que tu ne pourras pas prouver la correction de n'importe quel programme en général.
Donc la "Preuve Mathématique" n'est pas forcément possible
Ce n'est pas pertinent : il s'agit de prouver la correction d'un programme en particulier, celui qui vient d'écrire. Et il y a de bonnes raisons de supposer qu'il est décidable, ce programme particulier-là : tu l'as écrit en voulant faire quelque chose.
Ce qui doit etre prouvé c'est la proposition "Le programme correspond exactement au but X" Le fait que X existe ne rend pas la proposition en question décidable pour autant.
D'autant que X n'est pas forcément correctement defini. Mais là c'est un autre probleme... ;-)
Nicolas George vient de nous annoncer :
Mauvaise objection, changer d'objection.
Le théorème de Gödel (plus quelques théorèmes pour l'appliquer en
informatique) te permet d'affirmer que tu ne pourras pas prouver la
correction de n'importe quel programme en général.
Donc la "Preuve Mathématique" n'est pas forcément possible
Ce n'est pas pertinent :
il s'agit de prouver la correction d'un programme en particulier, celui qui
vient d'écrire. Et il y a de bonnes raisons de supposer qu'il est décidable,
ce programme particulier-là : tu l'as écrit en voulant faire quelque chose.
Ce qui doit etre prouvé c'est la proposition "Le programme correspond
exactement au but X"
Le fait que X existe ne rend pas la proposition en question décidable
pour autant.
D'autant que X n'est pas forcément correctement defini. Mais là c'est
un autre probleme... ;-)
Le théorème de Gödel (plus quelques théorèmes pour l'appliquer en informatique) te permet d'affirmer que tu ne pourras pas prouver la correction de n'importe quel programme en général.
Donc la "Preuve Mathématique" n'est pas forcément possible
Ce n'est pas pertinent : il s'agit de prouver la correction d'un programme en particulier, celui qui vient d'écrire. Et il y a de bonnes raisons de supposer qu'il est décidable, ce programme particulier-là : tu l'as écrit en voulant faire quelque chose.
Ce qui doit etre prouvé c'est la proposition "Le programme correspond exactement au but X" Le fait que X existe ne rend pas la proposition en question décidable pour autant.
D'autant que X n'est pas forcément correctement defini. Mais là c'est un autre probleme... ;-)
Nicolas George
JustMe , dans le message , a écrit :
donc peu utile.
Le compilateur Caml repère les cas de récursivité terminale, ce qui est déjà énorme. De toute évidence tu ne connais pas grand chose à ce que peut faire Caml, je t'invite donc à ne pas te prononcer dessus avant de t'être documenté plus avant.
JustMe , dans le message <mn.4c4b7d5331f66a44.15643@merci.beaucoup>, a
écrit :
donc peu utile.
Le compilateur Caml repère les cas de récursivité terminale, ce qui est déjà
énorme. De toute évidence tu ne connais pas grand chose à ce que peut faire
Caml, je t'invite donc à ne pas te prononcer dessus avant de t'être
documenté plus avant.
Le compilateur Caml repère les cas de récursivité terminale, ce qui est déjà énorme. De toute évidence tu ne connais pas grand chose à ce que peut faire Caml, je t'invite donc à ne pas te prononcer dessus avant de t'être documenté plus avant.
Nicolas George
JustMe , dans le message , a écrit :
Et personne n'assure que si malloc() renvoie un pointeur non NULL, la mémoire est utilisable. Ah ? Source ?
/proc/sys/vm/overcommit_memory
JustMe , dans le message <mn.4c4f7d53d14c4a48.15643@merci.beaucoup>, a
écrit :
Et personne n'assure que si malloc() renvoie un pointeur non NULL,
la mémoire est utilisable.
Ah ? Source ?
