Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C++ Abondonné ? et puis quoi encore ? : JAMAISEnvoyé par aliasjcdenton
A mon avis le scénario le plus probable est que le développement JAVA sous les plateformes Windows soit "phagocyté" par le .Net surtout, entre autres, avec l'emergence des produits MS très innovants et fortement interfacés aux dev .Net (Share point - BI - Office ...)
En ce qui concerne C++, je ne pense pas qu'il existe, à ce jour, un langage digne de le remplacer.
C était déjà beau puis amélioré en C++, ce dernier est l'un des plus beaux langages existant, les autres n'apportent qu'un soi-disant facilité comme GARBAGE COLLECTOR, MANAGED (dotnet) et "pas de pointeur"
L'avenir de C++ est encore merveilleux, surtout avec des gens comme moi pour le promouvoir
Concernant Java, je crains aussi que DOTNET l'écrasera bien que les deux sont presque égaux. Aujourd'hui, le dotnet commence à avoir la même part de marché que java alors qu'il n'a même pas 10 ans
J'ai adoré Java mais en plus des trucs .NET aujourd'hui, je m'y perd (quoi choisir JAVA ou C# alors que je suis sous Windows à 95% du temps) et je préfère m'attacher à C++.
randriano.dvp.com
Développeur. Product Owner [Agile]. Sites web, mobile apps, système d'information (SI).
En vrac :
Il y avait déja des livres sur dotnet notamment sur C# en 1998-1999...je m'en souviens car à l'époque je commençais et en face de moi j'avais un livre Visual Studio 6.0 et un autre développement C# à ... Auchan. J'imagine qu'avant cela on trouvait déja des choses (même si officiellement c'est en 2000 je crois que le framework 1.0 est sorti). Puis c'est un combat de titans entre sun/ibm vs ms sans oublier que pour sun java ce n'est pas le produit phare de la maison (c'est justement pour piquer des parts de marché à ms)alors que dotnet oui c'est un produit phare de ms.
Bref, pour ma part je trouve Java beaucoup plus nette à écrire que le C++ d'aujourd'hui(j'attends impatiemment c++0x).
Explications :
C++ est trop concentré sur des spécificités liés aux concepts même du langage, qui sont une perte de temps et sans interet je trouve, et qui nécessite donc de connaître le langage dans les moindres détails pour ne pas faire de dégats. Un exemple basic c'est le constructeur par recopie un concept propre au C++ qui n'est pas du tout révolutionnaire en soit mais qui va de pair avec le langage.
Java en standard c'est aussi des éléments graphiques tandis qu'en C++ il faut passer par une bibliothéque tierce donc on change de style de programmation d'une bibliothéque à l'autre ce qui est relativement contraignant.
Cependant, avec tout cela, je pense que C++ n'est pas prêt de disparaître et Java aussi.
On est obligé de passer par une bibliothèque tierce en C++ pour la bonne raison que C++ dépend de l'OS tandis que Java se veut multiplateforme et proposer une couche d'abstraction.
Mais quand il s'agit de faire des graphismes double-tamponnage ( "double buffer" ) Java c'est pas génialet je préfère faire cela avec mes CreateCompatibleDC du gdi32
Connais-tu le langage D ? Mon avis est qu'il peut avantageusement remplacer C++ dans 90% des cas. Bien sûr, ce n'est que mon avis...
Tu peux argumenter ?
J'aimerais surtout que tu m'expliques pourquoi il n'a depuis le temps pas de succès ?
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Par ces temps de crise c'est surtout un dérivé qui marche bien : le système D
L'utilisation de bibliotheques C en D est chiante, et encore pire pour du C++.
Il n'y a pas d'IDE valable, meme si il y a quelques trucs bien (je ne compte pas vim et emacs hein)
pas de compilo sur toute les plates formes
En revanche, D a quelques avantages certains par rapport au C++
deja, les templates fonctionnent sur des chaines litterales, ce qui permet de compiler tes propres regexp en statiques ou ce genre de chose (de meme avec les flottants)
la syntaxe des templates a été revue pour plus de lisibilité
en théorie c'est juste mieux, mais comme en pratique c'est incompatible, les gens s'en sont sans doute detournés
Il y a un biais dans la question, les qualités d'un langages seul ne suffisent pas à garantir un succès.
Je pourrais te l'expliquer si je savais ce qui fait le succès d'un langage. Or je crains que personne ne le sache vraiment.
Mais je pense que l'un des problèmes du langage D est qu'il est en constante évolution et développé par UN seul homme qui n'a pas l'intention d'abandonner la charge, ni du langage, ni des librairies (jusqu'à il y a peu, A. Alexandrescu, l'auteur de "Modern C++ Design", s'est joint au design du langage et des librairies). Cela n'incite pas des sociétés commerciales à lancer le développement d'un environnement de développement professionnel autour du langage.
Ceci étant, malgré cela, la popularité du langage est en croissance (http://www.tiobe.com/index.php/paperinfo/tpci/D.html), 12e entre Ruby et PL/SQL au classement Tiobe , ce qui est assez remarquable, même s'il n'atteint pas encore la masse critique nécessaire pour être un acteur majeur dans le domaine des langages système.
Quand à la supériorité de D sur C++, je pense qu'il ne permet pas de faire plus de choses que C++. P-ê même que D est légèrement moins universel que C++ (d'où mon 90%, mais ça reste à démontrer). Mais ce qui est certains, c'est que les 90% en question peuvent être réalisées de façon nettement plus simple, plus rigoureuse et plus sûre qu'en C++. Ce simple tableau est assez éloquent: http://www.digitalmars.com/d/2.0/comparison.html (en particulier les commentaires agrémentés d'exemples, il suffit de suivre les liens). La syntaxe des programmes D est bcp plus régulière et lisible que C++ (en fait d'une lisibilité comparable à Java). Mais surtout, le langage est développé et implémenté par qq qui connait intimement le C++, ses qualités et ses défauts, puisque ça fait 15 ans qu'il développe aussi des compilos C++ (en fait, le back-end du compilo C++ et de D sont le même).
En ce qui concerne les templates, les deux apports majeurs de D sont le static if et les expressions is (même si Boost a bien amélioré les choses du coté de C++).
Mais encore une fois, la qualité d'un langage ne fait pas son succès. Il y a des tas et des tas d'autres paramètres à prendre en compte,sur lesquels D est sans doute déficient. Sinon, Java n'aurait pas autant de succès.
@FloMo
Je pense que tu as une vision assez erronée du développement d'interfaces graphiques en JAVA.Quand je construit mon interface, de préférence, je n'ai pas envie de me retaper toutes les routines de dessins et suivre les guidelines des OS pour construire mes interfaces.
Au delà de l'aspect graphique des GUI, il est essentiel d'avoir une bonne ergonomie et donc une bonne intégration dans l'environnement ciblé. Le problème avec les interfaces Java est justement qu'elles sont reconnaissables car elles brisent l'ergonomie. (tout comme Gtk sous Windows par exemple) A contrario, les applications réalisées avec .Net, l'API Windows, Gtk sous Linux, Cocoa sous Mac et Qt sur chacune des plateformes s'intègrent parfaitement dans l'environnement.
Même si tout n'est pas parfait, on est loin de l'horreur que tu décris, et qui pourrait induire en erreur les gens qui te lisent.
Je me base sur les logiciels que je connais en Java, à savoir Gantt Project, Eclipse et Vuze (Azureus) qui se distinguent visuellement de Skype, Firefox, Filezilla...
Ensuite, c'est surtout le rapport entre facilité de création et résultat que Java me pose quelques soucis. Après, c'est une question de point de vue et cela reste un débat.
De prime abord, tu dois te dire que n'importe quel langage ayant eu une certaine "notabilité" (car on peut parler aussi bien de C++ et de Java, que de COBOL, de C, ou de Ada) n'a aucune chance de disparaitre dans un avenir "proche"...
La raison est bien simple: après quelques années de dev avec ces langages, les lignes de code se comptent par... millions, parfois dans une seule boite, et dont l'écriture s'est échelonnée sur... plusieurs années (décennies).
Dés lors, il devient bien souvent plus intéressant de payer "cher et vilain" la "perle rare" qui connait encore le langage pour qu'elle (la perle) écrive trois lignes de code par semaine que de devoir payer une équipe complète pour... porter tout ce code vers un autre langage.
Le résultat le plus visible, c'est sans doute qu'un langage finit par occuper "une niche" particulière (je pense à COBOL qui est encore énormément utilisé dans le domaine de la finance et des assurances, par exemple), mais il se fait que tant Java que C++ sont "suffisamment génériques" (dans le sens où ils sont adaptés à de nombreuses situations différentes) pour éviter de finir dans une niche particulière.
De plus, ces deux langages en particuliers évoluent quasi continuellement (la nouvelle norme C++ est sur le point de sortir, et java suit son "petit bonhomme de chemin"), ce qui est de nature à leur ouvrir de nouvelles horizons.
Le jour où il n'y aura plus d'évolution de la part de ces langages (et m'est avis que cela ne va pas arriver de si-tôt), il ne sera pas exclu que l'on assiste à une "raréfaction" des développements, mais il faudra encore compter quelques décennies avant de pouvoir dire que le langage est abandonné même par la dernière niche particulière qui l'utilisera
A méditer: La solution la plus simple est toujours la moins compliquée
je ne suis que partiellement d'accord avec cela, il faut savoir qu'avec les machines virtuelles multi-langages (comme la .Net), il arrive de grosses entreprises utilisent encore leurs vieux modules (en Cobol par exemple), mais que toutes les parties modernes soient dans un langage plus récent / plus à la mode / plus "rentable", et que dans ces conditions, la transition peut être faite module par module... ce qui explique parfois la boulémie en stage long de certains (codeurs pas chers)
C'est également assez répandu sur les environnements mainframe. L'IHM est codé en Java EE avec Websphere d'IBM et les procédures métiers sont encore en COBOL (et donc aussi déployé sous z/OS d'IBM).
Surtout qu'IBM a bien fourni ses API Java pour faire ça...
C'est la raison principale, c'est vrai...La raison est bien simple: après quelques années de dev avec ces langages, les lignes de code se comptent par... millions, parfois dans une seule boite, et dont l'écriture s'est échelonnée sur... plusieurs années (décennies
Vous négligez un argument de taille : la fiabilité....je ne suis que partiellement d'accord avec cela, il faut savoir qu'avec les machines virtuelles multi-langages (comme la .Net), il arrive de grosses entreprises utilisent encore leurs vieux modules (en Cobol par exemple), mais que toutes les parties modernes soient dans un langage plus récent / plus à la mode / plus "rentable", et que dans ces conditions, la transition peut être faite module par module... ce qui explique parfois la boulémie en stage long de certains (codeurs pas chers
Les bibliothèques mathématiques du CERN, pas exemple, sont toujours en Fortran (certaines parties encore en Fortran 77, et qui évoluent petit à petit).
C'est juste que à 25 millions de lignes testées et débuggées depuis 40 ans, et utilisées à travers le monde, difficile de garantir une telle fiabilité une fois la ré-écriture et/ou trqnsformation dans un autre langage faite...
Un très bon lien à ce sujet :
Rewrite considered harmful
Je fais un peu de HS mais dans ce cas précis pourquoi vouloir porter le code c.a.d de COBOL vers un autre langage ?
Si ça marche sur des roulettes sous COBOL pourquoi porter du code sous Java ou .NET ?
Pourquoi chambouler ce qu'on a mis des années à pérenniser ?
Je n'en vois pas l'intérêt en plus COBOL s'integre sans doute parfaitement avec les grands systèmes ( je vous dis tout de suite je n'y connais rien en COBOL ).
Et puis Java et .NET coté transactionnel c'est pas forcément adapté parce que c'est trop lourd pour tourner sur MainFRame...
Désolé de remonter un HS...
Le fait est que, ce n'est pas parce que l'on dispose de 10, 15 ou même 50 ans de recul avec un langage que l'on a *forcément* la réponse à tous les problèmes qui sont susceptibles de se présenter...Je fais un peu de HS mais dans ce cas précis pourquoi vouloir porter le code c.a.d de COBOL vers un autre langage ?
Si ça marche sur des roulettes sous COBOL pourquoi porter du code sous Java ou .NET ?
Pourquoi chambouler ce qu'on a mis des années à pérenniser ?
Je n'en vois pas l'intérêt en plus COBOL s'integre sans doute parfaitement avec les grands systèmes ( je vous dis tout de suite je n'y connais rien en COBOL ).
Et puis Java et .NET coté transactionnel c'est pas forcément adapté parce que c'est trop lourd pour tourner sur MainFRame...
Comme, malgré tout, les années de développement sont une "base de connaissance" qu'il ne faut pas négliger (Ah oui, pour telle partie, j'ai déjà quelque chose dans la manche
C'est pour cela que je disais que de nombreuses boites préfèrent se "garder" sous le coude un type, payé cher et vilain, qui connait le langage "matusaleméen" historiquement utilisé (et des stagiaires payés des cacahuètes pour ce qui peut être fait dans les autres langages, histoire de "rétablir l'équilibre"
Je comprends pas qu'il y ait encore des gens sur ce forum pour tenter d'argumenter avec les fanboys du C++...
Ca ressemble à un troll, mais vu l'acharnement et la mauvaise foi de certains, je ne pense pas que ça en soit un.
Le C++ a encore de beaux jours devant lui, puisque la machine virtuelle de java est écrit en C++!
Répondre avec citation
Partager