Publié par Julien L., le Mardi 29 Octobre 2013

Infographie : qui de Facebook et du Boeing 787 a le plus de lignes de code ?

En informatique, les programmes peuvent vite impliquer des milliers, des centaines de milliers voire des millions de lignes de code. L'infographiste David McCandless a choisi de comparer la taille du code source plusieurs projets. Et aussi étonnant que cela puisse paraître, Facebook mobilise par exemple plus de code qu'un Boeing 787, Curiosity ou la navette spatiale américaine...

Derrière les programmes que vous utilisez, les sites web que vous visitez et les appareils que vous manipulez, il y a du code informatique. Parfois, il n'en faut que très peu (une ligne peut suffire, par exemple, exécuter Hello world). Mais la plupart du temps, l'aboutissement d'une application en nécessite beaucoup plus. Certains programmes très ambitieux sont ainsi composés de millions de lignes de code.

C'est cette réalité que l'infographiste David McCandless a voulu représenter. Ce mois-ci, il a publié une vaste infographie classant les logiciels informatiques et les sites web selon l'importance de leur code source, du plus petit (un simple jeu pour iPhone) au plus gros (le site web consacré au Healthcare). Idéal pour comprendre la portée de certains projets.

Cinq catégories sont représentées par des couleurs différentes pour différencier les systèmes d'exploitation, les jeux vidéo, les applications, les navigateurs web et les machines. Des arcs ont également été apposés pour montrer l'évolution du code à travers le temps (comme le noyau Linux, Windows ou encore Microsoft Office).

Saviez-vous par exemple qu'un pacemaker implique moins de 100 000 lignes de code, tandis que le moteur id Tech 3 (Quake III engine) en mobilise plus du triple ? Que la navette spatiale américaine en a peine plus ? Que le rover Curiosity en utilise 5 millions ? Idem pour World of Warcraft, à peu de choses près ? Qu'un Boeing 787 en utilise moins que Windows 2000, Facebook ou que le système embarqué d'une voiture ?

Pour visualiser l'infographie en taille réelle, cliquez sur l'image ci-dessus :

( photo : Matthew CC BY-SA 3.0 ; infographie : David McCandless CC BY-NC 3.0 )

Publié par Julien L., le 29 Octobre 2013 à 17h59
 
46
Commentaires à propos de «Infographie : qui de Facebook et du Boeing 787 a le plus de lignes de code ?»
Inscrit le 04/03/2010
96 messages publiés
"une ligne peut suffire , par exemple, exécuter Hello world "
Mouais, ça depend comment on voit les choses. Si on fait abstraction des milliers de lignes de codes qui sont nécessaires pour executer l'appel d'un printf et avoir le résultat sur un écran...
Chez moi quake3 c'est une ligne de code : un fichier BAT avec le chemin du fichier à executer

"un pacemaker implique moins de 100 000 lignes de code"
Ca parait logique...vu la fonction du machin, il a pas 36 trucs à gérer ! pas besoin d'avoir un OS sur un truc pareil, ni de quantités de ressources...Qu'il fasse moins de 10K lignes de codes ne m'etonnerait pas...c'est ce qu'on appelle la programmation embarquée...sur des petits microcontrôleurs (qui peuvent aller de 8 à 32 bits), on peut faire des choses tres puissantes pour quelques milliers de lignes de codes...et des programmes de quelques dizaines de Ko

