Il semble que la plupart des navigateurs Web courants (Firefox, Chrome, Safari) soient développés en C ++. Pourquoi est-ce vrai?

Une autre façon de poser la question est de savoir quel type de support un navigateur a besoin? La courte liste est:

• Prise en charge de l'analyse (nécessaire pour donner un sens à [X] HTML, CSS et au script [ECMA / Java])
• Fonctionnalités de marche / interprétation dans les arbres (partie de l'analyse et de la construction de l'interface utilisateur)
• Prise en charge des graphiques accélérés
• Réseau rapide
• Pour les navigateurs plus avancés: contrôle des processus et isolation de la mémoire entre les pages
• Doit fonctionner sur toutes les plateformes supportées

La plupart des langues ont une sorte de support d'analyse. Vous avez des générateurs d'analyseurs pour C, C ++, C #, Java, etc. Cependant, C et C ++ ont quelques années d'avance sur le reste des alternatives, de sorte que les algorithmes et les implémentations sont plus matures. L'accès aux graphiques accélérés en Java est interdit, à moins que vous n'ayez des extensions natives pour le faire fonctionner. WPF on C # permet d’accéder à des graphismes accélérés, mais c’est trop nouveau pour avoir un navigateur sérieux construit avec la technologie.

La mise en réseau est en réalité la dernière des raisons de choisir C ++ plutôt que Java ou C #. La raison en est que la communication est plusieurs fois plus lente que le reste du traitement qui affiche la page. La vitesse brute du fil est le facteur limitant. A la fois Java et C # ont un support IO non bloquant, tout comme C ++. Donc, il n'y a vraiment pas de gagnant clair dans ce domaine.

Pourquoi pas Java? Avez-vous déjà essayé de construire une interface utilisateur avec Java? Cela semble lourd et lent comparé à tout ce qui se passe ailleurs, parce que c'est le cas. Aucun graphique accéléré n'est également un gros négatif ici. Le sandboxing de Java est vraiment bon et peut aider à améliorer la sécurité d'un navigateur s'il est utilisé correctement, mais il est difficile de configurer et de faire fonctionner le navigateur. Sans parler du support des formats graphiques par rapport à la plupart des navigateurs modernes.

Pourquoi pas C #? Si votre seule cible est Windows, C # peut en fait faire une bonne représentation. Le problème survient lorsque vous souhaitez prendre en charge autre chose. Mono n'a pas assez rattrapé pour être considéré comme suffisamment multi-plateformes pour cette tâche - en particulier avec un support graphique accéléré et WPF. Qui sait combien de temps cela prendra pour changer.

Pourquoi pas C? Il existe un compilateur C pour à peu près toutes les plates-formes existantes (y compris les périphériques intégrés). Cependant, il y a beaucoup de choses que C ne fait pas pour vous et pour lesquelles vous devrez faire preuve d'une vigilance accrue. Vous avez accès à tous les niveaux les plus bas des API, mais la majorité des développeurs C ne font pas d'interface graphique. Même les bibliothèques d'interface graphique C sont écrites de manière orientée objet. Dès que vous commencez à parler à l'interface utilisateur, un langage orienté objet prend tout son sens.

Pourquoi pas Objective C? Si votre seule cible est Apple, cela a beaucoup de sens. Cependant, la plupart des développeurs ne connaissent pas Objective-C et la seule raison de l’apprendre est de travailler sur NeXT ou les boîtes Apple. Bien sûr, vous pouvez utiliser n’importe quelle bibliothèque C avec Objective-C, et il existe des compilateurs pour de nombreuses plates-formes, mais il est un peu plus difficile de trouver des personnes sur lesquelles travailler. Qui sait? Peut-être qu'Apple pourrait remédier à cette lacune perçue.

