A propos de l'implémentation du logiciel Graphviz de visualisation de graphes,
je lis dans l'article "Graphviz and Dynagraph - Static and Dynamic Graph Drawing
Tools"
(cf.
http://www.research.att.com/areas/visualization/papers_videos/abstract.php?id=GDS-Ellsongknw03)
:
Implementation
The design and implementation of Graphviz reflect the age of the software,
with much of the core written in the early 1990’s. Most of Graphviz is written
in C, as it predates stable, efficient or portable implementations of C++
and Java.
suivi immédiatement de la note de bas de page suivante :
If the choice had to be made now, the same decision might be made for the same
reasons.
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette note de
bas de page : parce que l'article a été écrit en 2001 ou 2002, époque où
existaient déjà des implémentations stables, efficaces ou portables des langages
C++ ou Java.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc
candide wrote:
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette note de bas de page : parce que l'article a été écrit en 2001 ou 2002, époque où existaient déjà des implémentations stables, efficaces ou portables des langages C++ ou Java.
Vraiment ? gcc-3.0 est sorti à la mi-2001, on ne peut pas vraiment dire que les implémentations C++ étaient super avancées à l'époque. Java n'en était qu'à la version 1.3, où l'implémentation de Sun n'était pas encore super performante, et je ne sais pas trop où en étaient les autres implémentations (la JVM de Microsoft devait encore être bien présente).
De façon générale, même aujourd'hui, on ne fait pas vraiment mieux que le C pour les critères donnés (sauf que les définitions de ces critères ne sont pas très claires). Les raisons avancées pour choisir d'autres langages tournent plus autour de gros mots comme la productivité.
candide wrote:
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette
note de bas de page : parce que l'article a été écrit en 2001 ou 2002,
époque où existaient déjà des implémentations stables, efficaces ou
portables des langages C++ ou Java.
Vraiment ? gcc-3.0 est sorti à la mi-2001, on ne peut pas vraiment dire
que les implémentations C++ étaient super avancées à l'époque. Java n'en
était qu'à la version 1.3, où l'implémentation de Sun n'était pas encore
super performante, et je ne sais pas trop où en étaient les autres
implémentations (la JVM de Microsoft devait encore être bien présente).
De façon générale, même aujourd'hui, on ne fait pas vraiment mieux que le
C pour les critères donnés (sauf que les définitions de ces critères ne
sont pas très claires). Les raisons avancées pour choisir d'autres
langages tournent plus autour de gros mots comme la productivité.
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette note de bas de page : parce que l'article a été écrit en 2001 ou 2002, époque où existaient déjà des implémentations stables, efficaces ou portables des langages C++ ou Java.
Vraiment ? gcc-3.0 est sorti à la mi-2001, on ne peut pas vraiment dire que les implémentations C++ étaient super avancées à l'époque. Java n'en était qu'à la version 1.3, où l'implémentation de Sun n'était pas encore super performante, et je ne sais pas trop où en étaient les autres implémentations (la JVM de Microsoft devait encore être bien présente).
De façon générale, même aujourd'hui, on ne fait pas vraiment mieux que le C pour les critères donnés (sauf que les définitions de ces critères ne sont pas très claires). Les raisons avancées pour choisir d'autres langages tournent plus autour de gros mots comme la productivité.
Antoine Leca
Le 28/05/2009 0:43, candide cita :
written in C, as it predates stable, efficient or portable implementations of C++ and Java.
suivi immédiatement de la note de bas de page suivante :
If the choice had to be made now, the same decision might be made for the same reasons.
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette note de bas de page
Tu renverses le sens de l'implication, donc tu dois inverser les prédicats, et remplacer "or" par "and" (et "C++ and Java" par "C++ or Java", évidemment, il n'est pas nécessaire d'avoir _à la fois_ une implémentation de C++ et une de Java).
OEQLC?
Antoine
Le 28/05/2009 0:43, candide cita :
written in C, as it predates stable, efficient or portable implementations
of C++ and Java.
suivi immédiatement de la note de bas de page suivante :
If the choice had to be made now, the same decision might be made for the same
reasons.
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette note de
bas de page
Tu renverses le sens de l'implication, donc tu dois inverser les
prédicats, et remplacer "or" par "and" (et "C++ and Java" par "C++ or
Java", évidemment, il n'est pas nécessaire d'avoir _à la fois_ une
implémentation de C++ et une de Java).
written in C, as it predates stable, efficient or portable implementations of C++ and Java.
suivi immédiatement de la note de bas de page suivante :
If the choice had to be made now, the same decision might be made for the same reasons.
Alors, je veux bien qu'on m'explique le sens qu'il faut donner à cette note de bas de page
Tu renverses le sens de l'implication, donc tu dois inverser les prédicats, et remplacer "or" par "and" (et "C++ and Java" par "C++ or Java", évidemment, il n'est pas nécessaire d'avoir _à la fois_ une implémentation de C++ et une de Java).
OEQLC?
Antoine
candide
Antoine Leca a écrit :
Tu renverses le sens de l'implication, donc tu dois inverser les prédicats, et remplacer "or" par "and" (et "C++ and Java" par "C++ or Java", évidemment, il n'est pas nécessaire d'avoir _à la fois_ une implémentation de C++ et une de Java).
Merci de tes rappels de logique propositionnelle mais je connais la musique et le problème n'est pas là.
Je reprends ce que disent les 4 auteurs de l'article (article que l'on peut lire ici : http://www.graphviz.org/Documentation/EGKNW03.pdf)
--------------------- 8< ------------------------------------- The design and implementation of Graphviz reflect the age of the software, with much of the core written in the early 1990’s. Most of Graphviz is written in C, as it predates stable, efficient or portable implementations of C++ and Java --------------------- >8 -------------------------------------
Jusque là rien à dire : que Graphviz ait été écrit en C me parait en accord avec les moeurs du début des années 90, C++ n'était pas d'un usage répandu et Java n'existait pas ...
Par contre, désolé de me répéter, c'est la note de bas de page qui me parait très surprenante :
--------------------- 8< ------------------------------------- If the choice had to be made now, the same decision might be made for the same reasons. --------------------- >8 -------------------------------------
Ecrire ça en 2002 alors que C++ était un langage normalisé et très utilisé pour des applications portables plus amples que Graphviz, c'est plutôt surprenant. Quant à Java, en 2002, c'était un langage déjà bien installé, stable, portable et pas du tout inefficace.
J'ai contacté un des 4 auteurs de l'article pour lui demander ce qu'ils voulaient dire, et voilà en substance ce qu'il m'a répondu
--------------------- 8< ------------------------------------- Even if the C++ language is stable, the environments have been a moving target. When you combine this with strict type checking, it's quite hard to write source code that is portable across the many platforms (machines, OS versions, and even compilers) that we support (e.g. Intel C++ vs. Microsoft Visual Studio vs. Gnu plus maybe some legacy C++ compilers like SGI.) --------------------- 8< -------------------------------------
Donc, exit les arguments d'efficacité, de stabilité, ne restent que les arguments de portabilité.
OEQLC?
La question sur le langage C, c'est ça ? Ça me paraît évident :
en quoi le langage C est-il si stable, si efficace et/ou si portable pour que cela justifie qu'en 2002 on doive implémenter dans ce langage un outil comme GraphViz et qui pourtant n'est pas un outil extrêmement complexe ?
Et corrélativement, ça me parait poser la question essentielle de savoir : que _crée_-t-on aujourd'hui en 2009 et demain en langage C en dehors des programmes basés sur l'existant en C ou des contraintes matérielles (embarqué ou pas de compilateur C++) ?
Antoine Leca a écrit :
Tu renverses le sens de l'implication, donc tu dois inverser les
prédicats, et remplacer "or" par "and" (et "C++ and Java" par "C++ or
Java", évidemment, il n'est pas nécessaire d'avoir _à la fois_ une
implémentation de C++ et une de Java).
Merci de tes rappels de logique propositionnelle mais je connais la musique et
le problème n'est pas là.
Je reprends ce que disent les 4 auteurs de l'article (article que l'on peut lire
ici : http://www.graphviz.org/Documentation/EGKNW03.pdf)
--------------------- 8< -------------------------------------
The design and implementation of Graphviz reflect the age of the software,
with much of the core written in the early 1990’s. Most of Graphviz is written
in C, as it predates stable, efficient or portable implementations of C++
and Java
--------------------- >8 -------------------------------------
Jusque là rien à dire : que Graphviz ait été écrit en C me parait en accord avec
les moeurs du début des années 90, C++ n'était pas d'un usage répandu et Java
n'existait pas ...
Par contre, désolé de me répéter, c'est la note de bas de page qui me parait
très surprenante :
--------------------- 8< -------------------------------------
If the choice had to be made now, the same decision might be made for the same
reasons.
--------------------- >8 -------------------------------------
Ecrire ça en 2002 alors que C++ était un langage normalisé et très utilisé pour
des applications portables plus amples que Graphviz, c'est plutôt surprenant.
Quant à Java, en 2002, c'était un langage déjà bien installé, stable, portable
et pas du tout inefficace.
J'ai contacté un des 4 auteurs de l'article pour lui demander ce qu'ils
voulaient dire, et voilà en substance ce qu'il m'a répondu
--------------------- 8< -------------------------------------
Even if the C++ language is stable, the environments have been
a moving target. When you combine this with strict type checking,
it's quite hard to write source code that is portable across the
many platforms (machines, OS versions, and even compilers)
that we support (e.g. Intel C++ vs. Microsoft Visual Studio vs. Gnu
plus maybe some legacy C++ compilers like SGI.)
--------------------- 8< -------------------------------------
Donc, exit les arguments d'efficacité, de stabilité, ne restent que les
arguments de portabilité.
OEQLC?
La question sur le langage C, c'est ça ? Ça me paraît évident :
en quoi le langage C est-il si stable, si efficace et/ou si portable pour que
cela justifie qu'en 2002 on doive implémenter dans ce langage un outil comme
GraphViz et qui pourtant n'est pas un outil extrêmement complexe ?
Et corrélativement, ça me parait poser la question essentielle de savoir : que
_crée_-t-on aujourd'hui en 2009 et demain en langage C en dehors des programmes
basés sur l'existant en C ou des contraintes matérielles (embarqué ou pas de
compilateur C++) ?
Tu renverses le sens de l'implication, donc tu dois inverser les prédicats, et remplacer "or" par "and" (et "C++ and Java" par "C++ or Java", évidemment, il n'est pas nécessaire d'avoir _à la fois_ une implémentation de C++ et une de Java).
Merci de tes rappels de logique propositionnelle mais je connais la musique et le problème n'est pas là.
Je reprends ce que disent les 4 auteurs de l'article (article que l'on peut lire ici : http://www.graphviz.org/Documentation/EGKNW03.pdf)
--------------------- 8< ------------------------------------- The design and implementation of Graphviz reflect the age of the software, with much of the core written in the early 1990’s. Most of Graphviz is written in C, as it predates stable, efficient or portable implementations of C++ and Java --------------------- >8 -------------------------------------
Jusque là rien à dire : que Graphviz ait été écrit en C me parait en accord avec les moeurs du début des années 90, C++ n'était pas d'un usage répandu et Java n'existait pas ...
Par contre, désolé de me répéter, c'est la note de bas de page qui me parait très surprenante :
--------------------- 8< ------------------------------------- If the choice had to be made now, the same decision might be made for the same reasons. --------------------- >8 -------------------------------------
Ecrire ça en 2002 alors que C++ était un langage normalisé et très utilisé pour des applications portables plus amples que Graphviz, c'est plutôt surprenant. Quant à Java, en 2002, c'était un langage déjà bien installé, stable, portable et pas du tout inefficace.
J'ai contacté un des 4 auteurs de l'article pour lui demander ce qu'ils voulaient dire, et voilà en substance ce qu'il m'a répondu
--------------------- 8< ------------------------------------- Even if the C++ language is stable, the environments have been a moving target. When you combine this with strict type checking, it's quite hard to write source code that is portable across the many platforms (machines, OS versions, and even compilers) that we support (e.g. Intel C++ vs. Microsoft Visual Studio vs. Gnu plus maybe some legacy C++ compilers like SGI.) --------------------- 8< -------------------------------------
Donc, exit les arguments d'efficacité, de stabilité, ne restent que les arguments de portabilité.
OEQLC?
La question sur le langage C, c'est ça ? Ça me paraît évident :
en quoi le langage C est-il si stable, si efficace et/ou si portable pour que cela justifie qu'en 2002 on doive implémenter dans ce langage un outil comme GraphViz et qui pourtant n'est pas un outil extrêmement complexe ?
Et corrélativement, ça me parait poser la question essentielle de savoir : que _crée_-t-on aujourd'hui en 2009 et demain en langage C en dehors des programmes basés sur l'existant en C ou des contraintes matérielles (embarqué ou pas de compilateur C++) ?
Antoine Leca
Le 29/05/2009 23:02, candied écrivit :
Merci de tes rappels de logique propositionnelle mais je connais la musique et le problème n'est pas là.
Alors désolé je ne comprends plus ton problème.
Je reprends ce que disent les 4 auteurs de l'article (article que l'on peut lire ici : http://www.graphviz.org/Documentation/EGKNW03.pdf)
<snip>
Ecrire ça en 2002 alors que C++ était un langage normalisé et très utilisé pour des applications portables plus amples que Graphviz, c'est plutôt surprenant. Quant à Java, en 2002, c'était un langage déjà bien installé, stable, portable et pas du tout inefficace.
Je ne lis pas comme toi : l'avis des auteurs en 2002, c'est que ni C++ ni Java n'avaient les qualités qu'_ils_ estimaient nécessaires en matière de stabilité, d'efficacité et de portabilité.
Toute digression au-delà du simple rapport de cette opinion étant explicitement hors-sujet dans ce groupe, je saute à...
OEQLC?
en quoi le langage C est-il si stable, si efficace et/ou si portable pour que cela justifie qu'en 2002 on doive implémenter dans ce langage un outil comme GraphViz et qui pourtant n'est pas un outil extrêmement complexe ?
Parce qu'à l'époque, les compilateurs C avaient environ 25-30 ans de pratique, et une définition stabilisée depuis 12 ans, donc la divergence créatrice que l'on connut dans les années 80 était passée de mode, au profit de la stabilité et de la portabilité. Et franchement, au moins jusqu'en 1998-2000, ce n'était pas les seuls à avoir cet avis.
Et en 1998, un développeur de compilateur m'expliquait à peu près la même chose, sauf que le 5e mot était Fortran, et que son objectif était d'obtenir des compilos C qui atteignaient le niveau d'exigence de ses clients, en matière justement de portabilité (sous-entendu: de code numérique existants) et d'efficacité (sous-entendu: de ressources machine). Je ne suis plus au bon endroit pour savoir si c'est encore d'actualité.
Et corrélativement, ça me parait poser la question essentielle de savoir : que _crée_-t-on aujourd'hui en 2009 et demain en langage C en dehors des programmes basés sur l'existant en C ou des contraintes matérielles (embarqué ou pas de compilateur C++) ?
C'est juste que je n'avais pas lu cette question essentielle dans le message <news:4a1dde39$0$11806$
Cela étant, la réaction citée est typique de l'attitude des directeurs de projet, qui s'ils n'ont pas d'autre contrainte, vont souvent avoir tendance à prolonger sur plusieurs années un état de fait qui s'éloigne progressivement de l'état de l'art.
Et une partie importante de la formation d'un standard (au sens le plus large) est justement d'arriver à s'imposer comme état de fait après avoir été l'état de l'art : je compare cela à la théorie de l'inflation, c'est le coup d'accélérateur ou de rein qui sépare le produit "star" du simple produit vedette_en_son_temps (ou vache-à-lait selon le BCG).
Antoine
Le 29/05/2009 23:02, candied écrivit :
Merci de tes rappels de logique propositionnelle mais je connais la musique et
le problème n'est pas là.
Alors désolé je ne comprends plus ton problème.
Je reprends ce que disent les 4 auteurs de l'article (article que l'on peut lire
ici : http://www.graphviz.org/Documentation/EGKNW03.pdf)
<snip>
Ecrire ça en 2002 alors que C++ était un langage normalisé et très utilisé pour
des applications portables plus amples que Graphviz, c'est plutôt surprenant.
Quant à Java, en 2002, c'était un langage déjà bien installé, stable, portable
et pas du tout inefficace.
Je ne lis pas comme toi : l'avis des auteurs en 2002, c'est que ni C++
ni Java n'avaient les qualités qu'_ils_ estimaient nécessaires en
matière de stabilité, d'efficacité et de portabilité.
Toute digression au-delà du simple rapport de cette opinion étant
explicitement hors-sujet dans ce groupe, je saute à...
OEQLC?
en quoi le langage C est-il si stable, si efficace et/ou si portable pour que
cela justifie qu'en 2002 on doive implémenter dans ce langage un outil comme
GraphViz et qui pourtant n'est pas un outil extrêmement complexe ?
Parce qu'à l'époque, les compilateurs C avaient environ 25-30 ans de
pratique, et une définition stabilisée depuis 12 ans, donc la divergence
créatrice que l'on connut dans les années 80 était passée de mode, au
profit de la stabilité et de la portabilité.
Et franchement, au moins jusqu'en 1998-2000, ce n'était pas les seuls à
avoir cet avis.
Et en 1998, un développeur de compilateur m'expliquait à peu près la
même chose, sauf que le 5e mot était Fortran, et que son objectif était
d'obtenir des compilos C qui atteignaient le niveau d'exigence de ses
clients, en matière justement de portabilité (sous-entendu: de code
numérique existants) et d'efficacité (sous-entendu: de ressources machine).
Je ne suis plus au bon endroit pour savoir si c'est encore d'actualité.
Et corrélativement, ça me parait poser la question essentielle de savoir : que
_crée_-t-on aujourd'hui en 2009 et demain en langage C en dehors des programmes
basés sur l'existant en C ou des contraintes matérielles (embarqué ou pas de
compilateur C++) ?
C'est juste que je n'avais pas lu cette question essentielle dans le
message <news:4a1dde39$0$11806$426a74cc@news.free.fr>
Cela étant, la réaction citée est typique de l'attitude des directeurs
de projet, qui s'ils n'ont pas d'autre contrainte, vont souvent avoir
tendance à prolonger sur plusieurs années un état de fait qui s'éloigne
progressivement de l'état de l'art.
Et une partie importante de la formation d'un standard (au sens le plus
large) est justement d'arriver à s'imposer comme état de fait après
avoir été l'état de l'art : je compare cela à la théorie de l'inflation,
c'est le coup d'accélérateur ou de rein qui sépare le produit "star" du
simple produit vedette_en_son_temps (ou vache-à-lait selon le BCG).
Merci de tes rappels de logique propositionnelle mais je connais la musique et le problème n'est pas là.
Alors désolé je ne comprends plus ton problème.
Je reprends ce que disent les 4 auteurs de l'article (article que l'on peut lire ici : http://www.graphviz.org/Documentation/EGKNW03.pdf)
<snip>
Ecrire ça en 2002 alors que C++ était un langage normalisé et très utilisé pour des applications portables plus amples que Graphviz, c'est plutôt surprenant. Quant à Java, en 2002, c'était un langage déjà bien installé, stable, portable et pas du tout inefficace.
Je ne lis pas comme toi : l'avis des auteurs en 2002, c'est que ni C++ ni Java n'avaient les qualités qu'_ils_ estimaient nécessaires en matière de stabilité, d'efficacité et de portabilité.
Toute digression au-delà du simple rapport de cette opinion étant explicitement hors-sujet dans ce groupe, je saute à...
OEQLC?
en quoi le langage C est-il si stable, si efficace et/ou si portable pour que cela justifie qu'en 2002 on doive implémenter dans ce langage un outil comme GraphViz et qui pourtant n'est pas un outil extrêmement complexe ?
Parce qu'à l'époque, les compilateurs C avaient environ 25-30 ans de pratique, et une définition stabilisée depuis 12 ans, donc la divergence créatrice que l'on connut dans les années 80 était passée de mode, au profit de la stabilité et de la portabilité. Et franchement, au moins jusqu'en 1998-2000, ce n'était pas les seuls à avoir cet avis.
Et en 1998, un développeur de compilateur m'expliquait à peu près la même chose, sauf que le 5e mot était Fortran, et que son objectif était d'obtenir des compilos C qui atteignaient le niveau d'exigence de ses clients, en matière justement de portabilité (sous-entendu: de code numérique existants) et d'efficacité (sous-entendu: de ressources machine). Je ne suis plus au bon endroit pour savoir si c'est encore d'actualité.
Et corrélativement, ça me parait poser la question essentielle de savoir : que _crée_-t-on aujourd'hui en 2009 et demain en langage C en dehors des programmes basés sur l'existant en C ou des contraintes matérielles (embarqué ou pas de compilateur C++) ?
C'est juste que je n'avais pas lu cette question essentielle dans le message <news:4a1dde39$0$11806$
Cela étant, la réaction citée est typique de l'attitude des directeurs de projet, qui s'ils n'ont pas d'autre contrainte, vont souvent avoir tendance à prolonger sur plusieurs années un état de fait qui s'éloigne progressivement de l'état de l'art.
Et une partie importante de la formation d'un standard (au sens le plus large) est justement d'arriver à s'imposer comme état de fait après avoir été l'état de l'art : je compare cela à la théorie de l'inflation, c'est le coup d'accélérateur ou de rein qui sépare le produit "star" du simple produit vedette_en_son_temps (ou vache-à-lait selon le BCG).