Du temps des premières fusées, le controleur de trajectoire / pilotage moteur était un petit pross 8 bits qui tournait à 8 MHz avec une mémoire de quelques dizaines de Ko. Fallait juste qu'ils soit super blindés contre les rayonnements spatiaux...
Inscrit le 10/04/2009
2382 messages publiés
Les chiffres pour healthcare.gov a l'air d'être un énorme troll. De même pour le logiciel de bord dans une voiture, y compris très moderne...
[message édité par It08 le 29/10/2013 à 18:25 ]
Inscrit le 16/06/2009
9798 messages publiés
Mindo (Rédacteurs Numerama) le 29/10/2013 à 20:02
A priori, non : la source pour Healthcare est le NYT ( http://www.nytimes.c...wanted=all&_r=0 ) et Wired pour le logiciel de bord ( http://www.wired.com...omotive-os-war/ )
Inscrit le 10/04/2009
2382 messages publiés
C'est super bizarre. Tant de lignes ça aurait nécessité une décennie de code. 500 millions c'est assez peu réaliste pour un site. Mais bon, en effet la source le dit.
Inscrit le 30/09/2013
1264 messages publiés
Sachant que la notion de ligne de code dépend fortement du langage employé et que pour faire la même chose, il peut y avoir un facteur de 1 à 10 selon le langage employé.

De plus, dans des systèmes embarqués (automobile, avion, ...) pas mal de fonctions sont assurées par du matériel.

et dans facebook ou dans le site healthcare.gov, est-ce que le code HTML est compté dans les lignes de code ? parce que là, effectivement tous les compteurs sont explosés.
Inscrit le 14/07/2004
7719 messages publiés
flow (Modérateur(rice)) le 29/10/2013 à 20:17
C'est également que dans les systèmes embarqués, la taille de la mémoire est restreint.

Ensuite les normes de programmation et de certification sont très stricts (DO178B par exemple) où chaque ligne de code se doit d’être justifiée.
Inscrit le 30/09/2013
1264 messages publiés
C'est également que dans les systèmes embarqués, la taille de la mémoire est restreint.

Cela n'a rien à voir avec la taille du code source.
C'est une expérience que j'avais faite avec du C :
le code super compact de strcpy en C
strcpy(char *s1, const char *s2)
{
char *s = s1;
while ((*s++ = *s2++) != 0)
;
return (s1);
}

produisait un exécutable plus volumineux et plus lent que la même fonction codée "à la Pascal" c'est-à-dire avec un for et une copie d'une chaîne de l'un vers l'autre.
Cela dépend du compilateur : certains fonctionnent mieux lorsque toutes les étapes sont explicitement décrites.
Inscrit le 03/10/2011
6258 messages publiés
Oh là là ! Mais qu'est-ce que c'est que ce travail ! Mais ça va pas du tout ! C'est quoi ce test !=0, et les register, c'est fait pour les chiens.
Je te met 1/20, parce que t'as écrit quelque chose, mais c'est vraiment parce que je suis sympa.
Inscrit le 05/04/2011
491 messages publiés
Je ne pense pas qu'il aie commenté pour rendre sa copie, mais pour expliquer que le rapport nombre_de_lignes / performances a peu de sens.
Inscrit le 03/10/2011
6258 messages publiés
Non, mais voir qu'il y a plus de code dans Facebook que dans Windows ou Symbian, tend à me faire penser que Facebook est écrit avec les pieds.
[message édité par Centaurien le 30/10/2013 à 11:36 ]
Inscrit le 04/06/2010
2628 messages publiés
ok pour le != 0 qui rend le code trop clair, ça va pas ça ... :-)

par contre le register est fait pour les chiens... JAMAIS d'optimisation à la main, le compilo est plus malin que toi.

et d'ailleur rien ne dit que ce code fonctionnera sur une machine ayant des registres... merci de rester le plus possible virtuel et portable.

et de toute façon la fonction strcpy est interdite par tous bons chef de projet sous peine de licenciement immédiat ! :-)
Inscrit le 03/10/2011
6258 messages publiés
T'as qu'à appeler ta fonction copiechaine
Inscrit le 25/02/2013
946 messages publiés
faut arreter de dire les lignes de codes des logiciels propriétaire, on en a aucune preuve, c'est limite ridicule

et dans les lignes de codes, on comptes les commentaires? les sauts à la ligne pour clarifier son code? bref, c'est un peu du "kikitoutdure" ces comparaisons de codes qui au final ne veut pas toujours dire grand chose (a part montrer le travail effectué pour les logiciels, ca c'est bien de montrer)
Inscrit le 14/07/2004
7719 messages publiés
flow (Modérateur(rice)) le 29/10/2013 à 20:12
Est ce qu'il faut également compter les lignes de codes qui ont été misent par la NSA ?
Inscrit le 25/02/2013
946 messages publiés
bah pourquoi crois tu que Windows a tant de ligne de code ?
Inscrit le 06/11/2012
472 messages publiés
le "sloc" est une unité assez bien définit. Cela ne représente pas la même expressivité selon le langage, mais il a été montré que le nombre de sloc permet d'estimer le temps de développement.

https://en.wikipedia...e_lines_of_code
Inscrit le 23/11/2011
175 messages publiés
Pour Linux 3.1 pour avoir le même résultat qu'eux il faut inclure les commentaires et aussi la doc sous forme de tests.
Donc en effet on peut dire que cette infographie ne sert à rien.
Inscrit le 04/09/2002
2735 messages publiés
tout bon développeur sait que le nombre de lignes de code ne signifie strictement rien.

