[Précédent (date)] [Suivant (date)] [Précédent (sujet)] [Suivant (sujet)] [Index par date] [Index par sujet]

OT: Commentaires sur Java [was Re: D?bat: SLASHCODE :)]

Bon, c'est bête mais je ne me rappelle même plus du sujet exact.
On parlait de SlashCode et Python/Perl/PHP/Java je crois, non?
Et quelqu'un a dit que Java était lent et mal supporté...
M'enfin, le débat est intéressant quand même mais s'éloigne du
sujet de Linux de la ML. Je change donc le sujet pour un OT
(Off-Topic) afin que ceux qui ne sont pas intéresser puisse
le détruire.

On Sun, Aug 06, 2000 at 11:27:14AM -0400, Gilles J. Seguin wrote:
> Fabien Ninoles wrote:
> > 
> > gjc et kaffe supporte java de mieux en mieux...
> 
> On semble vouloir dire, la translation du source au language
> machine (compilation) a des avantages plus important que
> maintenir un language intermediare qui permet le reseautage.

Dans notre cas, le réseautage importe peu. Le code doit rouler
sur le serveur, pas sur un client inconnu. Autant alors utiliser
la compilation native plutôt qu'indépendante. Et puis, c'est
langage et pas "language" mais j'ai fait la même erreur moi aussi
à plusieurs reprises ;)

> 
> Et bien oui, lorsque nous avons un seul CPU, qui fonctionne
> dans un adresse memoire unique beaucoup des absractions
> (mecanismes) ne sont permis que parce que nous payons
> un pris plus grand que leur avantage.
> - machine virtual, c'est plus lent, ca consume de la memoire.
> - poubelle (garbage collection), c'est comme un poste de
>   peage, pour ceux qui aime les files d'attente.
>   Concepte originalement developper pour permettre le
>   developpement rapide (prototype)

Heu... là c'est moi qui me perd. Un CPU multiple utilise quand
même un adressage mémoire virtuelle et unique. Sinon, impossible
de partager la mémoire, non? C'est le cas de Linux entk.

> 
> > mais sun veut garder
> > le contrôle sur le language (pour éviter qu'il dégénère). C'est ça
                       ^^^^^^^^--> Hé! Qu'est-ce que je vous disais.
> > le problème. Trop de marketing trop tôt: on essaye d'établir un
> > standard artificiellement plutôt que de le laisser s'implémenter
> > soi-même. Á mon avis, dans ce cas précis, Sun aurait dù controler
> > au maximum le language et la plateforme jusqu'à ce que la
                  ^^^^^^^^--> Et de deux!
> > technologie soit bien répandu et qu'il en coûte cher de
> > s'éloigner du standard... Mais enfin, c'est une question
> > d'opinion. Je préfère encore utiliser des technologies
> > vraiment ouvertes et qui ont fait leur preuve par elles-mêmes
> > plutôt que ces technologies qui n'ont pas eu le temps
> > de mûrir avant d'être garroché par un marketing indécent.
> 
> Cette information est tres veille.  SVP revoir.  Et bien oui,
> six mois en informatique est presque la moitie de l'eternite.

Oui, effectivement, mais c'est bien ainsi que Java a été dévéloppé
et qui explique où il est rendu aujourd'hui. Que Sun ait tenté de
rectifier son tir ces derniers mois ne change rien sur ces débuts
"désastreux". Java doit encore faire ses preuves à MES yeux avant
d'être déclaré une alternative viable pour des applications autres
que des servlets et applets (tout ça AMHA - je ne suis vraiment pas
un fanatique en terme de langage). L'éternité n'a pas été assez
longue semble-t-il.

> 
> > N'otez-bien: java n'est pas un mauvais language et certainement
> > mieux que le C++,
> 
> Commentaire trivial et donc faux.  Supposons une application,
1+1=2 est trivial et, à ce que je sache, loin d'être faux.
> resoudre des equations differentiels comme les elements finis.
> Le fait de ne pouvoir utiliser son propre gestionnaire
> de memoire alouer, provoque un cout excessif en temps
> et en memoire.
> 
> Si c'est pout dire que le language Java convient mieux
> pour les programmeur amateurs, la reponse est oui.

C'était la qualité d'OO que l'on compare ici principalement.
C++ est horrible à ce point de vue tout comme perl (AMA). L'abstraction
OO est construite sur les bases d'un langage procédurale et le
résultat est souvent très moyen (il y a des exceptions; j'aime bien
personnellement le PascalObjet - à l'exception de l'implémentation
des interfaces par objet COM que l'on retrouve dans Delphi).

Ce que je veux surtout marquer (et j'avoue que le commentaire manquait
d'explications), c'est qu'un langage comme le C++ ou perl demande à
la base une bonne approche OO pour arriver à une bonne implémentation
OO. Un langage entièrement OO comme Java, SmallTalk ou Eiffel forcera
une meilleure approche du problème, toujours AMHA. Par contre, l'OO
ne garantie pas une bonne performance, ni même un bon design. C'est
toujours possible de faire de la merde avec même la meilleure méthode
au monde.

> 
> > il a seulement besoin de s'établir correctement,
> > hors des pressions commerciales qui le poussent
> > n'importe où!
> 
> Curieux commentaire, le language Java a ete concu a 
> l'origine pour echanger des programmes avec des
> peripheriques intelligents.
> 
> L'utilisation actuelle est un signe en effet que le
> language s'en va un peu n'importe ou.

On lit encore très souvent des articles sur l'utilisation
de Java dans des systèmes embarqués où l'utilisation d'un
langage plus compact (comme TCL ou Python) aurait probablement
été mieux adapté. Java n'est pas la panacé mais plusieurs
(pas nécessairement Sun, mais le marché lui-même) ont tenté
de le pousser à tout vent. C'est comme le OO. Ça a pris un
certains temps avant que les gens finissent par reconnaître
que l'OO comme on le connaissait méritait une certaine
réflexion avant d'être appliqué aux systèmes à temps réel.
Il y a un article intéressant là-dessus et sur le choix du langage
pour un projet dans le Embedded System du mois dernier.

-- 
-------------------------------*  *-------------------------
Fabien Niñoles                /  /          [email protected]
Chevalier Servant de Sa Dame /  /   C15D FE9E BB35 F596 127F
Veneur Gris par la Clef     /  /    BF7D 8F1F DFC9 BCE0 9436
Chaton pour Debian         /  / http://www.tzone.org/~fabien
--------------------------*  *------------------------------