Version imprimable
[EDIT 3DArchi] : fork de la discussion Le langage D sur cet aspect particulier : Le C++ est-il adapté pour le WEB ? [/EDIT -EDArchi]
Enfin c'est vrai que le gros manque (enfin perso ça me manque pas du tout ^^) de C++ face à java et C# c'est qu'il est pas du tout tournée vers le développement web, or c'est vrai que tout tends vers ça aujourd'hui... (même les jeux justement, comme quake par exemple).
En quoi le C++ n'est-il pas tourné vers le Web ?Citation:
Envoyé par Goten
C'est plus un problème de bibliothèque que de langage, non ?
Merci pour vos réactions, c'est intéressant ;).
Le C et le C++ ne sont pas trop tournés vers l'interface, le web en est un aspect...
Francois
Moi je parlais en comparaison de asp ou autre techno web du framework .NET ;).
A part deux ou trois librairies CGI il faut bien reconnaître que le C++ n'offre pas grand chose dans le développement web si on le compare par exemple à Java ou .Net qui proposent des frameworks à base de composants gérant la majeure partie des problèmes liés au session et à AJAX.Citation:
Envoyé par Florian Goo
Est-ce que c'est juste une histoire de biliothèque? Pas à 100% car la majorité des frameworks de présentation à base de MVC utilisent la réflexion qui n'est pas facilement disponible en C++, je dis pas qu'il est impossible de s'y prendre autrement mais c'est un élément, tout comme la capacité d'un serveur d'application écrit en java à charger dynamiquement, de façon sûre et aisée une autre application java pour servir des requêtes sans laisser les éventuels fautes de celle-ci le faire tomber.
Je dirai qu'en général, le C++ n'était pas vraiment idéal pour tout ce qui est application de gestion en fait, vous connaissez beaucoup d'ORM digne de ce nom en c++? Non? Peut être encore une fois l'absence de la réflexion dans le langage?
Il y a-t-il besoin d'avoir 50 frameworks ? Le nombre important n'est-il pas le signe qu'aucun n'en vaille la peine ?
Accessoirement, il est à noter les existences de :
- Wt: http://www.webtoolkit.eu/wt
- Cpp CMS: http://cppcms.sourceforge.net/wikipp/en/page/main
Quant au MVC, dans certains frameworks chez les voisins qui on le vent en poupe comme GXT, je le cherche toujours.
Dans GXT, les bindings des champs d'un modèle sont d'ailleurs ... écrit à la main. Besoin de la réflexivité ? Bouaif. Rien qu'un script perl et un petit DESL ne puisse résoudre.
Non ça c'est un hideux foutoir et je préfère 1500 fois l'approche .Net avec tout qui tourne autour d'ASP.net.Citation:
Envoyé par Luc Hermitte
Mais ça prouve que le langage est populaire pour ce type de projet.
Je dis pas que ce n'est pas possible mais que l'offre est très limitée.Citation:
Quant au MVC, dans certains frameworks chez les voisins qui on le vent en poupe comme GXT, je le cherche toujours.
Dans GXT, les bindings des champs d'un modèle sont d'ailleurs ... écrit à la main. Besoin de la réflexivité ? Bouaif. Rien qu'un script perl et un petit DESL ne puisse résoudre.
Histoire d'être clair, je vais commencer par une critique (parce que j'aime bien critiquer) et je terminerais par quelques arguments sur le sujet principal.
Bon, dans un premier temps : est-ce qu'un ORM est vraiment une bonne chose ? Dans ma vision (peut être un peu limitée), les ORM ne sont pas vraiment la panacée - ils offrent au programme la possibilité d'attaquer le modèle physique de la base de donnée. Or ce modèle physique est peut être très bon pour une base de donnée, mais nettement moins bon dès lors qu'on parle de conception orientée objet. Je ne vois pas pourquoi je devrais continuer à manipuler une notion de table dans mon code C++ (ou C#, ou Java). Dans mon esprit, les ORM répondent mal à une question qui ne se pose pas. Et visiblement, je ne suis pas le seul à avoir des problèmes relationnels avec les ORM.Citation:
Envoyé par _skip
Dans un second temps : LiteSQL, DTL et OpenORM sont des ORM C++. Donc : ça existe, même si certains (notamment OpenORM) ressemble à s'y méprendre à des usine à gaz inutilisable (mais bon, c'est aussi le cas de certains ORM Java, et pas des moindres...). Dans le domaine, celui qui me semble le plus probant reste LiteSQL.
C'est vrai que le C++ est le parent pauvre du développement web. Pour moi, la principale raison est purement historique, et pas du tout technique. Java n'est pas plus adapté que le C++ au développement d'applications coté serveur, alors pourquoi Java est plus employé ? La question de l'hétérogénéité des architecture ne se pose pas vraiment : en fait, les architecture sont souvent tellement hétérogène qu'il arrive que deux versions de Java tournant sur des serveurs différents utilisé dans la même application n'offre pas les même fonctionnalités et soient sur certains points incompatibles (vu avec GNU vs Sun). Je ne pense pas non plus que le problème soit lié aux fonctionnalités du langage : dans le cadre d'une architecture objet propre, la réflexion n'est pas un outil à utiliser (son utilisation suppose que le comportement de l'application change selon les caractéristiques physiques d'un objet, ce qui contrevient aux principes OCP et LSP). J'ai même l'intuition (mais ça n'est hélas qu'une intuition; pas de preuve formelle, pas d'arguments à opposer, ...) que la réflexion est un outil dont la puissance est directement liée à sa non-utilisation ;) Les programmeurs ont très bien vécu sans réflexion pendant des dizaines d'années, et ont résolu les problèmes que cette absence leur posait de manière élégante. Et sii on enlève la réflexion, Java devient relativement limité (en termes syntaxiques) par rapport au C++. Donc exit le problème de fonctionnalités liées au langage.
Alors pourquoi y a t-il plus de framework web Java que de framework web C++ ?
Rappelez vous les débuts de Java. Sa première utilisation grand publique a été de permettre le développement d'applets qui s'exécutaient sur le poste client. Vous vous en souvenez ? A l'époque, la génération dynamique de pages (donc coté serveur), c'était des scripts perl, shell ou des programmes compilés utilisant le protocol CGI. D'ailleurs, à cette époque, la plupart des pages servies étaient statiques, l'interactivité étant résolument coté client - pour le meilleur ou pour le pire. Etre programmeur web, cela signifiait donc :
- être capable de "programmer" en HTML
- connaître un poil de JavaScript
- être capable de réaliser des applets Java.
Un peu court... Le fait est que les programmeurs web étaient plutôt mal considérés. En 1996, les gens haut placé se demandaient pourquoi on formait des ingénieurs au métier du web - ça n'avait pas de sens, tant on avait dans l'idée que les métiers du web étaient simplistes (après tout HTML, c'est pas ce qu'on a fait de plus complexe...)
Alors que moi j'engloutissais du C et du C++, mes collègues en promo Metiers du Web (qui, pour beaucoup, n'aiment pas la programmation et avait espéré s'en tirer à bon compte en choisissant cette spé) apprenaient donc HTML, JavaScript et Java.
Fast forward (quelques années plus tard) : le web explose. De nouvelles technologies sont nécessaires pour stocker et traiter de nouvelles informations. Le futur n'est plus au pages web statiques, mais aux sites entièrement générés dynamiquement. Il faut que les technologies évoluent.
Les gens en place dans le métier sont ces ingénieurs formés quelques années plus tôt. Pour eux, Java est un choix naturel - on leur a confirmé pendant des années que c'était un langage simple. Depuis 96, le langage a fait des progrès et a démontré sa versatilité. Et puis, dans le domaine du Web, Java est un langage nettement plus utilisé que les autres langages de programmation (a cette époque, la très grande majorité des fanboys Java sont des programmeurs Web ; on appelle ça la dissonance cognitive...). Avec un gros vivier de programmeur Java qui (étrangement) ne se sont jamais intéressé à d'autres langages que Java, il n'est pas illogique que rapidement, on voie fleurir des outils permettant de programmer coté serveur en Java. Au niveau technique, Java n'est pourtant pas (à l'époque) ce qui se fait de mieux en termes de rapidité de traitements. D'ailleurs, les moteurs de recherche de l'époque sont généralement basés sur des CGI.
Mais ça y est : les graines sont semées. De dominant coté web client (ou l'utilisation de Java a un intérêt, ne serait-ce que pour supporter les différentes plateformes), Java passe à dominant coté serveur (ou sa prétendue portabilité n'a strictement aucune influence). Des apprentis designers logiciels créent des monstruosités qui sont étendues par d'autres, devenant des quasi-standard dans le domaine du web et hop, on se retrouve aujourd'hui à parler d'ORM et de framework web MVC - alors que dans l'esprit d'un designer logiciel sain, ces deux choses ne sauraient exister.
Mais c'est une autre histoire.
Pour résumer, ce n'est pas l'excellence technique de Java qui a fait que le langage soit adopté en masse et qui a produit le développement des frameworks utilisés de nos jours ; c'est l'adoption par les développeurs web de cette technologie coté client qui a poussé au développement des frameworks cotés serveur qui a poussé à l'adoption en masse. Et curieusement au détriment d'un seul type de langage informatique : les langages compilés nativement - au profit de langages qui, à l'heure actuelle, sont de plus en plus compilés en byte code avant d'être compilés nativement grâce à un compilateur JIT.
Il y a 5 ans, l'idée qu'on pouvait réaliser un site web avec des CGI était complètement absurde - il faut un langage scripté ou un langage basé sur une VM. Pourtant, à bien y réflechir, je ne voie aucune contre-indication à l'utilisation de programmes binaires natifs pour la génération de pages web.
Vous en voyez vous ?
L'existence d'une machine virtuelle (vm) facilite l'intégration de programmes tiers (applets) dans les navigateurs non?
Si tu veux parler de cet article de SQLPro qui compare des procédures stockées écrites par un expert SQL aguerri à une couche client faite par un idiot qui sait pas ce qu'il fait, ce sera sans moi. Je suis suffisamment intervenu sur le sujet en question.Citation:
Envoyé par Emmanuel Deloget
Pour le reste je me tiens à l'écart, mon post a été déplacé ici, tout ce que j'ai voulu faire c'était relever le fait que l'offre C++ sur le développement web était limitée et que l'informatique de gestion s'était déjà tourné vers autre chose.
Ce n'est pas de mon ressort de dire pourquoi ça s'est fait comme ça ou pas autrement, les choses étant ce qu'elles sont si on me demande ce que je recommande pour le développement d'un intranet avec base de données, ça me vient même pas à l'idée de considérer C++.
Dans le même ordre d'idée, cf les initiatives comme GWT qui ... compilent du Java en javascript.Citation:
Envoyé par Emmanuel Deloget
Il n'y a pas d'impossibilité, mais la charge sur de telles appli est bien souvent sur le réseau et la BDD, plus que sur l'appli elle même. On a donc interêt à utiliser un langage bien plus permissif que C++, quitte à y perdre sur d'autres points.
Je ne vois pas ce qui empêche de faire des applis web en c++.
A part peut être que des dixaines de solutions, plateformes, frameworks et langages sont spécialisés pour ce genre de job (et que ça marche quand même).
Mais bon, quand un composant s'avère valoir le coup, il finira par être implémenté en c ou c++ et une ribambelle de bindings viendront graviter autour.
Oui mais ça, c'est coté client - et c'est complètement justifié, ne serait-ce qu'au niveau de la gestion de l'hétérogénéité des plateformes cibles et au niveau sécurité.Citation:
Envoyé par r0d
Une question purement naive : est-ce que la gestion de la mémoire (et donc des strings notamment) peut être un problématique de performance comparé aux languages sous garbage collector dans le type de cas d'applications web totalement générées?
Je sais que le fait d'être au controle de la memoire est déjà rédibitoire pour l'essentiel des développeurs web, mais si on omet ça deux minutes, est-ce qu'il y a un quelconque impact sensible (positif ou négatif) niveau performances qui irait contre l'idée qu'ont peu baser un site web sur du C++?
Pas à ma connaissance - ça serait bien le premier cas ou on me dirait "C++, c'est trop lent pour ce type de traitement".Citation:
Envoyé par Klaim
C'est vrai qu'une application web gère énormément de chaines de caractère. Ceci dit, c'est vrai - qu'on soit en C++ ou en Java. Je ne pense donc pas que la gestion de la mémoire associées à ces string soit plus problématique en C++ qu'en Java. Si toutefois cela s'avère être le cas, on peut toujours trouver une autre solution (basée par exemple sur un allocator spécifique ; certains sont très performants dès lors qu'il s'agit de gérer des petits blocs de mémoire très volatiles).
Salut,
Je vois une autre raison 'historique' à l'absence d'utilisation du C++ pour le web. Au tournant des années 2k, quand le web a explosé, il n'était pas rare d'avoir un bel écran bleu avec un programme natif. Je ne sais pas si la fréquence était la même avec un programme tournant sur une VM. Bien sûr cet argument reste moins vrai aujourd'hui.
Le C++ est-il adapté au oueb aujourd'hui ? Ben j'aurais une réponse de normand : le C++ n'est adapté à rien mais permet de faire tout. C'est sa faiblesse et sa puissance. Après, concrètement, c'est bien l'historique qui pèse dans ce genre de prise de décision. Une boîte ne va pas (re)former tous ses développeurs vers un nouveau langage et des bibliothèques spécifiques pour un gain pas évident. Le problème de perf ? Ca coûte moins cher d'acheter un nouveau serveur + boosté que 5 jours de prestations. Le calcul est vite fait.
Ensuite, je n'ai pas l'impression qu'il y ait de framework/bibliothèque 'référence' pour faire du dev oueb en C++. Tout refaire serait absurde. Choisir une plateforme plutôt qu'une autre pose différents problèmes : formation des développeurs, stabilité de la plateforme, support disponible, pérennité ?
J'ai entendu beaucoup de biens de Wt (notament sur stackoverflow.com) mais jamais essayé.
Sinon, je viens de me rappeler autre chose en rapport avec les strings, qui pourrait avoir rebuté l'essentiel des programmeurs web : le manque de standardisation de la gestion des caractères unicodes dans le language (corrigé dans C++0x a priori).
Je ne suis pas sur de l'impact que ça peut avoir, ce n'est qu'une autre supposition naïve.
Quel argument de choc! Ca me parait un peu gros, à moins que tu ne fasses allusion qu'au monde de Windows? (sans troll, juste par rapport au blue screen)Citation:
Envoyé par 3DArchi
Plus prosaïquement, le manque de sécurité offert par un programme natif : si un attacker arrive à faire planter le programme, risque-t-il de faire flancher le serveur aussi ? AVec les OS Windows d'il y a quelques années, c'était quand même plus que probable. Tandis que faire planter la VM (et donc arriver au même résultat) c'est quand même plus compliqué.Citation:
Envoyé par metagoto
Le fait est que maintenant, la plupart des gros serveurs webs sont virtualisés. Si une machine virtuelle plante, on la redémare et hop, ni vu ni connu. Et faire tourner une VM sur une machine virtuelle (ça se fait ; gamedev.net est géré comme ça, si je ne me trompe pas. Le site est en C# et tourne sur plusieurs serveurs IIS virtualisés), c'est prendre le risque de dégrader les performances par rapport à du code natif (qui, avec la virtualisation hardware, sera à priori plus performant).