A supposer qu'une entreprise veuille mettre son parc sous Linux.
Et qu'elle reçoive des documents venant d'Access, Excel,... peut-elle
les lire , les travailler et les renvoyer de manière que le
destinantaire sur produits Microsoft puisse les lire, etc...
?
"Michel Talon" a écrit dans le message de news: cbscoj$bff$
Nicolas George wrote:
Michel Talon, dans le message <cbsbe1$bff$, a
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants.
Et, oh surprise, c'est de débutants qu'il est question.
Alors dans ce cas tu as peut être raison, mais je minorerais quand même l'intérêt de la rigueur, même dans ce cas là. Beaucoup trop de gens voient les mathématiques comme une sombre bouse, précisément parcequ'on ne leur a montré que ce coté rébarbatif des choses et pas du tout la beauté intrinsèque des constructions. Comme il ne me semble pas possible de faire les deux d'un coup, je sacrifirais sans hésitation la rigueur.
c'est un peu le meme pb
entre la programmation obg et la programmation dite classique prendre un pro du c de perl le sortir de son clavier tu lui dis qu'il utilise en gros moins de 100 instructions et qu'il serait bien qu'il reflechisse un chouya avant de coder et de regarder du cote de ulm ou dessing patern
l'on a d'un cote un mec qui prend son pied et de l'autre un mec qui se fait chier a coder toujours les memes modeles
a l'arrivee c'est en gros la meme chose et pour revenir au debut les theories sur les ensembles c'est chiant je prefere un bon vieux theoreme ou pb bien sexy comme Fermat ou RSA a une demonstration avec des machines et des bidules a base de patate
meme si je n'ai pas raison
remy
--
Michel TALON
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de news:
cbscoj$bff$3@asmodee.lpthe.jussieu.fr...
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message <cbsbe1$bff$1@asmodee.lpthe.jussieu.fr>, a
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt
sauf pour les débutants et les pédants.
Et, oh surprise, c'est de débutants qu'il est question.
Alors dans ce cas tu as peut être raison, mais je minorerais quand
même l'intérêt de la rigueur, même dans ce cas là. Beaucoup trop de gens
voient les mathématiques comme une sombre bouse, précisément parcequ'on
ne leur a montré que ce coté rébarbatif des choses et pas du tout la
beauté intrinsèque des constructions. Comme il ne me semble pas possible
de faire les deux d'un coup, je sacrifirais sans hésitation la rigueur.
c'est un peu le meme pb
entre la programmation obg et la programmation dite classique
prendre un pro du c de perl le sortir de son clavier
tu lui dis qu'il utilise en gros moins de 100 instructions
et qu'il serait bien qu'il reflechisse un chouya avant de coder
et de regarder du cote de ulm ou dessing patern
l'on a d'un cote un mec qui prend son pied et de l'autre
un mec qui se fait chier a coder toujours les memes modeles
a l'arrivee c'est en gros la meme chose
et pour revenir au debut les theories sur les ensembles
c'est chiant je prefere un bon vieux theoreme ou pb bien sexy
comme Fermat ou RSA a une demonstration
avec des machines et des bidules a base de patate
"Michel Talon" a écrit dans le message de news: cbscoj$bff$
Nicolas George wrote:
Michel Talon, dans le message <cbsbe1$bff$, a
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants.
Et, oh surprise, c'est de débutants qu'il est question.
Alors dans ce cas tu as peut être raison, mais je minorerais quand même l'intérêt de la rigueur, même dans ce cas là. Beaucoup trop de gens voient les mathématiques comme une sombre bouse, précisément parcequ'on ne leur a montré que ce coté rébarbatif des choses et pas du tout la beauté intrinsèque des constructions. Comme il ne me semble pas possible de faire les deux d'un coup, je sacrifirais sans hésitation la rigueur.
c'est un peu le meme pb
entre la programmation obg et la programmation dite classique prendre un pro du c de perl le sortir de son clavier tu lui dis qu'il utilise en gros moins de 100 instructions et qu'il serait bien qu'il reflechisse un chouya avant de coder et de regarder du cote de ulm ou dessing patern
l'on a d'un cote un mec qui prend son pied et de l'autre un mec qui se fait chier a coder toujours les memes modeles
a l'arrivee c'est en gros la meme chose et pour revenir au debut les theories sur les ensembles c'est chiant je prefere un bon vieux theoreme ou pb bien sexy comme Fermat ou RSA a une demonstration avec des machines et des bidules a base de patate
meme si je n'ai pas raison
remy
--
Michel TALON
Richard Delorme
prenons un cas "classique"
une base de donnees avec une tab tu veux la publier sur le woin woin woin
donc tu as un tableau que tu dois contactener et tu dois enrober chaque ligne du tableau de quelques balises html par exemple
Facile en C avec la famille des *printf.
et dans 1 a 2 ans la taille de ton tableau passe de 50 lignes a 100 lignes
entre un code java et c quel est le plus lisible et quel est celui qui a un cout de maintenance le moins cher
A mon avis la lisibilité est proche, puisque le C et le Java ont une syntaxe semblable. En fait, l'orientation objet du Java aura même tendance à alourdir le code, donc je donne un léger avantage au C.
Quant à la maintenance, je préfèrerais maintenir du C. Avec Java, après quelques semaines d'inutilisation, j'ai toujours du mal à me rappeler la subtilité qu'il y a entre un String et un StringBuffer, ou quel *InputStream je dois utiliser pour ouvrir ce fichier, à savoir où est le code important au milieu de tous ces try/catch, etc.
et au niveau rapidite d'execution l'on est pas loin du kif kif avec du c propre
Le facteur limitant étant l'accès à la base de donnée, ton assertion est sans doute vrai. PS : contrairement à une idée répandue, le C propre est plus rapide que le C sale.
sans parler de l'interaction avec la base de donnees
Il est très facile d'interagir avec une base de données en C. Il suffit d'utiliser les outils fournis avec le gestionnaire de base de données : bibliothèque, embedded-SQL, etc. En Java, on utilisera les outils fournis par le langage. La différence est uniquement dans l'origine des outils fournis.
donc le langage depend de l'objectif a mon avi
De l'objectif, des performances recherchées, des compétences disponibles, de la mode, etc.
-- Richard
prenons un cas "classique"
une base de donnees avec une tab
tu veux la publier sur le woin woin woin
donc tu as un tableau que tu dois contactener
et tu dois enrober chaque ligne du tableau de quelques balises html
par exemple
Facile en C avec la famille des *printf.
et dans 1 a 2 ans la taille de ton tableau passe de 50 lignes a 100 lignes
entre un code java et c quel est le plus lisible et quel est celui
qui a un cout de maintenance le moins cher
A mon avis la lisibilité est proche, puisque le C et le Java ont une
syntaxe semblable. En fait, l'orientation objet du Java aura même
tendance à alourdir le code, donc je donne un léger avantage au C.
Quant à la maintenance, je préfèrerais maintenir du C. Avec Java, après
quelques semaines d'inutilisation, j'ai toujours du mal à me rappeler la
subtilité qu'il y a entre un String et un StringBuffer, ou quel
*InputStream je dois utiliser pour ouvrir ce fichier, à savoir où est le
code important au milieu de tous ces try/catch, etc.
et au niveau rapidite d'execution l'on est pas loin du kif kif
avec du c propre
Le facteur limitant étant l'accès à la base de donnée, ton assertion est
sans doute vrai.
PS : contrairement à une idée répandue, le C propre est plus rapide que
le C sale.
sans parler de l'interaction avec la base de donnees
Il est très facile d'interagir avec une base de données en C. Il suffit
d'utiliser les outils fournis avec le gestionnaire de base de données :
bibliothèque, embedded-SQL, etc. En Java, on utilisera les outils
fournis par le langage. La différence est uniquement dans l'origine des
outils fournis.
donc le langage depend de l'objectif a mon avi
De l'objectif, des performances recherchées, des compétences
disponibles, de la mode, etc.
une base de donnees avec une tab tu veux la publier sur le woin woin woin
donc tu as un tableau que tu dois contactener et tu dois enrober chaque ligne du tableau de quelques balises html par exemple
Facile en C avec la famille des *printf.
et dans 1 a 2 ans la taille de ton tableau passe de 50 lignes a 100 lignes
entre un code java et c quel est le plus lisible et quel est celui qui a un cout de maintenance le moins cher
A mon avis la lisibilité est proche, puisque le C et le Java ont une syntaxe semblable. En fait, l'orientation objet du Java aura même tendance à alourdir le code, donc je donne un léger avantage au C.
Quant à la maintenance, je préfèrerais maintenir du C. Avec Java, après quelques semaines d'inutilisation, j'ai toujours du mal à me rappeler la subtilité qu'il y a entre un String et un StringBuffer, ou quel *InputStream je dois utiliser pour ouvrir ce fichier, à savoir où est le code important au milieu de tous ces try/catch, etc.
et au niveau rapidite d'execution l'on est pas loin du kif kif avec du c propre
Le facteur limitant étant l'accès à la base de donnée, ton assertion est sans doute vrai. PS : contrairement à une idée répandue, le C propre est plus rapide que le C sale.
sans parler de l'interaction avec la base de donnees
Il est très facile d'interagir avec une base de données en C. Il suffit d'utiliser les outils fournis avec le gestionnaire de base de données : bibliothèque, embedded-SQL, etc. En Java, on utilisera les outils fournis par le langage. La différence est uniquement dans l'origine des outils fournis.
donc le langage depend de l'objectif a mon avi
De l'objectif, des performances recherchées, des compétences disponibles, de la mode, etc.
-- Richard
Manuel Leclerc
Le fait qu'une bug dans un source puisse se traduire par "n'importe quoi, n'importe où, n'importe quand" EXCLUE définitivement, et sans appel, le C de la catégorie "langage évolué".
Je vais te dire un secret : c'est vrai dans quasiment tous les langages. Un bug subtil dans un algorithme, ça peut provoquer des résultats complètement aberrants à des endroits qui n'ont rien à voir.
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Le C est un peu plus sensible à ce phénomène que la moyenne, certes, et alors ?
Avec la notion de "comportement indéfini", une frontière est franchie. Concrètement, cela a un gros impact sur les efforts à produire pour sortir un programme correct, et cela a aussi un gros impact sur les conséquences d'un programme incorrect.
-- As to whether DRM is bad for Microsoft, I will leave that to Microsoft to decide. --Jerry Pournelle
Le fait qu'une bug dans un source puisse se traduire par
"n'importe quoi, n'importe où, n'importe quand" EXCLUE
définitivement, et sans appel, le C de la catégorie
"langage évolué".
Je vais te dire un secret : c'est vrai dans quasiment tous les
langages. Un bug subtil dans un algorithme, ça peut provoquer des
résultats complètement aberrants à des endroits qui n'ont rien à
voir.
Bien sûr, mais la question n'est pas là. La question est : le
programme va-t-il exécuter les instructions indiquées dans le
source, ou va-t-il faire N'IMPORTE QUOI ?
Le C est un peu plus sensible à ce phénomène que la moyenne,
certes, et alors ?
Avec la notion de "comportement indéfini", une frontière est
franchie. Concrètement, cela a un gros impact sur les efforts
à produire pour sortir un programme correct, et cela a aussi
un gros impact sur les conséquences d'un programme incorrect.
--
As to whether DRM is bad for Microsoft, I will leave that to Microsoft
to decide.
--Jerry Pournelle
Le fait qu'une bug dans un source puisse se traduire par "n'importe quoi, n'importe où, n'importe quand" EXCLUE définitivement, et sans appel, le C de la catégorie "langage évolué".
Je vais te dire un secret : c'est vrai dans quasiment tous les langages. Un bug subtil dans un algorithme, ça peut provoquer des résultats complètement aberrants à des endroits qui n'ont rien à voir.
Bien sûr, mais la question n'est pas là. La question est : le programme va-t-il exécuter les instructions indiquées dans le source, ou va-t-il faire N'IMPORTE QUOI ?
Le C est un peu plus sensible à ce phénomène que la moyenne, certes, et alors ?
Avec la notion de "comportement indéfini", une frontière est franchie. Concrètement, cela a un gros impact sur les efforts à produire pour sortir un programme correct, et cela a aussi un gros impact sur les conséquences d'un programme incorrect.
-- As to whether DRM is bad for Microsoft, I will leave that to Microsoft to decide. --Jerry Pournelle
Emmanuel Florac
Le Wed, 30 Jun 2004 00:44:26 +0200, Richard Delorme a écrit :
Bref il s'agissait de créer un langage de haut niveau, en partant de langages existants (BCPL), et non d'un assembleur amélioré.
Pourtant :
In Chapter 4, we argued that C has been successful because it acts as a layer of thin glue over computer hardware approximating the "standard architecture" of [BlaauwBrooks].
Dans "Art Of Unix programming" d'ESR : http://www.catb.org/~esr/writings/taoup/html/c_evolution.html
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Wed, 30 Jun 2004 00:44:26 +0200, Richard Delorme a écrit :
Bref il s'agissait de créer un langage de haut niveau, en partant de
langages existants (BCPL), et non d'un assembleur amélioré.
Pourtant :
In Chapter 4, we argued that C has been successful because it acts as a
layer of thin glue over computer hardware approximating the "standard
architecture" of [BlaauwBrooks].
Dans "Art Of Unix programming" d'ESR :
http://www.catb.org/~esr/writings/taoup/html/c_evolution.html
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Wed, 30 Jun 2004 00:44:26 +0200, Richard Delorme a écrit :
Bref il s'agissait de créer un langage de haut niveau, en partant de langages existants (BCPL), et non d'un assembleur amélioré.
Pourtant :
In Chapter 4, we argued that C has been successful because it acts as a layer of thin glue over computer hardware approximating the "standard architecture" of [BlaauwBrooks].
Dans "Art Of Unix programming" d'ESR : http://www.catb.org/~esr/writings/taoup/html/c_evolution.html
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
JKB
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Votre question n'a aucun sens.
Précisément ce que je veux souligner : la distinction entre compilé et interprétée n'est pas pertinente.
J'aimerais bien savoir en quel honneur.
JKB
Le 29-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message <slrnce2v3g.te.bertrand@grossebaf.systella.fr>, a
écrit :
Votre question n'a aucun sens.
Précisément ce que je veux souligner : la distinction entre compilé et
interprétée n'est pas pertinente.
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
JKB , dans le message , a écrit :
Votre question n'a aucun sens.
Précisément ce que je veux souligner : la distinction entre compilé et interprétée n'est pas pertinente.
J'aimerais bien savoir en quel honneur.
JKB
remy
Quant à la maintenance, je préfèrerais maintenir du C. Avec Java, après quelques semaines d'inutilisation, j'ai toujours du mal à me rappeler la subtilité qu'il y a entre un String et un StringBuffer,
dans ton jdk il y a un fichier src.zip la seul source info via pour java
remy
Quant à la maintenance, je préfèrerais maintenir du C. Avec Java, après
quelques semaines d'inutilisation, j'ai toujours du mal à me rappeler la
subtilité qu'il y a entre un String et un StringBuffer,
dans ton jdk il y a un fichier src.zip
la seul source info via pour java
Quant à la maintenance, je préfèrerais maintenir du C. Avec Java, après quelques semaines d'inutilisation, j'ai toujours du mal à me rappeler la subtilité qu'il y a entre un String et un StringBuffer,
dans ton jdk il y a un fichier src.zip la seul source info via pour java
remy
JKB
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
Tu avances cet argument, mais il n'y a rien derrière. Prenons un cas trivial :
2 × (x + y)
2 x y + ×
Il me semble que la différence de lisibilité saute aux yeux. Tiens,
Non. C'est un peu le même argument que celui qui consiste à prétendre que l'écriture arabe ressemble à un plat de nouilles car on ne sait pas la lire. Donc mauvais argument, changer d'argument.
dis-moi, comment parses-tu :
x y z f g
Faut-il le lire « g(x, f(y, z)) », ou bien « g(x, y, f(z)) » ? Ou peut-être « g(f(x, y, z)) » ? À moins que ce ne soit « g(f(z), y(x) » ?
Sorti du contexte, on peut tout faire dire à une expression RPN. Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une fonction ou simplement le x-ième élément du vecteur g ?
Le RPN suppose de connaître a priori le type des arguments, donc aussi si une variable est une variable ou une fonction. Il n'y a donc aucune ambiguïté. Un analyseur RPN commence par regarder le type de l'objet élémentaire avant de le mettre dans la pile et agit en conséquence (variable, valeur numérique, fonction, expression RPN ou algébrique).
JKB
Le 29-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
Tu avances cet argument, mais il n'y a rien derrière. Prenons un cas
trivial :
2 × (x + y)
2 x y + ×
Il me semble que la différence de lisibilité saute aux yeux. Tiens,
Non. C'est un peu le même argument que celui qui consiste à
prétendre que l'écriture arabe ressemble à un plat de nouilles car
on ne sait pas la lire. Donc mauvais argument, changer d'argument.
dis-moi, comment parses-tu :
x y z f g
Faut-il le lire « g(x, f(y, z)) », ou bien « g(x, y, f(z)) » ? Ou
peut-être « g(f(x, y, z)) » ? À moins que ce ne soit « g(f(z), y(x) » ?
Sorti du contexte, on peut tout faire dire à une expression RPN.
Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une
fonction ou simplement le x-ième élément du vecteur g ?
Le RPN suppose de connaître a priori le type des arguments, donc
aussi si une variable est une variable ou une fonction. Il n'y a
donc aucune ambiguïté. Un analyseur RPN commence par regarder le
type de l'objet élémentaire avant de le mettre dans la pile et agit
en conséquence (variable, valeur numérique, fonction, expression RPN
ou algébrique).
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
Tu avances cet argument, mais il n'y a rien derrière. Prenons un cas trivial :
2 × (x + y)
2 x y + ×
Il me semble que la différence de lisibilité saute aux yeux. Tiens,
Non. C'est un peu le même argument que celui qui consiste à prétendre que l'écriture arabe ressemble à un plat de nouilles car on ne sait pas la lire. Donc mauvais argument, changer d'argument.
dis-moi, comment parses-tu :
x y z f g
Faut-il le lire « g(x, f(y, z)) », ou bien « g(x, y, f(z)) » ? Ou peut-être « g(f(x, y, z)) » ? À moins que ce ne soit « g(f(z), y(x) » ?
Sorti du contexte, on peut tout faire dire à une expression RPN. Comme à une expression algébrique d'ailleurs : 'g(x)' est-elle une fonction ou simplement le x-ième élément du vecteur g ?
Le RPN suppose de connaître a priori le type des arguments, donc aussi si une variable est une variable ou une fonction. Il n'y a donc aucune ambiguïté. Un analyseur RPN commence par regarder le type de l'objet élémentaire avant de le mettre dans la pile et agit en conséquence (variable, valeur numérique, fonction, expression RPN ou algébrique).
JKB
Manuel Leclerc
[type "string"]
L'avantage de cette méthode est que les utilisations répétées de la longueur de la chaîne sont plus rapides que des appels répétées (évitables en stockant la longueur dans une variable) à strlen() en C,
et en utilisant memcpy à la place de strcpy et strcat. Ce qui revient à dire qu'on peut éviter quelques inconvénients de la gestion classique des chaînes en C : il suffit de ne pas utiliser cette gestion classique, mais une autre !
Mais c'est tout l'intérêt du C, ce genre de "work arround" :-)
et le défaut de cette méthode est de calculer inutilement la longueur de la chaîne si l'on en a pas besoin.
On ajuste un compteur quand on change la chaîne. Si on la change, je suppose que c'est parce qu'on va la relire, non ? Je ne vois pas bien à quel moment cet ajustement pourrait être considéré comme "inutile".
--
http://www.linuxdevices.com/files/misc/asay-paper.pdf My method of accessing the web through email and wget does not
work for binary files, so I don't know what is in that file. --Richard Stallman
[type "string"]
L'avantage de cette méthode est que les utilisations répétées
de la longueur de la chaîne sont plus rapides que des appels
répétées (évitables en stockant la longueur dans une variable)
à strlen() en C,
et en utilisant memcpy à la place de strcpy et strcat. Ce qui
revient à dire qu'on peut éviter quelques inconvénients de
la gestion classique des chaînes en C : il suffit de ne pas
utiliser cette gestion classique, mais une autre !
Mais c'est tout l'intérêt du C, ce genre de "work arround" :-)
et le défaut de cette méthode est de calculer inutilement la
longueur de la chaîne si l'on en a pas besoin.
On ajuste un compteur quand on change la chaîne. Si on la
change, je suppose que c'est parce qu'on va la relire, non ?
Je ne vois pas bien à quel moment cet ajustement pourrait
être considéré comme "inutile".
--
http://www.linuxdevices.com/files/misc/asay-paper.pdf
My method of accessing the web through email and wget does not
work for binary files, so I don't know what is in that file.
--Richard Stallman
L'avantage de cette méthode est que les utilisations répétées de la longueur de la chaîne sont plus rapides que des appels répétées (évitables en stockant la longueur dans une variable) à strlen() en C,
et en utilisant memcpy à la place de strcpy et strcat. Ce qui revient à dire qu'on peut éviter quelques inconvénients de la gestion classique des chaînes en C : il suffit de ne pas utiliser cette gestion classique, mais une autre !
Mais c'est tout l'intérêt du C, ce genre de "work arround" :-)
et le défaut de cette méthode est de calculer inutilement la longueur de la chaîne si l'on en a pas besoin.
On ajuste un compteur quand on change la chaîne. Si on la change, je suppose que c'est parce qu'on va la relire, non ? Je ne vois pas bien à quel moment cet ajustement pourrait être considéré comme "inutile".
--
http://www.linuxdevices.com/files/misc/asay-paper.pdf My method of accessing the web through email and wget does not
work for binary files, so I don't know what is in that file. --Richard Stallman
JKB
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Thierry Boudet écrivait dans fr.comp.os.linux.debats :
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne peut aller nulle part. S'il faut utiliser une notation plus restrictive pour forcer les élèves débutants à être rigoureux, c'est dommage, mais c'est comme ça.
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants. Le coeur des mathématiques c'est l'imagination et l'invention.
Ne classe-t-on pas les mathematiques comme un "art hypothético-déductif" ?
Michel Talon wrote:
Nicolas George <george@clipper.ens.fr> wrote:
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne
peut aller nulle part. S'il faut utiliser une notation plus restrictive
pour forcer les élèves débutants à être rigoureux, c'est dommage, mais
c'est comme ça.
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt
sauf pour les débutants et les pédants. Le coeur des mathématiques c'est
l'imagination et l'invention.
Ne classe-t-on pas les mathematiques comme un "art hypothético-déductif" ?
Le plus important, en maths, c'est la rigueur. Sans la rigueur, on ne peut aller nulle part. S'il faut utiliser une notation plus restrictive pour forcer les élèves débutants à être rigoureux, c'est dommage, mais c'est comme ça.
Ce que tu dis là est absolument inepte. La rigueur n'a aucun intérêt sauf pour les débutants et les pédants. Le coeur des mathématiques c'est l'imagination et l'invention.
Ne classe-t-on pas les mathematiques comme un "art hypothético-déductif" ?