Pourquoi C ++? Il existe un compilateur C ++ pour à peu près toutes les plateformes. Presque toutes les bibliothèques d'interface graphique ont une interface C ++, parfois c'est mieux et parfois c'est tout simplement différent. Par exemple, l'ATL de Microsoft est bien meilleur que les appels de fonction win32 C ou même la bibliothèque MFC. Il existe des wrappers C ++ pour GTK sous Unix, et je serais surpris que quelqu'un ne dispose pas d'un wrapper C ++ autour de la bibliothèque d'interface graphique Objective-C d'Apple. La gestion des processus est plus facile en C ++ que Java ou C # (ces détails sont résumés pour vous). Sa vitesse perçue provient davantage de l'accélération matérielle que des performances brutes. Le C ++ s'occupe de plus de choses que le C brut (comme les chaînes délimitées), mais vous donne toujours la liberté de modifier les choses.

Pour le moment, C ++ élimine les alternatives.

J'ai décidé d'écrire un roman à ce sujet dans l'espoir que les gens l'oublieront et m'inviteront davantage. Non, non, je rigole! J'ai souffert de chaque mot. Chaque mot, je vous le dis!

Demander 'quand' avant 'pourquoi'

Tous les principaux navigateurs Web peuvent retracer leurs origines jusqu'aux années 90. Konqueror est devenu Safari et Chrome; Netscape est devenu Firefox; IE et Opera sont toujours IE et Opera. Ces navigateurs ont tous une avance de 15 ans sur les opérateurs historiques.

Je vous suggère même d'essayer de nommer un langage compatible multi-plateformes (Windows / Mac / Unix et même pire) qui était disponible aux alentours de 1995, lorsque les navigateurs modernes ont été créés. Pour construire le noyau en tout sauf en C / C ++, vous auriez probablement dû créer ou acheter et modifier un compilateur et des bibliothèques de plate-forme.

Pourquoi pas aujourd'hui? Quelles sont les alternatives?

Juste pour le plaisir, réfléchissons au problème aujourd'hui. Oui, il existe des alternatives, mais il reste des problèmes majeurs.

Le choix de la langue présente au moins ces problèmes:

1. Problèmes de connaissances - Embaucher / former des développeurs ou attirer des contributeurs
2. Problèmes organisationnels / sociaux - Acceptation de la langue
3. Implémentation linguistique: rapidité, support de plateforme, outillage
4. Puissance linguistique

1: Problèmes de connaissance

Où trouvez-vous des gens qui connaissent la langue ou peuvent l’apprendre? Ceci est un obstacle pour des langages comme OCaml, Fa #, Haskell, Common Lisp et D qui sont assez rapides et de niveau élevé pour écrire un navigateur bien, mais qui ont peu d’adeptes (dans la gamme de 10k à 100k, peut-être) même si vous en avez compter tous les amateurs et les universitaires.

2: Problèmes sociaux / organisationnels

Corollaire à la réponse culte de la cargaison ci-dessus:

• Un navigateur open source n'utilisant pas de C, C ++, C # ou Java aurait soi - disant des difficultés avec les contributeurs.
• Un navigateur propriétaire n'utilisant pas C, C ++, C # ou Java fera cracher les chefs de projet dans la plupart des organisations.

3. Problèmes techniques

Même à l’époque moderne, vous avez besoin d’un langage relativement rapide pour les parties de calcul de pages qui nécessitent beaucoup de calcul et d’exécution de Javascript. Vous pouvez choisir de compléter cela avec un langage de haut niveau pour construire des éléments d'interface graphique, etc. (par exemple, l'approche Firefox en C ++ et Javascript), mais vous devez avoir une intégration étroite entre les langages; vous ne pouvez pas simplement dire "d'accord, C # et Lua." Vous devrez probablement construire et déboguer ce pont vous-même, à moins que vous ne choisissiez C ou C ++ comme langage de base.

