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.
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.
Maintenant, remplacez INT_MAX par ce que vous voudrez, je vous fais le pari de trouver une architecture où il ne fonctionnera pas (au hasard une architecture douze bits).
Le C (je veux dire : la norme du C) nous garantit que les opérations sur le type int sont identiques à l'arithmétique usuelle tant que le résultat reste dans l'intervalle [INT_MIN, INT_MAX], et nous garantit également que INT_MAX vaut au moins 32767.
Donc le C sur architecture 12 bits, soit il se débrouille pour faire quand même des calculs enteirs sur 16 bits, soit ce n'est pas du C.
Vous pouvez faire ce que vous voulez à un code C, il y aura toujours des "implementation defined" qui traînent, sauf à le restreindre drastiquement
Je prétends qu'il n'y en a pas dans l'exemple que j'ai posté. C'est un exemple simple, certes, mais pas complètement trivial, et qui donne les idées sur ce qu'il faut faier et ce qu'il ne faut pas faire.
JKB , dans le message <slrnd2s3tk.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
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.
Maintenant, remplacez INT_MAX par ce que
vous voudrez, je vous fais le pari de trouver une architecture où il
ne fonctionnera pas (au hasard une architecture douze bits).
Le C (je veux dire : la norme du C) nous garantit que les opérations sur le
type int sont identiques à l'arithmétique usuelle tant que le résultat reste
dans l'intervalle [INT_MIN, INT_MAX], et nous garantit également que INT_MAX
vaut au moins 32767.
Donc le C sur architecture 12 bits, soit il se débrouille pour faire quand
même des calculs enteirs sur 16 bits, soit ce n'est pas du C.
Vous pouvez faire ce que vous voulez à un code C, il y aura toujours
des "implementation defined" qui traînent, sauf à le restreindre
drastiquement
Je prétends qu'il n'y en a pas dans l'exemple que j'ai posté. C'est un
exemple simple, certes, mais pas complètement trivial, et qui donne les
idées sur ce qu'il faut faier et ce qu'il ne faut pas faire.
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.
Maintenant, remplacez INT_MAX par ce que vous voudrez, je vous fais le pari de trouver une architecture où il ne fonctionnera pas (au hasard une architecture douze bits).
Le C (je veux dire : la norme du C) nous garantit que les opérations sur le type int sont identiques à l'arithmétique usuelle tant que le résultat reste dans l'intervalle [INT_MIN, INT_MAX], et nous garantit également que INT_MAX vaut au moins 32767.
Donc le C sur architecture 12 bits, soit il se débrouille pour faire quand même des calculs enteirs sur 16 bits, soit ce n'est pas du C.
Vous pouvez faire ce que vous voulez à un code C, il y aura toujours des "implementation defined" qui traînent, sauf à le restreindre drastiquement
Je prétends qu'il n'y en a pas dans l'exemple que j'ai posté. C'est un exemple simple, certes, mais pas complètement trivial, et qui donne les idées sur ce qu'il faut faier et ce qu'il ne faut pas faire.
Joe Cool
On Tue, 08 Mar 2005 20:24:53 +0100, Joe Cool wrote:
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
#include <stdlib.h>
int main(int argc, char **argv) { int a[10];
a[11] = 3; return EXIT_SUCCESS; }
On dirait que tu ne comprends pas très bien. Je vais te faire un dessin pour t'expliquer. Voici une représentation d'un tableau a[10] : ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ | | | | | | | | | | | |a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]| |____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et la 10e case est a[9]. On se rend immédiatement compte que la 11e case de ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans ton exemple.
Quelle horreur ! toute l'argumentation vient de tomber à l'eau !
-- Joe Cool
On Tue, 08 Mar 2005 20:24:53 +0100, Joe Cool wrote:
Comment se fait il qu'on puisse écrire dans la 11e case d'un
tableau de 10 éléments.
On ne peut pas, tu te trompes.
#include <stdlib.h>
int main(int argc, char **argv)
{
int a[10];
a[11] = 3;
return EXIT_SUCCESS;
}
On dirait que tu ne comprends pas très bien. Je vais te faire un
dessin pour t'expliquer. Voici une représentation d'un tableau a[10] :
____ ____ ____ ____ ____ ____ ____ ____ ____ ____
| | | | | | | | | | |
|a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]|
|____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et
la 10e case est a[9]. On se rend immédiatement compte que la 11e case de
ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans
ton exemple.
Quelle horreur ! toute l'argumentation vient de tomber à l'eau !
On Tue, 08 Mar 2005 20:24:53 +0100, Joe Cool wrote:
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
#include <stdlib.h>
int main(int argc, char **argv) { int a[10];
a[11] = 3; return EXIT_SUCCESS; }
On dirait que tu ne comprends pas très bien. Je vais te faire un dessin pour t'expliquer. Voici une représentation d'un tableau a[10] : ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ | | | | | | | | | | | |a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]| |____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et la 10e case est a[9]. On se rend immédiatement compte que la 11e case de ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans ton exemple.
Quelle horreur ! toute l'argumentation vient de tomber à l'eau !
-- Joe Cool
JKB
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 écrit :
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 ».
JKB
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
écrit :
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 ».
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 écrit :
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 ».
JKB
Joe Cool
Joe Cool , dans le message <422e07d2$0$16915$, a
Ce qui oblige à se confiner dans les cas particuliers pour éviter les erreurs.
Un programme est toujours un cas particulier. On peut même dire : un programme utile est forcément dans un cas qui in fine est décidable, puisqu'on attend de lui qu'il fasse quelque chose d'utile, justement.
J'espère que vous vous rendez compte que vous racontez n'importe quoi, sinon vous êtes un cas désespéré.
-- Joe Cool
Joe Cool , dans le message <422e07d2$0$16915$636a15ce@news.free.fr>, a
Ce qui oblige à se confiner dans les cas particuliers pour éviter les
erreurs.
Un programme est toujours un cas particulier. On peut même dire : un
programme utile est forcément dans un cas qui in fine est décidable,
puisqu'on attend de lui qu'il fasse quelque chose d'utile, justement.
J'espère que vous vous rendez compte que vous racontez n'importe quoi,
sinon vous êtes un cas désespéré.
Ce qui oblige à se confiner dans les cas particuliers pour éviter les erreurs.
Un programme est toujours un cas particulier. On peut même dire : un programme utile est forcément dans un cas qui in fine est décidable, puisqu'on attend de lui qu'il fasse quelque chose d'utile, justement.
J'espère que vous vous rendez compte que vous racontez n'importe quoi, sinon vous êtes un cas désespéré.
-- Joe Cool
Nicolas George
JKB , dans le message , a écrit :
Et moi, j'entends par portable : « qui doit donner le _même_ résultat ».
Y compris en temps ? Cette définition est mauvaise, mais qu'à celà ne tienne : la variante avec 32767 à la place d'INT_MAX est JKB-portable, et fait toujours une opération nun-triviale, même si elle sous-utilise la machine dans beaucoup de cas.
JKB , dans le message <slrnd2s4sa.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
Et moi, j'entends par portable : « qui doit donner le _même_
résultat ».
Y compris en temps ? Cette définition est mauvaise, mais qu'à celà ne
tienne : la variante avec 32767 à la place d'INT_MAX est JKB-portable, et
fait toujours une opération nun-triviale, même si elle sous-utilise la
machine dans beaucoup de cas.
Et moi, j'entends par portable : « qui doit donner le _même_ résultat ».
Y compris en temps ? Cette définition est mauvaise, mais qu'à celà ne tienne : la variante avec 32767 à la place d'INT_MAX est JKB-portable, et fait toujours une opération nun-triviale, même si elle sous-utilise la machine dans beaucoup de cas.
Nicolas George
Joe Cool , dans le message <422e1595$0$25601$, a écrit :
J'espère que vous vous rendez compte que vous racontez n'importe quoi, sinon vous êtes un cas désespéré.
C'est un peu facile comme affirmation. Je pourrais ressortir la même à tout moment. C'est du non-argument à l'état pur.
Joe Cool , dans le message <422e1595$0$25601$626a14ce@news.free.fr>, a
écrit :
J'espère que vous vous rendez compte que vous racontez n'importe quoi,
sinon vous êtes un cas désespéré.
C'est un peu facile comme affirmation. Je pourrais ressortir la même à tout
moment. C'est du non-argument à l'état pur.
J'espère que vous vous rendez compte que vous racontez n'importe quoi, sinon vous êtes un cas désespéré.
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.
-- Irvin
Sam Hocevar
On Tue, 08 Mar 2005 22:03:56 +0100, Joe Cool wrote:
On dirait que tu ne comprends pas très bien. Je vais te faire un dessin pour t'expliquer. Voici une représentation d'un tableau a[10] : ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ | | | | | | | | | | | |a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]| |____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et la 10e case est a[9]. On se rend immédiatement compte que la 11e case de ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans ton exemple.
Quelle horreur ! toute l'argumentation vient de tomber à l'eau !
Bien sûr que non, ne t'inquiète pas ! C'est pourtant évident, allez je t'aide encore : il te faut maintenant utiliser cette petite bourde pour affirmer que c'est la faute du langage C et que dans un vrai langage tu n'aurais jamais fait une telle erreur !
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 Tue, 08 Mar 2005 22:03:56 +0100, Joe Cool wrote:
On dirait que tu ne comprends pas très bien. Je vais te faire un
dessin pour t'expliquer. Voici une représentation d'un tableau a[10] :
____ ____ ____ ____ ____ ____ ____ ____ ____ ____
| | | | | | | | | | |
|a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]|
|____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et
la 10e case est a[9]. On se rend immédiatement compte que la 11e case de
ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans
ton exemple.
Quelle horreur ! toute l'argumentation vient de tomber à l'eau !
Bien sûr que non, ne t'inquiète pas ! C'est pourtant évident, allez
je t'aide encore : il te faut maintenant utiliser cette petite bourde
pour affirmer que c'est la faute du langage C et que dans un vrai
langage tu n'aurais jamais fait une telle erreur !
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 Tue, 08 Mar 2005 22:03:56 +0100, Joe Cool wrote:
On dirait que tu ne comprends pas très bien. Je vais te faire un dessin pour t'expliquer. Voici une représentation d'un tableau a[10] : ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ | | | | | | | | | | | |a[0]|a[1]|a[2]|a[3]|a[4]|a[5]|a[6]|a[7]|a[8]|a[9]| |____|____|____|____|____|____|____|____|____|____|
Comme tu peux le constater, la première case du tableau est a[0], et la 10e case est a[9]. On se rend immédiatement compte que la 11e case de ce tableau, s'il y en avait une, serait a[10] et non a[11] comme dans ton exemple.
Quelle horreur ! toute l'argumentation vient de tomber à l'eau !
Bien sûr que non, ne t'inquiète pas ! C'est pourtant évident, allez je t'aide encore : il te faut maintenant utiliser cette petite bourde pour affirmer que c'est la faute du langage C et que dans un vrai langage tu n'aurais jamais fait une telle erreur !
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/
Jean-Baptiste CAMPESATO
Le Tue, 08 Mar 2005 17:39:13 +0100, Tom a écrit :
Bonjour,
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
Bonjour, Si tu cherches un language typé, utilise l'Ada :) Sinon les .NET sont pas si reussit :)... Pleins de languages sont puissants :) Et tu peux faire un programme en C très jolie :) (même moi j'y arrive :) alors que sur feuille j'ai jamais été tres soigné)
Et ce n'est pas de a bidouillerie pour les programmeurs qui prennent leurs temps :) (Perso je trouve que les derniers Kernels sont bidouillés oui mais on va pas s'arreter aux kernels linux... L'informatique est plus vaste :))
Cordialement,
Le Tue, 08 Mar 2005 17:39:13 +0100, Tom a écrit :
Bonjour,
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
Bonjour,
Si tu cherches un language typé, utilise l'Ada :)
Sinon les .NET sont pas si reussit :)...
Pleins de languages sont puissants :) Et tu peux faire un programme en C
très jolie :) (même moi j'y arrive :) alors que sur feuille j'ai jamais
été tres soigné)
Et ce n'est pas de a bidouillerie pour les programmeurs qui prennent leurs
temps :)
(Perso je trouve que les derniers Kernels sont bidouillés oui mais on va
pas s'arreter aux kernels linux... L'informatique est plus vaste :))
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
Bonjour, Si tu cherches un language typé, utilise l'Ada :) Sinon les .NET sont pas si reussit :)... Pleins de languages sont puissants :) Et tu peux faire un programme en C très jolie :) (même moi j'y arrive :) alors que sur feuille j'ai jamais été tres soigné)
Et ce n'est pas de a bidouillerie pour les programmeurs qui prennent leurs temps :) (Perso je trouve que les derniers Kernels sont bidouillés oui mais on va pas s'arreter aux kernels linux... L'informatique est plus vaste :))
Cordialement,
JustMe
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 ?
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 ?
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 ?
