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 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
Blaise Potard
Tom wrote:
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 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é...
si : un segmentation fault. Ca aurait changé l'histoire.
Un overflow ne déclenche pas de Segfault. Ça peut déclencher des exceptions, à la limite.
Tom wrote:
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
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é...
si : un segmentation fault. Ca aurait changé l'histoire.
Un overflow ne déclenche pas de Segfault. Ça peut déclencher des
exceptions, à la limite.
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 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é...
si : un segmentation fault. Ca aurait changé l'histoire.
Un overflow ne déclenche pas de Segfault. Ça peut déclencher des exceptions, à la limite.
Miguel Moquillon
Tout va bien dans le meilleur des mondes. Dans combien de temps vous viendrez pleurer ? Dans cinquante ans ? Quand j'ai vu smalltalk et que je vois ce que je me tape au boulot, j'ai
tout de suite commencé à pleurer et je continue toujours à pleurer. Maintenant, j'ai ma boite de kleenex à côté.
Tout va bien dans le meilleur des mondes. Dans combien de temps vous
viendrez pleurer ? Dans cinquante ans ?
Quand j'ai vu smalltalk et que je vois ce que je me tape au boulot, j'ai
tout de suite commencé à pleurer et je continue toujours à pleurer.
Maintenant, j'ai ma boite de kleenex à côté.
Tout va bien dans le meilleur des mondes. Dans combien de temps vous viendrez pleurer ? Dans cinquante ans ? Quand j'ai vu smalltalk et que je vois ce que je me tape au boulot, j'ai
tout de suite commencé à pleurer et je continue toujours à pleurer. Maintenant, j'ai ma boite de kleenex à côté.
Joe Cool
Tom wrote:
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son système de non-types que le C est un non-langage ! Sachez que c'est grâce au typage statique que Caml est un langage évolué.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Si tu me parlais de l'inférence de type ou de la force du typage, ça irait, mais là, j'ai vraiment du mal à comprendre où tu veux en venir.
Un typage est dit statique quand le type des données est décidé au moment de la compilation.
Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe.
Le typage des objets est statique en ocaml.
Le mécanisme de typage est une preuve du programme.
Lol. T'en as beaucoup des comme ça ? Évidemment, avoir un typage rigoureux est une des conditions pour faire une preuve de programme, mais c'est loin de suffir.
Un typage *est* une preuve.
Alors quand tu racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de quoi tu parles.
Ignorance, quand tu nous tiens.
-- Joe Cool
Tom wrote:
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de
son système de non-types que le C est un non-langage ! Sachez que
c'est grâce au typage statique que Caml est un langage évolué.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Si tu me
parlais de l'inférence de type ou de la force du typage, ça irait,
mais là, j'ai vraiment du mal à comprendre où tu veux en venir.
Un typage est dit statique quand le type des données est décidé au
moment de la compilation.
Alors que OCaml, comme tout langage objet, a des types dynamiques à
cause de l'héritage de classe.
Le typage des objets est statique en ocaml.
Le mécanisme de typage est une preuve du programme.
Lol. T'en as beaucoup des comme ça ? Évidemment, avoir un typage
rigoureux est une des conditions pour faire une preuve de programme,
mais c'est loin de suffir.
Un typage *est* une preuve.
Alors quand tu racontes ce genre de choses, tu m'excuseras,
mais tu me fais doucement rigoler. Je pense que la seule chose que tu
prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de
quoi tu parles.
On ne veut pas se soucier du type ! Mais bon sang c'est à cause de son système de non-types que le C est un non-langage ! Sachez que c'est grâce au typage statique que Caml est un langage évolué.
"Typage statique" ? Qu'est-ce que tu veux dire par là ? Si tu me parlais de l'inférence de type ou de la force du typage, ça irait, mais là, j'ai vraiment du mal à comprendre où tu veux en venir.
Un typage est dit statique quand le type des données est décidé au moment de la compilation.
Alors que OCaml, comme tout langage objet, a des types dynamiques à cause de l'héritage de classe.
Le typage des objets est statique en ocaml.
Le mécanisme de typage est une preuve du programme.
Lol. T'en as beaucoup des comme ça ? Évidemment, avoir un typage rigoureux est une des conditions pour faire une preuve de programme, mais c'est loin de suffir.
Un typage *est* une preuve.
Alors quand tu racontes ce genre de choses, tu m'excuseras, mais tu me fais doucement rigoler. Je pense que la seule chose que tu prouves c'est que tu ne sais pas (mais alors vraiment pas) du tout de quoi tu parles.
Ignorance, quand tu nous tiens.
-- Joe Cool
JKB
Le 09-03-2005, à propos de Re: a-t-on le choix ?, nicolas vigier écrivait dans fr.comp.os.linux.debats :
On 2005-03-09, Tom wrote:
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code écrit en C qui ne comporte pas à un endroit ou un autre un truc qui n'est pas implementation defined. Et je ne parle pas de trucs pathologiques du style i+=i++ !
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Ben oui, i+=i++ ca n'a aucun sens, et c'est ton probleme si tu utilises volontairement ca dans un programme. Et un bon compilateur te previens que tu as surement ecrit une connerie. C'est quoi la prochaine connerie pour laquelle tu vas raler ? La fonction random() qui ne renvoit pas toujours la meme chose ? La non fiabilite de la plupars des distribs linux quand on execute un "rm -Rf /" en root ?
Dites... Est-ce que vous avez déjà vu dans la _vraie_ vie un programmeur qui s'arrête aux warnings donnés par un compilo ? La plupart du temps, il faut déjà mettre une option spécifique pour obtenir ces warnings...
JKB
Le 09-03-2005, à propos de
Re: a-t-on le choix ?,
nicolas vigier écrivait dans fr.comp.os.linux.debats :
On 2005-03-09, Tom <tom@tom.com> wrote:
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code
écrit en C qui ne comporte pas à un endroit ou un autre un truc qui
n'est pas implementation defined. Et je ne parle pas de trucs
pathologiques du style i+=i++ !
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un
comportement défini. Certains compilateurs vont incrémenter avant,
d'autres après l'affectation. Quel exemple de portabilité ! :-)
Ben oui, i+=i++ ca n'a aucun sens, et c'est ton probleme si tu utilises
volontairement ca dans un programme. Et un bon compilateur te previens
que tu as surement ecrit une connerie. C'est quoi la prochaine connerie
pour laquelle tu vas raler ? La fonction random() qui ne renvoit pas
toujours la meme chose ? La non fiabilite de la plupars des distribs
linux quand on execute un "rm -Rf /" en root ?
Dites... Est-ce que vous avez déjà vu dans la _vraie_ vie un
programmeur qui s'arrête aux warnings donnés par un compilo ? La
plupart du temps, il faut déjà mettre une option spécifique pour
obtenir ces warnings...
Le 09-03-2005, à propos de Re: a-t-on le choix ?, nicolas vigier écrivait dans fr.comp.os.linux.debats :
On 2005-03-09, Tom wrote:
Alors si on veux pinailler, je n'ai _jamais_ vu un seul bout de code écrit en C qui ne comporte pas à un endroit ou un autre un truc qui n'est pas implementation defined. Et je ne parle pas de trucs pathologiques du style i+=i++ !
Un exemple flagrant de la faiblesse du C : ce i+=i++ n'est pas un comportement défini. Certains compilateurs vont incrémenter avant, d'autres après l'affectation. Quel exemple de portabilité ! :-)
Ben oui, i+=i++ ca n'a aucun sens, et c'est ton probleme si tu utilises volontairement ca dans un programme. Et un bon compilateur te previens que tu as surement ecrit une connerie. C'est quoi la prochaine connerie pour laquelle tu vas raler ? La fonction random() qui ne renvoit pas toujours la meme chose ? La non fiabilite de la plupars des distribs linux quand on execute un "rm -Rf /" en root ?
Dites... Est-ce que vous avez déjà vu dans la _vraie_ vie un programmeur qui s'arrête aux warnings donnés par un compilo ? La plupart du temps, il faut déjà mettre une option spécifique pour obtenir ces warnings...
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-08, wrote:
Mais pourtant il y a Ada et AdaOS ;-)
Ada, n'est-ce pas le langage qui t'interdit de faire de la compote
si tu reviens du marché avec des pommes _et_ des poires ? C'est pratique pour écrire un os, ça :)
C'est assez bien vu... ;-)
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-08, noone@nowhere.com <noone@nowhere.com> wrote:
Mais pourtant il y a Ada et AdaOS ;-)
Ada, n'est-ce pas le langage qui t'interdit de faire de la compote
si tu reviens du marché avec des pommes _et_ des poires ?
C'est pratique pour écrire un os, ça :)
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, wrote:
Mais pourtant il y a Ada et AdaOS ;-)
Ada, n'est-ce pas le langage qui t'interdit de faire de la compote
si tu reviens du marché avec des pommes _et_ des poires ? C'est pratique pour écrire un os, ça :)
C'est assez bien vu... ;-)
JKB
Tom
Quels informaticiens théoriciens?
cherchez model checking et prouveurs sur Google.
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. Que vous êtes méprisant.
Tom
Quels informaticiens théoriciens?
cherchez model checking et prouveurs sur Google.
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.
Que vous êtes méprisant.
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. Que vous êtes méprisant.
Tom
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-08, JKB wrote:
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Que vient faire Naibed dans ce troll ?
Rien. Et je ne pensais pas à elle (surtout pas, en fait) !
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-08, JKB <knatschke@koenigsberg.fr> wrote:
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Que vient faire Naibed dans ce troll ?
Rien. Et je ne pensais pas à elle (surtout pas, en fait) !
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:
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Que vient faire Naibed dans ce troll ?
Rien. Et je ne pensais pas à elle (surtout pas, en fait) !
JKB
Sam Hocevar
On Wed, 09 Mar 2005 14:08:13 +0100, Joe Cool wrote:
% cat foo.ml let a = Array.create 10 0;; a.(10) <- 1 % ocamlc foo.ml -o foo %
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 ?
Le problème c'est que ça compile. Toi, là, tu vérifies à l'exécution que ça marche (ou pas). Pas très efficace, Tom ne serait pas très content de ta façon de programmer quelque peu hasardeuse.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
On Wed, 09 Mar 2005 14:08:13 +0100, Joe Cool wrote:
% cat foo.ml
let a = Array.create 10 0;;
a.(10) <- 1
% ocamlc foo.ml -o foo
%
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 ?
Le problème c'est que ça compile. Toi, là, tu vérifies à l'exécution
que ça marche (ou pas). Pas très efficace, Tom ne serait pas très
content de ta façon de programmer quelque peu hasardeuse.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/
On Wed, 09 Mar 2005 14:08:13 +0100, Joe Cool wrote:
% cat foo.ml let a = Array.create 10 0;; a.(10) <- 1 % ocamlc foo.ml -o foo %
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 ?
Le problème c'est que ça compile. Toi, là, tu vérifies à l'exécution que ça marche (ou pas). Pas très efficace, Tom ne serait pas très content de ta façon de programmer quelque peu hasardeuse.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