Le développement multiplate-forme est un autre sac de vers. Vous pouvez utiliser C # ou F # et croiser vos doigts pour que GTK # et Mono soient en vie et à l’avenir. Vous pouvez essayer Common Lisp, Haskell, OCaml ... Bonne chance pour que tout fonctionne correctement sous Windows , Mac et Linux.

4. Puissance linguistique

Après tout cela, vous devez créer une quantité énorme de fonctionnalités. Par conséquent, si vous choisissez un langage de bas niveau, vous aurez besoin d’une armée de codeurs encore plus imposante qu’avant. Notez que personne n’a vraiment construit un navigateur à partir de rien en une quinzaine d’années. C'est en partie parce que (surprise!) C'est difficile.

Plus précisément, avoir un interprète Javascript est le problème 3 (en acquérir un) ou le problème 4 (en construire un).

Conclusion:

Si vous avez développé un navigateur à trois plates-formes (Windows / Mac / * nix) aujourd'hui (début 2011), quels sont certains des choix?

• C: Voir (2). Tout le monde va réclamer le C ++. Amusez-vous en choisissant une boîte à outils multi-plateformes ou en en construisant une (1, 2, 3 et 4). Voir aussi (4); Amusez-vous à construire un navigateur stable et sécurisé.
• C ++: amusez-vous en sélectionnant une boîte à outils multi-plateformes ou en en construisant une (1, 2, 3 et 4). Amusez-vous (4) en construisant un navigateur stable et sécurisé.
• C ou C ++ et HLL: Votre meilleur pari. Choisissez votre poison sur le langage dynamique; Voir (1) et (2). Trop de bonnes langues, trop peu de disciples. (1, 2, 3 et 4) sur la boîte à outils.
• Java: Deuxième meilleur choix si vous devez faire plaisir à la direction intermédiaire. Voir (4); Construire des choses énormes en Java prend beaucoup plus de code que dans n'importe quoi d'autre sur cette liste mais peut-être C.
• Scala: Beats Java on (4); (1) et (2) mais ça commence à prendre forme.
• C et Javascript: Comme cas particulier, c'est attrayant car vous devez déjà construire ou acquérir et assimiler un interprète Javascript. (D'où Firefox.) (1, 2, 3 et 4) sur la boîte à outils; le peuple Mozilla a construit son propre IIRC.
• C #: Amusez-vous sur (3). Vous êtes probablement coincé avec GTK #, aussi bon soit-il, ou construisez vos propres calques et rendus au-dessus de GTK # et de Windows Forms.
• Ruby / Python / Perl / Racket / Lua / Erlange etc .: Vous avez (3) sur les bibliothèques de widgets multi-plateformes et la vitesse. La loi de Moore est avec vous sur (4); la demande croissante sur les navigateurs est contre vous.
• OCaml, Haskell, Common Lisp, Smalltalk: (1) et (2) en pique. Pas de problème de vitesse, probablement, mais (3) pour le développement multiplate-forme, et vous devrez construire votre propre tout ou passer d'une manière ou d'une autre aux bibliothèques C / C ++.
• Objective-C: (3) Je ne suis pas sûr de savoir comment le développement multi-plateforme fonctionnerait ici.

Si nous voyons un autre navigateur important faire son apparition dans les prochaines années, je parierais qu'il sera écrit en C ou C ++ et dans un langage dynamique (comme Firefox), qu'il soit open source ou propriétaire.

Edit (31 juillet 2013) : Les commentateurs de Hacker News semblent mentionner Rust and Go (qui n’est pas spécifiquement lié à ma réponse), qui tombent vaguement dans le panier "divers". Essayer de garder cette liste de langues égalitaire et à jour sera une bataille perdue d'avance, alors je l'appelle plutôt un échantillon représentatif au moment de la rédaction et de la laisser tranquille.

La vitesse

Aussi moche qu'il soit, C ++ est toujours ce que vous utilisez lorsque vous voulez une application rapide et un contrôle total sur le code.