ça peut tout autant signifier que le code a été pondu avec les pieds, qu'il est super optimisé, qu'il est hyper clair, qu'il comporte un max de commentaires...

(..)t aussi étonnant que cela puisse paraître, Facebook mobilise par exemple plus de code qu'un Boeing 787, Curiosity ou la navette spatiale américaine...(..)

ben justement, faut espérer que le code pondu pour les trucs importants (autres que facebook donc) a été mûrement réfléchi et testé 36 fois.
pour facebook, je doute qu'il y ait autant de rigueur...

quoiqu'il en soit, le nombre de lignes ne veut de toute façon rien dire...
Inscrit le 20/03/2009
1122 messages publiés
+1
un très bon exemple en sont le milliers de scripts php qui trainent sur le web, pour la plupart c'est une bouillit innommable écrit même pas avec les pieds là mais avec les moignons.
de manière générale un code efficace est un code petit. quand à l'optimisation, disons que s'il faut 6 mois pour pondre un programme il faudrait 18 mois (ou 3 fois plus de personnes ça revient au même) pour pondre le même programme optimisé. du coup là ou l'optimisation n'est pas nécessaire et bien on s'en passe parce que ça revient très cher. j'ose imaginer que curiosity et facebook n'ont pas les mêmes contraintes, donc pas la même approche sur ce point...
Inscrit le 10/07/2008
3066 messages publiés
pour facebook, je doute qu'il y ait autant de rigueur...


Tu n'as plus à douter. Facebook est une énorme bouze. Je vois des éléments qui se déplacent (qui ne sont plus là où tu as cliqué_), d'autres qui disparaissent au mouseover parceque toute la mise en page s'est déplacée, des boutons qui se dissocient de la zone sensible allant même jusqu'à rendre la sortie d'une page impossible (t'as un unique bouton "oui", il est pas cliquable). Je dois ruser pour charger un album, le lien "publier" s'évanouit. Des éléments d'arrière-plan répondent à la souris quand tu déplaces les scrollbars et en ouvrent d'autres en premier plan, donc par-dessus celui que tu manipules. Je n'ai jamais vu un interface aussi merdique. Impression générale de foutoir, ergonomie bâclée, réactivité épouvantable. Ce logiciel serait réfusé à toute recette sérieuse. J'en viens même à penser qu'il va s'effondrer sous son obésité. Je précise que je l'utilise par obligation (je ne suis pas maso). Mon intime conviction est que les "applications web" ont des limites, en particulier à cause de l'asynchronisme des différents processus qui les composent, et que FB a été trop loin.
[message édité par /dev/tty le 29/10/2013 à 21:49 ]
Inscrit le 16/10/2011
1609 messages publiés
Tu parles de simples aspects cosmétiques je trouve (assez dérangeants il est vrai), ce n'est pas ça qui va faire le nombre de lignes de code.

Pour les curieux, le code php de Facebook en 2007 .
Inscrit le 04/06/2010
2628 messages publiés
pourtant ça a bien un sens ... un code gros est bien plus optimisé et fiable, car il a été déroulé de manière à être prouvé et relu facilement.

un bon chef de projet interdit les pseudo-optimisations et les écritures concises. Il allait jusqu'à interdire d'écrire i++
et obligeait d'écrire i = i + 1 .... c'est plus clair et ça se compile pareil de toute façon.

un boeing et office 2013 sont comparables car écrits tous les deux en C++. Le truc c'est qu'il y a tout simplement bien moins de fonctionnalités à avoir dans un boeing...
Inscrit le 06/11/2012
472 messages publiés
Boeing en C++, c'est sûr ?
Inscrit le 03/10/2011
6258 messages publiés
Boeing, ça doit être de l'ADA et office, il doit y avoir du .NET de merde dedans.
Un bon chef de projet ...
Mais un bon chef de projet, mon p'tit gars, il n'est pas là pour regarder comment ton programme est écrit, il est là pour gérer le projet
Inscrit le 24/10/2012
16 messages publiés
Je suis assez d'accord avec toi. Oui, un chef de projet à autre chose à faire... par contre il y a des revues par les pairs du code et des règles de codage. L'Ada est privilégié pour la réalisation de fonctions critiques, c'est un langage strict et qui fourni nativement tous le nécessaire pour gérer les contraintes temps réel, et des compilateurs facilement certifiable avec les pires contraintes.

