wrote:Marc Boyer wrote in message
news:<bttrqg$iea$...Non, pas si minimaliste que ca: l'histoire de l'informatique est
pleine de normes qui gereaient tout et n'ont jamais ete
implementees et sont tombees dans les oubliettes apres une survie
de niche: CORBA, ATM, la pile OSI...
Quelle survie de niche : CORBA est encore très vivante, et
pratiquement la seule solution possible si tu ne veux pas te lier à
un seul fournisseur.
Il faudrait bien sur sortir des chiffres, mais mon impression est
que CORBA a une diffusion bien en dessous de ses ambitions initiales,
et qu'il reste un marché de niche alors qu'il avait des ambitions
d'universalité. Je ne dis pas qu'il est inutile, ni mal fait.
La pile OSI sert aussi pas mal dans les applications de la
téléphonie.
La téléphonie des années 70-80 ;-)
Je me suis fait présenté l'architecture GPRS,
on est très loin d'OSI.
En ce qui concerne la normalisation d'une interface graphique : le
fait qu'il y a des systèmes sans écran n'est pas un argument. D'une
part, il y a d'autres fonctions qui ne sont pas implémentables par
tout (time, par exemple), et de l'autre, la plupart des systèmes
sans écran sont des systèmes embarqués, avec des implémentations «
free standing ».
Jean-Marc a donné les vrais arguments contre la normalisation.
Tu n'aimes pas mes arguments, Gaby semble ne pas aimer
ceux de Jean-Marc.
kanze@gabi-soft.fr wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<bttrqg$iea$1@news.cict.fr>...
Non, pas si minimaliste que ca: l'histoire de l'informatique est
pleine de normes qui gereaient tout et n'ont jamais ete
implementees et sont tombees dans les oubliettes apres une survie
de niche: CORBA, ATM, la pile OSI...
Quelle survie de niche : CORBA est encore très vivante, et
pratiquement la seule solution possible si tu ne veux pas te lier à
un seul fournisseur.
Il faudrait bien sur sortir des chiffres, mais mon impression est
que CORBA a une diffusion bien en dessous de ses ambitions initiales,
et qu'il reste un marché de niche alors qu'il avait des ambitions
d'universalité. Je ne dis pas qu'il est inutile, ni mal fait.
La pile OSI sert aussi pas mal dans les applications de la
téléphonie.
La téléphonie des années 70-80 ;-)
Je me suis fait présenté l'architecture GPRS,
on est très loin d'OSI.
En ce qui concerne la normalisation d'une interface graphique : le
fait qu'il y a des systèmes sans écran n'est pas un argument. D'une
part, il y a d'autres fonctions qui ne sont pas implémentables par
tout (time, par exemple), et de l'autre, la plupart des systèmes
sans écran sont des systèmes embarqués, avec des implémentations «
free standing ».
Jean-Marc a donné les vrais arguments contre la normalisation.
Tu n'aimes pas mes arguments, Gaby semble ne pas aimer
ceux de Jean-Marc.
wrote:Marc Boyer wrote in message
news:<bttrqg$iea$...Non, pas si minimaliste que ca: l'histoire de l'informatique est
pleine de normes qui gereaient tout et n'ont jamais ete
implementees et sont tombees dans les oubliettes apres une survie
de niche: CORBA, ATM, la pile OSI...
Quelle survie de niche : CORBA est encore très vivante, et
pratiquement la seule solution possible si tu ne veux pas te lier à
un seul fournisseur.
Il faudrait bien sur sortir des chiffres, mais mon impression est
que CORBA a une diffusion bien en dessous de ses ambitions initiales,
et qu'il reste un marché de niche alors qu'il avait des ambitions
d'universalité. Je ne dis pas qu'il est inutile, ni mal fait.
La pile OSI sert aussi pas mal dans les applications de la
téléphonie.
La téléphonie des années 70-80 ;-)
Je me suis fait présenté l'architecture GPRS,
on est très loin d'OSI.
En ce qui concerne la normalisation d'une interface graphique : le
fait qu'il y a des systèmes sans écran n'est pas un argument. D'une
part, il y a d'autres fonctions qui ne sont pas implémentables par
tout (time, par exemple), et de l'autre, la plupart des systèmes
sans écran sont des systèmes embarqués, avec des implémentations «
free standing ».
Jean-Marc a donné les vrais arguments contre la normalisation.
Tu n'aimes pas mes arguments, Gaby semble ne pas aimer
ceux de Jean-Marc.
Marc Boyer wrote in message
news:<bu0bbc$6ug$...Il faudrait bien sur sortir des chiffres, mais mon impression est
que CORBA a une diffusion bien en dessous de ses ambitions initiales,
et qu'il reste un marché de niche alors qu'il avait des ambitions
d'universalité. Je ne dis pas qu'il est inutile, ni mal fait.
Je ne sais pas exactement ce qui étaient ses ambitions au départ. C'est
vrai que dernièrement, on entend plutôt parler de XML (à tort, à mon
avis), mais je peux t'assurer que Corba est encore bien vivant aussi.
Je suppose tout dépend de ce que tu appelles un niche et des oubliettes.
La pile OSI sert aussi pas mal dans les applications de la
téléphonie.
La téléphonie des années 70-80 ;-)
Il servait encore dans la plupart des applications téléphoniques
jusqu'au milieu des années 90, au moins.
Je me suis fait présenté l'architecture GPRS,
on est très loin d'OSI.
Dans la pratique, aujourd'hui, la plupart des applications font un
mélange de OSI et de divers protocoles Internet.
La RNIS se base sur
OSI, et la dernière fois que j'ai régardé (1997), les protocols OSI
jouait encore un rôle important dans la gestion de reseau.
Il ne faut pas oublier non plus que des parties de OSI ont été adoptées
par l'Internet. Donc, SNMP et LDAP se base tous les deux sur ASN.1 (la
couche présentation de OSI). À la long, je parlerais pas tellement de la
disparition d'une ou de l'autre suite, mais d'une fusion : l'Internet
adopte des parties de OSI, tandis que beaucoup de systèmes OSI
incorporent des protocols Internet en plus. C'est assez fréquent, par
exemple, de voir des protocols des trois couches supérieurs de OSI
tourner sur une pile TCP/IP. Ou que deux machines utilise LAP-D (un
protocol de la couche deux de ISO) pour transporter des trames IP.
Jean-Marc a donné les vrais arguments contre la normalisation.
Tu n'aimes pas mes arguments, Gaby semble ne pas aimer
ceux de Jean-Marc.
Je ne sais pas si c'est tellement qu'il ne les aime pas. J'avais plutôt
l'impression qu'il les reconnaissait, et qu'il les adressait.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> wrote in message
news:<bu0bbc$6ug$3@news.cict.fr>...
Il faudrait bien sur sortir des chiffres, mais mon impression est
que CORBA a une diffusion bien en dessous de ses ambitions initiales,
et qu'il reste un marché de niche alors qu'il avait des ambitions
d'universalité. Je ne dis pas qu'il est inutile, ni mal fait.
Je ne sais pas exactement ce qui étaient ses ambitions au départ. C'est
vrai que dernièrement, on entend plutôt parler de XML (à tort, à mon
avis), mais je peux t'assurer que Corba est encore bien vivant aussi.
Je suppose tout dépend de ce que tu appelles un niche et des oubliettes.
La pile OSI sert aussi pas mal dans les applications de la
téléphonie.
La téléphonie des années 70-80 ;-)
Il servait encore dans la plupart des applications téléphoniques
jusqu'au milieu des années 90, au moins.
Je me suis fait présenté l'architecture GPRS,
on est très loin d'OSI.
Dans la pratique, aujourd'hui, la plupart des applications font un
mélange de OSI et de divers protocoles Internet.
La RNIS se base sur
OSI, et la dernière fois que j'ai régardé (1997), les protocols OSI
jouait encore un rôle important dans la gestion de reseau.
Il ne faut pas oublier non plus que des parties de OSI ont été adoptées
par l'Internet. Donc, SNMP et LDAP se base tous les deux sur ASN.1 (la
couche présentation de OSI). À la long, je parlerais pas tellement de la
disparition d'une ou de l'autre suite, mais d'une fusion : l'Internet
adopte des parties de OSI, tandis que beaucoup de systèmes OSI
incorporent des protocols Internet en plus. C'est assez fréquent, par
exemple, de voir des protocols des trois couches supérieurs de OSI
tourner sur une pile TCP/IP. Ou que deux machines utilise LAP-D (un
protocol de la couche deux de ISO) pour transporter des trames IP.
Jean-Marc a donné les vrais arguments contre la normalisation.
Tu n'aimes pas mes arguments, Gaby semble ne pas aimer
ceux de Jean-Marc.
Je ne sais pas si c'est tellement qu'il ne les aime pas. J'avais plutôt
l'impression qu'il les reconnaissait, et qu'il les adressait.
Marc Boyer wrote in message
news:<bu0bbc$6ug$...Il faudrait bien sur sortir des chiffres, mais mon impression est
que CORBA a une diffusion bien en dessous de ses ambitions initiales,
et qu'il reste un marché de niche alors qu'il avait des ambitions
d'universalité. Je ne dis pas qu'il est inutile, ni mal fait.
Je ne sais pas exactement ce qui étaient ses ambitions au départ. C'est
vrai que dernièrement, on entend plutôt parler de XML (à tort, à mon
avis), mais je peux t'assurer que Corba est encore bien vivant aussi.
Je suppose tout dépend de ce que tu appelles un niche et des oubliettes.
La pile OSI sert aussi pas mal dans les applications de la
téléphonie.
La téléphonie des années 70-80 ;-)
Il servait encore dans la plupart des applications téléphoniques
jusqu'au milieu des années 90, au moins.
Je me suis fait présenté l'architecture GPRS,
on est très loin d'OSI.
Dans la pratique, aujourd'hui, la plupart des applications font un
mélange de OSI et de divers protocoles Internet.
La RNIS se base sur
OSI, et la dernière fois que j'ai régardé (1997), les protocols OSI
jouait encore un rôle important dans la gestion de reseau.
Il ne faut pas oublier non plus que des parties de OSI ont été adoptées
par l'Internet. Donc, SNMP et LDAP se base tous les deux sur ASN.1 (la
couche présentation de OSI). À la long, je parlerais pas tellement de la
disparition d'une ou de l'autre suite, mais d'une fusion : l'Internet
adopte des parties de OSI, tandis que beaucoup de systèmes OSI
incorporent des protocols Internet en plus. C'est assez fréquent, par
exemple, de voir des protocols des trois couches supérieurs de OSI
tourner sur une pile TCP/IP. Ou que deux machines utilise LAP-D (un
protocol de la couche deux de ISO) pour transporter des trames IP.
Jean-Marc a donné les vrais arguments contre la normalisation.
Tu n'aimes pas mes arguments, Gaby semble ne pas aimer
ceux de Jean-Marc.
Je ne sais pas si c'est tellement qu'il ne les aime pas. J'avais plutôt
l'impression qu'il les reconnaissait, et qu'il les adressait.
Marc Boyer writes:
En ce qui me concerne, ce n'est pas une question d'aimer ou ne pas
aimer. Je trouve simplement que ces arguments peuvent être avancés,
pour la plus part d'entre eux, contre des composants de la
bibliothèque standard. Donc, je ne les trouve pas des « vrais »
arguments.
En fait, je ne sais pas s'il faut trouver des arguments contre la
standardisation d'une GUI en C++.
Le problème de C++, ce n'est pas qu'il n'a pas de GUI, c'est qu'il y
en a tellement.
Au fond, cela me rappelle la situation où tout le monde faisait sa
classe String...
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
En ce qui me concerne, ce n'est pas une question d'aimer ou ne pas
aimer. Je trouve simplement que ces arguments peuvent être avancés,
pour la plus part d'entre eux, contre des composants de la
bibliothèque standard. Donc, je ne les trouve pas des « vrais »
arguments.
En fait, je ne sais pas s'il faut trouver des arguments contre la
standardisation d'une GUI en C++.
Le problème de C++, ce n'est pas qu'il n'a pas de GUI, c'est qu'il y
en a tellement.
Au fond, cela me rappelle la situation où tout le monde faisait sa
classe String...
Marc Boyer writes:
En ce qui me concerne, ce n'est pas une question d'aimer ou ne pas
aimer. Je trouve simplement que ces arguments peuvent être avancés,
pour la plus part d'entre eux, contre des composants de la
bibliothèque standard. Donc, je ne les trouve pas des « vrais »
arguments.
En fait, je ne sais pas s'il faut trouver des arguments contre la
standardisation d'une GUI en C++.
Le problème de C++, ce n'est pas qu'il n'a pas de GUI, c'est qu'il y
en a tellement.
Au fond, cela me rappelle la situation où tout le monde faisait sa
classe String...
Marc Boyer writes:
| Gabriel Dos Reis wrote:
| Quand j'évoque la difficulté d'avoir une "X" portable et à
| l'interface clairement définie, je pense qu'on a des réponses
| différentes pour X == vector et X == GUI.
vector est portable parce qu'il fait partie de la norme et que
les implémentations le fournissent. À partir du moment où on met un
GUI dans la norme et que les implémentations le fournissent, il devient
portable.
| > En fait, je ne sais pas s'il faut trouver des arguments contre la
| > standardisation d'une GUI en C++.
|
| Quand on évoque un projet, on cherche et évalue les
| arguments pour et contre, non ? On part pas tête
| baissée en ayant évalué que les avantages, si ?
Tu cherches des arguments contre quoi exactement ?
Il y a au moins deux choses que tu sembles confondre : le souhait
d'avoir un GUI dans la norme et une spécification d'un tel GUI.
Tu argues pour/contre quoi exactement ?
| Cf. ci dessus.
| Une classe String efficace, portable et internationalisable,
| est-ce du même niveau de difficulté de spécification et
| d'implémentation qu'une GUI efficace, portable et
| internationalisable ?
Tu n'as qu'à essayer, tu verras.
| Si la réponse est "oui", alors,
| c'est un effort qui a déjà été fourni dans le passé, et
| qu'on peut donc imaginer réalisable. Je subodore que
| la réponse soit "non", mais on pourra toujours me
| faire remarquer mon inexpérience en développement
| de String et de GUI.
En fait, que la réponse soit « oui » ou « non » est sans aucune espèce
d'importance.
Si le comité a une proposition concrète sur la table, je crois qu'il
l'examinera indépendamment de ce que ce soit plus facile ou plus
difficile qu'une class string internationalisable.
Been there, done that.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Gabriel Dos Reis wrote:
| Quand j'évoque la difficulté d'avoir une "X" portable et à
| l'interface clairement définie, je pense qu'on a des réponses
| différentes pour X == vector et X == GUI.
vector est portable parce qu'il fait partie de la norme et que
les implémentations le fournissent. À partir du moment où on met un
GUI dans la norme et que les implémentations le fournissent, il devient
portable.
| > En fait, je ne sais pas s'il faut trouver des arguments contre la
| > standardisation d'une GUI en C++.
|
| Quand on évoque un projet, on cherche et évalue les
| arguments pour et contre, non ? On part pas tête
| baissée en ayant évalué que les avantages, si ?
Tu cherches des arguments contre quoi exactement ?
Il y a au moins deux choses que tu sembles confondre : le souhait
d'avoir un GUI dans la norme et une spécification d'un tel GUI.
Tu argues pour/contre quoi exactement ?
| Cf. ci dessus.
| Une classe String efficace, portable et internationalisable,
| est-ce du même niveau de difficulté de spécification et
| d'implémentation qu'une GUI efficace, portable et
| internationalisable ?
Tu n'as qu'à essayer, tu verras.
| Si la réponse est "oui", alors,
| c'est un effort qui a déjà été fourni dans le passé, et
| qu'on peut donc imaginer réalisable. Je subodore que
| la réponse soit "non", mais on pourra toujours me
| faire remarquer mon inexpérience en développement
| de String et de GUI.
En fait, que la réponse soit « oui » ou « non » est sans aucune espèce
d'importance.
Si le comité a une proposition concrète sur la table, je crois qu'il
l'examinera indépendamment de ce que ce soit plus facile ou plus
difficile qu'une class string internationalisable.
Been there, done that.
Marc Boyer writes:
| Gabriel Dos Reis wrote:
| Quand j'évoque la difficulté d'avoir une "X" portable et à
| l'interface clairement définie, je pense qu'on a des réponses
| différentes pour X == vector et X == GUI.
vector est portable parce qu'il fait partie de la norme et que
les implémentations le fournissent. À partir du moment où on met un
GUI dans la norme et que les implémentations le fournissent, il devient
portable.
| > En fait, je ne sais pas s'il faut trouver des arguments contre la
| > standardisation d'une GUI en C++.
|
| Quand on évoque un projet, on cherche et évalue les
| arguments pour et contre, non ? On part pas tête
| baissée en ayant évalué que les avantages, si ?
Tu cherches des arguments contre quoi exactement ?
Il y a au moins deux choses que tu sembles confondre : le souhait
d'avoir un GUI dans la norme et une spécification d'un tel GUI.
Tu argues pour/contre quoi exactement ?
| Cf. ci dessus.
| Une classe String efficace, portable et internationalisable,
| est-ce du même niveau de difficulté de spécification et
| d'implémentation qu'une GUI efficace, portable et
| internationalisable ?
Tu n'as qu'à essayer, tu verras.
| Si la réponse est "oui", alors,
| c'est un effort qui a déjà été fourni dans le passé, et
| qu'on peut donc imaginer réalisable. Je subodore que
| la réponse soit "non", mais on pourra toujours me
| faire remarquer mon inexpérience en développement
| de String et de GUI.
En fait, que la réponse soit « oui » ou « non » est sans aucune espèce
d'importance.
Si le comité a une proposition concrète sur la table, je crois qu'il
l'examinera indépendamment de ce que ce soit plus facile ou plus
difficile qu'une class string internationalisable.
Been there, done that.
La "mort" de ceux qui s'obstinent à choisir des langages ou des outils
peu adaptés à leurs besoins me paraît plus probable que celle du C++ :)
Par ailleurs le C++ évolue.
pas dans tous les domaines car il y a encore quelques blocages
Mais l'objectif de C++ n'est pas de se contenter d'équivalents de
char*. C'est au C qu'il faudrait demander ça.
et pourquoi donc ?
je ne savais pas que l'objectif du c++ etait de ne pas se contenter de
char, mais de se contenter d'un acces tres basique aux interfaces
je ne savais meme pas qu'il avait un objectif fige completement
Le type string est le type chaîne de C++,
marrant de dire cela
il y avait le string au debut du cpp? non ?
il est apparu parceque certaines personnes ne se sont pas bloquees en
disant que le cpp n'etait pas dedie a ca ou ca
peu importe comment il est
réalisé.
idem pour les gui !
La "mort" de ceux qui s'obstinent à choisir des langages ou des outils
peu adaptés à leurs besoins me paraît plus probable que celle du C++ :)
Par ailleurs le C++ évolue.
pas dans tous les domaines car il y a encore quelques blocages
Mais l'objectif de C++ n'est pas de se contenter d'équivalents de
char*. C'est au C qu'il faudrait demander ça.
et pourquoi donc ?
je ne savais pas que l'objectif du c++ etait de ne pas se contenter de
char, mais de se contenter d'un acces tres basique aux interfaces
je ne savais meme pas qu'il avait un objectif fige completement
Le type string est le type chaîne de C++,
marrant de dire cela
il y avait le string au debut du cpp? non ?
il est apparu parceque certaines personnes ne se sont pas bloquees en
disant que le cpp n'etait pas dedie a ca ou ca
peu importe comment il est
réalisé.
idem pour les gui !
La "mort" de ceux qui s'obstinent à choisir des langages ou des outils
peu adaptés à leurs besoins me paraît plus probable que celle du C++ :)
Par ailleurs le C++ évolue.
pas dans tous les domaines car il y a encore quelques blocages
Mais l'objectif de C++ n'est pas de se contenter d'équivalents de
char*. C'est au C qu'il faudrait demander ça.
et pourquoi donc ?
je ne savais pas que l'objectif du c++ etait de ne pas se contenter de
char, mais de se contenter d'un acces tres basique aux interfaces
je ne savais meme pas qu'il avait un objectif fige completement
Le type string est le type chaîne de C++,
marrant de dire cela
il y avait le string au debut du cpp? non ?
il est apparu parceque certaines personnes ne se sont pas bloquees en
disant que le cpp n'etait pas dedie a ca ou ca
peu importe comment il est
réalisé.
idem pour les gui !
Si C++ n'est pas adpate a un projet, est-ce le probleme de C++
ou du chef de projet ?
des deux
si les chefs de projets decident la meme chose, c'est que le marche les
dirige vers cette solution (d'ailleurs, ce ne sont que rarement les
chefs de projets mais plutot les financiers)
ensuite le but du cpp n'a jamais ete d'etre complet ! normal ... mais de
resoudre des problemes vitaux, si
Il y a peut-etre un manque d'outillage a ce niveau. Mais pourquoi
pas VC++ et les MFC au fait ?
windows / linux
et windows / norme
les entreprises se mettent pas mal a gcc pour son prix :-)
et les mfc sont trop specifiques a windows
mais j'ai trouve en partie ce que je cherchjais pour moi en tant
qu'outil de base
mais cela ne convient pas toujours aux boites que je vois ...
Mais C++ lui meme n'est il pas "trop lourd pour de la base" ?
amha (donc qui n'engage que moi), non :-)
mais bon, le c (et le cpp) sont des langages que j'aime a defaut de
maitriser, donc cela fausse mon jugement
le probleme est la possibilite du choix... les choix ne sont pas
toujours bases sur le langage lui meme mais sur le cout d'un programmeur
connaissant le langage ...
Si C++ n'est pas adpate a un projet, est-ce le probleme de C++
ou du chef de projet ?
des deux
si les chefs de projets decident la meme chose, c'est que le marche les
dirige vers cette solution (d'ailleurs, ce ne sont que rarement les
chefs de projets mais plutot les financiers)
ensuite le but du cpp n'a jamais ete d'etre complet ! normal ... mais de
resoudre des problemes vitaux, si
Il y a peut-etre un manque d'outillage a ce niveau. Mais pourquoi
pas VC++ et les MFC au fait ?
windows / linux
et windows / norme
les entreprises se mettent pas mal a gcc pour son prix :-)
et les mfc sont trop specifiques a windows
mais j'ai trouve en partie ce que je cherchjais pour moi en tant
qu'outil de base
mais cela ne convient pas toujours aux boites que je vois ...
Mais C++ lui meme n'est il pas "trop lourd pour de la base" ?
amha (donc qui n'engage que moi), non :-)
mais bon, le c (et le cpp) sont des langages que j'aime a defaut de
maitriser, donc cela fausse mon jugement
le probleme est la possibilite du choix... les choix ne sont pas
toujours bases sur le langage lui meme mais sur le cout d'un programmeur
connaissant le langage ...
Si C++ n'est pas adpate a un projet, est-ce le probleme de C++
ou du chef de projet ?
des deux
si les chefs de projets decident la meme chose, c'est que le marche les
dirige vers cette solution (d'ailleurs, ce ne sont que rarement les
chefs de projets mais plutot les financiers)
ensuite le but du cpp n'a jamais ete d'etre complet ! normal ... mais de
resoudre des problemes vitaux, si
Il y a peut-etre un manque d'outillage a ce niveau. Mais pourquoi
pas VC++ et les MFC au fait ?
windows / linux
et windows / norme
les entreprises se mettent pas mal a gcc pour son prix :-)
et les mfc sont trop specifiques a windows
mais j'ai trouve en partie ce que je cherchjais pour moi en tant
qu'outil de base
mais cela ne convient pas toujours aux boites que je vois ...
Mais C++ lui meme n'est il pas "trop lourd pour de la base" ?
amha (donc qui n'engage que moi), non :-)
mais bon, le c (et le cpp) sont des langages que j'aime a defaut de
maitriser, donc cela fausse mon jugement
le probleme est la possibilite du choix... les choix ne sont pas
toujours bases sur le langage lui meme mais sur le cout d'un programmeur
connaissant le langage ...
