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.
Tom , dans le message <422ec75c$0$18054$, a écrit :
Comment se fait il alors qu'on puisse ajouter un entier à un caractère ?
Quel est le problème ?
Qu'on puisse diviser un void par une chaine de caractères ?
Tu prouves encore que tu ne connais pas le C.
ça doit pas être un mauvais programmeur celui qui l'a fait je suppose.
Oui.
Pourtant c'est possible. Un programme n'a la sémantique qu'on veut bien lui donner.
Cette phrase ne veut rien dire.
Je ne pense pas qu'il y ait un intérêt aux classes.
Tu ne penses pas beaucoup, on dirait.
Ils ne devraient tout simplement pas exister.
Tu as invoqué toi-même le fait que c'était un problème indécidable.
Joe Cool
Joe Cool avait écrit le 09/03/2005 :
Eh bien vas-y, montre-nous comme tu es fort : choisis ton langage, fais un programme qui serve vraiment à quelque chose dans la vraie vie (un traitement de texte, un navigateur web, un serveur de news, un système de comptabilité), et prouve qu'il fonctionne.
On va bien rire, tiens.
Les attaques ad hominem commencent à pulluler. Ce n'est pas sérieux.
Vous confondez "défis" et "attaque".
Dans ce cas montez moi votre système d'exploitation à vous écrit en C standard : il faut que le code soit le même pour toutes les architectures possèdant un compilateur C.
-- Joe Cool
Joe Cool avait écrit le 09/03/2005 :
Eh bien vas-y, montre-nous comme tu es fort : choisis ton langage,
fais un
programme qui serve vraiment à quelque chose dans la vraie vie (un
traitement de texte, un navigateur web, un serveur de news, un
système de
comptabilité), et prouve qu'il fonctionne.
On va bien rire, tiens.
Les attaques ad hominem commencent à pulluler. Ce n'est pas sérieux.
Vous confondez "défis" et "attaque".
Dans ce cas montez moi votre système d'exploitation à vous écrit en C
standard : il faut que le code soit le même pour toutes les
architectures possèdant un compilateur C.
Eh bien vas-y, montre-nous comme tu es fort : choisis ton langage, fais un programme qui serve vraiment à quelque chose dans la vraie vie (un traitement de texte, un navigateur web, un serveur de news, un système de comptabilité), et prouve qu'il fonctionne.
On va bien rire, tiens.
Les attaques ad hominem commencent à pulluler. Ce n'est pas sérieux.
Vous confondez "défis" et "attaque".
Dans ce cas montez moi votre système d'exploitation à vous écrit en C standard : il faut que le code soit le même pour toutes les architectures possèdant un compilateur C.
-- Joe Cool
Nicolas George
JustMe , dans le message , a écrit :
Que fais tu du théorème de Godel ?
Mauvaise objection, changer d'objection.
JustMe , dans le message <mn.4a5f7d533da24a14.15643@merci.beaucoup>, a
écrit :
Quelle reponse détaillée, objective et argumentée ;-D
Le théorème de Gôdel possède une preuve de sa validité.
-- Joe Cool
Emmanuel Florac
Le Wed, 09 Mar 2005 11:22:12 +0100, Tom a écrit :
Si les processeurs étaient bien foutus ce ne serait pas le cas.
Ah, on y vient enfin. Vas-y, explique nous comment on conçoit un processeur qui se programme de façon non impérative, ou peut-être aussi des barettes mémoires avec typage statique des données?
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Le Wed, 09 Mar 2005 11:22:12 +0100, Tom a écrit :
Si les processeurs étaient
bien foutus ce ne serait pas le cas.
Ah, on y vient enfin. Vas-y, explique nous comment on conçoit un
processeur qui se programme de façon non impérative, ou peut-être aussi
des barettes mémoires avec typage statique des données?
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
Si les processeurs étaient bien foutus ce ne serait pas le cas.
Ah, on y vient enfin. Vas-y, explique nous comment on conçoit un processeur qui se programme de façon non impérative, ou peut-être aussi des barettes mémoires avec typage statique des données?
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
JustMe
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
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
Parce que vous savez faire un OS en C vous. Montrez-nous le donc.
http://www.systella.fr/~bertrand/freevms
Ça ira ?
« Le noyau FreeVMS est pour l'instant un noyau Linux 2.4 patché pour bénéficier du support ext3. »
Eh ! C'est de la triche !
-- Joe Cool
Nicolas George
Joe Cool , dans le message <422ebc4a$0$25620$, a écrit :
Il existe un truc tout nouveau, un truc révolutionnaire qui s'appelle ... attendez, je cherche.... une preuve mathématique.
Oui, et ? Un programme en C peut tout autant être pvouvé qu'un programme en Caml ou en n'importe quel autre langage. Il n'y a absolument aucune différence de fond : dans tous les cas l'environnement de compilation/exécution aide le programmeur dans la mesure de ses moyens à faire cette preuve, et dans tous les cas avoir une preuve complète est infiniment trop fastidieux pour qu'on prenne le temps de le faire globalement et explicitement pour les programmes courants.
La seule différence est quantitative : certains langages, en enfermant le programmeur dans des structures plus strictes, permettent à l'environnement de compilation/exécution de fournir des bouts de preuve un peu plus larges à bas niveau. Mais ça reste forcément limité.
De plus, l'idée de preuve mathématique d'un programme se heurte à une objection fondamentale : une preuve mathématique porte sur des objets mathématiques, alors que l'utilité d'un programme est en général dans le domaine réel (images, sons, paquets réseau). La correspondance entre le théorème qui a été prouvé et la réalité pratique qu'il est censé recouvrir ne peut pas être prouvée.
Joe Cool , dans le message <422ebc4a$0$25620$626a14ce@news.free.fr>, a
écrit :
Il existe un truc tout nouveau, un truc révolutionnaire qui s'appelle
... attendez, je cherche.... une preuve mathématique.
Oui, et ? Un programme en C peut tout autant être pvouvé qu'un programme en
Caml ou en n'importe quel autre langage. Il n'y a absolument aucune
différence de fond : dans tous les cas l'environnement de
compilation/exécution aide le programmeur dans la mesure de ses moyens à
faire cette preuve, et dans tous les cas avoir une preuve complète est
infiniment trop fastidieux pour qu'on prenne le temps de le faire
globalement et explicitement pour les programmes courants.
La seule différence est quantitative : certains langages, en enfermant le
programmeur dans des structures plus strictes, permettent à l'environnement
de compilation/exécution de fournir des bouts de preuve un peu plus larges à
bas niveau. Mais ça reste forcément limité.
De plus, l'idée de preuve mathématique d'un programme se heurte à une
objection fondamentale : une preuve mathématique porte sur des objets
mathématiques, alors que l'utilité d'un programme est en général dans le
domaine réel (images, sons, paquets réseau). La correspondance entre le
théorème qui a été prouvé et la réalité pratique qu'il est censé recouvrir
ne peut pas être prouvée.
Joe Cool , dans le message <422ebc4a$0$25620$, a écrit :
Il existe un truc tout nouveau, un truc révolutionnaire qui s'appelle ... attendez, je cherche.... une preuve mathématique.
Oui, et ? Un programme en C peut tout autant être pvouvé qu'un programme en Caml ou en n'importe quel autre langage. Il n'y a absolument aucune différence de fond : dans tous les cas l'environnement de compilation/exécution aide le programmeur dans la mesure de ses moyens à faire cette preuve, et dans tous les cas avoir une preuve complète est infiniment trop fastidieux pour qu'on prenne le temps de le faire globalement et explicitement pour les programmes courants.
La seule différence est quantitative : certains langages, en enfermant le programmeur dans des structures plus strictes, permettent à l'environnement de compilation/exécution de fournir des bouts de preuve un peu plus larges à bas niveau. Mais ça reste forcément limité.
De plus, l'idée de preuve mathématique d'un programme se heurte à une objection fondamentale : une preuve mathématique porte sur des objets mathématiques, alors que l'utilité d'un programme est en général dans le domaine réel (images, sons, paquets réseau). La correspondance entre le théorème qui a été prouvé et la réalité pratique qu'il est censé recouvrir ne peut pas être prouvée.
Joe Cool
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
Oui, et Linux n'est absolument pas adapté aux impératifs industriels : il n'est pas assez stable et manque de fonctionnalités indispensables.
C'est bien connu.
-- Joe Cool
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
Oui, et Linux n'est absolument pas adapté aux impératifs industriels :
il n'est pas assez stable et manque de fonctionnalités indispensables.
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
Oui, et Linux n'est absolument pas adapté aux impératifs industriels : il n'est pas assez stable et manque de fonctionnalités indispensables.
