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...
?
C'est idiot comme argument lorsque l'on parle de langage interprété
C'est la distinction interprété/compilé qui est pipo.
(donc représentable par une machine de Turing de base).
Ça c'est complètement n'importe quoi. Des buzzwords jetés n'importe comment.
Par ailleurs il existe des langages compilables et d'autres qui ne le sont pas (cf. Donald Knuth, je ne sais plus quel tome du Art of computing).
Je rêve ou tu as dit toi-même que c'était toi qui choisissais le langage ?
george
j , dans le message , a écrit :
Continuer à enseigner la notation de Newton pour les calculs différentiels au lycée voici une dissonance cognitive (la notation de Leibniz étant au moins «auto-cohérente»). d(f(g(x)))/dxß(g)/dg . d(g(x))/dx est plus simple que la règle à apprendre pour (f rong g)'(x)
C'est vrai, et c'est même tellement vrai qu'à haut niveau, c'est ce formalisme qui est employé. Cependant, cette notation a de gros problèmes pour l'enseignement, en ce qu'elle favorise manipulations qui ne sont pas forcément légitimes. J'ai déjà vu quelqu'un simplifier f dans f'/f, et ne garder que ', si on enseignait la même chose avec les formes différentielles, 80% des élèves, au bas mot, feraient n'importe quoi. Le pire étant qu'environ la moitié des manipulations abusives qu'on a envie de faire avec les dx sont, au final, exactes, mais pour des raisons autres.
j , dans le message <20040629150837.321cc379@osmonda.prive.jul>, a
écrit :
Continuer à enseigner la notation de Newton pour les calculs
différentiels au lycée voici une dissonance cognitive (la notation de
Leibniz étant au moins «auto-cohérente»).
d(f(g(x)))/dxß(g)/dg . d(g(x))/dx est plus simple que la règle à
apprendre pour (f rong g)'(x)
C'est vrai, et c'est même tellement vrai qu'à haut niveau, c'est ce
formalisme qui est employé. Cependant, cette notation a de gros
problèmes pour l'enseignement, en ce qu'elle favorise manipulations qui
ne sont pas forcément légitimes. J'ai déjà vu quelqu'un simplifier f
dans f'/f, et ne garder que ', si on enseignait la même chose avec les
formes différentielles, 80% des élèves, au bas mot, feraient n'importe
quoi. Le pire étant qu'environ la moitié des manipulations abusives
qu'on a envie de faire avec les dx sont, au final, exactes, mais pour
des raisons autres.
Continuer à enseigner la notation de Newton pour les calculs différentiels au lycée voici une dissonance cognitive (la notation de Leibniz étant au moins «auto-cohérente»). d(f(g(x)))/dxß(g)/dg . d(g(x))/dx est plus simple que la règle à apprendre pour (f rong g)'(x)
C'est vrai, et c'est même tellement vrai qu'à haut niveau, c'est ce formalisme qui est employé. Cependant, cette notation a de gros problèmes pour l'enseignement, en ce qu'elle favorise manipulations qui ne sont pas forcément légitimes. J'ai déjà vu quelqu'un simplifier f dans f'/f, et ne garder que ', si on enseignait la même chose avec les formes différentielles, 80% des élèves, au bas mot, feraient n'importe quoi. Le pire étant qu'environ la moitié des manipulations abusives qu'on a envie de faire avec les dx sont, au final, exactes, mais pour des raisons autres.
george
JKB , dans le message , a écrit :
Rien ne m'empêche d'écrire du C comme un goret contrairement au Fortran par exemple. Le truc compile si ça vous intéresse. Ce qui fait la facilité de lecture ou d'écriture d'un langage n'est pas intrinsèque au langage lui-même.
Est-ce que tu es conscient que ces deux phrases sont contradictoires ?
JKB , dans le message <slrnce2pm0.te.bertrand@grossebaf.systella.fr>, a
écrit :
Rien ne m'empêche d'écrire du C comme un goret contrairement au
Fortran par exemple. Le truc compile si ça vous intéresse.
Ce qui fait la facilité de lecture ou d'écriture d'un langage n'est
pas intrinsèque au langage lui-même.
Est-ce que tu es conscient que ces deux phrases sont contradictoires ?
Rien ne m'empêche d'écrire du C comme un goret contrairement au Fortran par exemple. Le truc compile si ça vous intéresse. Ce qui fait la facilité de lecture ou d'écriture d'un langage n'est pas intrinsèque au langage lui-même.
Est-ce que tu es conscient que ces deux phrases sont contradictoires ?
Manuel Leclerc
Pour ce qui est de l'efficacité, maintenant, n'importe quel programme un peu gros manipulant des chaînes de caractères en C est truffé de code comptant les caractères pour vérifier que ça va passer et/ou utilise l'allocation dynamique. Que ce soit plus "efficace" qu'un mécanisme "built-in" se discute, pour le moins.
C'est quoi un « mécanisme "built-in" »? une fonction de la bibliothèque ?
C'est un truc genre "type de donnée string" par exemple. Comme en pascal.
S'il y a un domaine où la bibliothèque C standard est relativement complète, c'est quand même celui de la manipulation des chaînes de caractères.
Mieux vaut lire ça que d'être sourd, je suppose.
Si, par « mécanisme "built-in" », tu veux dire que les autres langages font des choses, comme l'allocation dynamique ou la mesure de la longueur d'une chaîne, sans qu'on leur demande, alors qu'en C tout est explicite, c'est pour moi indiscutable que le programme C sera plus efficace.
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL) len = strlen(idstr) + 1; else len = strlen(library) + strlen(idstr) + 1; strdata = (char *) malloc (len); strcpy(strdata, library); strcat(strdata, idstr);
En pascal, c'est plutôt :
strdata := library + idstr;
L version C sera un plus performante au niveau mémoire et CPU ? Ce n'est pas évident. strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
En tout cas, au jour d'aujourd'hui, pour des vrais programmes de la vraie vie, je classe la version C dans la catégorie "brain fuck".
--
Look for instance at KOffice, OpenOffice and AbiWord. They all duplicate their efforts - just imagine what could happen if they all worked together. 800 megs and constantly swapping?
--D. Starner
Pour ce qui est de l'efficacité, maintenant, n'importe
quel programme un peu gros manipulant des chaînes de
caractères en C est truffé de code comptant les caractères
pour vérifier que ça va passer et/ou utilise l'allocation
dynamique.
Que ce soit plus "efficace" qu'un mécanisme "built-in" se
discute, pour le moins.
C'est quoi un « mécanisme "built-in" »? une fonction de la
bibliothèque ?
C'est un truc genre "type de donnée string" par exemple. Comme
en pascal.
S'il y a un domaine où la bibliothèque C standard est
relativement complète, c'est quand même celui de la manipulation
des chaînes de caractères.
Mieux vaut lire ça que d'être sourd, je suppose.
Si, par « mécanisme "built-in" », tu veux dire que les autres
langages font des choses, comme l'allocation dynamique ou la
mesure de la longueur d'une chaîne, sans qu'on leur demande,
alors qu'en C tout est explicite, c'est pour moi indiscutable
que le programme C sera plus efficace.
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL)
len = strlen(idstr) + 1;
else
len = strlen(library) + strlen(idstr) + 1;
strdata = (char *) malloc (len);
strcpy(strdata, library);
strcat(strdata, idstr);
En pascal, c'est plutôt :
strdata := library + idstr;
L version C sera un plus performante au niveau mémoire
et CPU ? Ce n'est pas évident. strlen et strcat ne
sont pas des fonctions particulièrement conçues pour
optimiser les performances de manipulations de chaîne,
me semble-t-il...
En tout cas, au jour d'aujourd'hui, pour des vrais
programmes de la vraie vie, je classe la version C dans
la catégorie "brain fuck".
--
Look for instance at KOffice, OpenOffice and AbiWord. They all duplicate
their efforts - just imagine what could happen if they all worked together.
800 megs and constantly swapping?
Pour ce qui est de l'efficacité, maintenant, n'importe quel programme un peu gros manipulant des chaînes de caractères en C est truffé de code comptant les caractères pour vérifier que ça va passer et/ou utilise l'allocation dynamique. Que ce soit plus "efficace" qu'un mécanisme "built-in" se discute, pour le moins.
C'est quoi un « mécanisme "built-in" »? une fonction de la bibliothèque ?
C'est un truc genre "type de donnée string" par exemple. Comme en pascal.
S'il y a un domaine où la bibliothèque C standard est relativement complète, c'est quand même celui de la manipulation des chaînes de caractères.
Mieux vaut lire ça que d'être sourd, je suppose.
Si, par « mécanisme "built-in" », tu veux dire que les autres langages font des choses, comme l'allocation dynamique ou la mesure de la longueur d'une chaîne, sans qu'on leur demande, alors qu'en C tout est explicite, c'est pour moi indiscutable que le programme C sera plus efficace.
Indiscutable ?
Tiens, un exemple marrant :
if (library == NULL) len = strlen(idstr) + 1; else len = strlen(library) + strlen(idstr) + 1; strdata = (char *) malloc (len); strcpy(strdata, library); strcat(strdata, idstr);
En pascal, c'est plutôt :
strdata := library + idstr;
L version C sera un plus performante au niveau mémoire et CPU ? Ce n'est pas évident. strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
En tout cas, au jour d'aujourd'hui, pour des vrais programmes de la vraie vie, je classe la version C dans la catégorie "brain fuck".
--
Look for instance at KOffice, OpenOffice and AbiWord. They all duplicate their efforts - just imagine what could happen if they all worked together. 800 megs and constantly swapping?
--D. Starner
george
"Manuel Leclerc" , dans le message , a écrit :
strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Bien sûr que si.
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal.
"Manuel Leclerc" , dans le message <40e16efe@neottia.net>, a écrit :
strlen et strcat ne
sont pas des fonctions particulièrement conçues pour
optimiser les performances de manipulations de chaîne,
me semble-t-il...
Bien sûr que si.
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du
style :
strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Bien sûr que si.
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal.
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 :
C'est idiot comme argument lorsque l'on parle de langage interprété
C'est la distinction interprété/compilé qui est pipo.
Et pourquoi ? Dans l'ensemble des langages possibles, il existe l'interprété et le compilé (plus quelques trucs exotiques), et si tous les langages compilables peuvent être interprétés, contrairement à ce que vous semblez croire, il existe des langages interprétés qui ne peuvent _théoriquement_ pas être compilés.
(donc représentable par une machine de Turing de base).
Ça c'est complètement n'importe quoi. Des buzzwords jetés n'importe comment.
Ah ? Pourtant la machine de Turing est un exemple simple et _universel_ d'automate, donc est tout à fait apte à représenter un interpréteur.
Par ailleurs il existe des langages compilables et d'autres qui ne le sont pas (cf. Donald Knuth, je ne sais plus quel tome du Art of computing).
Je rêve ou tu as dit toi-même que c'était toi qui choisissais le langage ?
Oui et non. On a un objectif, et on fait des compromis pour atteindre cet objectif. Le choix d'un langage plutôt qu'un autre est une conséquence et non un choix libre.
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 <slrnce2p9t.te.bertrand@grossebaf.systella.fr>, a
écrit :
C'est idiot comme argument lorsque l'on parle de langage interprété
C'est la distinction interprété/compilé qui est pipo.
Et pourquoi ? Dans l'ensemble des langages possibles, il existe
l'interprété et le compilé (plus quelques trucs exotiques), et si
tous les langages compilables peuvent être interprétés,
contrairement à ce que vous semblez croire, il existe des langages
interprétés qui ne peuvent _théoriquement_ pas être compilés.
(donc représentable par une machine de Turing de base).
Ça c'est complètement n'importe quoi. Des buzzwords jetés n'importe
comment.
Ah ? Pourtant la machine de Turing est un exemple simple et
_universel_ d'automate, donc est tout à fait apte à représenter un
interpréteur.
Par ailleurs
il existe des langages compilables et d'autres qui ne le sont pas
(cf. Donald Knuth, je ne sais plus quel tome du Art of computing).
Je rêve ou tu as dit toi-même que c'était toi qui choisissais le
langage ?
Oui et non. On a un objectif, et on fait des compromis pour atteindre cet
objectif. Le choix d'un langage plutôt qu'un autre est une
conséquence et non un choix libre.
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 :
C'est idiot comme argument lorsque l'on parle de langage interprété
C'est la distinction interprété/compilé qui est pipo.
Et pourquoi ? Dans l'ensemble des langages possibles, il existe l'interprété et le compilé (plus quelques trucs exotiques), et si tous les langages compilables peuvent être interprétés, contrairement à ce que vous semblez croire, il existe des langages interprétés qui ne peuvent _théoriquement_ pas être compilés.
(donc représentable par une machine de Turing de base).
Ça c'est complètement n'importe quoi. Des buzzwords jetés n'importe comment.
Ah ? Pourtant la machine de Turing est un exemple simple et _universel_ d'automate, donc est tout à fait apte à représenter un interpréteur.
Par ailleurs il existe des langages compilables et d'autres qui ne le sont pas (cf. Donald Knuth, je ne sais plus quel tome du Art of computing).
Je rêve ou tu as dit toi-même que c'était toi qui choisissais le langage ?
Oui et non. On a un objectif, et on fait des compromis pour atteindre cet objectif. Le choix d'un langage plutôt qu'un autre est une conséquence et non un choix libre.
JKB
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 :
Rien ne m'empêche d'écrire du C comme un goret contrairement au Fortran par exemple. Le truc compile si ça vous intéresse. Ce qui fait la facilité de lecture ou d'écriture d'un langage n'est pas intrinsèque au langage lui-même.
Est-ce que tu es conscient que ces deux phrases sont contradictoires ?
Non. Je tiens juste à montrer que l'on peut écrire bien ou non dans n'importe quel langage.
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 <slrnce2pm0.te.bertrand@grossebaf.systella.fr>, a
écrit :
Rien ne m'empêche d'écrire du C comme un goret contrairement au
Fortran par exemple. Le truc compile si ça vous intéresse.
Ce qui fait la facilité de lecture ou d'écriture d'un langage n'est
pas intrinsèque au langage lui-même.
Est-ce que tu es conscient que ces deux phrases sont contradictoires ?
Non. Je tiens juste à montrer que l'on peut écrire bien ou non dans
n'importe quel langage.
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 :
Rien ne m'empêche d'écrire du C comme un goret contrairement au Fortran par exemple. Le truc compile si ça vous intéresse. Ce qui fait la facilité de lecture ou d'écriture d'un langage n'est pas intrinsèque au langage lui-même.
Est-ce que tu es conscient que ces deux phrases sont contradictoires ?
Non. Je tiens juste à montrer que l'on peut écrire bien ou non dans n'importe quel langage.
JKB
JKB
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Manuel Leclerc écrivait dans fr.comp.os.linux.debats :
En tout cas, au jour d'aujourd'hui, pour des vrais programmes de la vraie vie, je classe la version C dans la catégorie "brain fuck".
Dans mes bras ;-)
JKB
Le 29-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Manuel Leclerc écrivait dans fr.comp.os.linux.debats :
En tout cas, au jour d'aujourd'hui, pour des vrais
programmes de la vraie vie, je classe la version C dans
la catégorie "brain fuck".
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Manuel Leclerc écrivait dans fr.comp.os.linux.debats :
En tout cas, au jour d'aujourd'hui, pour des vrais programmes de la vraie vie, je classe la version C dans la catégorie "brain fuck".
Dans mes bras ;-)
JKB
JKB
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
"Manuel Leclerc" , dans le message , a écrit :
strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Bien sûr que si.
Bien sûr que non, parce que les outils str* dépendent de l'implémentation (gcc utilise des define, d'autres des inline et j'en passe), et que la bonne façon d'utiliser des chaînes pour optimiser la ressource CPU est d'introduire un descripteur de chaîne.
JKB
Le 29-06-2004, à propos de
Re: Fichier Windows et matériel Linux,
Nicolas George écrivait dans fr.comp.os.linux.debats :
"Manuel Leclerc" , dans le message <40e16efe@neottia.net>, a écrit :
strlen et strcat ne
sont pas des fonctions particulièrement conçues pour
optimiser les performances de manipulations de chaîne,
me semble-t-il...
Bien sûr que si.
Bien sûr que non, parce que les outils str* dépendent de
l'implémentation (gcc utilise des define, d'autres des inline et
j'en passe), et que la bonne façon d'utiliser des chaînes pour
optimiser la ressource CPU est d'introduire un descripteur de
chaîne.
Le 29-06-2004, à propos de Re: Fichier Windows et matériel Linux, Nicolas George écrivait dans fr.comp.os.linux.debats :
"Manuel Leclerc" , dans le message , a écrit :
strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Bien sûr que si.
Bien sûr que non, parce que les outils str* dépendent de l'implémentation (gcc utilise des define, d'autres des inline et j'en passe), et que la bonne façon d'utiliser des chaînes pour optimiser la ressource CPU est d'introduire un descripteur de chaîne.
JKB
Manuel Leclerc
strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Bien sûr que si.
Non, elles utilisent le concept "un zéro à la fin". C'est nul. Tu trouves plein de code qui passe son temps à chercher le même zéro et des fonctions de bibliothèques qui sont sous-optimales pour les copies. Si tu veux être _vraiment_ efficace, tu te définies ta structure string, et tu fais des macros à coup de memcpy, mais l'efficacité tu t'en fous, non ?
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal.
???
-- We've found that most of our customers LIKE having Product Y hang, freeze, and emit smoke. --dpbsmith
strlen et strcat ne sont pas des fonctions
particulièrement conçues pour optimiser les
performances de manipulations de chaîne,
me semble-t-il...
Bien sûr que si.
Non, elles utilisent le concept "un zéro à la fin".
C'est nul. Tu trouves plein de code qui passe
son temps à chercher le même zéro et des fonctions
de bibliothèques qui sont sous-optimales pour les
copies. Si tu veux être _vraiment_ efficace, tu te
définies ta structure string, et tu fais des macros
à coup de memcpy, mais l'efficacité tu t'en fous, non ?
Accessoirement, réfléchis un peu à ce que peut donner
quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal.
???
--
We've found that most of our customers LIKE having Product Y hang, freeze,
and emit smoke.
--dpbsmith
strlen et strcat ne sont pas des fonctions particulièrement conçues pour optimiser les performances de manipulations de chaîne, me semble-t-il...
Bien sûr que si.
Non, elles utilisent le concept "un zéro à la fin". C'est nul. Tu trouves plein de code qui passe son temps à chercher le même zéro et des fonctions de bibliothèques qui sont sous-optimales pour les copies. Si tu veux être _vraiment_ efficace, tu te définies ta structure string, et tu fais des macros à coup de memcpy, mais l'efficacité tu t'en fous, non ?
Accessoirement, réfléchis un peu à ce que peut donner quelque chose du style :
file = path + "/" + basename + "." + extension
en C ou avec ton compilateur pascal.
???
-- We've found that most of our customers LIKE having Product Y hang, freeze, and emit smoke. --dpbsmith