C'est pourquoi les jeux, les composants non essentiels (tels que les importateurs de fichiers) d'Office et d'autres encore sont toujours écrits en C ++.

Édité pour inclure la réponse de MSalters

Portabilité

Je peux seulement deviner, mais vous parlez de produits logiciels qui ciblent plusieurs plates-formes, et le C ++ peut être compilé pour n’importe quelle plate-forme.

(Je travaille sur Firefox depuis environ cinq ans.)

Le questionneur a raison de dire que beaucoup de code de Firefox est en C ++, et que C ++ est majoritaire si vous comptez par lignes de code (bien que cela ne raconte pas toute l'histoire, car nous avons beaucoup de JavaScript, et JS est plus concis que C ++).

Mais en réalité, Firefox est écrit dans beaucoup de langues différentes:

• C ++
• C (NSS, NSPR, diverses bibliothèques importées)
• Assemblage x86 et ARM
• JavaScript
• XUL (un langage de balisage de type HTML) et CSS
• Objective C (code uniquement MacOS)
• Java (code uniquement pour Android)
• Plusieurs langues de définition d'interface personnalisées (XPIDL, IPDL)
• WebIDL (un autre langage de définition d'interface, mais celui-ci n'est pas personnalisé, même si le générateur de code l'est)
• Python (générateurs de code)

J'en oublie sûrement.

Cette liste est importante car elle fait allusion à l'incroyable complexité qui se cache derrière un navigateur Web.

Oui, Firefox a beaucoup de code C ++, et oui, cela a quelque chose à voir avec le fait que C ++ était le meilleur langage pour ce genre de choses lors de la création de Netscape. Mais je soutiens également qu’il n’existe pas de meilleur langage aujourd’hui pour beaucoup de ce que nous faisons.

Aucun autre langage ne possède un écosystème de bibliothèques aussi puissant (nous nous appuyons fortement sur du code externe). Peu de langages vous offrent un contrôle total de la pile, comme le C ++ (nous ajustons régulièrement notre allocateur de tas personnalisé et faisons toutes sortes de choses dangereuses pour la mémoire pour être plus rapides ou utiliser moins de mémoire). Peu de langues vous permettent de ré-implémenter la plupart des bibliothèques standard de manière rationnelle (nous avons nos propres implémentations de chaînes et de collections, adaptées à nos besoins). Peu de langues vous permettent d'implémenter votre propre ramasse-miettes. Etc.

Bien que le C ++ soit le choix évident pour bon nombre de nos activités, les personnes qui suggèrent que nous pourrions écrire un navigateur en Java et écrire notre propre JVM, si nécessaire, sont attentives. C’est essentiellement ce que nous faisons, mais avec JavaScript au lieu de Java. Bien sûr, une grande partie du navigateur n'est pas écrite en JavaScript. Mais un montant surprenant est.

Eh bien, il faudrait demander directement aux développeurs de ces produits pour obtenir la réponse, mais je suppose que c'est une combinaison de familiarité (c'est ce que ces développeurs connaissaient le mieux), de performance (compiler avec un binaire natif plutôt que du bytecode), et outils (comparé à des langages tels que C, C ++ regorge de gadgets permettant d’économiser du temps, comme le STL)

Histoire

Chacun des navigateurs a une histoire qui a influencé le choix de la langue.

Par exemple, Chrome et Safari sont tous deux basés sur WebKit, qui tire ses origines de la partie KHTML du projet KDE. KDE a été créé (en partie) à titre de démonstration de la boîte à outils Qt GUI. KDE est donc globalement un projet C ++. Tous les nouveaux projets KDE étaient à l’époque entièrement écrits en C ++. C’était donc un choix logique pour KHTML. Depuis, il a été porté pour utiliser d'autres kits d'outils graphiques.

Le moteur Presto d’Opera a été écrit avec des performances et une petite taille binaire à l’esprit: C ++ était le choix logique.

Internet Explorer a été écrit sous forme de collection de composants ActiveX, qui auraient pu être écrits dans n'importe quel langage comportant des liaisons COM, mais probablement dans un sous-ensemble de C ++, car la majorité de leur base de code est déjà écrite dans ce langage.

Mozilla de Netscape a été écrit en C ++, probablement parce que la portabilité était une préoccupation majeure de leur part. Les compilateurs C et C ++ sont (pratiquement) omniprésents et c’était donc un choix logique.

Il n'y a pas de raison technique inhérente à ces choix. Cela "semblait être une bonne idée à l'époque".

La mise en réseau en C et C ++ est facile à optimiser car vous n’avez pas besoin d’utiliser des bibliothèques si vous ne le souhaitez pas. Je soupçonne que C ++ est le langage de choix car il permet les avantages de C:

• La vitesse
• Optimisation
• Une certaine quantité de portabilité
• Langage compilé, non interprété

couplé aux avantages de la POO:

• Extensibilité
• Visualisation plus facile
• Meilleur support de bibliothèque pour les tâches non critiques telles que le traitement des chaînes et les structures de données

Lorsque les premières lignes de code de la première série de navigateurs ont été écrites, C # et Java n'existaient pas. Ruby non plus. Python existait peut-être déjà, mais il s’agissait toujours d’un petit projet homebrew.

En gros, il n’y avait vraiment pas d’autre choix que le C ++ qui permettrait de construire un navigateur rapide et compatible avec de nombreuses plates-formes différentes.

Alors pourquoi ont-ils été écrits en C ++? Parce que c'était la seule langue disponible dans laquelle ils pouvaient être écrits.

Parce que les navigateurs (par exemple, HotJava, assez bien écrit en Java) écrit dans d’autres langues n’ont jamais atteint un degré substantiel d’acceptation / pénétration sur le marché.

Je ne peux rien dire à propos de l' itération actuelle (ou la plus récente - n'a pas été mise à jour depuis longtemps) de HotJava, mais lorsque j'ai essayé, le manque de pénétration du marché m'a paru (au moins pour moi) extrêmement facile à comprendre. - c'était moche, lent et incompatible avec pas mal de pages web. En fin de compte, cela semblait reposer sur un principe qui n’a jamais été résolu: que le Web se composerait principalement d’applets Java, le code HTML n’étant qu’un simple wrapper indiquant les applets à afficher où.

