[Débat] C++ vs Java

[rimram31]

Envoyé par Luc Hermitte

La main-mise à laquelle je faisais allusion o. Un des meilleurs en termes d'optimisation même pour le C++. Est-ce que s'engager vers la voie C++ aurait été faire le jeu de microsoft ? Je n'en suis pas sûr.

La question, il faut la poser a James Gosling (http://en.wikipedia.org/wiki/Oak_%28...ng_language%29) qui a inventé un nouveau langage parce que le C++ ne répondait pas a ses besoins. Ne pas oublier que le C++ n'est que la conséquence des besoins de l'époque de POO dont l'approche existait bien avant lui (et je m'y étais essayé en C ...). Force est de constater que le C++ n'a pas satisfait les attentes de l'époque, sinon, Java n'aurait jamais existé.

[Luc Hermitte]

Je ne parle pas d'une personne qui pond un nouveau langage (il y en a à la pelle, et ça tous les jours), mais d'une société qui investit de façon conséquente dans un nouveau langage et non dans le procédé de standardisation d'un langage international d'une certaine façon (comme le I de ISO l'indique).

[rimram31]

Envoyé par Luc Hermitte

Je ne parle pas d'une personne qui pond un nouveau langage (il y en a à la pelle, et ça tous les jours), mais d'une société qui investit de façon conséquente dans un nouveau langage et non dans le procédé de standardisation d'un langage international d'une certaine façon (comme le I de ISO l'indique).

Tu m'as mal lu ou alors je me suis mal exprimé. J'écrivais que les raisons qui ont fait que l'équipe de Sun a travaillé sur une autre approche avaient du sens au delà de leur simple projet. Oak a d'ailleurs été abandonné, mais repris pour un autre projet chez Sun autour du web, ce n'est qu'à ce moment là que les "dirigeants" de Sun (qui se trouvaient être aussi très techniques ...) ont vu le potentiel de la technologie et décidé de la pousser.

J'ai évalué pour la première fois Java, il venait de passer en 1.0.2 (), donc dans les années 96/97 je suppose, je peux te dire qu'a l'époque c'était bien timide et même "gadget". C'est bien parce que Java a eu du succès, trouvant application au delà des plans initiaux de Sun qu'il est devenu ce qu'il est et que Sun a investi de plus en plus.

[alexrtz]

Envoyé par souviron34

quand ça n'était pas l'ouvrir tout simplement : Linus Torwald a créé Linux parce que de 93 à 95 m$ ne livrait que des machines soudées, où on ne pouvait accèder à rien de l'interne

Linus Torvalds a commencé à écrire Freax (qui deviendra Linux) en 1991 comme un passe-temps pour comprendre comment fonctionnait sa machine.

Il a effectivement acheté une machine en pièces détachées mais il faisait déjà tourner un OS dessus (Minix).

[Nemek]

Le JCP a tout de même son gros effet pervers : le lobbying.

Jusqu'à récemment, il n'était constitué que d'industriel qui crééait surtout des JSRs pour mettre en avant leur propre produit. Car il y a une chose qui très forte mais qui créé tout le lobbying, toute JSR doit être accompagnée d'une implémentation.
On en veut pour preuve le problème avec Jigsaw/OSGi, Closure/Lamba Expression/etc, ou même l'API de cache de Red Hat...

Ensuite avoir un comité de pilotage implique une forte lenteur des changements puisqu'il faut que la moitié des membres aillent dans le même sens. Le langage n'évolue pas énormément, malgré toute l'envie qu'il y a de toute part (utilisateurs, JUG leaders, industriels, etc.). On voit bien de nouvelles fonctionnalités s'ajouter mais peu de choses en place qui évolue.

Un autre point noir pour Java et une des fameuses règles qui finira sûrement par tuer Java si elle n'est pas brisée d'ici les 2-3 prochaines versions majeurs : la rétrocompatibilité binaire. La règle qui tue tout, comme avoir des génériques uniquement "compile-time". Aucun intérêt puisque la compatibilité de l'API n'est pas garantie.

Concernant l'investissement de Sun dans Java, il ne faut pas oublié qu'une part importante des développeurs et des technologies intégrés dans Java ne sont pas de Sun mais d'Apache, IBM, Xerox, Red Hat et autres.


Aujourd'hui la seule force de Java c'est d'avoir été là et relativement bon avec une courbe d'apprentissage très rapide au moment de la bulle Internet. Tout comme COBOL dans les années 70-80. Franchement, il y a un paquet de langage que je préfère à Java. Cependant Java n'a aucune niche, donc il est voué à mourir s'il ne se met pas au niveau de langage plus évolué. Ou alors l'avenir se jouera sur des langages alternatifs comme Groovy et Scala. Comme C# l'a été pour la plateforme Microsoft en remplacement de VB et C++.

[jabbounet]

En parlant de jsr, a une époque j'ai bossé sur la validation d'une implémentation faite par un client de la jsr-043 (il y'a 2 ans environ), nous n'avions pas accès au code juste à l'api ainsi que la doc de l'api.

Cette jsr en particulier c'est un beau paquet de nouille, (je ne sais pas si les autres jsr sont comme ça, il y'en a certainement qui sont claire et bien faite)

par exemple à certains endroit il y'a de jolies contradictions sur les comportements de l'api qui font que le système pouvait selon les interprétation se retrouver dans des états différent pour un même use case (selon l'interprétation de l'importance de certaines règles par rapport à d'autres).

je ne compte pas non plus les points trop vagues qui fait que parfois ou ne peut pas savoir ce que fait l'api, par exemple dans certaines fonctionnalités type conférence/renvoi d'appel, il n'etait simplement pas possible de savoir ce qu'il se passe pour l'appel si le correspondant n’était pas joignable....

je pense que pour toute normalisation, quelque soit le langage, il est important d'avoir de bon comité de relecture et de bien suivre les cycles de type auteur/lecteur, d'avoir des gens avec un peu de bouteille dans le domaine et de vérifier que les chose sont réalisable sans ambiguïtés (ce n'est pas forcément simple, mais bon)

[rimram31]

Envoyé par Nemek

Le JCP a tout de même son gros effet pervers : le lobbying.

Il en a un autre, celui de nous pondre des usines a gaz, d'où les échecs relatifs des EJB par exemple (vs les ORM). On peut constater que la dynamique initiale de Java qui se voulait "simple" ait pris sérieusement du plomb dans l'aile.

Envoyé par Nemek

Aujourd'hui la seule force de Java c'est d'avoir été là et relativement bon avec une courbe d'apprentissage très rapide au moment de la bulle Internet.

Pas d'accord :-), d'où mon commentaire plus haut, il avait des caractéristiques ou au minimum des objectifs qui répondaient aux besoins de l'internet client et serveur: sécurité, portabilité ... portabilité qui couvraient des besoins bien plus riches que les autres langages de l'époque (UI, couche http par exemple)

Envoyé par Nemek

... Java n'a aucune niche, donc il est voué à mourir s'il ne se met pas au niveau ...

Pas tout a fait d'accord ... je ne pense pas que Java, pas plus que le C aujourd'hui par exemple, disparaisse. Par contre, tout comme le C, il sera utilisé pour des besoins précis, ceux proches de l'architecture web par exemple.

Ca rejoint finalement ce que tu dis, dans quelques temps, on aura a disposition un ensemble d'outils, de composants ... codés "en usine" en java (ou autre!) que l'on utilisera avec d'autres langages "de glue". Plus l'informatique avance et plus elle devient un métier d'assemblage que de construction "from scratch" suivant une évolution similaire a celle qu'a pu connaître l'électronique il y a quelques années où on fait d'abord son marché de composants plus que de concevoir son typo et aller acheter du perchlorure de fer

[Nemek]

Envoyé par jabbounet

je pense que pour toute normalisation, quelque soit le langage, il est important d'avoir de bon comité de relecture et de bien suivre les cycles de type auteur/lecteur, d'avoir des gens avec un peu de bouteille dans le domaine et de vérifier que les chose sont réalisable sans ambiguïtés (ce n'est pas forcément simple, mais bon)

Je ne sais pas si c'était le cas à l'époque de cette activité mais en tout cas désormais tout le monde peut être relecteur / critique / auteur / etc sur une JSR. Le problème c'est qu'il faut arriver avant la finalisation du draft. Sinon je ne sais pas s'il est possible à n'importe qui d'initialiser une nouvelle version mais tu peux toujours proposer ;-)

Envoyé par rimram31

Il en a un autre, celui de nous pondre des usines a gaz, d'où les échecs relatifs des EJB par exemple (vs les ORM). On peut constater que la dynamique initiale de Java qui se voulait "simple" ait pris sérieusement du plomb dans l'aile.

Les EJBs s'améliorent de version en version. Cependant je n'ai jamais trop pratiqué mais je me souvient bien d'un TP où on a passé 4h à essayer de créer un descripteur de déploiement avec l'interface Swing ... Un cauchemar.

Envoyé par rimram31

Pas d'accord :-), d'où mon commentaire plus haut, il avait des caractéristiques ou au minimum des objectifs qui répondaient aux besoins de l'internet client et serveur: sécurité, portabilité ... portabilité qui couvraient des besoins bien plus riches que les autres langages de l'époque (UI, couche http par exemple)

Je vois pas trop en quoi avoir une couche serveur (HTTP, FTP ou n'importe quoi) de portable soit un réel avantage stratégique. Les serveurs sont toujours installés sur des environnements similaires voir exactement identiques.
En revanche, j'admet que d'avoir une API standard aide bien. C'est d'ailleurs le premier truc qui m'avait attiré vers Java. Mais ca rejoint l'idée de la "coube d'apprentissage", tu apprends le langage et son API et "tu sais tout".
Pour le "à l'époque", je ne saurais dire, j'ai commencé à apprendre Java qu'en 2003. Et n'ai commencé à l'utiliser de manière industrielle qu'en 2008 pour de l'embarqué et en 2009 pour du web.

Envoyé par rimram31

Pas tout a fait d'accord ... je ne pense pas que Java, pas plus que le C aujourd'hui par exemple, disparaisse. Par contre, tout comme le C, il sera utilisé pour des besoins précis, ceux proches de l'architecture web par exemple.

Disparaître non mais mourir si, tout comme le COBOL.
En gros il sera remplacé au fur et à mesure par une autre technologie, type Ruby. Java n'offre vraiment rien de particulier.

Aujourd'hui Java ne doit sa vie qu'à la masse de projet en maintenance, qui fait que la compétence est fortement maintenue et donc également indispensable pour les nouveaux projets. C'est un cercle vertueux mais qui finira sûrement pas s'éteindre si on ne met pas de nouvelles bûches dans le feu.
C'est pourquoi je crois que l'avenir de Java se joue dans les langages alternatifs (particulièrement Scala) et une rupture de la rétrocompatibilité (genre Java 9 incompatible avec les précédentes mais Java 10 compatible avec la précédente).

[souviron34]

Envoyé par Nemek

En revanche, j'admet que d'avoir une API standard aide bien. C'est d'ailleurs le premier truc qui m'avait attiré vers Java. Mais ca rejoint l'idée de la "coube d'apprentissage", tu apprends le langage et son API et "tu sais tout".

C'est surtout que c'était le but initial

Au départ, comme déjà mentionné, ce n'était pas fait pour faire autre chose que des API standards, pour pallier au refus par M$ d'implémenter X11...

[rimram31]

Envoyé par Nemek

... Je vois pas trop en quoi avoir une couche serveur (HTTP, FTP ou n'importe quoi) de portable soit un réel avantage stratégique...

Ben il faut regarder ce qu'offrait un JDK, je ne sais pas aujourd'hui, mais au début des années 2000, avoir l'équivalent dans une autre techno demandait d'y ajouter une bonne douzaine de librairies supplémentaires qui n'auraient pas été les mêmes selon les environnements: ici HP, là bas Sun, encore ailleurs IBM ou tartampion ... et tout ça parfois pour gérer une simple liste. Tu y ajoutes le JSDK pour le serveur web, JDBC, le support du multi threading et tu avais "tout ce dont on peut avoir besoin" pour faire du développement serveur. Je me souviens avoir codé un serveur multi clients à l'époque en moins d'une journée, inimaginable a l'époque dans un autre langage.

Je m'aperçois d'ailleurs, ne faisant plus trop de java, que c'est encore le cas aujourd'hui dans d'autres technos où tu as dix mille façons différentes de faire la même chose et qui marchent pas toujours selon l'environnement.