Dans le cas de Java, évidemment : on a un langage qui s'est basé sur C. Pourquoi, par exemple, sans la contrainte de la compatilibilité, il n'a pas répensé la syntaxe des déclarations ?
Pour attirer son public.
Ca marche (malheureusement) tres bien...
In article <2e8606d7-35fe-49b0-b19d-2498c4b73052@e6g2000prf.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:
Dans le cas de Java, évidemment : on a un langage qui s'est
basé sur C. Pourquoi, par exemple, sans la contrainte de la
compatilibilité, il n'a pas répensé la syntaxe des
déclarations ?
Dans le cas de Java, évidemment : on a un langage qui s'est basé sur C. Pourquoi, par exemple, sans la contrainte de la compatilibilité, il n'a pas répensé la syntaxe des déclarations ?
Pour attirer son public.
Ca marche (malheureusement) tres bien...
Gabriel Dos Reis
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools.
| > | Une des raisons principales pour sa manque de | > | simplicité et d'élégance, c'est qu'il se base sur le C. Sans ce | > | rapport avec le C, je suis sûr qu'il serait beaucoup plus simple | > | et plus élégant (encore que les problèmes de compatibilité entre | > | le C++ d'aujourd'hui, et celui du passée, exigeraient aussi des | > | compromis). Sans ce rapport, il serait aussi beaucoup moins | > | utilisé, vraiment beaucoup. | > | > Note cependant que d'autres langages comme Java on Ada n'ont pas ce | > poids de compatibilité avec le C, mais sont quand même assez complexes | > (au moins aussi complexe que C++). | | AMA, le langage Java en lui même n'est pas très difficile à apprendre. Ce qui | prends du temps est la tonne de bibliothèques, frameworks et patterns associés | sans lesquels Java perd beaucoup de son intérêt.
Oui, mais qu'est-ce qui fait un langage ?
-- Gaby --8323584-573008096-1197383986=:12489--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
| > | Une des raisons principales pour sa manque de
| > | simplicité et d'élégance, c'est qu'il se base sur le C. Sans ce
| > | rapport avec le C, je suis sûr qu'il serait beaucoup plus simple
| > | et plus élégant (encore que les problèmes de compatibilité entre
| > | le C++ d'aujourd'hui, et celui du passée, exigeraient aussi des
| > | compromis). Sans ce rapport, il serait aussi beaucoup moins
| > | utilisé, vraiment beaucoup.
| >
| > Note cependant que d'autres langages comme Java on Ada n'ont pas ce
| > poids de compatibilité avec le C, mais sont quand même assez complexes
| > (au moins aussi complexe que C++).
|
| AMA, le langage Java en lui même n'est pas très difficile à apprendre. Ce qui
| prends du temps est la tonne de bibliothèques, frameworks et patterns associés
| sans lesquels Java perd beaucoup de son intérêt.
| > | Une des raisons principales pour sa manque de | > | simplicité et d'élégance, c'est qu'il se base sur le C. Sans ce | > | rapport avec le C, je suis sûr qu'il serait beaucoup plus simple | > | et plus élégant (encore que les problèmes de compatibilité entre | > | le C++ d'aujourd'hui, et celui du passée, exigeraient aussi des | > | compromis). Sans ce rapport, il serait aussi beaucoup moins | > | utilisé, vraiment beaucoup. | > | > Note cependant que d'autres langages comme Java on Ada n'ont pas ce | > poids de compatibilité avec le C, mais sont quand même assez complexes | > (au moins aussi complexe que C++). | | AMA, le langage Java en lui même n'est pas très difficile à apprendre. Ce qui | prends du temps est la tonne de bibliothèques, frameworks et patterns associés | sans lesquels Java perd beaucoup de son intérêt.
Oui, mais qu'est-ce qui fait un langage ?
-- Gaby --8323584-573008096-1197383986=:12489--
James Kanze
On Dec 11, 12:14 pm, (Marc Espie) wrote:
In article om>, James Kanze wrote:
Dans le cas de Java, évidemment : on a un langage qui s'est basé sur C. Pourquoi, par exemple, sans la contrainte de la compatilibilité, il n'a pas répensé la syntaxe des déclarations ?
Pour attirer son public.
Ca marche (malheureusement) tres bien...
Je sais. Je me rappelle parler avec quelqu'un chez Alcatel, peu après son apparition. (Quelqu'un qui aimait bien l'Ada, en fait.) J'ai posé cette question, et il m'a répondu : la compatibilité psychologique. Ce qui est un très bonne réponse, à mon avis.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 11, 12:14 pm, es...@lain.home (Marc Espie) wrote:
In article <2e8606d7-35fe-49b0-b19d-2498c4b73...@e6g2000prf.googlegroups.c om>,
James Kanze <james.ka...@gmail.com> wrote:
Dans le cas de Java, évidemment : on a un langage qui s'est
basé sur C. Pourquoi, par exemple, sans la contrainte de la
compatilibilité, il n'a pas répensé la syntaxe des
déclarations ?
Pour attirer son public.
Ca marche (malheureusement) tres bien...
Je sais. Je me rappelle parler avec quelqu'un chez Alcatel, peu
après son apparition. (Quelqu'un qui aimait bien l'Ada, en
fait.) J'ai posé cette question, et il m'a répondu : la
compatibilité psychologique. Ce qui est un très bonne réponse, à
mon avis.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Dans le cas de Java, évidemment : on a un langage qui s'est basé sur C. Pourquoi, par exemple, sans la contrainte de la compatilibilité, il n'a pas répensé la syntaxe des déclarations ?
Pour attirer son public.
Ca marche (malheureusement) tres bien...
Je sais. Je me rappelle parler avec quelqu'un chez Alcatel, peu après son apparition. (Quelqu'un qui aimait bien l'Ada, en fait.) J'ai posé cette question, et il m'a répondu : la compatibilité psychologique. Ce qui est un très bonne réponse, à mon avis.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Dec 11, 10:44 am, Fabien LE LEZ wrote:
On Tue, 11 Dec 2007 00:47:57 -0800 (PST), James Kanze :
Well, il y a Perl :-/
C'est vrai. Comme quoi, avec un peu d'effort, on peut donner même à C++ l'air d'être simple et élégant en comparaison.
J'ai essayé d'utiliser, dans bash, des fonctions capables de renvoyer une valeur. C'est mignon aussi.
Bash souffre, au moins en partie, du même problème que C++ : les contraintes de compatabilité avec ces prédécesseurs. Mais l'histoire de la fonction qui renvoie une valeur, c'est due à une autre cause : une fonction s'appelle exactement comme si elle était une commande système. (Et en passant, qu'est-ce que tu entends par << renvoyer une valeur >> ? Le code de retour, ou les sorties standard ? Capter ces dernières exige une syntaxe un peu bizarre, on peut le dire.)
Ce qui est beau avec bash, et les autres shells, évidemment, c'est qu'une bonne partie du programme s'exécute dans les commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut savoir à chaque instant qui va interpréter quoi.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 11, 10:44 am, Fabien LE LEZ <grams...@gramster.com> wrote:
On Tue, 11 Dec 2007 00:47:57 -0800 (PST), James Kanze
<james.ka...@gmail.com>:
Well, il y a Perl :-/
C'est vrai. Comme quoi, avec un peu d'effort, on peut donner
même à C++ l'air d'être simple et élégant en comparaison.
J'ai essayé d'utiliser, dans bash, des fonctions capables de
renvoyer une valeur. C'est mignon aussi.
Bash souffre, au moins en partie, du même problème que C++ :
les contraintes de compatabilité avec ces prédécesseurs. Mais
l'histoire de la fonction qui renvoie une valeur, c'est due à
une autre cause : une fonction s'appelle exactement comme si
elle était une commande système. (Et en passant, qu'est-ce que
tu entends par << renvoyer une valeur >> ? Le code de retour,
ou les sorties standard ? Capter ces dernières exige une
syntaxe un peu bizarre, on peut le dire.)
Ce qui est beau avec bash, et les autres shells, évidemment,
c'est qu'une bonne partie du programme s'exécute dans les
commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui
fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut
savoir à chaque instant qui va interpréter quoi.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Tue, 11 Dec 2007 00:47:57 -0800 (PST), James Kanze :
Well, il y a Perl :-/
C'est vrai. Comme quoi, avec un peu d'effort, on peut donner même à C++ l'air d'être simple et élégant en comparaison.
J'ai essayé d'utiliser, dans bash, des fonctions capables de renvoyer une valeur. C'est mignon aussi.
Bash souffre, au moins en partie, du même problème que C++ : les contraintes de compatabilité avec ces prédécesseurs. Mais l'histoire de la fonction qui renvoie une valeur, c'est due à une autre cause : une fonction s'appelle exactement comme si elle était une commande système. (Et en passant, qu'est-ce que tu entends par << renvoyer une valeur >> ? Le code de retour, ou les sorties standard ? Capter ces dernières exige une syntaxe un peu bizarre, on peut le dire.)
Ce qui est beau avec bash, et les autres shells, évidemment, c'est qu'une bonne partie du programme s'exécute dans les commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut savoir à chaque instant qui va interpréter quoi.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jean-Marc Bourguet
James Kanze writes:
Ce qui est beau avec bash, et les autres shells, évidemment, c'est qu'une bonne partie du programme s'exécute dans les commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut savoir à chaque instant qui va interpréter quoi.
Et apres, tu mets ca dans un makefile... :-)
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze <james.kanze@gmail.com> writes:
Ce qui est beau avec bash, et les autres shells, évidemment,
c'est qu'une bonne partie du programme s'exécute dans les
commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui
fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut
savoir à chaque instant qui va interpréter quoi.
Et apres, tu mets ca dans un makefile... :-)
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ce qui est beau avec bash, et les autres shells, évidemment, c'est qu'une bonne partie du programme s'exécute dans les commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut savoir à chaque instant qui va interpréter quoi.
Et apres, tu mets ca dans un makefile... :-)
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Michael DOUBEZ
On Tue, 11 Dec 2007, Michael DOUBEZ wrote:
| > | Une des raisons principales pour sa manque de | > | simplicité et d'élégance, c'est qu'il se base sur le C. Sans ce | > | rapport avec le C, je suis sûr qu'il serait beaucoup plus simple | > | et plus élégant (encore que les problèmes de compatibilité entre | > | le C++ d'aujourd'hui, et celui du passée, exigeraient aussi des | > | compromis). Sans ce rapport, il serait aussi beaucoup moins | > | utilisé, vraiment beaucoup. | > | > Note cependant que d'autres langages comme Java on Ada n'ont pas ce | > poids de compatibilité avec le C, mais sont quand même assez complexes | > (au moins aussi complexe que C++). | | AMA, le langage Java en lui même n'est pas très difficile à apprendre. Ce qui | prends du temps est la tonne de bibliothèques, frameworks et patterns associés | sans lesquels Java perd beaucoup de son intérêt.
Oui, mais qu'est-ce qui fait un langage ?
Si on se limite à la définition restrictive de "langage de programmation" comme l'ensemble des éléments syntaxiques permettant de communiquer avec une machine alors la question peut se poser de savoir si les bibliothèques font partie du langage ou non.
Dans le cas particulier d'un langage standardisé avec une librairie standard, AMA elles en font parties car elles sont spécifiées dans le standard, donc le compilateur pourrait les intégrer directement (comme la vérification de format en C pour les fonction de style printf).
Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois) où le programmeur discute avec la machine virtuelle qui discute avec la machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE, J2ME, J2BingWizzBang ...
Ici, je pense qu'on franchit la ligne de séparation langage/bibliothèque car ces modifications/spécialisations de la bibliothèque standard de la JVM répondent à une limitation du modèle Java: celui-ci ne permet pas l'accès à la machine. Donc, pour assurer le paradigme "Compile Once, run everywhere" qui a fait leur succès, ils sont obligés de fournir, une distribution standard qui garanti un certain nombre de fonctionnalités. Nous sommes ici dans une famille de produits en non plus dans le domaine du langage même si quelque part, avec Java, c'est le distributeur du produit qui definit le langage.
Michael
On Tue, 11 Dec 2007, Michael DOUBEZ wrote:
| > | Une des raisons principales pour sa manque de
| > | simplicité et d'élégance, c'est qu'il se base sur le C. Sans ce
| > | rapport avec le C, je suis sûr qu'il serait beaucoup plus simple
| > | et plus élégant (encore que les problèmes de compatibilité entre
| > | le C++ d'aujourd'hui, et celui du passée, exigeraient aussi des
| > | compromis). Sans ce rapport, il serait aussi beaucoup moins
| > | utilisé, vraiment beaucoup.
| >
| > Note cependant que d'autres langages comme Java on Ada n'ont pas ce
| > poids de compatibilité avec le C, mais sont quand même assez complexes
| > (au moins aussi complexe que C++).
|
| AMA, le langage Java en lui même n'est pas très difficile à apprendre. Ce qui
| prends du temps est la tonne de bibliothèques, frameworks et patterns associés
| sans lesquels Java perd beaucoup de son intérêt.
Oui, mais qu'est-ce qui fait un langage ?
Si on se limite à la définition restrictive de "langage de
programmation" comme l'ensemble des éléments syntaxiques permettant de
communiquer avec une machine alors la question peut se poser de savoir
si les bibliothèques font partie du langage ou non.
Dans le cas particulier d'un langage standardisé avec une librairie
standard, AMA elles en font parties car elles sont spécifiées dans le
standard, donc le compilateur pourrait les intégrer directement (comme
la vérification de format en C pour les fonction de style printf).
Maintenant en Java, il y a un standard defacto (encore géré par Sun je
crois) où le programmeur discute avec la machine virtuelle qui discute
avec la machine réelle. Cet ensemble de base pour discuter avec la JVM
est AMA assez simple à maitriser; la difficulté arrive quand on passe
aux frameworks: J2EE, J2ME, J2BingWizzBang ...
Ici, je pense qu'on franchit la ligne de séparation langage/bibliothèque
car ces modifications/spécialisations de la bibliothèque standard de la
JVM répondent à une limitation du modèle Java: celui-ci ne permet pas
l'accès à la machine. Donc, pour assurer le paradigme "Compile Once, run
everywhere" qui a fait leur succès, ils sont obligés de fournir, une
distribution standard qui garanti un certain nombre de fonctionnalités.
Nous sommes ici dans une famille de produits en non plus dans le domaine
du langage même si quelque part, avec Java, c'est le distributeur du
produit qui definit le langage.
| > | Une des raisons principales pour sa manque de | > | simplicité et d'élégance, c'est qu'il se base sur le C. Sans ce | > | rapport avec le C, je suis sûr qu'il serait beaucoup plus simple | > | et plus élégant (encore que les problèmes de compatibilité entre | > | le C++ d'aujourd'hui, et celui du passée, exigeraient aussi des | > | compromis). Sans ce rapport, il serait aussi beaucoup moins | > | utilisé, vraiment beaucoup. | > | > Note cependant que d'autres langages comme Java on Ada n'ont pas ce | > poids de compatibilité avec le C, mais sont quand même assez complexes | > (au moins aussi complexe que C++). | | AMA, le langage Java en lui même n'est pas très difficile à apprendre. Ce qui | prends du temps est la tonne de bibliothèques, frameworks et patterns associés | sans lesquels Java perd beaucoup de son intérêt.
Oui, mais qu'est-ce qui fait un langage ?
Si on se limite à la définition restrictive de "langage de programmation" comme l'ensemble des éléments syntaxiques permettant de communiquer avec une machine alors la question peut se poser de savoir si les bibliothèques font partie du langage ou non.
Dans le cas particulier d'un langage standardisé avec une librairie standard, AMA elles en font parties car elles sont spécifiées dans le standard, donc le compilateur pourrait les intégrer directement (comme la vérification de format en C pour les fonction de style printf).
Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois) où le programmeur discute avec la machine virtuelle qui discute avec la machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE, J2ME, J2BingWizzBang ...
Ici, je pense qu'on franchit la ligne de séparation langage/bibliothèque car ces modifications/spécialisations de la bibliothèque standard de la JVM répondent à une limitation du modèle Java: celui-ci ne permet pas l'accès à la machine. Donc, pour assurer le paradigme "Compile Once, run everywhere" qui a fait leur succès, ils sont obligés de fournir, une distribution standard qui garanti un certain nombre de fonctionnalités. Nous sommes ici dans une famille de produits en non plus dans le domaine du langage même si quelque part, avec Java, c'est le distributeur du produit qui definit le langage.
Michael
James Kanze
On Dec 12, 9:32 am, Jean-Marc Bourguet wrote:
James Kanze writes:
Ce qui est beau avec bash, et les autres shells, évidemment, c'est qu'une bonne partie du programme s'exécute dans les commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut savoir à chaque instant qui va interpréter quoi.
Et apres, tu mets ca dans un makefile... :-)
Il faut bien quelque chose pour rendre les choses intéressantes:-). GNU make est un langage Turing complet en lui-même. Plutôt fonctionnel d'orientation, et dynamique -- un peu comme si on avait des templates qui se résolvait lors de l'exécution. Ajoute à ça qu'il y a une bonne partie qui est déclarative, ce qui fait qu'il n'y a nulle part pour mettre des log ou des traces, et qu'il n'y a pas d'outils de deboggage, et on a du quoi s'occuper pour un moment.
En revanche, à l'encontre du shell, les fichiers source du make ne contient en général que du make. L'utilisation d'autres syntaxes se cantonne en général dans les règles de production, bien séparées dans le fichier.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Dec 12, 9:32 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
James Kanze <james.ka...@gmail.com> writes:
Ce qui est beau avec bash, et les autres shells, évidemment,
c'est qu'une bonne partie du programme s'exécute dans les
commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui
fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut
savoir à chaque instant qui va interpréter quoi.
Et apres, tu mets ca dans un makefile... :-)
Il faut bien quelque chose pour rendre les choses
intéressantes:-). GNU make est un langage Turing complet en
lui-même. Plutôt fonctionnel d'orientation, et dynamique -- un
peu comme si on avait des templates qui se résolvait lors de
l'exécution. Ajoute à ça qu'il y a une bonne partie qui est
déclarative, ce qui fait qu'il n'y a nulle part pour mettre des
log ou des traces, et qu'il n'y a pas d'outils de deboggage, et
on a du quoi s'occuper pour un moment.
En revanche, à l'encontre du shell, les fichiers source du make
ne contient en général que du make. L'utilisation d'autres
syntaxes se cantonne en général dans les règles de production,
bien séparées dans le fichier.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ce qui est beau avec bash, et les autres shells, évidemment, c'est qu'une bonne partie du programme s'exécute dans les commandes qu'il invoque. Chacune avec sa propre syntaxe. Ce qui fait qu'il y a des syntaxes dans la syntaxe, et qu'il faut savoir à chaque instant qui va interpréter quoi.
Et apres, tu mets ca dans un makefile... :-)
Il faut bien quelque chose pour rendre les choses intéressantes:-). GNU make est un langage Turing complet en lui-même. Plutôt fonctionnel d'orientation, et dynamique -- un peu comme si on avait des templates qui se résolvait lors de l'exécution. Ajoute à ça qu'il y a une bonne partie qui est déclarative, ce qui fait qu'il n'y a nulle part pour mettre des log ou des traces, et qu'il n'y a pas d'outils de deboggage, et on a du quoi s'occuper pour un moment.
En revanche, à l'encontre du shell, les fichiers source du make ne contient en général que du make. L'utilisation d'autres syntaxes se cantonne en général dans les règles de production, bien séparées dans le fichier.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Gabriel Dos Reis
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools.
| Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois) | où le programmeur discute avec la machine virtuelle qui discute avec la | machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez | simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE, | J2ME, J2BingWizzBang ...
Il n'est pas clair que la bibliothèque ne fait pas partie du language. Considère les classes comme String avec ses operateurs surchargés qu'on ne peut pas écrire dans le langage lui même.
-- Gaby --8323584-1198403625-1197553713=:12284--
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
| Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois)
| où le programmeur discute avec la machine virtuelle qui discute avec la
| machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez
| simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE,
| J2ME, J2BingWizzBang ...
Il n'est pas clair que la bibliothèque ne fait pas partie du language.
Considère les classes comme String avec ses operateurs surchargés
qu'on ne peut pas écrire dans le langage lui même.
| Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois) | où le programmeur discute avec la machine virtuelle qui discute avec la | machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez | simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE, | J2ME, J2BingWizzBang ...
Il n'est pas clair que la bibliothèque ne fait pas partie du language. Considère les classes comme String avec ses operateurs surchargés qu'on ne peut pas écrire dans le langage lui même.
-- Gaby --8323584-1198403625-1197553713=:12284--
Michael DOUBEZ
On Wed, 12 Dec 2007, Michael DOUBEZ wrote:
| Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois) | où le programmeur discute avec la machine virtuelle qui discute avec la | machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez | simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE, | J2ME, J2BingWizzBang ...
Il n'est pas clair que la bibliothèque ne fait pas partie du language. Considère les classes comme String avec ses operateurs surchargés qu'on ne peut pas écrire dans le langage lui même.
Je suis d'accord mais AMA il y a des choses intégrés à la VM qui relèvent du cas d'utilisation.
Avec Java, on pourrait dire que tout fait parti du langage puisque tout est livré par ligne de produit et qui plus est intégré à la VM (tout ou presque, je ne sait pas). Donc, soit on dit qu'il y a plusieurs langages Java: le java J2SE, le java J2EE ... qui dependent de la VM sur laquelle ils tournent. Ou alors dresser une ligne en disant que J2SE (la VM de base) définit le langage (le coeur du langage) et que les autres produits sont des déclinaisons.
Je pourrait aussi wrapper du code C++ en Java et le distribuer pour les diférentes plateformes supportées par la VM et le livrer avec les distributions de Sun. Pour moi, ça reste une bibliothèque et c'est ainsi que je considère les différentes sortes de J2Machin.
L'argument est faible, je le voit: tant qu'il n'y aura qu'un seul décideur de ce qu'est Java, tous ce qu'il intègre dans le produit pourrait être considéré comme faisant parti du langage.
Michael
On Wed, 12 Dec 2007, Michael DOUBEZ wrote:
| Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois)
| où le programmeur discute avec la machine virtuelle qui discute avec la
| machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez
| simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE,
| J2ME, J2BingWizzBang ...
Il n'est pas clair que la bibliothèque ne fait pas partie du language.
Considère les classes comme String avec ses operateurs surchargés
qu'on ne peut pas écrire dans le langage lui même.
Je suis d'accord mais AMA il y a des choses intégrés à la VM qui
relèvent du cas d'utilisation.
Avec Java, on pourrait dire que tout fait parti du langage puisque tout
est livré par ligne de produit et qui plus est intégré à la VM (tout
ou presque, je ne sait pas).
Donc, soit on dit qu'il y a plusieurs langages Java: le java J2SE, le
java J2EE ... qui dependent de la VM sur laquelle ils tournent. Ou alors
dresser une ligne en disant que J2SE (la VM de base) définit le langage
(le coeur du langage) et que les autres produits sont des déclinaisons.
Je pourrait aussi wrapper du code C++ en Java et le distribuer pour les
diférentes plateformes supportées par la VM et le livrer avec les
distributions de Sun. Pour moi, ça reste une bibliothèque et c'est ainsi
que je considère les différentes sortes de J2Machin.
L'argument est faible, je le voit: tant qu'il n'y aura qu'un seul
décideur de ce qu'est Java, tous ce qu'il intègre dans le produit
pourrait être considéré comme faisant parti du langage.
| Maintenant en Java, il y a un standard defacto (encore géré par Sun je crois) | où le programmeur discute avec la machine virtuelle qui discute avec la | machine réelle. Cet ensemble de base pour discuter avec la JVM est AMA assez | simple à maitriser; la difficulté arrive quand on passe aux frameworks: J2EE, | J2ME, J2BingWizzBang ...
Il n'est pas clair que la bibliothèque ne fait pas partie du language. Considère les classes comme String avec ses operateurs surchargés qu'on ne peut pas écrire dans le langage lui même.
Je suis d'accord mais AMA il y a des choses intégrés à la VM qui relèvent du cas d'utilisation.
Avec Java, on pourrait dire que tout fait parti du langage puisque tout est livré par ligne de produit et qui plus est intégré à la VM (tout ou presque, je ne sait pas). Donc, soit on dit qu'il y a plusieurs langages Java: le java J2SE, le java J2EE ... qui dependent de la VM sur laquelle ils tournent. Ou alors dresser une ligne en disant que J2SE (la VM de base) définit le langage (le coeur du langage) et que les autres produits sont des déclinaisons.
Je pourrait aussi wrapper du code C++ en Java et le distribuer pour les diférentes plateformes supportées par la VM et le livrer avec les distributions de Sun. Pour moi, ça reste une bibliothèque et c'est ainsi que je considère les différentes sortes de J2Machin.
L'argument est faible, je le voit: tant qu'il n'y aura qu'un seul décideur de ce qu'est Java, tous ce qu'il intègre dans le produit pourrait être considéré comme faisant parti du langage.
Michael
Sylvain
Michael DOUBEZ wrote on 13/12/2007 22:04:
L'argument est faible, je le voi[s]: tant qu'il n'y aura qu'un seul décideur de ce qu'est Java, tou[t] ce qu'il intègre dans le produit pourrait être considéré comme faisant parti du langage.
les lieux de définition de Java (au sens le + large) ne sont peut être pas l'image parfaite d'un comité de proposition pour le C ou C++, soit. penser pour autant qu'il n'existerait qu'un seul décideur (moral, je ne saurais lire physique) est une erreur.
les "APIs standards et obligeatoires" (dont l'ensemble définit un subset du langage: ME, SE ou EE) sont normalisées par Sun mais leurs origines sont multiples.
le fait qu'une classe propose des opérateurs - impossibles à définir soi-même - ou non, n'est pas imho un fait d'appartenance au langage. "langage Java", pas plus que "langage C++" ne se réduit à sa seule syntaxe, un environnement Java (ME, SE ou EE) est donc nécessairement constitué de tous les packages (toutes les librairies) obligeatoires pour cet environnement - comme un environnement C++ 'conforme' sera constitué de l'ensemble de sa librairie standard.
Sylvain.
Michael DOUBEZ wrote on 13/12/2007 22:04:
L'argument est faible, je le voi[s]: tant qu'il n'y aura qu'un seul
décideur de ce qu'est Java, tou[t] ce qu'il intègre dans le produit
pourrait être considéré comme faisant parti du langage.
les lieux de définition de Java (au sens le + large) ne sont peut être
pas l'image parfaite d'un comité de proposition pour le C ou C++, soit.
penser pour autant qu'il n'existerait qu'un seul décideur (moral, je ne
saurais lire physique) est une erreur.
les "APIs standards et obligeatoires" (dont l'ensemble définit un subset
du langage: ME, SE ou EE) sont normalisées par Sun mais leurs origines
sont multiples.
le fait qu'une classe propose des opérateurs - impossibles à définir
soi-même - ou non, n'est pas imho un fait d'appartenance au langage.
"langage Java", pas plus que "langage C++" ne se réduit à sa seule
syntaxe, un environnement Java (ME, SE ou EE) est donc nécessairement
constitué de tous les packages (toutes les librairies) obligeatoires
pour cet environnement - comme un environnement C++ 'conforme' sera
constitué de l'ensemble de sa librairie standard.
L'argument est faible, je le voi[s]: tant qu'il n'y aura qu'un seul décideur de ce qu'est Java, tou[t] ce qu'il intègre dans le produit pourrait être considéré comme faisant parti du langage.
les lieux de définition de Java (au sens le + large) ne sont peut être pas l'image parfaite d'un comité de proposition pour le C ou C++, soit. penser pour autant qu'il n'existerait qu'un seul décideur (moral, je ne saurais lire physique) est une erreur.
les "APIs standards et obligeatoires" (dont l'ensemble définit un subset du langage: ME, SE ou EE) sont normalisées par Sun mais leurs origines sont multiples.
le fait qu'une classe propose des opérateurs - impossibles à définir soi-même - ou non, n'est pas imho un fait d'appartenance au langage. "langage Java", pas plus que "langage C++" ne se réduit à sa seule syntaxe, un environnement Java (ME, SE ou EE) est donc nécessairement constitué de tous les packages (toutes les librairies) obligeatoires pour cet environnement - comme un environnement C++ 'conforme' sera constitué de l'ensemble de sa librairie standard.