Une partie de celle-ci est probablement aussi historique: la plupart des grands navigateurs Web existent depuis longtemps. Quand ils ont été écrits pour la première fois, le paysage était très différent: le C ++ était un nouveau langage "chaud", il était donc utilisé pour de nombreux nouveaux développements. Les navigateurs sont devenus l’un des logiciels les plus utilisés, alors que beaucoup d’autres de l’époque sont tombés dans l’oubli.

Je pense que "l'attitude" affichée du langage a également un effet: C ++ (comme C avant) a toujours mis l'accent sur l'aspect pratique et le pragmatisme. Cette attitude de base a tendance à attirer les programmeurs qui sont aussi pragmatiques. De nombreuses autres langues mettent beaucoup plus l'accent sur des éléments tels que l'élégance et, ce faisant, attirent les programmeurs qui pensent de la même manière. Le problème, c’est ce que j’appelle «l’effet Lisp». Les symptômes incluent:

1. Des discussions sans fin sur la mise en œuvre la plus élégante des choses les plus triviales.
2. Incapacité à geler les fonctionnalités et à finir quelque chose qui peut être expédié (même avec des défauts)
3. Incapacité à faire des compromis. Quiconque n'est pas d'accord avec moi n'a pas tort, il doit être stupide ou diabolique.

