Bonjour,

Je n'y connais absolument rien en programmation.

J'y ai touché un peu étant plus jeune, j'étais tout fier de savoir faire une calculatrice ou alors un questionnaire

Je me demandais juste, est-ce que la programmation a encore de beaux jours devant elle ?

Ça vaut encore le coup de commencer ?

Je me demande dans quel sens ça va évoluer ? Est-ce que le C, C++ sera encore à jour dans plusieurs années ?

Pardonnez mon ignorance.

Ne me lynchez pas

Salut,

Oui la programmation à beaucoup d'avenir bien évidement, mais la programmation ne se suffit pas à elle même, si tu veux programmer il faut bien avoir quelque chose à programmer, de par le fait c'est utile d'avoir d'autres compétence que la programmation.

Pour devenir développeur un langage de programmation c'est bien mais c'est pas suffisant, généralement tu va aussi avoir besoin de stocker des données, donc connaitre les SGBD et SQL, et donc devoir te former dans bien des domaines...

Donc pour devenir développeur il faut apprendre bien plus qu'un simple langage de programmation.

D'autre part les cibles en programmation se sont diversifiées, en plus de la programmation classique tu as aussi le développement pour les plateformes web , mobiles et embarquées, plus la nouvelle mode du "cloud", et tout cela demande des connaissances spécifiques.

Généralement les gens se spécialisent dans un domaine pour se rendre vraiment utile.

Et en même temps pour être un bon programmeur il faut avoir plusieurs cordes à son arc, connaître au moins un langage de chaque type, et continuer à en apprendre. Et aimer programmer pour le fun, en dehors du taff :p

Je plussoie grandement ce que mes VDD ont dit.

Surtout Silvermo avec "Et aimer programmer pour le fun, en dehors du taff"

Et la programmation est toujours aussi active, il n'y a pas de baisse de régime, les nouvelles technologies usent de la programmation sans exceptions (Smartphones, Tablettes, etc.).

Je ne vois par conséquent pas ce qui te fait peur de perdre ton temps.

Essayes, si tu aimes continues, sinon arrêtes, c'est qu'un simple loisir à l'origine, ce n'est qu'après que ça doit se transformer en volonté d'en faire son métier.

Bon courage.

Oui y a de l avenir, mais clairement c est pas seulement un language, etant devellopeur, je dois connaitre un language, le sql, des logiciel comme eclipse, des serveurs d applications comme tomcat, des outils de design comme photoshop. Bref fait en connaitre un max... Et l informatique ca fait que commencer. Donc pas
De soucis pour l avenir

Bonsoir,

« Je me demande dans quel sens ça va évoluer ? Est-ce que le C, C++ sera encore à jour dans plusieurs années ? » cette série de question sauve le sujet.

Il est clair que la programmation est devenue omniprésente, et que le besoin d'écrire des programmes n'est pas prêt de disparaître. Après, évidemment que la façon de programmer va évoluer. Il y a beaucoup de recherche sur le sujet, car il y a encore pas mal de choses que l'on ne maîtrise pas bien. Et je ne doute pas qu'on va continuer à progresser dans les prochaines années.

Pour ce qui est des langages, le C et le C++ sont tellement ancrés partout que ça me paraît improbable qu'il disparaisse dans les 20 prochaines années. De plus, ils ont été révisés encore l'an dernier, ce qui montre que ces langages arrivent à s'adapter un minimum afin de survivre au temps qui passe.

Pour Java, ça me semble être une mode qui va déjà en diminuant. C'est très utilisé aujourd'hui car tout le monde s'est mis à coder en java il y a une dizaine d'année, et qu'il faut bien maintenir/mettre à jour tout ça. Mais ce n'est pas du code aussi central que pour le cas du C/C++, donc je serais moins surpris de voir l'usage de Java se marginaliser.

Après, vu l'évolution des mentalités et le caractère de l'Humain, je pense aussi qu'on va continuer encore un peu vers la multiplication des langages. L'histoire montre que les langages qui ont eu un minimum de succès restent même lorsqu'ils ne sont plus vraiment utilisés (cf Ada, Pascal et Fortran). Et pendant ce temps là, d'autres langages apparaissent (cf la tentative récente de Google).

La clé du bon programmeur, c'est d'avoir des connaissances très générales sur la théorie des langages de programmation. Ainsi, on sait "programmer" sans dépendre d'un langage. Ou plus précisément, on saura à un instant donné quel langage choisir pour un problème fixé, et comment faire dans les grandes lignes (même si on ne connaît rien à la syntaxe même du langage).

L'avènement des architectures massivement parallèles va sans doute favoriser la croissance des langages fonctionnels.

42.....,
Moi j'en doute beaucoup au contraire. On nous bassinne de programmation fonctionnel qui est bien pour le calcul parallel. Mais j'attends toujours de voir une application grosse application pour machine parallele qui ne soit pas programmer en C, en C++, en fortran ou dans un langage specifique a la machine (genre cuda).