Et en Ada ce n’est pas possible de faire de l'incrémentation style "i++".
[message édité par reven le 30/10/2013 à 14:19 ]
Inscrit le 04/06/2010
2628 messages publiés
et si c'est écrit avec les pieds, le projet il marche pas .... c'est con hein ...

je ne suis qu'un gestionnaire super... gestonnaire d'un truc qui marche pas.

sinon .NET n'est pas un langage mais un framework... je vois que tu maitrises ...

et ADA oui, mais 10% à tout casser... tu crois quand même pas que le code de l'interface graphique des écrans cockpit est en ADA ?
Inscrit le 05/10/2011
2885 messages publiés
"pourtant ça a bien un sens ... un code gros est bien plus optimisé et fiable, car il a été déroulé de manière à être prouvé et relu facilement."

Euh. Tu as de l'expérience sur des projets avec beaucoup de lignes de code ? Parce que je peux t'assurer que c'est pas parce qu'il y a plein de lignes de code que c'est optimisé et fiable. Je peux te faire un beau projet bien gros à coups de copier/coller de code partout.

Et le chef de projet qui définit les bonnes pratiques de code, c'est particulièrement étrange.
[message édité par milord le 30/10/2013 à 11:18 ]
Inscrit le 04/06/2010
2628 messages publiés
et bien si tu veux rendre le code lisible, il faut beaucoup de ligne de code, c'est le b-a-ba.

régle n°1 du dev : KEEP IT SIMPLE & STUPID

tu écris ça en caractères rouges de 50cm sur les murs de tous les bureaux

ya pas de différence entre les projets à beaucoup de lignes et à pas beaucoup.
un projet étant découpé en boite noire élémentaires et testée unitairement.

qu'il y en ait 5 ou 500 boites noires, ça se passera bien si elles ont toutes passé les tests unitaires.

au passage, je vous signale les "pro de l'info", qu'on considère raisonnablement un bug toutes les 30 lignes si vous êtes bons.

un bug, c'est à dire un point où le code ne fait pas exactement ce que vous croyez qu'il fait.

et oui ... humilité ...
Inscrit le 05/10/2011
2885 messages publiés
"et bien si tu veux rendre le code lisible, il faut beaucoup de ligne de code, c'est le b-a-ba."

Quand tu veux faire un code lisible, tu dois en général écrire plus de fonctions pour rendre les tests unitaires plus faciles et pour rendre ton code plus parlant. Ca c'est vrai. Mais ça n'implique absolument pas que qu'un projet qui compte énormément de lignes de code soit forcément plus optimisé et fiable. Et ça c'est ce que tu as dit, je le rappelle, et c'est profondément stupide.

"ya pas de différence entre les projets à beaucoup de lignes et à pas beaucoup.
un projet étant découpé en boite noire élémentaires et testée unitairement.

qu'il y en ait 5 ou 500 boites noires, ça se passera bien si elles ont toutes passé les tests unitaires."

Ouais ça c'est dans le monde des bisounours... Dans la réalité, on tombe la plupart du temps sur des gros projet monobloc et/ou avec une mauvaise couverture de code des tests unitaires. Et donc le nombre de lignes de code n'est témoin de rien du tout, surtout pas de la qualité du développement.

Je peux pas croire que tu aies un jour bossé dans le développement. Rassure moi, ce n'est pas le cas ?
Inscrit le 04/06/2010
2628 messages publiés
j'ai jamais dit que les projets à million de ligne étaient plus fiables !
au contraire, plus ya de ligne, plus ya de bug potentiel, forcément.

un projet printf("hello world"); ne comporte aucun bug !

les fonctions c'est simple c'est une fonction par page écran.

je dis juste que dé-conciser lel code le rend très lisible, et qu'il faut aussi éviter tout ce qui est code astucieux et soi-disant optimisé.

j'ai jamais bossé dans le dev merdique, j'ignore les pratiques de n'importenawak... mais vu le taux de projet arrivant à terme et livré, je devine que c'est bien le bordel avec des kevin partout ...
Inscrit le 05/10/2011
2885 messages publiés
"les fonctions c'est simple c'est une fonction par page écran."
Je pense que tu devrais faire un livre avec toutes tes règles de développement. Ca m'étonnerait que ça se vende dans le monde professionnel, mais tu as peut-être une chance de te faire de la thune en le vendant à des étudiants.

