C'est des coups a ne plus developper qu'en smalltalk ca, d'autant
qu'on peut maintenant trouver une jolie implementation sur les 3 BSD:
squeak(pub)
C'est des coups a ne plus developper qu'en smalltalk ca, d'autant
qu'on peut maintenant trouver une jolie implementation sur les 3 BSD:
squeak(pub)
C'est des coups a ne plus developper qu'en smalltalk ca, d'autant
qu'on peut maintenant trouver une jolie implementation sur les 3 BSD:
squeak(pub)
Un peu d'objet en ocaml, c'est pas mal non plus (si tu tiens tant que ca
a l'objet). Mais (je snip toutes les explications), perso, je prefere le
fonctionnel type, et je trouve les modules/functors bien plus simple a
utiliser.
Un peu d'objet en ocaml, c'est pas mal non plus (si tu tiens tant que ca
a l'objet). Mais (je snip toutes les explications), perso, je prefere le
fonctionnel type, et je trouve les modules/functors bien plus simple a
utiliser.
Un peu d'objet en ocaml, c'est pas mal non plus (si tu tiens tant que ca
a l'objet). Mais (je snip toutes les explications), perso, je prefere le
fonctionnel type, et je trouve les modules/functors bien plus simple a
utiliser.
Pas tous. CC m'a fait remarque l'autre jour que la totalite des fils dans
lesquels tu intervenais derivaient tot ou tard vers la consommation de
boissonsethyliques ou de choses bonnes a manger.
Et donc, dans ce cas, le thread est déclaré terminé, et on gagne un
«point CC», pas vrai ?
Pas tous. CC m'a fait remarque l'autre jour que la totalite des fils dans
lesquels tu intervenais derivaient tot ou tard vers la consommation de
boissons
ethyliques ou de choses bonnes a manger.
Et donc, dans ce cas, le thread est déclaré terminé, et on gagne un
«point CC», pas vrai ?
Pas tous. CC m'a fait remarque l'autre jour que la totalite des fils dans
lesquels tu intervenais derivaient tot ou tard vers la consommation de
boissonsethyliques ou de choses bonnes a manger.
Et donc, dans ce cas, le thread est déclaré terminé, et on gagne un
«point CC», pas vrai ?
Il y a fort a parier que, tot ou tard, on aura des implementations
java plus efficaces que celles du C++.
- evolution rapide, avec une enorme bibliotheque derriere, qui conduit
bien souvent en production a avoir une jvm par appli, ou presque. (et
comme c'est du proprietaire dont on a souvent pas les sources, tout
recompiler ne marche pas trop).
- implementation libre (FSF, par exemple) a la traine (bon d'accord, le
C++ n'est pas tres au point non plus). Plus cafouilleuse qu'Ada, c'est dire!
- quelques defauts du langage lui-meme: qui a du mal a gerer la genericite
de facon esthetiquement plaisante (peu grave);
qui a supprime les types non signes pour simplifier la vie du
programmeur, ce qui oblige a des atrocites pour manipuler de betes
adresses IPv4;
qui n'a comme concept de `ressource' integree au langage que la
memoire, ce qui est pour moi la pire des conneries de java. Les gens
programment comme des pieds, comme le langage gere la memoire `pour
eux', oublient bien souvent qu'il y a plein d'autres ressources a
gerer, en particulier en cas d'erreur (connexions reseaux, connexions
BD, imprimantes, peripheriques); et le langage n'offre guere
qu'un pauvre `finally' pour gerer ca, au lieu d'exceptions et de
destructeurs en bonne et due forme...
Il y a fort a parier que, tot ou tard, on aura des implementations
java plus efficaces que celles du C++.
- evolution rapide, avec une enorme bibliotheque derriere, qui conduit
bien souvent en production a avoir une jvm par appli, ou presque. (et
comme c'est du proprietaire dont on a souvent pas les sources, tout
recompiler ne marche pas trop).
- implementation libre (FSF, par exemple) a la traine (bon d'accord, le
C++ n'est pas tres au point non plus). Plus cafouilleuse qu'Ada, c'est dire!
- quelques defauts du langage lui-meme: qui a du mal a gerer la genericite
de facon esthetiquement plaisante (peu grave);
qui a supprime les types non signes pour simplifier la vie du
programmeur, ce qui oblige a des atrocites pour manipuler de betes
adresses IPv4;
qui n'a comme concept de `ressource' integree au langage que la
memoire, ce qui est pour moi la pire des conneries de java. Les gens
programment comme des pieds, comme le langage gere la memoire `pour
eux', oublient bien souvent qu'il y a plein d'autres ressources a
gerer, en particulier en cas d'erreur (connexions reseaux, connexions
BD, imprimantes, peripheriques); et le langage n'offre guere
qu'un pauvre `finally' pour gerer ca, au lieu d'exceptions et de
destructeurs en bonne et due forme...
Il y a fort a parier que, tot ou tard, on aura des implementations
java plus efficaces que celles du C++.
- evolution rapide, avec une enorme bibliotheque derriere, qui conduit
bien souvent en production a avoir une jvm par appli, ou presque. (et
comme c'est du proprietaire dont on a souvent pas les sources, tout
recompiler ne marche pas trop).
- implementation libre (FSF, par exemple) a la traine (bon d'accord, le
C++ n'est pas tres au point non plus). Plus cafouilleuse qu'Ada, c'est dire!
- quelques defauts du langage lui-meme: qui a du mal a gerer la genericite
de facon esthetiquement plaisante (peu grave);
qui a supprime les types non signes pour simplifier la vie du
programmeur, ce qui oblige a des atrocites pour manipuler de betes
adresses IPv4;
qui n'a comme concept de `ressource' integree au langage que la
memoire, ce qui est pour moi la pire des conneries de java. Les gens
programment comme des pieds, comme le langage gere la memoire `pour
eux', oublient bien souvent qu'il y a plein d'autres ressources a
gerer, en particulier en cas d'erreur (connexions reseaux, connexions
BD, imprimantes, peripheriques); et le langage n'offre guere
qu'un pauvre `finally' pour gerer ca, au lieu d'exceptions et de
destructeurs en bonne et due forme...
On peut difficilement reprocher à Sun ou à Java le manque d'intérêt que
porte la FSF au langage. En d'autres lieux, tu serais le premier à
dire que c'est ces salauds de GNU-istes qui tentent d'enterrer Java
(et de promouvoir C# à la place, cf Mono).
On peut difficilement reprocher à Sun ou à Java le manque d'intérêt que
porte la FSF au langage. En d'autres lieux, tu serais le premier à
dire que c'est ces salauds de GNU-istes qui tentent d'enterrer Java
(et de promouvoir C# à la place, cf Mono).
On peut difficilement reprocher à Sun ou à Java le manque d'intérêt que
porte la FSF au langage. En d'autres lieux, tu serais le premier à
dire que c'est ces salauds de GNU-istes qui tentent d'enterrer Java
(et de promouvoir C# à la place, cf Mono).
According to Marc Espie :- evolution rapide, avec une enorme bibliotheque derriere, qui conduit
bien souvent en production a avoir une jvm par appli, ou presque. (et
comme c'est du proprietaire dont on a souvent pas les sources, tout
recompiler ne marche pas trop).
Ceci est bien faux. Le langage est à évolution rapide dans le sens
de l'ajout de classes et de méthodes, mais pas dans le sens de la
disparition. La très grande partie des évolutions se fait sous la forme
de packages indépendants qui sont progressivement rajoutés dans le
"standard" ; on peut notamment distribuer par ailleurs ces packages si
on veut en profiter tout en tournant sur les vieilles JVM (par exemple,
quand on veut utiliser Swing, histoire d'avoir un rendu graphique joli,
mais qu'on veut continuer à tourner sur les JVM 1.1, histoire de rester
compatible avec les malheureux qui utilisent Internet Explorer 4 comme
JVM). J'utilise régulièrement tout un tas d'outils en Java qui marchent
bien sur les vieux JDK (1.1) et que je lance néanmoins sur des JDK
récents (1.4) sans encombre.
According to Marc Espie <espie@nerim.net>:
- evolution rapide, avec une enorme bibliotheque derriere, qui conduit
bien souvent en production a avoir une jvm par appli, ou presque. (et
comme c'est du proprietaire dont on a souvent pas les sources, tout
recompiler ne marche pas trop).
Ceci est bien faux. Le langage est à évolution rapide dans le sens
de l'ajout de classes et de méthodes, mais pas dans le sens de la
disparition. La très grande partie des évolutions se fait sous la forme
de packages indépendants qui sont progressivement rajoutés dans le
"standard" ; on peut notamment distribuer par ailleurs ces packages si
on veut en profiter tout en tournant sur les vieilles JVM (par exemple,
quand on veut utiliser Swing, histoire d'avoir un rendu graphique joli,
mais qu'on veut continuer à tourner sur les JVM 1.1, histoire de rester
compatible avec les malheureux qui utilisent Internet Explorer 4 comme
JVM). J'utilise régulièrement tout un tas d'outils en Java qui marchent
bien sur les vieux JDK (1.1) et que je lance néanmoins sur des JDK
récents (1.4) sans encombre.
According to Marc Espie :- evolution rapide, avec une enorme bibliotheque derriere, qui conduit
bien souvent en production a avoir une jvm par appli, ou presque. (et
comme c'est du proprietaire dont on a souvent pas les sources, tout
recompiler ne marche pas trop).
Ceci est bien faux. Le langage est à évolution rapide dans le sens
de l'ajout de classes et de méthodes, mais pas dans le sens de la
disparition. La très grande partie des évolutions se fait sous la forme
de packages indépendants qui sont progressivement rajoutés dans le
"standard" ; on peut notamment distribuer par ailleurs ces packages si
on veut en profiter tout en tournant sur les vieilles JVM (par exemple,
quand on veut utiliser Swing, histoire d'avoir un rendu graphique joli,
mais qu'on veut continuer à tourner sur les JVM 1.1, histoire de rester
compatible avec les malheureux qui utilisent Internet Explorer 4 comme
JVM). J'utilise régulièrement tout un tas d'outils en Java qui marchent
bien sur les vieux JDK (1.1) et que je lance néanmoins sur des JDK
récents (1.4) sans encombre.
Tu évoquais la puissance des ports, c'est un argument en faveur de
l'utilisation de FreeBSD en tant que station de travail.
Je peux t'assurer que c'est du bonheur à mettre à jour / utiliser /
administrer ! :)
Voici mon problème, j'ai deux PCs relies par des cartes ethernet,
configures avec le protocole PPP.
-+- Romain in Guide du linuxien pervers - "Ils sont fous ces romains !" -+-
Tu évoquais la puissance des ports, c'est un argument en faveur de
l'utilisation de FreeBSD en tant que station de travail.
Je peux t'assurer que c'est du bonheur à mettre à jour / utiliser /
administrer ! :)
Voici mon problème, j'ai deux PCs relies par des cartes ethernet,
configures avec le protocole PPP.
-+- Romain in Guide du linuxien pervers - "Ils sont fous ces romains !" -+-
Tu évoquais la puissance des ports, c'est un argument en faveur de
l'utilisation de FreeBSD en tant que station de travail.
Je peux t'assurer que c'est du bonheur à mettre à jour / utiliser /
administrer ! :)
Voici mon problème, j'ai deux PCs relies par des cartes ethernet,
configures avec le protocole PPP.
-+- Romain in Guide du linuxien pervers - "Ils sont fous ces romains !" -+-
C'est des coups a ne plus developper qu'en smalltalk ca, d'autant qu'on
peut maintenant trouver une jolie implementation sur les 3 BSD: squeak
(pub)
Reste Objective-C alors. C'est grosso-modo une fusion de smalltalk
avec du C. Du peu que j'en ai vu ca a l'air top ! Pas vraiment
repandu... Ca a eu son heure de gloire avec les machines NeXT, et
semble revenir avec les nouveaux Mac.
C'est des coups a ne plus developper qu'en smalltalk ca, d'autant qu'on
peut maintenant trouver une jolie implementation sur les 3 BSD: squeak
(pub)
Reste Objective-C alors. C'est grosso-modo une fusion de smalltalk
avec du C. Du peu que j'en ai vu ca a l'air top ! Pas vraiment
repandu... Ca a eu son heure de gloire avec les machines NeXT, et
semble revenir avec les nouveaux Mac.
C'est des coups a ne plus developper qu'en smalltalk ca, d'autant qu'on
peut maintenant trouver une jolie implementation sur les 3 BSD: squeak
(pub)
Reste Objective-C alors. C'est grosso-modo une fusion de smalltalk
avec du C. Du peu que j'en ai vu ca a l'air top ! Pas vraiment
repandu... Ca a eu son heure de gloire avec les machines NeXT, et
semble revenir avec les nouveaux Mac.
[ une JVM par appli ]
Ceci est bien faux. Le langage est à évolution rapide dans le sens de
l'ajout de classes et de méthodes, mais pas dans le sens de la
disparition. La très grande partie des évolutions se fait sous la
forme de packages indépendants qui sont progressivement rajoutés dans
le "standard" ; on peut notamment distribuer par ailleurs ces packages
si on veut en profiter tout en tournant sur les vieilles JVM (par
exemple, quand on veut utiliser Swing, histoire d'avoir un rendu
graphique joli, mais qu'on veut continuer à tourner sur les JVM 1.1,
histoire de rester compatible avec les malheureux qui utilisent Internet
Explorer 4 comme JVM). J'utilise régulièrement tout un tas d'outils en
Java qui marchent bien sur les vieux JDK (1.1) et que je lance
néanmoins sur des JDK récents (1.4) sans encombre.
Bwah ! Tous les objets Java ont une méthode finalize() pour ça, et ce
depuis le JDK 1.0 !
Histoire d'être précis : la méthode finalize() est invoquée quand
l'objet est désalloué par le GC. On peut forcer un passage du GC en
appelant System.gc().
Maintenant, si tu veux faire une gestion plus fine de ce genre de choses
(notamment savoir exactement quand ton destructeur est appelé), rien
n'empêche d'écrire tes destructeurs et de les appeler au moment où tu
veux. Il n'y a pas de différence fondamentale entre "delete truc" et
"truc.delete()".
En dehors de ça, fort de mon expérience, je déclare que Java est un
langage décent, adapté à la programmation d'"applications" (par
opposition à des "commandes"). Il lui manque quelques features, qu'on
peut trouver ici à là dans quelques autres langages, mais je n'ai pas
encore rencontré de langage qui offre une meilleure combinaison
d'efficacité, support syntaxique, et existence d'une large
bibliothèque. À noter le gros avantage de Java (à mon sens) :
javadoc.
[ une JVM par appli ]
Ceci est bien faux. Le langage est à évolution rapide dans le sens de
l'ajout de classes et de méthodes, mais pas dans le sens de la
disparition. La très grande partie des évolutions se fait sous la
forme de packages indépendants qui sont progressivement rajoutés dans
le "standard" ; on peut notamment distribuer par ailleurs ces packages
si on veut en profiter tout en tournant sur les vieilles JVM (par
exemple, quand on veut utiliser Swing, histoire d'avoir un rendu
graphique joli, mais qu'on veut continuer à tourner sur les JVM 1.1,
histoire de rester compatible avec les malheureux qui utilisent Internet
Explorer 4 comme JVM). J'utilise régulièrement tout un tas d'outils en
Java qui marchent bien sur les vieux JDK (1.1) et que je lance
néanmoins sur des JDK récents (1.4) sans encombre.
Bwah ! Tous les objets Java ont une méthode finalize() pour ça, et ce
depuis le JDK 1.0 !
Histoire d'être précis : la méthode finalize() est invoquée quand
l'objet est désalloué par le GC. On peut forcer un passage du GC en
appelant System.gc().
Maintenant, si tu veux faire une gestion plus fine de ce genre de choses
(notamment savoir exactement quand ton destructeur est appelé), rien
n'empêche d'écrire tes destructeurs et de les appeler au moment où tu
veux. Il n'y a pas de différence fondamentale entre "delete truc" et
"truc.delete()".
En dehors de ça, fort de mon expérience, je déclare que Java est un
langage décent, adapté à la programmation d'"applications" (par
opposition à des "commandes"). Il lui manque quelques features, qu'on
peut trouver ici à là dans quelques autres langages, mais je n'ai pas
encore rencontré de langage qui offre une meilleure combinaison
d'efficacité, support syntaxique, et existence d'une large
bibliothèque. À noter le gros avantage de Java (à mon sens) :
javadoc.
[ une JVM par appli ]
Ceci est bien faux. Le langage est à évolution rapide dans le sens de
l'ajout de classes et de méthodes, mais pas dans le sens de la
disparition. La très grande partie des évolutions se fait sous la
forme de packages indépendants qui sont progressivement rajoutés dans
le "standard" ; on peut notamment distribuer par ailleurs ces packages
si on veut en profiter tout en tournant sur les vieilles JVM (par
exemple, quand on veut utiliser Swing, histoire d'avoir un rendu
graphique joli, mais qu'on veut continuer à tourner sur les JVM 1.1,
histoire de rester compatible avec les malheureux qui utilisent Internet
Explorer 4 comme JVM). J'utilise régulièrement tout un tas d'outils en
Java qui marchent bien sur les vieux JDK (1.1) et que je lance
néanmoins sur des JDK récents (1.4) sans encombre.
Bwah ! Tous les objets Java ont une méthode finalize() pour ça, et ce
depuis le JDK 1.0 !
Histoire d'être précis : la méthode finalize() est invoquée quand
l'objet est désalloué par le GC. On peut forcer un passage du GC en
appelant System.gc().
Maintenant, si tu veux faire une gestion plus fine de ce genre de choses
(notamment savoir exactement quand ton destructeur est appelé), rien
n'empêche d'écrire tes destructeurs et de les appeler au moment où tu
veux. Il n'y a pas de différence fondamentale entre "delete truc" et
"truc.delete()".
En dehors de ça, fort de mon expérience, je déclare que Java est un
langage décent, adapté à la programmation d'"applications" (par
opposition à des "commandes"). Il lui manque quelques features, qu'on
peut trouver ici à là dans quelques autres langages, mais je n'ai pas
encore rencontré de langage qui offre une meilleure combinaison
d'efficacité, support syntaxique, et existence d'une large
bibliothèque. À noter le gros avantage de Java (à mon sens) :
javadoc.
Je pense que ton style de programmation te conduit a faire les choses
correctement.
Je pense que ton style de programmation te conduit a faire les choses
correctement.
Je pense que ton style de programmation te conduit a faire les choses
correctement.