J'allais émettre des doutes... mais godrik l'a fait avant moi.

Le fait est que le fonctionnel pur (ce qui en vrai ne court pas les rues) présente des avantages quand il s'agit d'obtenir une exécution parallèle du code. Mais en contrepartie, et malgré les progrès ces 10 dernières années, les programmes fonctionnels sont lents et on n'atteint pas les performances des programmes C parallèles équivalents.

Après, nos machines actuelles ont 4 (au mieux 8) coeurs. Ce n'est pas du massivement parallèle, et de fait c'est tout juste bon pour faire du parallélisme au niveau application (= mettre à jour son antivirus ou windows tout en jouant à Diablo 3 sur l'écran de gauche et en causant sur skype sur l'écran de droite). Bref, le code lui même n'a pas tellement besoin d'être parallèle en fait.

Bien sûr, dans un cadre professionnel ce que je dis ne tiens pas. Mais même chez les pros, tout le monde ne fait pas du calcul intensif distribué ou sur GPU (ou les deux).

Oui alors je suis tout à fait d'accord avec vous deux. Je dis juste que si un jour les compilateurs deviennent assez intelligents pour paralléliser du code automatiquement, cela se fera correctement que sur des langages fonctionnels purs. Et c'est tout à fait vrai que le paradigme purement fonctionnel ne courent pas les rues actuellement. Haskell est quand même à mes yeux ce qui s'en rapproche le plus.

godrik
Le C, le C++ et le fortran ont quand même une base très solide et qui date de la nuit des temps. C'est tout à fait normal qu'ils dominent dans ce domaine. Les langages fonctionnels sont encore loin du degré d'optimisation de ces mastodontes, et c'est normal, j'ai envie de dire.

Chris_27
Je pense quand même que pour les applications de tous les jours, le mieux serait que le code soit parallélisé. Je trouve ça scandaleux que certains jeux, algorithmes de compression, ou même navigateur ne le soit pas. En terme de rapidité, c'est devenu essentiel.

Le probleme du paradigme fonctionnel, c'est que c'est de la merde pour faire des applications de la vraie vie. C'est a dire des applications fortement couple avec des lib externes pas forcement suivant ton modele de programmation. C'est a dire des applications temps reel. C'est a dire des applications qui font beaucoup d'I/O.

Pour toute application qui demande des performances (et donc du parallelisme), il y a le grand probleme des I/O et des effets de bords. Si tu n'as pas un controle parfait sur a quel moment tes I/Os sont effectue, tu n'auras jamais de haute performances.

La bonne utilisation des GPUs demandent d'avoir du code extrement synchronise ou les donnees sont streame dans la memoire du GPU avec un ordonnancement juste a temps.

la bonne utilisation des machines NUMA demande un positionnement des taches de calcul optimales, ce qui demande d'exposer explicitement au programmeur le positionnement des donnees. L'ordonnancement des communications entre les differents noeuds NUMA devient imperatif.

42..., tu dis qu'il faudrait que le code des applications soient parallelise. Je ne suis pas d'accord avec ca. La parallelisation est quelquechose de tres complique et mal paralleliser une application peut etre tres nefaste pour les performances. Deplus, quand toutes les applications deviennent paralleles, le probleme du partage de ressource devient important. Deux applications paralleles qui tournent en meme temps sera bien plus lent que deux applications sequentielle qui tournent en meme temps.

Ce probleme de partage de ressources de calcul au niveau du systeme n'est actuellement pas regler. Les applications paralleles cohabitent tres mal.

Avoir des algorithmes paralleles pousse un parallelisme a grain fin. Ce qui n'est pas forcement souhaites. Un parallelisme a gros grain est souvent preferable pour eviter les overheads de synchronisation. A moins que tu rencontres des problemes qui sont cache-constraint. Auquel cas, le parallelisme a grain fin est le seul qui fonctionnera.

tl;dr Le probleme du calcul parallele pour des machines de bureau n'est pas regler du tout. Il n'est pas clair qu'une strategie de tout parallele ne finissent pas par degrader les performances des machines a moyen terme.

« Haskell est quand même à mes yeux ce qui s'en rapproche le plus. » et c'est surtout le seul langage fonctionnel à ma connaissance qui vaille quelque chose coté parallélisme. D'où ma formulation tout à l'heure.

« ou même navigateur ne le soit pas. » alors là je t'arrête net. Ose encore me dire que firefox (enfin, iceweasel ici) n'est pas parallèle après ça :
http://chadok.info/~cmouille/screenshots/damned_firefox.png
Nan, vraiment, firefox fait déjà bien trop de parallélisme sur ma machine qui n'a qu'un seul coeur (sic). Et plus ça vient, plus les threads popent, et plus c'est lent globalement. Donc ce qui est scandaleux, c'est surtout de faire du parallélisme comme un pignouf.