Il y en a plus, mais vous avez une idée générale (et oui, j'exagère un peu - mais seulement dans une certaine mesure). Oui, une partie du code que vous obtiendrez sera incroyablement belle - mais il y a de fortes chances qu'elle ait six mois de retard, et la plupart du temps incompatible avec tout autre élément de code (ce qui est censé être) dans le système, et au moment où vous le recevez, Il y a de fortes chances que quelque chose d'autre ait suffisamment changé pour que vous ne puissiez plus l'utiliser.

Il existe également des langages qui fonctionneraient sans aucun doute, mais qui (à tort ou à raison) n’ont tout simplement pas (ou au moment crucial, n’ont pas) des parts de marché pour que quiconque ait jamais écrit un navigateur. Compte tenu de la taille et de la complexité d'un navigateur complet, le développement de celui-ci prend beaucoup de temps et beaucoup de temps. Avec ce type d'investissement, beaucoup de gens deviennent relativement conservateurs à propos d'outils tels que les outils de développement.

Programmation cargo-culte. La perception selon laquelle "C ++ est rapide" est toujours d'actualité (malgré des fonctionnalités mal conçues au niveau de la langue, telles que son modèle d'objet mal cassé qui ralentit le processus) et les utilisateurs veulent que leurs navigateurs soient rapides, ils écrivent donc en C ++. .

Dans un monde sain d'esprit, les personnes qui écrivent des logiciels destinés au réseau seraient horrifiées à la seule pensée d'utiliser un langage qui résoudrait tous les problèmes de sécurité inhérents à C, ce qui constituerait en réalité un acte de négligence criminelle. (Il suffit de regarder combien d'exploits de débordement de mémoire tampon ont été trouvés contre différents navigateurs au cours des 15 dernières années! Combien de millions de dollars de dégâts ces codeurs sont-ils responsables?)

Il existe d'autres langages compilés capables de créer des fichiers binaires rapides. Le problème est qu'ils n'ont pas la même exposition que la famille C et nous devons tous en souffrir.

Anecdote: lorsque le Morris Worm est arrivé sur Internet en 1988, il a démontré de façon concluante les problèmes liés à l'écriture de systèmes d'exploitation et de logiciels orientés réseau en C (qui n'ont toujours pas été résolus à ce jour, car ils présentent des failles inhérentes au langage. ,) Apple publiait le système d’exploitation le plus avancé que le monde ait jamais vu, écrit depuis plusieurs années déjà en Pascal.

Accès aux API de niveau système

Tous les navigateurs doivent s’interfacer avec le système d’exploitation à un moment donné, et la plupart des principaux systèmes d’exploitation possèdent des API et des bibliothèques C et C ++ bien établies. Il est généralement plus facile de travailler avec ces API en C ou C ++ plutôt qu'avec des wrappers en écriture.

Contrôle et portabilité

la plupart des arguments de vitesse peuvent aller dans les deux sens, mais dans tout ce qui nécessite un contrôle précis sur la manière de faire quelque chose, beaucoup de langues de niveau supérieur vont pleuvoir sur votre défilé. Il existe des exceptions à cela, mais la plupart d'entre elles ne sont pas suffisamment multiplates-formes pour compter dans un navigateur.

Compatibilité Legacy - ne peut pas jeter l'ancien code

Cela n'a rien à voir avec les mérites du C ++ par rapport aux autres langages. Vous pouvez sûrement écrire un meilleur navigateur à partir de zéro dans une langue comme Haskell; Un projet aussi important pourrait même implémenter sa propre JVM s’il devait garantir certaines caractéristiques de performance. J'aime comment Facebook a écrit son propre compilateur / optimiseur PHP.

Un navigateur qui rompt avec un balisage non standard est pire qu'inutile. La compatibilité avec Legacy est si critique et complexe qu'une réécriture n'est tout simplement pas une option. Beaucoup de temps et d'argent sont investis dans une sécurité éprouvée au combat, etc. Vous ne pouvez pas simplement gaspiller cet investissement. Encore une fois, comment Facebook est encore écrit en PHP.