"je dis juste que dé-conciser lel code le rend très lisible, et qu'il faut aussi éviter tout ce qui est code astucieux et soi-disant optimisé."
Tu en as beaucoup des lieux communs comme ça ?

"j'ai jamais bossé dans le dev merdique"
Franchement, je doute que tu aies bossé dans le dev tout court.
Inscrit le 13/08/2013
117 messages publiés
"un bon chef de projet interdit les pseudo-optimisations et les écritures concises. Il allait jusqu'à interdire d'écrire i++
et obligeait d'écrire i = i + 1"

Donc non seulement il s'occupe du code plutôt que de son boulot de chef de projet, mais en plus il embête les devs avec des règles inutiles.
Oui oui, c'est un "bon" chef de projet.
Inscrit le 04/06/2010
2628 messages publiés
c'est utile d'avoir une appli qui tourne à la date prévue. c'est LE boulot du chef de projet.

si kevin-j-mi-connait a fourré quelques bug vicieux en écrivant du code de porc, c'est la catastrophe.
Inscrit le 05/10/2011
2885 messages publiés
Faire un i++, c'est du code de porc ?

J'ai rarement vu un projet prendre du retard parce que les développeurs avaient utilisé i++.
Inscrit le 04/06/2010
2628 messages publiés
c'est le cas extrème qui permet de rappeller à tous et tous les jours d'écrire de l'hyper clair...

tous les jours tu te dis t'ain il me gave avec son i = i +1, mais ça forge la discipline.

par exemple a[ i ] = i++ ;

cette merde compile sans warning sur un compilo un peu ancien et ça fait n'importe quoi...

combien de kevin savent que cette écriture fait n'importe quoi ?
Inscrit le 05/10/2011
2885 messages publiés
J'en sais rien... tu précises même pas de quel langage il s'agit.
Et je dirais que si t'es mon chef de projet et que tu viens me dire que j'ai pas le droit d'utiliser i++ parce que dans certains cas ça produit des bugs, je me fous de ta gueule, et je te dis d'aller t'occuper de ton planning et de tes ressources.
Inscrit le 05/09/2009
275 messages publiés
Amusant les différences entre, dans l'ordre, Windows XP, puis Windows Vista plus bas. ET au final Windows Seven juste avant XP.
Inscrit le 03/10/2011
6258 messages publiés
ça doit être ce code en plus qui fait que Vista rame autant.
Inscrit le 22/08/2011
258 messages publiés
le C++ est correct en temps réel , ce qui n 'est pas le cas du Java
Inscrit le 04/06/2010
2628 messages publiés
ça n'a pas de sens, ça dépend des specs... une machine java peut être largement assez rapide pour un delta T temps réel pas trop petit ...

j'ai fait des appli temps réel de commande de four, où la période d'échantillonnage est 1 seconde... t'as le temps !
[message édité par marinebis le 30/10/2013 à 15:18 ]
Inscrit le 22/08/2011
258 messages publiés
Je pensais plus à des systemes de pilotages , d ' armement , de firewall ... le job de QNX en fait
Inscrit le 20/01/2006
20 messages publiés
Il faudrait savoir le nombre de lignes de code utile et le nombre de lignes de code servant à corriger les bugs.
Inscrit le 30/10/2013
1 messages publiés
de toute façon, ce n'est pas la taille qui compte !
Inscrit le 18/03/2008
774 messages publiés
ne nombre de lignes de code te donne une vague idée de la quantité de temps de programmation passée sur le projet quand même. C'est pas indicatif de la qualité du programme ou de son efficacité en revanche.

Je connais des boites où le style demandé aux développeurs est très explicite, pas de oneliners, et beaucoup de commentaires.

Si facebook c'est ce genre ça m'étonnerait pas que leur code soit tout de suite très volumineux.
Inscrit le 03/11/2010
1084 messages publiés
Chouette, un concoure de taille de bit.....


Wait, de taille de code.

Ce qui est tout aussi intéressant.
Inscrit le 03/10/2011
6258 messages publiés
Reste à savoir qui vole le plus haut.
Est-ce que ça dépend de la taille du code ?
Répondre

Tous les champs doivent être remplis.

OU

Tous les champs doivent être remplis.

FORUMS DE NUMERAMA
Poser une question / Créer un sujet
vous pouvez aussi répondre ;-)
Numerama sur les réseaux sociaux
Octobre 2013
 
Lu Ma Me Je Ve Sa Di
30 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 1 2 3
4 5 6 7 8 9 10