godrik
En ce qui concerne le grand problème des I/O, je suis entièrement d'accord. Mais parler de problèmes d'effet de bords sur un langage purement fonctionnel, c'est simplement pas possible.

En ce qui concerne le parallélisme bureautique, je précise que c'est utile pour certains types d'applications uniquement. Mais en effet, le tout parallèle cohabiterait sans doute très mal sur nos processeurs actuels. Par contre, sur des 80 cœurs le problème ne se pose même plus. La cohabitation est possible.

Chris_27
Le parallélisme d'Haskell est vraiment bien foutu, je trouve.
Par contre, c'est vrai que j'avais oublié le parallélisme crasse de firefox. Je pensais plutôt à l'idée one thread per tab de chrome. Mais là je te rejoins complètement.

« l'idée one thread per tab de chrome » bonne idée ça tient. Tu n'as qu'un seul tab d'ouvert à chaque instant, donc c'est clairement génial de se payer les surcouts liés au thread pour l'heureux tab à afficher.

« Par contre, sur des 80 cœurs le problème ne se pose même plus. La cohabitation est possible. » oui, vu l'augmentation du pouvoir d'achat, le français moyen n'aura plus les moyens de payer la facture EDF une fois qu'il aura fait l'acquisition de la machine.

intel avait fait un projet sur un processeur avec ce nombre de coeurs, il s'appellait Penryn ou Larrabee, et ça n'avait pas l'air de nécessiter une tranche entière de réacteur nucléaire...

ça devait être de petits coeurs?

" bonne idée ça tient. Tu n'as qu'un seul tab d'ouvert à chaque instant, donc c'est clairement génial de se payer les surcouts liés au thread pour l'heureux tab à afficher. "

En lisant ça j'écoutais un stream ouvert dans un autre onglet, tout en chargeant une page dans un autre onglet. Et ça tournait plutôt bien. Pas sûr que ce soit une mauvaise idée de mettre un thread par tab

"Pas sûr que ce soit une mauvaise idée de mettre un thread par tab "

une de mes connaissances utilisait Opera, et avait la flemme de fermer ses onglets: quand il avait besoin d'aller quelque part, il ouvrait un nouvel onglet. son nombre d'onglet était estimé à plus de 600 après quelques mois et son pc fonctionnait encore parfaitement. je ne suis pas sûr que 600 processus lourds, même des processus qui ne font rien, ne soient pas sans dommage pour les performances de la machine, il y a bien un moment où il faut les commuter et cette opération est lente.

4223161584, les code non jouet passent leurs temps a faire des effets de bords. Et avec l'augmentation de la puissance de calcul et la stagnation des vitesse d'entree/sortie, les IOs prennent le devant de la scene en terme de performance. Le probleme n'est quasiment jamais de calculer plus vite. Le probleme est de streamer les donnees plus vite, ou de streamer moins de donnnes.

"Par contre, sur des 80 cœurs le problème ne se pose même plus."

Sauf que ca n'existe pas les machines a 80 coeurs dans les machines de bureau. J'imagine que tu fais reference au projet Larabee de intel. Ce projet est completement mort et a ete remplace par Many Integrated Core (MIC). J'ai bosse sur un prototype Knights Ferry[1] et on devrait bientot recevoir un Knights Corner. Ca a en effet une puissance de calcul potentiellement monumental, mais la encore, la bonne repartition des communications memoire<->cache est un bottleneck majeure a regler. Comme sur les GPUs d'ailleurs. Extraire du parallelisme est quelquechose de relativement trivial sur les applications modernes. Arrive a deployer ce parallelisme sur une architecture particuliere est une autre histoire.

Intel developpe aussi des processeurs a 10 coeur (xeon westmere), mais ces processeurs ne sont pas destine a des machines de bureau. C'est plutot des proc comme les i5 qui finissent sur les bureau.

[1] http://bmi.osu.edu/~esaule/public-website/paper/mtaap12-SSC.pdf

"Ca a en effet une puissance de calcul potentiellement monumental, mais la encore, la bonne repartition des communications memoire<->cache est un bottleneck majeure a regler. Comme sur les GPUs d'ailleurs. Extraire du parallelisme est quelquechose de relativement trivial sur les applications modernes. Arrive a deployer ce parallelisme sur une architecture particuliere est une autre histoire."

Je suis entièrement d'accord avec ce que tu dis ici. Et ton papier est bien sympathique. Je travaille aussi sur quelque chose de similaire mais entièrement sur GPU. Faire un usage correcte de la mémoire shared et des threads dépend beaucoup du type d'applications, c'est bien vrai. Dans le domaine que je traite (simulation Monte-Carlo) l'aspect crucial c'est bel et bien la gestion de la mémoire. Par contre, je ne comprends pas très bien ce que tu veux dire par :

"les IOs prennent le devant de la scene en terme de performance"

De quels IOs parles-tu?