IBM "presse" Sun depuis quelques années pour libérer Java, et ils reviennent à la charge suite à une récente position plus "pro-libre" de Sun qui est toujours hésitant sur la question.
Mise à jour : LinuxToday publie une analyse plus détaillée (et elle retrace les déclarations de Scott McNealy "The open-source model is our friend" puis la lettre ouverte d'Eric Raymond (ESR) et le follow-up par Simon Phipps)
![[en]](../images/en.png)
L'article sur Silicon.com (1034 hits)-
LinuxToday : " Community: Beyond an Open Source Java " (469 hits)
> Lire la dépêche (293 commentaires, moyenne: 1,3).
Vous avez demandé le commentaire #356519.
[+] Re: IBM demande à Sun de "libérer" Java
Chouette un super coin pour la chasse au Troll.
AU fait, JAVA, ça à quoi comme avantge par rapport aux autres langages?
[+] [^]Re: IBM demande à Sun de "libérer" Java
Ben, il n'y a pas de pointeurs.
Tu peux fermer ton code tout en restant multi-plateforme.
Tout est objet (même les types de base, me semble-t-il ?).
Tu ne peux déclarrer qu'une classe par module, ce qui t'oblige à un découpage méticuleux.
Doit y en avoir d'autre...
[^]Re: IBM demande à Sun de "libérer" Java
Tout est objet (même les types de base, me semble-t-il ?).
Non justement, pas les types de base.
[^]Re: IBM demande à Sun de "libérer" Java
En fait si, tous les types de base sont en objet mais en partique manipulable également par des type primitifs, ex. int pour java.lang.Integer, char pour java.lang.Charater.
Exception pour String qui n'est qu'en objet.
[^]Re: IBM demande à Sun de "libérer" Java
"en partique manipulable également"
Si tu pouvais mettre une constante int dans un Vector ca serait cool
Si tu pouvais facilement faire un switch sur des Integer (la val mais aussi chaque case prendre une constante Integer, vu qu'on avait besoin d'un Integer pour avoir un objet) ca serait cool aussi
Perso je prefere franchement le Ruby ou au moins _tout_ est un objet.
[^]Re: IBM demande à Sun de "libérer" Java
java 1.5 est fait pour toi ...
Vector monVector = new Vector();
monVector.add(42);
... vivement demain .... :-)
[^]Re: IBM demande à Sun de "libérer" Java
Ouai, sauf que la spec indique précisément que le 42 en question est placé dans un objet Integer avant d'être mis dans le Vector (d'ailleurs, il ne faut plus utiliser Vector depuis le 1.2, mais bon). Donc au niveau syntaxique, c'est sympa, mais au niveau perf...
[^]Re: IBM demande à Sun de "libérer" Java
> d'ailleurs, il ne faut plus utiliser Vector depuis le 1.2, mais bon
Hein quoi ? pourquoi tu dis ça ?
C'est pas "deprecated" le Vector ?
Je veux bien un lien ou une explication stp
[^]Re: IBM demande à Sun de "libérer" Java
Vector est avantageusement remplacé par les List, en version ArrayList. Vector est synchronized (thread safe) ce qui la rend lente comparée à ArrayList quand on n'a justement pas besoin de l'aspect synchronized.
[^]Re: IBM demande à Sun de "libérer" Java
Euh un vector est une List, c'est juste une List(l'interface) synchronizée, mais tu peux tjrs utiliser vector.
All those moments will be lost in time, like tears in the rain.
[^]Re: IBM demande à Sun de "libérer" Java
Oui, tu peux, mais c'est moins efficace.
[^]Re: IBM demande à Sun de "libérer" Java
Mais dans un fonctionnement multi-thread, ca peut etre un peu plus sur... Non?
[^]Re: IBM demande à Sun de "libérer" Java
...mais ça ne sert à rien si tu fais de la lecture simple.
Possible à utiliser : les bag de chez apache Commons fastArray et autre...
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[^]Re: IBM demande à Sun de "libérer" Java
> Mais dans un fonctionnement multi-thread, ca peut etre un peu plus
> sur... Non?
Oui, mais un bon programmeur s'en charge lui-même et synchronise à un niveau supérieur, là où c'est nécessaire pour son application. C'est plus rapide de synchroniser un bloc dans ta classe, où tu accèdes à la liste, que de synchroniser deux fois - dans ton bloc ET dans la liste.
Un Vector, oui, c'est plus sûr, mais tu ne devrais pratiquement pas avoir besoin de sa synchronisation. Si tu ne veux pas prendre de chances, ok, mais un Collections.synchronizedList(new ArrayList(...)) fait tout aussi bien l'affaire.
[^]Re: IBM demande à Sun de "libérer" Java
A partir du moment ou tu souhaites considérer les types de base comme des objets, il faut accepter une perte de perf et ça quelque soit le langage. Après le compilateur peut essayer de faire qq optimisations mais ça doit pas toujours être évident.
Dans ton cas, tu peux toujours utiliser des listes qui manipulent des types primitifs pour optimiser les perfs, il en existe pléthore. en java (cf. apache.org).
Comme souvent, c'est un compromis en perf et facilité/généricité.
Nb. Rien à voir avec post en cours.
Je suis toujours surpris du nombre de trolls déclenché par le mot Java sur le dlfp. Quelqu'un aurait-il une explication? Le geek linux ne parle-t-il que le C, et accessoirement le Perl?
[^]Re: IBM demande à Sun de "libérer" Java
A partir du moment ou tu souhaites considérer les types de base comme des objets, il faut accepter une perte de perf et ça quelque soit le langage.
C'est faux. Eiffel et Sather considèrent les types de base comme objet sans perte de performance. Pour ce faire, il faut distinguer deux catégories d'objets (comme en C#), ces objets passés par référence et des objets passés par valeurs. Les types de base sont des objets passés par valeur, ce qui élimine les problèmes d'occupation mémoire et d'efficacité induit par l'autoboxing.
[^]Re: IBM demande à Sun de "libérer" Java
Un objet même passé par valeur reste de toute manière beaucoup plus lent qu'un vrai type primitif "mappable" directement sur l'architecture de données du processeur.
Ceci dit c'est effectivement un domaine ou j'aimerais bien que Java évolue, cela permettrait d'améliorer les perfs de qq softs de manière notable au détriment, malheureusement, d'une complication du langage.
[^]Re: IBM demande à Sun de "libérer" Java
Un objet même passé par valeur reste de toute manière beaucoup plus lent qu'un vrai type primitif "mappable" directement sur l'architecture de données du processeur.
Non, les tests de Sather et Eiffel prouvent le contraire. Un objet passé par valeur ne supporte pas l'héritage, il n'y a donc pas de table de méthodes "virtuelles" à la C++. Un int Eiffel est un objet, mais il est manipulé comme un int natif dans le code engendré.
[^]Re: IBM demande à Sun de "libérer" Java
Le problème, c'est qu'en Java, tout objet hérite de java.lang.Object, qui contient déjà pas mal de bazard : Une info de typage dynamique, des verrous pour les éventuels "synchronized", ...
Résultat, un Integer en Java occupe entre 20 et 30 octets, alors qu'en principe, c'est seulement 4 !
Si tu les passe par valeur, il faut tout recopier à chaque fois, si tu passe par référence, il y a une indirection de plus a chaque accès. Pas trop de compromis possible là dessus.
[^]Re: IBM demande à Sun de "libérer" Java
si tu passe par référence, il y a une indirection de plus
Le cout perdu a l'indirection est extremement faible dans une grosse appli.
Je me rappele encore mes profs me repeter qu'il ne sert a rien de se battre sur ce genre d'optimisations et d'essayer plutot d'optimiser l'algo lui meme.
[^]Re: IBM demande à Sun de "libérer" Java
Tes profs sont des cons. Le coût perdu par l'indirection en Java est énorme car il participe de la mauvaise gestion de la mémoire des applis Java. Tout objet en Java est manipulé par référence. Oui, l'indirection elle-même ne coûte pas grand chose pour un objet. Mais quand tu scannes un tableau d'objets, tu n'as plus de localité en mémoire et ça peut donner des résultats catastrophiques à cause des accès "random" à la mémoire qui ne profitent pas du tout du cache. Un exemple : produit matriciel programmé en tenant compte de la localité du stockage peut être 100 fois plus rapide que le même produit matriciel programmé à la grand père, en ne tenant pas compte de la localité. Sur des tableaux d'objets, on obtient le même genre de perfs...
[^]Re: IBM demande à Sun de "libérer" Java
Arrete c'est bon, tu prends justement l'exemple qui evidement contredit ce que je venais de dire. Si tu savais lire tu verrai que je parlais d'une appli et pas d'un algo particulier.
[^]Re: IBM demande à Sun de "libérer" Java
C'est le principe. Il faut toujours adapter la structure de données à l'algo qu'on utilise. Effectivement, on pourra toujours, dans tous les langages, faire un tres bon algo qui va tres mal fonctionner à cause des données mal présentées, et faire des données super bien présentées qui sont mal traitées à cause de l'algo de merde...
Bref, en gros, discution stérile.
[^]Re: IBM demande à Sun de "libérer" Java
C'est vrai, mais je parlais pas de ca.
[^]Re: IBM demande à Sun de "libérer" Java
Je sais lire la masse de conneries que tu as postées dans cette news. Toutes les applis Java que je connais sont pénalisées par une consommation de mémoire pléthorique. Avec une grosse quantité de mémoire, elles fonctionnent très bien, avec des performances très honorables. D'où vient cette consommation ? Du fait que tous les objets sont manipulés par référence (d'où l'occupation de 4 octets pour chaque objet au minimum) et que Object est bloated pour des raisons de conception.
Le problème de Java est que tu ne peux pas faire autrement : tu ne peux pas manipuler les objets par valeur, même quand ça permet d'économiser de la mémoire et des perfs. Donc, oui l'indirection coûte quelque chose, à la fois en occupation mémoire et en perfs. Mais tu appliques servilement les préceptes de mauvais profs, donc tu ne comprends rien. Dans mes cours, tu aurais des sales notes.
[^]Re: IBM demande à Sun de "libérer" Java
Ok, maintenant regarde un peu le code deroulé quand tu utilises Corba, Com, l'overhead des interfaces graphiques et des commandes utilisateurs ... ce n'est pas une indirection sur un objet qui va bouffer tes perfs.
Ton probleme c'est que tu n'as qu'une vue locale de ce que tu developpes. Je suis d'accord avec toi que sur un algo bien precis il faut effectuer ce genre d'optimisation comme pour l'exemple que tu as cite. Mais d'une maniere generale, l'utilisation d'un formalisme de haut niveau tel que la programation distribuée ou par composants, les IHM, permettent un developpement plus rapide et de meilleur qualite au detriment des perfs (indirections, overhead inevitables)
Pour mes profs, je ne prends pas tous leur préceptes a coeur, j'essaie plutot de me construire mon propre avis, et sur ce point la je suis d'accord avec eux car je l'ai mesuré concretement.
[^]Re: IBM demande à Sun de "libérer" Java
Ok, maintenant regarde un peu le code deroulé quand tu utilises Corba, Com, l'overhead des interfaces graphiques et des commandes utilisateurs ... ce n'est pas une indirection sur un objet qui va bouffer tes perfs.
Tu ne comprends donc rien. L'indirection obligatoire en Java fait qu'on ne peut pas économiser la mémoire et donc ça bouffe tes perfs même avec des usines à gaz comme Corba ou Swing (qui subissent elles aussi cette contrainte et donc sont encore plus des usines à gaz en Java que dans leur version C++). L'absence de l'équivalent des structs du C# en Java est une catastrophe en terme de performances à cause de la mémoire.
Ton probleme c'est que tu n'as qu'une vue locale de ce que tu developpes. Je suis d'accord avec toi que sur un algo bien precis il faut effectuer ce genre d'optimisation comme pour l'exemple que tu as cite. Mais d'une maniere generale, l'utilisation d'un formalisme de haut niveau tel que la programation distribuée ou par composants, les IHM, permettent un developpement plus rapide et de meilleur qualite au detriment des perfs (indirections, overhead inevitables)
Tu lis O1, c'est ça ? Je me demande comment tu utilises un formalisme de haut niveau alors que tu n'as rien compris à l'objet...
[^]Re: IBM demande à Sun de "libérer" Java
Tu ne comprends donc rien. L'indirection obligatoire en Java fait qu'on ne peut pas économiser la mémoire
Sur ce point je suis d'accord.
Tu lis O1, c'est ça ? Je me demande comment tu utilises un formalisme de haut niveau alors que tu n'as rien compris à l'objet...
Ba ouai ca doit etre ca... d'ailleur dans la boite ou je suis on est tous abonné a 01.
[^]Re: IBM demande à Sun de "libérer" Java
Autre chose, tu es autant intolerant et irrespecteux avec tes eleves ?
[^]Re: IBM demande à Sun de "libérer" Java
Je suis en effet très intolérant avec la connerie et très irrespecteux de celle-ci. Tu l'incarnes ici. Tu arrives dans ce thread et tu multiplies les posts débiles du genre :
- "C++ n'est pas objet car il ne supporte pas le typage dynamique" : n'importe quoi. Une telle déclaration prouve simplement que tu ne connais rien aux langages objets, en particulier certains des plus avancés comme Eiffel ou Objective Caml.
- "Dans un monde objet l'heritage n'a pas vraiment de sens" : désolé, mais là, ce n'est même plus n'importe quoi, c'est tout simplement débile
- "L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet. " : j'ai déjà répondu à ça, mais visiblement tu ne sais pas comment un modèle objet est implémenté (sur le hardware), donc ça ne sert à rien de continuer
- "De toute facon la notion d'objet, a mes yeux, n'est pas dependante du langage mais plutot de la facon dont le developpeur utilise les fonctionnalités du langage utilisé. Elles ne sont la que pour l'aider et formaliser syntaxiquement ce concept." : tu n'as encore rien compris, comme toutes les personnes qui prétendent faire de l'objet en C.
Bon, je m'arrête, ça suffira. Tu démontres pas ces posts que tu parles de choses que tu ne connais pas. Je n'ai aucun respect pour ça (soit dit en passant, tu m'indiques que je ne sais pas lire, ce qui n'est pas très respectueux non plus).
[^]Re: IBM demande à Sun de "libérer" Java
Je persiste, tu ne sais effectivement pas lire, tu viens de sortir des phrases de leur contexte d'une part, et tu as deformé mes propos.
1. Le typage dynamique etait juste un exemple parmi d'autres des concepts objets non implementés par le C++, de plus je n'ai jamais dit que ce n'etait pas objet, tu remarqueras le vrai entre guillemets, mais malheureusement ta "connerie", mot que tu affectionnes particulierement, te fait lire les choses qu'a moitié.
2. Pour l'heritage, reportez vous a l'ensemble de mon post. (C'etait volontairement provocateur)
3. Sur ce point la j'avoue ne pas tout connaitre, d'ailleur je n'ai rien compris a tes reponses. Est-ce volontaire de ta part ? C'est dommage tu sembles avoir sur ce point beaucoup d'experiences.
4. gni ???
En gros je crois avoir saisit le personnage, tu aimes apparement te faire passer pour un pro (ce que tu es certainement, je n'en doute pas). Mais quand tu reponds aux "conneries", pourrais-tu plus souvent justifier ces conneries, car repondre "tu n'as encore rien compris", "ça ne sert à rien de continuer", " c'est tout simplement débile", ... et repondre a des posts de maniere imprecise n'est pas tres constructif.
[^]Re: IBM demande à Sun de "libérer" Java
Dans mes cours, tu aurais des sales notes.
On dirait Tanenbaum.
[^]Re: IBM demande à Sun de "libérer" Java
Je suis d'accord, le problème essentiel de Java est son occupation mémoire causée par les un java.lang.Object complètement bloated. Ceci étant, ce n'est pas une fatalité :
1) il existe des techniques pour virer le verrou nécessaire au synchronized. C'est implémenté dans SableVM (http://www.sablevm.org/(...)).
2) des langages objets plus vieux de Java (Eiffel et Sather) ont une notion d'objets passés par valeur (et uniquement par valeur) qui ressemblent aux structs du C et qui permettent de régler le problème poser par Integer. Comme le typage devient 100% statique avec ces objets, on peut s'arranger pour qu'ils occupent exactement la place mémoire nécessaire. Pour les petits objets type Integer, ou nombre complexe, c'est la fête.
[^]Re: IBM demande à Sun de "libérer" Java
C'est très rare que c'est nécessaire de passer un Integer par valeur (clôné). Un Integer ne se modifie pas, une fois qu'il est instancié, alors tu ne devrais pas avoir peur qu'il soit changé par un autre thread.
La seule situation où clôner un Integer peut être souhaitable, est si tu synchronises dessus. Mais encore là, ça dépend beaucoup du contexte, et je ne crois pas que ça arrive souvent.
[^]Re: IBM demande à Sun de "libérer" Java
Je suis toujours surpris du nombre de trolls déclenché par le mot Java sur le dlfp
Je pense que c'est essentiellement parce que Java n'est pas libre. S'il l'était, il aurait eu un développement bien plus important car Java est potentiellement très intéressant. L'attitude de Sun est frileuse et fait qu'un utilisateur de Java ressent toujours l'épée de Damoclès au dessus de sa tête.
[+] [^]Re: IBM demande à Sun de "libérer" Java
Non, le probléme, c'est que Java est présenté comme le langage ultime, celui qui sert à tout. Alors que le probléme, c'est que dans tout les domaines, il existe un langage qui est plus efficace que Java.
Au début, il a été utilisé comme un langage pour le web, puis php et companie se sont révelé plus éfficace. Depuis, il n'a pas retrouvé de place.
\_°< C01N C01N ! >°_/
[^]Re: IBM demande à Sun de "libérer" Java
Au début, il a été utilisé comme un langage pour le web, puis php et companie se sont révelé plus éfficace.
:-) LOL
On voit que tu connais le domaine !!
Vache qui rit, à moitié dans son lit
[^]Re: IBM demande à Sun de "libérer" Java
faut l'excuser le pauvre il a confondu java et javascript :D
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: IBM demande à Sun de "libérer" Java
Pas sûr, il pensait peut être aux applets Java. Mais même dans ce cas, PHP ne remplace pas les applets Java...
[^]Re: IBM demande à Sun de "libérer" Java
En effet, j'ai fait une erreur, c'est plutôt le flash qui à remplacer les applets Java. Enfin, ça fait un moment que j'ai plus vue d'applets Java.
Puis au lieu de moinsser, dite moi plutôt dans quel domaine java est meilleur qu'un autre langage.
Puis tant qu'on y est: Pourquoi dans le mot javascript, y'a java?
\_°< C01N C01N ! >°_/
[^]Re: IBM demande à Sun de "libérer" Java
Vraiment n'importe quoi. Les types de base ne sont pas des objets, ils sont manipulés par valeur uniquement, n'ont pas de méthode, etc. Il existe effectivement un type objet associé à chaque type de base (genre Integer pour int), mais il a fallut attendre la version 1.5 pour avoir un autoboxing qui simplifie les jonglages entre int et Integer du point de vue syntaxique mais est toujours une horreur du point de vue des perfs.
[^]Re: IBM demande à Sun de "libérer" Java
il te force à gérer les exceptions à la compilation
[^]Re: IBM demande à Sun de "libérer" Java
Par forcement ya Exception et RuntimeException le tout est de bien chargé en fonction des cas.
EJB Exception Handling :
http://www-106.ibm.com/developerworks/java/library/j-ejb01283.html(...)
[+] [^]Re: IBM demande à Sun de "libérer" Java
Je vais aider mais je pense que c'est trop enorme :
Quel est l'interet de liberer Java puisque Perl est libre ?
Linux c'est comme ...
heu ...
comme ...
c'est bien quoi !
[^]Re: IBM demande à Sun de "libérer" Java
Java et Perl ont autant de points communs que le basic et le C++, à savoir à peu pres aucun.
[^]Re: IBM demande à Sun de "libérer" Java
beurk t'as marché dedans :(
[+] [^]Re: IBM demande à Sun de "libérer" Java
Java et Perl ont autant de points communs que le basic et le C++, à savoir à peu pres aucun.
Java == basic
Perl == C++
?
^^; plus là ! ->[]
[+] [^]Re: IBM demande à Sun de "libérer" Java
« Java et Perl ont autant de points communs que le basic et le C++, à savoir à peu pres aucun. »
Il y en a un des deux que tu ne connais pas. Surtout s'il était question de Perl6.
[^]Re: IBM demande à Sun de "libérer" Java
Moi, je verrais bien Java sous la nouvelle licence XFree et la doc sous GFDL.
Poilu ? Comment ça, poilu ?
[^]Re: IBM demande à Sun de "libérer" Java
AU fait, JAVA, ça à quoi comme avantge par rapport aux autres langages?
A l'attaque!!!!!
[^]Re: IBM demande à Sun de "libérer" Java
C'est méchant !
Tu as oublié de préciser qu'il a relancé la demande mondiale de RAM parce qu'en dessous de 256, tu peux oublier des environnement comme Jbuilder
[^]Re: IBM demande à Sun de "libérer" Java
oui, mais grâce à Java et Websphere Commerce ma machine de dev (au taf) a 1Go de RAM !!!
Donc moi je dit merci à SUN et à IBM :))
[^]Re: IBM demande à Sun de "libérer" Java
Effectivement, JBuilder pour faire du Java, c'est un peu comme OpenOffice pour éditer un script bash...
[^]Re: IBM demande à Sun de "libérer" Java
Il permet de se souvenir des joies de l'optimisation, en ramenant la puissance d'un octoprocesseur Opteron à 8 G(i)B de RAM (sec) à un processeur 386 SX virtuel, mais multiplateformes ! (Comment une machine peut-elle être multiplatormes déjà ? Ah, oui, avec un processeur Java natif ?!)
On doit donc se tuer le cerveau à pratiquer des optimisations dépassées, avec deux contraintes supplémentaires: le faire en orienté objet, et sans les pointeurs.
[^]Re: IBM demande à Sun de "libérer" Java
Ah, oui, avec un processeur Java natif ?!)
Ça fait pas un peu des années que Sun a abandonné le truc ? (un peu comme Oracle avec ses NetPC)
[+] [^]Re: IBM demande à Sun de "libérer" Java
s/memcheck86/valgrind/
Sauf erreur de ma part, memcheck86, c'est pour vérifier que la mémoire physique est OK, ce qu'aucun language ne peut faire.
Ce n'est surement pas le seul language au monde a garantir ça. La plupart des languages interpretés sont comme ça aussi. Les langages sans pointeurs sont à ma connaissance tous comme ça (Si on fait les tests de débordements de tableau, c'est bon). On peut citer Lisp, C#, BASIC (!), perl je crois, bash, ...
Et dans des langages un minimum défensifs comme Ada, il faut vraiment demander gentilment pour faire des conneries avec la mémoire. Là, ça ne se règle pas à coup de valgrind, mais à coup de "grep" dans le source !
[^]Re: IBM demande à Sun de "libérer" Java
En fait, un truc ultra puissant de Java c'est que les vérifications pour la mémoire se font dynamiquement, à partir du .class. Tu peux charger une application compilée dans une sandbox et l'exécuter en contrôlant parfaitement son exécution en terme de droit d'accès aux ressources de la machine virtuelle. En fait, tu peux charger dans une même machine plusieurs applications et maîtriser parfaitement les communications entre elles. A ma connaissance, seul C# possède des fonctionnalités de ce genre. Les exemples que tu cites sont bons à partir du moment ou on dispose du source. Par contre, quand on produit un code exécutable, on ne peut plus vérifier grand chose sur celui-ci. En Java et en C#, un modèle de sécurité très évolué permet au contraire de contrôler parfaitement l'exécution d'un code compilé. L'aspect mémoire est une petite partie de ces fonctionnalités.
Ceci étant, tu as parfaitement raison pour memcheck86, mais je crois que ton interlocuteur faisait une "petite blague" sur l'utilisation mémoire de Java, un vrai problème...
[^]Re: IBM demande à Sun de "libérer" Java
Tu n'as pas compris c'est bien de memcheck86 dont il parle...
traduction: java utilise TOUTE ta ram et donc la teste (comme memcheck86).
[^]Re: IBM demande à Sun de "libérer" Java
et ça teste à fond ta partition de swap, par le même coup.
Windows has no users. It has hostages.
[^]Re: IBM demande à Sun de "libérer" Java
J'ai déjà eu un memory leak avec les exceptions sous Perl (eval / die). Quand ton programme tourne 24h/24 c'est un peu chiant de constater qu'au bout d'une semaine il bouffe 50 Mo de RAM. ;)
[^]Re: IBM demande à Sun de "libérer" Java
la notion de garbage collector est indépendante des langages. il existe des GC pour à peu près tous les langages à commencer par le C
[^]Re: IBM demande à Sun de "libérer" Java
C'est sûr qu'ils sont vachement utilisés en C, il n'y a qu'a regarder dans gnome. Comme le C est intrinsèquement non sûr, on ne peux pas faire un GC parfaitement sûr pour ce langage, de même que pour le C++. Donc désolé, mais pour qu'un GC puisse (au moins en théorie) fonctionner parfaitement, il faut que le langage soit conçu pour.
[^]Re: IBM demande à Sun de "libérer" Java
C'est le cas de C++, tu trouveras quelques mots de Stroustrup à ce propos. Évidemment comme toujours, C++ ne l'impose pas, la norme est simplement compatible, des compilateurs pourraient le faire.
Ceci dit, il ne faut pas négliger l'utilisation d'une bibliothèque dédiée, qui propose ses services d'allocation. Et là pas besoin que le langage soit conçu pour tourner avec un GC.
[^]Re: IBM demande à Sun de "libérer" Java
Oui, sauf que non. Si tu utilises un GC dans un environement de production, ce n'est pas pour avoir un memory leak. Or, les GC destinés aux langages comme le C ou le C++ ne peuvent pas garantir à 100% qu'il n'y aura pas de memory leak. Tu me diras qu'il y a toujours des bugs dans les GC et donc que du 100%, ça n'existe pas, ce qui n'est pas faux. Sauf que dans la situation présente, ce n'est un bug dans le GC qui est à craindre, mais un problème dans ton code qui fait que le GC ne peut pas désallouer une partie de la mémoire...
Sinon, je t'avoue que la prose de Stroustrup ne m'intéresse absolument pas. Ce brave homme a montré depuis des années qui ne connaissait absolument rien à ce que la recherche a produit dans le domaine des langages de programmation et le résultat est C++, plein de bonne volonté et plein d'erreurs de conception. Ca m'arrache le coeur de l'avouer, mais Microsoft a bien compris le problème et a donc embaucher des gens compétents dans le domaine pour faire C#, et franchement, ça se voit...
[^]Re: IBM demande à Sun de "libérer" Java
Contrairement à pas mal de languages de script adorés par tous les boutonneux de service, Java est vraiment un language objet. En plus il est compilable (bytecode et natif). Et il dispose de toutes les fonctionnalités pour une adoption en entreprise, pas seulement pour faire un système "qui marche" dans un coin (activité favorite des boutonneux nommés ci-dessus) mais qui se révèle inutilisable en exploitation.
Quant aux performances, l'indulgence m'empêche de parler de celles d'un certain language qui porte le nom d'un serpent tropical, et dont les boutonneux sont tombés amoureux, sans doute parce-que le nom leur plait et que ça fait bien de parler d'animaux sauvages plus ou moins dangereux devant les nanas.
Si l'amour rend aveugle, la branlette rend sourd...
[^]Re: IBM demande à Sun de "libérer" Java
qu'est ce que cela aurait donné, si tu avais comparé Java à Ruby (les pierres précieuses aussi ça doit arracher devant les nanas :) )
Heureusement qu'on a dans la partie Troll, sinon je penserais vraiment que ce site est parcouru par des pédants qui se croient supérieurs car ils utilisent tel langage au lieu de tel autre.
[^]Re: IBM demande à Sun de "libérer" Java
ce site est parcouru par des pédants qui se croient supérieurs car ils utilisent tel langage au lieu de tel autre.
Je crois bien que c'est le cas malheureusement !
[^]Re: IBM demande à Sun de "libérer" Java
sinon je penserais vraiment que ce site est parcouru par des pédants qui se croient supérieurs car ils utilisent tel langage au lieu de tel autre.
Meuh non :-))))))))))))))))))))))))))))
[+] [^]Re: IBM demande à Sun de "libérer" Java
Et ne parlons même pas de ceux que ça fait bander d'utiliser un langage au nom également tropical qui rappelle une célèbre île d'Indonésie (ça doit leur rappeller leurs vacances), à la syntaxe verbeuse et souvent inutile mais qui ressemble à des langages célèbres et autrement excellents (ça doit leur faire croire qu'ils savent coder), et supportées par l'un des plus gros géant de l'informatique dans le monde (ça leur fait trouver du boulot, seul point positif, et ça leur fait croire que quand on y met de l'argent c'est bien).
Plus concrètement, vous faites pitié.
[+] [^]Re: IBM demande à Sun de "libérer" Java
Dans le style commentaire de pauvre cloche, c'est un record !
Aucun commentaire supplémentaire ne s'impose :-))))
[+] [^]Re: IBM demande à Sun de "libérer" Java
C'est toujours affligeant de voir que les idiots ne se reconnaissent pas dans les critiques qui sont faites d'eux.
[^]Re: IBM demande à Sun de "libérer" Java
s/un certain language qui porte le nom d'un serpent tropical/un certain language qui fait réference à une bande de comiques anglais culte/
Ni !
[^]Re: IBM demande à Sun de "libérer" Java
Riki riki riki pam pam!
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[+] [^]Re: IBM demande à Sun de "libérer" Java
« Contrairement à pas mal de languages de script adorés par tous les boutonneux de service, Java est vraiment un language objet. »
Ce n'est pas un langage objet. Il y a des langages objet, et Java n'en fait pas partie.
Et le pire, c'est que ce langage se veut objet, donc au final : il ne propose pas d'autres types de programmation, et il n'est pas terrible dans celui qu'il prétend être.
Java est apparemment bien adapté aux applications web. Pour toute autre application, on trouve plus adapté (mais évidemment, ça dépend de l'application).
Un avantage quand même : il est pas mal pour l'enseignement.
[^]Re: IBM demande à Sun de "libérer" Java
Un avantage quand même : il est pas mal pour l'enseignement.
Oui, un manuel de référence Java dans la tronche, ça te calme vite les cancres les plus aguerris.
[^]Re: IBM demande à Sun de "libérer" Java
...Mais sur le pied ça te bousille les vacances à la montagne
Every takeoff is optional. Every landing is mandatory. -- Rules Of Flying
[+] [^]Re: IBM demande à Sun de "libérer" Java
Quel intéret par rapport au C++ ?
Même portabilité, et le C++ est plus joli est plus rapide !
Franchement, il y a des c*ns partout.
[+] [^]Re: IBM demande à Sun de "libérer" Java
C'est sur qu'en terme de performances pures C++ est plus puissant mais pas portable en réalité.
Si ton programme C++ dépend d'une lib C++ il faut que cette lib existe sur toute les plateformes, ce qui n'est pas toujours le cas.
En du moment qu'il ya un JVM pour la plateforme, quasi toute les plateformes, ta lib windows marchera sous la JVM linux et donc, le programme en Java dépendant de la lib fonctionnera lui aussi, à fortiori.
Et puis le C++ c'est moins objet (je dis pas que Java est tout objet, je dis qu'il est largement plus objet que C++), avec les histoires d'héritage multiple qui viole la notion d'objet.
C++ pour les performances pures
Java pour la portabilité et l'objet
[^]Re: IBM demande à Sun de "libérer" Java
Heuuu, comment dire... « n'importe quoi » ?
[+] [^]Re: IBM demande à Sun de "libérer" Java
Renseigne toi ...
C++ n'est pas un "vrai" langage objet et pour plusieurs raisons (heritage multiple entre autre a la place d'interface) mais aussi le fait qu'il ne supporte pas le typage dynamique ...
[+] [^]Re: IBM demande à Sun de "libérer" Java
Une derniere chose, UML permet effectivement de modeliser l'heritage multiple, mais UML n'a pas inventer la conception objet.
Dans un monde objet l'heritage n'a pas vraiment de sens, on lui prefere la notion d'extension (equivalente a l'heritage simple) pour specialiser l'objet et la notion d'interface pour ajouter un comportement. Generalement l'extension implement l'interface et etend un objet pour lui ajouter le comportement de cette interface. Je ne sais pas si c tres clair ce que je viens d'ecrire ;)
[^]Re: IBM demande à Sun de "libérer" Java
C'est pas un peu fini, les conneries ?! Ce n'est pas parce que smalltalk était complètement dynamique qu'il faut obligatoirement supporté le "typage dynamique" (ce qui ne veut rien dire) pour être objet. Eiffel et Sather sont des vrais langages objets et ils sont plus proche de C++ que de smalltalk, par exemple.
[^]Re: IBM demande à Sun de "libérer" Java
Ben...
1) Explique-moi ce qu'est un « vrai langage objet » alors, et en quoi l'héritage multiple viole ce concept de véritable objectitude
2) Eiffel gère l'héritage multiple, ce n'est pas un « vrai langage objet » ?
3) Java est un langage fortement typé ET statiquement typé, comme C++. On peut, en Java, caster un objet en une de ses sous-classes, si l'objet est du bon type (si c'était ça que tu voulais dire). Mais en C++ aussi, grâce à dynamic_cast.
[^]Re: IBM demande à Sun de "libérer" Java
J'ai mis vrai entre guillement.
C++ est un langage objet, puisqu'il reprend les principaux principes, mais, comme pratiquement tous les langages et pour des raisons de facilité d'utilisation il va plus loin et propose des fonctionnalités qui sorte du cadre de la conception purement objet.
On peut, en Java, caster un objet en une de ses sous-classes, si l'objet est du bon type (si c'était ça que tu voulais dire). Mais en C++ aussi, grâce à dynamic_cast.
Le typage dynamique permet juste de determiner le type d'un objet a l'execution. Il n'y a pas de controle a la compilation. Dans l'exemple que tu as cite le "cast" est controle a la compilation. L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet.
[+] [^]Re: IBM demande à Sun de "libérer" Java
L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet.
Ultra puissant, on remplace une table de fonctions virtuelles par un pointeur vers le type de l'objet. Quel gain remarquable !!! De toute manière, Java est typé à la compilation...
[^]Re: IBM demande à Sun de "libérer" Java
Nan nan, la particularité de dynamic_cast est justement de vérifier le type de l'objet à l'exécution (voir ici: http://www.cplusplus.com/doc/tutorial/tut5-4.html(...) )
[^]Re: IBM demande à Sun de "libérer" Java
Bon, ceci dit, dynamic_cast c'est loin d'être la feature la plus heureuse du C++.
En passant, j'ai lu la doc Ruby récemment, ça a l'air très sympathique (beaucoup plus que Python) : syntaxe légère, grande expressivité, et l'implémentation des itérateurs est particulièrement alléchante. Vivement que ça mûrisse.
[^]Re: IBM demande à Sun de "libérer" Java
Ah, un troll python/ruby, ça change des vieux trolls C++/Java!
Ceci dit, en quoi tu trouves que Ruby est beaucoup plus sympathique que Python?
[^]Re: IBM demande à Sun de "libérer" Java
Le Python, c'est des types distincts pour les tuples et les listes, les strings qui sont invariables, la fausse bonne idée des indentations pour délimiter les blocs de code, le self explicite dans les déclarations de méthode, les globales qui se retrouvent locales quand tu écris dedans... Et c'est à moitié objet (types de bases vs. objets). Ruby quant à lui conserve la syntaxe ultra-concise d'un langage comme Perl, tout en apportant une sémantique beaucoup plus haut niveau (mate les coroutines, qui permettent d'engendrer les itérateurs en un tournemain avec le mot-clé yield).
Bref j'ai l'impression que Ruby est beaucoup plus abouti conceptuellement. Note que je n'aborde pas le sujet de la vitesse ou de la richesse des bibliothèques.
[^]Re: IBM demande à Sun de "libérer" Java
Bon pour rester dans le conceptuellement, Ruby s'inspire beaucoup de python et pourtant n'apporte presque rien. Syntaxe utra-concise, Python est plus concis, pas à moitié-objet,Python est totalement objet.
[^]Re: IBM demande à Sun de "libérer" Java
Python est totalement objet
Les types de base de Python (entiers, etc.) ne sont pas des objets.
[^]Re: IBM demande à Sun de "libérer" Java
mince alors, comment ça se fait que j'arrive à hériter de tous les types de bases alors ? c'est pas très sérieux tout ça, tu ferais mieux de lire un peu et la documentation et les sources
[^]Re: IBM demande à Sun de "libérer" Java
Syntaxe utra-concise, Python est plus concis, pas à moitié-objet,Python est totalement objet.
Moi aussi je veux troller !!
Je suis pas un pro de la conception objet, mais un langage de prog objet, mais quand je lis ça :
There is limited support for class-private identifiers. [...] Note that the mangling rules are designed mostly to avoid accidents; it still is possible for a determined soul to access or modify a variable that is considered private.
Ba j'ai des doutes...
plus ce que disait Moby-Dik sur le self exoplicit...
En fait, quand tu regarde un peu la doc, tu te rends vite compte que le support des classes dans python, c'est un infâme bricolage degueulasse. Alors oui, c'est facile de coder en Python, on peut faire des progs vraiment bon (cf Zope) mais arrêtez de balancer a qui veut l'entendre que c'est un language totalement objet, c'est pas vrai à mon sens.
Pour finir sur les apport de Ruby, y'en a certe peu (et encore c'est relatif) mais ils sont de taille. Pour moi, rien que pour les code blocks, la gestion de la visibilité des méthodes et des variables d'instance, des getters/setters et de certains design patterns ça me suffit.
Garci
[^]Re: IBM demande à Sun de "libérer" Java
Je ne connais pas Ruby. Y a-t-il une (ou des) bibliothèques permettant de développer une interface graphique de facon relativement simple, et surtout portable (style tkinter)?
[^]Re: IBM demande à Sun de "libérer" Java
Faut se renseigner avant de dire des conneries ! ;-)
Python est orienté objet, mais n'est pas objet. Même les pythoneux les plus aguerris le savent...
[^]Re: IBM demande à Sun de "libérer" Java
OK, c'est assez critiquable en effet. Ceci dit , y'a de bonnes raisons à ça (ok il y en a toujours), et en pratique c'est pas si gênant.
Ça, c'est un gros problème, je te l'accorde.
Alors là oui mais non ! Cette méthode est bien plus élégante que toutes les autres méthodes qui nécessitent un formatage redondant (indentation + délimiteurs)
Bof, je vois pas en quoi c'est gênant.
Les globales ça sux, de toutes façons. La solution Pythonesque évite au moins qu'elles viennent pourrir l'espace de nommage de tes fonctions. J'aime mieux ça à PERL ou PHP où les variables sont globales par défaut.
Ben euh, non pas vraiment. Les types de bases aussi sont des objets (et ont parfois des méthodes)
En python aussi, on peut générer des itérateurs instantanément avec le mot-clé yield : )
(ceci dit, je ne nie pas que Ruby a l'air d'être un très bon langage aussi, mais je le connais peu)
[^]Re: IBM demande à Sun de "libérer" Java
> Alors là oui mais non ! Cette méthode est bien plus élégante que toutes les autres méthodes qui nécessitent un formatage redondant (indentation + délimiteurs)
sauf que quand tu fais du copier coller ça devient vite le bordel pour retrouver où commencent et finissent les blocs
[^]Re: IBM demande à Sun de "libérer" Java
Oui, c'est sûr, faut ajuster l'indentation après chaque collage.
[^]Re: IBM demande à Sun de "libérer" Java
> J'aime mieux ça à PERL ou PHP où les variables sont globales par défaut.
Les variables PHP sont *locales* par défaut. Pour utiliser une globale il faut le demander explicitement, aucune confusion ni aucune ambiguité n'est possible.
[^]Re: IBM demande à Sun de "libérer" Java
"C++ est un langage objet"
Non. C++ est un langage multi-paradigmes, il _peut_ etre objet, mais la partie généricité STL est loin d'être objet ...
[^]Re: IBM demande à Sun de "libérer" Java
il _peut_ etre objet
Arreter de jouer sur les mots, si tu avais pris la peine de me lire depuis le debut tu verrais qu'on pense exactement la meme chose.
De toute facon la notion d'objet, a mes yeux, n'est pas dependante du langage mais plutot de la facon dont le developpeur utilise les fonctionnalités du langage utilisé. Elles ne sont la que pour l'aider et formaliser syntaxiquement ce concept.
[+] [^]Re: IBM demande à Sun de "libérer" Java
Ouais, m'enfin faire tous les types de polymorphisme en assembleur, c'est quand même pas terrible par rapport à un langage qui les supporte :)
[^]Re: IBM demande à Sun de "libérer" Java
Violer est peut-être une notion un peu forte, foutre le bordel est plus exact.
Prends une classe A avec une methode m, tu la dérives en classe A1 et A2 dans lesquels tu surcharge m par respectivement m1 et m2.
Maintenant tu prends une clase B qui hérite à la fois de A1 et A2.
Tu commence à voir un peu le problème ...
Bon on y est, tu instancies B et tu fais appel à la méthode m.
C'est quelle version que tu vas executer?
Est-tu sûr que c'est celle que tu voulais?
En C++ cela dépend du compilo, si celui ci accepte l'héritage mutiple
En Java tu ne peux hériter que d'une classe et de plusieurs interface ce qui ne pose pas de problème vu que dans une interface toutes les méthodes sont abstraites.
En Eiffel, tu peux indiquer quelle version tu veux mais là on commence à dénaturer l'héritage.
Cela reste une différence de point de vue:
Pour le C++ c'est au programmeur à savoir programmer et tant pis pour lui s'il code comme un porc.
Pour Java, on considère que cela est source d'erreur donc on ne l'authorise pas
Pour Eiffel on laisse la possibilité mais avec des mécanismes de sécurité
Mais si tu veux vraiment du code élégant vaut mieux utiliser un langage fonctionnel :) (Qui a dit que cela sent le troll?)
[^]Re: IBM demande à Sun de "libérer" Java
OOOOOOOO Cam il est poilu ! ...
Ma signature ici
[^]Re: IBM demande à Sun de "libérer" Java
Ben oui, l'héritage multiple peut poser des problèmes de « diamant » si les développeurs / concepteurs se débrouillent mal, mais c'est pas pour ça que ça « viole » les concepts objet d'une quelconque manière.
[+] [^]
Effectivement.
[^]Re: IBM demande à Sun de "libérer" Java
Ah, ah, ah. Allez, je me lance dans le troll.
C++ plus joli, non mais franchement !! Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C avec les principes objet.
On va me dire que c'est au programmeur de coder proprement, de ne pas mélanger le C et le C++. Mais c'est justement là toute la différence entre un langage propre (et vous remarquerez que je n'ai pas cité Java) et un langage qui n'est qu'une rustine pour éviter aux gens pleins d'inertie d'apprendre une nouvelle syntaxe.
Parlant de Java, il présente un des problèmes qui me font bondir régulièrement quand on parle de langage à objets. D'ailleurs, je fais le distingo entre un langage à objet et un langage orienté objet (même si c'est un terme anglais mal traduit) : les types de bases.
Java et C++ sont des langages orientés objet parce que justement tout n'est pas objet (int, long et consorts), donc ils tendent vers la prog à objet mais n'y sont pas. Java est plus proche du but que C++ avec ces objets Integer, etc. et il possède au moins l'avantage d'avoir un objet de base Object, ce qui manque cruellement en C++ (pff). Et je parle même pas des templates en C++ sur lesquels je m'arrache les cheveux juste pour une pseudo généricité.
Un langage à objet est, par exemple, Eiffel. Il a ses défauts comme tous langage mais au moins, pas de questions pour savoir si on a objet ou non. Les conneries du style créer un objet à partir d'un int pour mettre ça dans un container de la lib standard me foutent hors de moi.
En bref, tous les langages ont leurs défauts et il serait bien d'arrêter dire Java, c'est nul, C++, c'est de la balle. D'une part, ça n'apporte pas grand chose, d'autre part, c'est vraiment très loin de la réalité. La qualité d'un langage ne se juge pas que sur sa rapidité d'exécution pure.
Bon, je me suis un peu défoulé, ça fait du bien.
[+] [^]Re: IBM demande à Sun de "libérer" Java
Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C
Mwaha ahahaha ! Le C, un « très bon » langage ?! :-D
[^]Re: IBM demande à Sun de "libérer" Java
C++ plus joli, non mais franchement !! Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C avec les principes objet.
Surtout qu'on peut très bien faire de "l'orienté" objet en C pur !
[+] [^]Re: IBM demande à Sun de "libérer" Java
Le c un un trés bon langage?
Faudrait voir à ne pas pousser mémé dans les orties là.
Un langage qui permet de créer un tableau de 10 éléments et d'aller taper allègrement dans le 15ième est un peu fonctionnellement déficient :)
Le c à des avantages (rapide, proche du système) mais ne reste qu'une surcouche à l'assembleur.
C'est à dire aucun mécanisme de sécurité et une factorisation du code proche de zero sans faire appel à tout un tas de mécanisme plus ou moins tordus.
[^]Re: IBM demande à Sun de "libérer" Java
AAAAh l'assembleur!!! Voila un langage pour les hommes, les VRAIS.
C'est le seul VRAI langage qui permet de TOUT faire!!!
Quand vous saurez réécrire MultideskOS en assembleur, là vous pourrez parler !!!
En attendant, arrêtez de racconter des conneries!
[^]Re: IBM demande à Sun de "libérer" Java
AAAAh l'assembleur!!! Voila un langage pour les hommes, les VRAIS.
euh non, l'assembleur c'est un langage pour les machines...
pù là --->[]
[^]Re: IBM demande à Sun de "libérer" Java
Nan, le langage pour les machine c'est justement le langage machine (une série de 0 et de 1 que seule une machine peut comprendre).
Ca, c'est pas un langage pour les hommes mais pour les Dieux!!!
[^]Re: IBM demande à Sun de "libérer" Java
00101110010111011000110101001
[^]Re: IBM demande à Sun de "libérer" Java
big endian, little endian ????????
[^]Re: IBM demande à Sun de "libérer" Java
gros boutiste, petit boutiste ????????
[^]Re: IBM demande à Sun de "libérer" Java
les oeufs je commence d'abord par les couper en 2 :)
[^]Re: IBM demande à Sun de "libérer" Java
Et tu les coupes en deux en commençant par le gros bout ou par le petit bout ?
[^]Re: IBM demande à Sun de "libérer" Java
Moi je les coupe en deux mais dans le sens de la hauteur, comme ca je suis pas embêté par le bout :)
[^]Re: IBM demande à Sun de "libérer" Java
Et Ada alors....
La généricité....
Un langage complétement portable au niveau source
Mais le problème d'Ada (mois c'est pour ca que j'adore) c'est qu'il ne permet pas de bricoler comme dans les autres langages.... Si on a pas bien réfléchi à ce que l'on code.... on code n'importe quoi et donc le compilo Ada nous le fait sentir....
Mais vaut-il mieux avoir des problèmes lors de la compilation ou lors de l'éxécution ?
Moi quand j'ai Java qui se plante de façon aléatoire ou un prog en C qui me fait un segmentation fault ca m'énerve plus que de débugguer mon programme lors du codage (Les problèmes relevés par les compilateurs sont toujours à prendre aux sérieux.... )
[^]Re: IBM demande à Sun de "libérer" Java
L'ada a quand même quelques défauts:
- On n'a pas à s'embeter avec les pointeurs et c'est dur pour les gens qui ont appris à pisser du C.
- La norme, n'inclus pas les sockets réseaux.
- L'instruction use pour les packages est a ne pas utiliser.
- L'execution des programmes est plus lent qu'en C, mais c'est normal, car il verifie les indices de boucles, tableau, etc... ainsi que d'autres choses. Ce qui à l'avantage d'eviter des buffer overflow. Enfin tans que tu n'utilises pas #pragma supress all_cheks.
- Mais surtout son gros problémes, c'est ça philosophie et si tu ne l'as pas apprise en même temps, tu ne pourra pas l'utiliser correctement.
Par contre, il a de nombreux avantages:
- Faciliter de relecture si la personne qui a codé n'a pas fait trop de connerie.
- C'est une norme (contrairement à d'autres langages normés, on trouve facilement la nrome sur internet)
- Il y a de l'objet pour ceux qui veulent à tous pris en faire, mais c'est souvent plus simple de faire un package.
- On ne s'emmerde pas avec les pointeurs
Et plein d'autre encore que j'oublie.
\_°< C01N C01N ! >°_/
[+] [^]Re: IBM demande à Sun de "libérer" Java
Je me lance aussi :)
« On va me dire que c'est au programmeur de coder proprement, de ne pas mélanger le C et le C++. Mais c'est justement là toute la différence entre un langage propre et un langage qui n'est qu'une rustine pour éviter aux gens pleins d'inertie d'apprendre une nouvelle syntaxe. »
Il suffit de connaître son langage, et il n'y a pas besoin de connaître C pour connaître le C++. Et vu la syntaxe de C++, il est clair que le but n'est pas de faciliter la transitions aux développeurs C.
« Java est plus proche du but que C++ avec ces objets Integer, etc. et il possède au moins l'avantage d'avoir un objet de base Object, ce qui manque cruellement en C++ (pff). Et je parle même pas des templates en C++ sur lesquels je m'arrache les cheveux juste pour une pseudo généricité. »
Ah, la classe Object, un des trucs les plus dégueulasses jamais réalisés. Heureusement Java reconnaît son erreur et va admettre des templates dans la prochaine version. Faire du générique sans support, c'est quand même aussi crade que de l'objet sans support du langage (comme de l'objet en C)
« En bref, tous les langages ont leurs défauts et il serait bien d'arrêter dire Java, c'est nul, C++, c'est de la balle. »
Ce n'est pas aussi simple. Le problème c'est que Java a trop de limitations (volontaires) censées simplifier, mais qui *manquent* vraiment. Java m'a longtemps paru meilleur, mais finalement C++ est un meilleur investissement. Par contre, il est clair qu'il faut très bien le connaître, et que son apprentissage est nettement plus long.
[^]Re: IBM demande à Sun de "libérer" Java
> Ah, la classe Object, un des trucs les plus dégueulasses jamais réalisés.
Va falloir m'expliquer là. Parce que dans un langage à objet, il est quand même bien d'avoir un objet de base qui permette d'avoir un contenant universel.
> Heureusement Java reconnaît son erreur et va admettre des templates dans la prochaine version.
Quel est le rapport entre les templates et la classe Object ??? Les templates vont amener une certaine généricité (je ne suis pas encore assez au courant pour savoir si elle pourra être contrainte) mais si c'est à la C++, je préfère me tirer une baste tout de suite. :p
> Par contre, il est clair qu'il faut très bien le connaître, et que son apprentissage est nettement plus long.
Ca doit faire maintenant 7 ans que je me paluche du C++ et du Java dans mon taf et, franchement, mon avis est moins tranché que le tien entre Java et C++. Et j'en ai suffisament soupé des limites de C++ pour avoir un doute quant au terme "meilleur" investissement. En tous cas, concernant les concepts objet, ces deux-là sont loin derrière Eiffel à mon humble avis. ;)
[+] [^]Re: IBM demande à Sun de "libérer" Java
« Va falloir m'expliquer là. Parce que dans un langage à objet, il est quand même bien d'avoir un objet de base qui permette d'avoir un contenant universel. »
J'aurais dû préciser. Je n'en vois pas le besoin mais pourquoi pas. Par contre, quand c'est la seule solution pour remplacer des templates, c'est très crade. Mais des cas où c'est utile, oui je veux bien croire, ça doit exister... quoique ça paraît étrange sur un schéma de conception.
« Quel est le rapport entre les templates et la classe Object ??? Les templates vont amener une certaine généricité (je ne suis pas encore assez au courant pour savoir si elle pourra être contrainte) mais si c'est à la C++, je préfère me tirer une baste tout de suite. :p »
La syntaxe sera pourtant inspirée de celle de C++. Qu'est-ce qui ne te convient pas ? Moi ça me paraît plutot aberrant qu'un langage qui se veut assez généraliste n'en propose pas.
« Ca doit faire maintenant 7 ans que je me paluche du C++ et du Java dans mon taf et, franchement, mon avis est moins tranché que le tien entre Java et C++. Et j'en ai suffisament soupé des limites de C++ pour avoir un doute quant au terme "meilleur" investissement. »
Je vois surtout des limites dans Java. D'ailleurs, c'est ce qu'on reproche à C++ : ne pas en mettre assez (de limites). Ce n'est pas une mauvaise chose de mettre des limites, mais je trouve que Java les a mal placées.
« En tous cas, concernant les concepts objet, ces deux-là sont loin derrière Eiffel à mon humble avis. ;) »
On est d'accord. Mais au moins C++ n'a pas la prétention d'être un langage tout-objet, juste de supporter un minimum de POO (ce qu'il fait mieux que Java: fonctions non virtuelles, héritage multiple, etc.)
[^]Re: IBM demande à Sun de "libérer" Java
> La syntaxe sera pourtant inspirée de celle de C++. Qu'est-ce qui ne te convient pas ? Moi ça me paraît plutot aberrant qu'un langage qui se veut assez généraliste n'en propose pas.
En fait peu m'importe la syntaxe. Et, oui, un langage généraliste devrait avoir de la généricité. Il devrait aussi avoir une gestion des droits d'accès bcp plus précise que private/protected/public/default (déjà 10 ans que Eiffel a les deux !).
Par contre, j'ai bcp de mal à dire templates==généricité. En fait mon problème avec le templates est cette différence : template <int valeur> et template<class nom>. Même syntaxe, comportement à l'opposé. Surtout que, d'après moi, la première n'apporte "pas grand chose" par rapport à un constructeur à paramètre si ce n'est que ça a l'avantage d'être un typage plus fort. Mais je crois que je me suis braqué à un moment à force de me prendre la tête. ;)
> mieux que Java: fonctions non virtuelles.
Euh, c'est pas un peu le but de final ?
A tout prendre, je préfère largement "les fonctions virtuelles" (lire "la liaison dynamique") par défaut, c'est bcp plus proche du raisonnement humain à mon avis. De plus, je trouve plus simple de dire quand la liaison dynamique doit s'arrêter que de dire tout le tps qu'elle doit avoir lieu.
Mais on en revient tjs à une question de goût vis à vis des langages. La majorité apporte de bonnes choses et trainent qq casseroles. Le tout, c'est de choisir celui qui en trainent le moins pour le projet en cours.
[^]Re: IBM demande à Sun de "libérer" Java
A tout prendre, je préfère largement "les fonctions virtuelles" (lire "la liaison dynamique") par défaut, c'est bcp plus proche du raisonnement humain à mon avis. De plus, je trouve plus simple de dire quand la liaison dynamique doit s'arrêter que de dire tout le tps qu'elle doit avoir lieu
Parfaitement d'accord, d'autant qu'un bon compilateur (cf smalleiffel) est capable d'enlever lui-même l'aspect "virtuel" quand il peut démonntrer (si, si, il s'agit d'une preuve) qu'il n'en n'aura pas besoin à l'exécution. Mais bon, dès que quelqu'un te dit que les virtuels du C++ c'est super pour l'optimisation, tu dois détecter qu'il a dix ans de retard sur l'état de l'art en compilation des langages objets (et encore, 10 ans, je minimise). Les virtuels, c'est la plus grosse connerie du C++ avec l'absence de GC.
[^]Re: IBM demande à Sun de "libérer" Java
« Par contre, j'ai bcp de mal à dire templates==généricité. »
Je n'ai rien contre ce que tu dis ensuite, mais je ne vois pas en quoi ça joue... Je trouve qu'il manque ce type de polymorphisme à Java, et l'appréciant en C++, ça me semble un vrai manque. Ca me parait vraiment une bonne chose que ça arrive en Java. Pour tout ce qui est conteneurs, ce que propose Java est quand même ridicule par rapport à la STL à cause de ça, non ?
« Euh, c'est pas un peu le but de final ? »
« final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
Maintenant pour ce qui est de la valeur par défaut, personnellement ça ne me dérange pas, mais en effet si je devais en choisir un, je choisirais plutôt comme Java : virtuel par défaut. Et on préciserait les choses avec un mot clé nonvirtual. Mais je parla