Discussion :

[gangsoleil]

Déjà vu de nombreuses fois dans des codes....

tab[++i] ...

Tu as manqué le premier élément, et tu vas au delà du dernier

Ou pire, tu initialises la variable a -1, pour ne pas louper le premier element. Comme ca, si tu dois rajouter du code apres, tu es certain qu'il y ait une grande chance pour aller lire tab[-1]...

Es-tu d'accord que {tab[++i];} est équivalent à {i=i+1;tab[i];} ?

Sans plus, oui.
Mais je rappelle pour les petits malins que les codes suivant ont un comportement indetermine :

tab[i++] = i++;
tab[++i] = ++i;

Le principal, c'est de faire du code lisible par tous -- du moins par tous ceux connaissant la syntaxe du langage.

[Invité]

@françois: encore une fois, je parle de principes, ce ne sont pas des lois immuables ni des dogmes. Si le for ou le ERI (erase-remove idiom) ne respectent pas SoC, on ne va pas en faire une histoire.

C'est d'autant plus étrange que tu parles de principes. Tu ne veux pas du ternaire parce qu'il ferait plusieurs choses, et qu'il violerait donc un bon principe du C++ moderne, qu'une bonne moitié des constructions standard sur C++ (moderne ou pas) violent également...

Il faut choisir, alors, soit le SoC est quelque chose de très important, et dans ce cas, on peut se demander s'il faut encore utiliser le C++. Soit ce n'est pas si important que cela, et alors, je ne vois plus très bien en quoi le ternaire est une "mauvaise pratique".

Ce que j'essaye de dire, je crois, c'est que l'informatique théorique vit toujours dans le mythe du "silver bullet": la solution miracle à tous nos problèmes. Les théoriciens, concepteurs de langages, professeurs, ou auteurs de librairies (écrire une librairie, ca n'a pas grand chose à voir avec développer et maintenir un programme) adorent raisonner en paradigme, et nous vendre "leur" solution miracle à tous nos problèmes.

Les praticiens voient les choses différemment, et ont généralement tendance à écouter les théoriciens, mais à ne pas prendre très au sérieux ce qui concerne les remèdes miracles. Et c'est peut être la vraie différence entre les jeunes diplomés et les vieux informaticiens : au fond, on ne fait pas tout à fait le même métier...

Francois

[Invité]

et alors tu parles toi même de performance différente, certainement pas de but premier différent : stocker des données. quoi ça soit map, vector ou list, tu pourras associer plus ou moins facilement un index à une donnée

Ce qui stocke des données, ce ne sont pas des conteneurs mais des fichiers, ou leur équivalent en mémoire. Le conteneur, c'est un moyen permettant d'accéder à des données, d'en ajouter, d'en enlever, de les modifier, de les rechercher, en fonction de leur valeur ou de leur position dans le conteneur (quand celle ci a un sens).

Et d'un conteneur à l'autre, les fonctions changent.

Par exemple, sur une table de hachage, la notion de "suivant/précédent" n'a aucun sens, elle existe dans les listes, les tableaux, et les associatifs triés. De même, la notion de position dans le conteneur, indispensable pour le tableau, n'a pas réellement de sens dans les tables associatives, ou dans les tables de hachage, et elle n'est pas réellement utilisée dans les listes (en général on n'implémente pas d'opérateur [])

Quant à la performance, c'est tout sauf un détail, sinon, on n'aurait qu'un conteneur depuis longtemps, non?

je vais prendre un autre exemple, j'ai de 10 à 100 entiers à stocker, des fois de temps en temps je fais des insertions et des suppressions, alors vector ou list?

En C++, et sous réserve de la façon dont tu accèdes à ces données (tu ne le précises pas), vector parce que c'est le "type par défaut", moins d'empreinte mémoire, interface maximale. Mais bon, ensuite, si tes programmes ne stockent jamais plus de 100 entiers à la fois, il est clair que tout ceci n'a aucune importance.

Maintenant, je travaille peut être dans un secteur très spécial, mais j'ai la sensation que les tableaux de quelques millions d'entiers ne sont pas si rares, dans un programme "normal".

Francois

[souviron34]

ça me rappelle qqun qui n'utilisait exclusivement des char* à la place des string sous prétexte que c'est plus rapide, et ça même pour les fonctions utilitaires qui ne sont appelés qu'une seule fois dans toute la vie d'un programme.

Sans doute, cependant

a) à un moment T, on te dit que ça doit communiquer avec un programme en C
b) à un moment T', on te dit que ça doit communiquer avec un programme en Pascal
c) à un moment T", on te dit qu'il faut que ça envoie via TCP/IP et sockets...

Ben ce sera nettement plus simple si c'est déjà sous forme de char*...

et encore un cas très particulier pour essayer d'en tirer un enseignement général ...

je vais prendre un autre exemple, j'ai de 10 à 100 entiers à stocker, des fois de temps en temps je fais des insertions et des suppressions, alors vector ou list?
bah n'importe lequel, mes contraintes en temps et en place sont tellement insignifiantes que l'un ou l'autre n'aura pas de conséquences dramatique à l'exécution.

est ce que je peux dire que dans tous les cas ça sera vrai? bah non, par contre si j'ai suffisamment découpé mon code, je pourrai changer de conteneurs assez facilement et m'adapter à d'autres contraintes.

C'est justement ce que j'essayais de dire...

La NORME apprise dans les formations et dans les manuels du bon petit programmeur et dans la grande majorité des algos trouvés de nos jours sur les sites ou les forums priiviilégient les listes simplement ou doublement chaînées..

SANS SE POSER DE QUESTIONS....

Or, contrairement à ce que tu sembles penser, le problème est très présent : toute les demandes de données géo-références - avec l'explosion des GPS, du Web et des cartes dynamiques, des applis pour mobiles et smartphones, etc...

Plus tout ce qui est développement embarqué... et les jeux... qui, si on regarde les annonces, représentent une bonne part du boulot...

Donc non ce n'est pas "un cas très particulier".. ça l'était, mais ça devient de plus en plus un cas général, au contraire...

Avant c'était par manque de mémoire qu'il fallait la surveiller. Maintenant c'est par le nombre d'applis en //, l'immensité des bases, le nombre des utilisateurs simultanés, et la sophistication des applis qu'on veut faire tourner avec de petits moyens...

C'est au contraire de plus en plus d'actualité...

Ce que j'essaye de dire, je crois, c'est que l'informatique théorique vit toujours dans le mythe du "silver bullet": la solution miracle à tous nos problèmes. Les théoriciens, concepteurs de langages, professeurs, ou auteurs de librairies (écrire une librairie, ca n'a pas grand chose à voir avec développer et maintenir un programme) adorent raisonner en paradigme, et nous vendre "leur" solution miracle à tous nos problèmes.

Les praticiens voient les choses différemment, et ont généralement tendance à écouter les théoriciens, mais à ne pas prendre très au sérieux ce qui concerne les remèdes miracles. Et c'est peut être la vraie différence entre les jeunes diplomés et les vieux informaticiens : au fond, on ne fait pas tout à fait le même métier...

[r0d]

C'est d'autant plus étrange que tu parles de principes. Tu ne veux pas du ternaire parce qu'il ferait plusieurs choses, et qu'il violerait donc un bon principe du C++ moderne, qu'une bonne moitié des constructions standard sur C++ (moderne ou pas) violent également...

Une bonne moitié certainement pas. Quelques uns, certes. Mais cela ne m'empêche pas, effectivement, d'essayer constamment d'améliorer le code que je produis. Et la théorie est un des outils qui est à ma disposition. Le c++ a des défaut, et la boucle for en est un. Il y a d'ailleurs un débat, un peu trollesque mais tout de même très intéressant, sur le forum c++ qui pose la question de la suppression du mot-clé for.

C'est également mon expérience personnelle qui m'a amené à m'intéresser à certaines questions théoriques qui paraissent inutiles, comme par exemple la sémantique, la const-conformité et ce genre de choses. Je me rend compte que, dans le cadre professionnel, je passe plus de temps à modifier du code, parfois le mien, qu'à en créer du neuf. Comprendre un code (parfois le mien) est une des activité qui me prend le plus de temps en réalité, peut-être plus que l'écriture de code. De là en découle le besoin de gagner du temps sur cette tâche, donc d'essayer de trouver des outils pour cela. Je ne sais pas selon quelle proportion, mais l'analyse (lecture et compréhension du code) est une des tâches sur lesquelles nous passons le plus de temps.

Sur le forum c++ nous essayons d'insister sur la sémantique et la lisibilité car c'est, selon nous, une façon d'améliorer globalement la qualité des logiciels. De nos jours, un logiciel important voit passer plusieurs développeurs, souvent des dizaines. Si chacun fait un effort sur des choses comme la lisibilité, la sémantique et la cohérence, alors le logiciel en question sera de meilleure qualité et les développeurs qui travailleront dessus auront plus de temps pour faire les choses bien car ils en perdront moins à comprendre le code. Il n'est pas question du saint graal, mais de petites choses qui changent réellement et concrètement le quotidien des développeurs.

[souviron34]

Je rebondirais sur ce que vient de dire François :

et? c'est du niveau du détail de comment le service est rendu et de l'implémentation, certainement pas du service en lui même.
...
et alors tu parles toi même de performance différente, certainement pas de but premier différent : stocker des données.

Si la performance n'a pas d'importance dans ton milieu, tant mieux pour toi...

Mais c'est - très loin - d'être le cas général en informatique..

Sinon pourquoi parlerais-t-on de "compelxité algorithmique" ou de "compelxité spatiale" ??

Essaye de faire une recherche dichotomique avec une liste , ça va être du sport....

Essaye de stocker dans un maillage 3D de 1000 * 1000 * 1000 25 paramètres par point avec des listes chaînées...

Sur le forum c++ nous essayons d'insister sur la sémantique et la lisibilité car c'est, selon nous, une façon d'améliorer globalement la qualité des logiciels. De nos jours, un logiciel important voit passer plusieurs développeurs, souvent des dizaines. Si chacun fait un effort sur des choses comme la lisibilité, la sémantique et la cohérence, alors le logiciel en question sera de meilleure qualité et les développeurs qui travailleront dessus auront plus de temps pour faire les choses bien car ils en perdront moins à comprendre le code. Il n'est pas question du saint graal, mais de petites choses qui changent réellement et concrètement le quotidien des développeurs.

Je ne sais pas sur le forum C++, mais sur le forum C aussi on pousse à ça.. De même que dans le forum Débats...

Par contre, cela va - pas toujours, mais fréquemment - à l'encontre justement de la "modernité" de certaines features/inclusion (par exemple il y a eu toute une discussion sur 2 points de la norme C11, ou plus précisément de 2 points ajoutés dans C11 et de quelques uns retirés de C99.. Qui a bien été moderne à un moment donné, hein ? (http://www.developpez.net/forums/d11...n-est-achevee/).. Quand je m'y étais opposé à l'époque, et avant C11, on m'avait traité de retardé... Ben C11 a corrigé quelques points que j'avais noté )

[r0d]

Ce qui stocke des données, ce ne sont pas des conteneurs mais des fichiers, ou leur équivalent en mémoire. Le conteneur, c'est un moyen permettant d'accéder à des données, d'en ajouter, d'en enlever, de les modifier, de les rechercher, en fonction de leur valeur ou de leur position dans le conteneur (quand celle ci a un sens).

C'est une approche, mais il y en a une autre, le SRP, (single responsability principle) qui préfère que le conteneur se contente de contenir les donénes, et que toutes les manipulations soient faites de l'extérieur. C'est l'idée de l'en-tête <algorithm> de la STL. Mais la STL est un peu un foutoir, et ses conteneurs ont aussi de grosses interfaces.

[Invité]

Il y a d'ailleurs un débat, un peu trollesque mais tout de même très intéressant, sur le forum c++ qui pose la question de la suppression du mot-clé for.

J'espère que ce n'est pas pour la remplacer par for_each(), transform() ou quelque chose du genre. Parce que là, on est quand même un peu dans le foutage de gueule.

Si tu veux un langage sans boucle, il faut faire de l'APL, ou du J (tiens un vieux fil qui en parle)
http://www.developpez.net/forums/d86...s-pratiquants/

Je ne sais pas selon quelle proportion, mais l'analyse (lecture et compréhension du code) est une des tâches sur lesquelles nous passons le plus de temps.

Bien d'accord, et c'est la chose la moins bien enseignée. La plupart des informaticiens ont du mal à lire du "code des autres" et encore plus à le lire en se disant que l'autre n'était peut être pas un imbécile qui codait avec les pieds.

Ceci dit, je ne connais pas d'informaticien qui écrive du code illisible. Chacun a son style, comme quand on écrit ou on parle, mais la plupart des professionnels écrivent correctement.

Sur le forum c++ nous essayons d'insister sur la sémantique et la lisibilité car c'est, selon nous, une façon d'améliorer globalement la qualité des logiciels.

Des logiciels je ne crois pas, du code, peut être... Ce qui m'ennuie dans cette approche (et qui fait que je ne traine plus trop sur le forum C++), c'est le côté novlangue et l'obsession du "moderne" qui va avec. En fait, tout le monde a lu les mêmes livres, partage la même vision de ce que doit être un "bon C++", et de ce qui est "moderne", ce qui fait une discussion un peu pauvre, et très répétitive.

Je n'en conteste pas l'utilité, remarque...

Francois

[stardeath]

Ce qui stocke des données, ce ne sont pas des conteneurs mais des fichiers, ou leur équivalent en mémoire. Le conteneur, c'est un moyen permettant d'accéder à des données, d'en ajouter, d'en enlever, de les modifier, de les rechercher, en fonction de leur valeur ou de leur position dans le conteneur (quand celle ci a un sens).

Et d'un conteneur à l'autre, les fonctions changent.

Par exemple, sur une table de hachage, la notion de "suivant/précédent" n'a aucun sens, elle existe dans les listes, les tableaux, et les associatifs triés. De même, la notion de position dans le conteneur, indispensable pour le tableau, n'a pas réellement de sens dans les tables associatives, ou dans les tables de hachage, et elle n'est pas réellement utilisée dans les listes (en général on n'implémente pas d'opérateur [])

et alors, puisque tu sembles pinailler sur le vocabulaire, vu qu'il n'y a pas de conteneur miracle, tu vas forcément faire des concessions, soit en perf, soit en flexibilité, etc. donc forcément perdre sur un des tableaux, et les perfs ou l'empreinte mémoire ne sont pas primordiaux pour tout le monde.
bref je répète ce que j'ai dit au départ je ne comprends pas ce débat.

Quant à la performance, c'est tout sauf un détail, sinon, on n'aurait qu'un conteneur depuis longtemps, non?

seulement si tu as besoin de perf, sinon tu vas au plus simple et au moins fatiguant, non?

En C++, et sous réserve de la façon dont tu accèdes à ces données (tu ne le précises pas), vector parce que c'est le "type par défaut", moins d'empreinte mémoire, interface maximale. Mais bon, ensuite, si tes programmes ne stockent jamais plus de 100 entiers à la fois, il est clair que tout ceci n'a aucune importance.

Maintenant, je travaille peut être dans un secteur très spécial, mais j'ai la sensation que les tableaux de quelques millions d'entiers ne sont pas si rares, dans un programme "normal".

Francois

j'aurai tendance à dire la même chose mais non, vu que je parle de faire des insertions/suppressions beaucoup pourrait prendre cette contrainte comme importante et donc utiliser les list par défaut.
je rajouterai même que sur des ensembles de plusieurs millions d'entités, j'y réfléchirai à 2 fois avant d'utiliser par défaut vector si je dois faire des insertions/suppressions justement.

Sans doute, cependant

a) à un moment T, on te dit que ça doit communiquer avec un programme en C
b) à un moment T', on te dit que ça doit communiquer avec un programme en Pascal
c) à un moment T", on te dit qu'il faut que ça envoie via TCP/IP et sockets...

Ben ce sera nettement plus simple si c'est déjà sous forme de char*...

et donc ça suppose de s'emmerder tout le reste du temps avec des char*, bah chez moi non.
de plus le dernier point est absolument fantaisiste, la majorité des échanges de données sur le réseau se font en envoyant du texte, pour le coup de la simplicité donc autant prendre des std::string vu qu'on montre clairement que les perfs on s'en moque, autant s'éviter les gestions de mémoire à la mano.

C'est justement ce que j'essayais de dire...

La NORME apprise dans les formations et dans les manuels du bon petit programmeur et dans la grande majorité des algos trouvés de nos jours sur les sites ou les forums priiviilégient les listes simplement ou doublement chaînées..

SANS SE POSER DE QUESTIONS....

Or, contrairement à ce que tu sembles penser, le problème est très présent : toute les demandes de données géo-références - avec l'explosion des GPS, du Web et des cartes dynamiques, des applis pour mobiles et smartphones, etc...

Plus tout ce qui est développement embarqué... et les jeux... qui, si on regarde les annonces, représentent une bonne part du boulot...

Donc non ce n'est pas "un cas très particulier".. ça l'était, mais ça devient de plus en plus un cas général, au contraire...

Avant c'était par manque de mémoire qu'il fallait la surveiller. Maintenant c'est par le nombre d'applis en //, l'immensité des bases, le nombre des utilisateurs simultanés, et la sophistication des applis qu'on veut faire tourner avec de petits moyens...

C'est au contraire de plus en plus d'actualité...

je dirai que l'informatique de gestion est majoritaire, mais bon, pas de chiffre donc pas de chiffre.
ensuite je sais pas où tu travailles, mais moi à chaque fois qu'on m'a dit "on a besoin de perf" j'ai toujours remarqué une tare que je rapportes avant, c'est les milliers de kilomètres de textes échangés sur le réseau ou envoyés pour les logs ... alors bon, moi ça me fait juste rire (et j'ai bossé en embarqué, en jeux vidéo et en finance, et dans les 3 j'ai eu le coup du "besoin" de perf)

parler de performance dans ces contextes c'est juste du foutage de gueule en puissance.
donc non, je n'ai jamais rencontré une VRAIE problématique de perf.

Si la performance n'a pas d'importance dans ton milieu, tant mieux pour toi...
Mais c'est - très loin - d'être le cas général en informatique..
Sinon pourquoi parlerais-t-on de "compelxité algorithmique" ou de "compelxité spatiale" ??
Essaye de faire une recherche dichotomique avec une liste , ça va être du sport....
Essaye de stocker dans un maillage 3D de 1000 * 1000 * 1000 25 paramètres par point avec des listes chaînées...

je dirai le contraire, le cas général c'est que ça doit marcher et non pas que ça doit être performant.
et ce qui est bien avec ma précédente phrase, c'est qu'elle s'applique aussi en premier lieu dans le domaine des perfs et dans tout en général, ça doit d'abord marcher, les perfs c'est bien quand on est sur de pas s'être planté sur le reste.

[Invité]

C'est une approche, mais il y en a une autre, le SRP, (single responsability principle) qui préfère que le conteneur se contente de contenir les données, et que toutes les manipulations soient faites de l'extérieur.

C'est plus ou moins le cas dans la STL, mais il n'empêche que la complexité (garantie) de telle ou telle méthode, sa syntaxe, voire son existence, dépend du type du conteneur, et que tu auras beaucoup de mal à éviter cela...

Francois

[Invité]

je rajouterai même que sur des ensembles de plusieurs millions d'entités, j'y réfléchirai à 2 fois avant d'utiliser par défaut vector si je dois faire des insertions/suppressions justement.

En fait, dans la STL, quand les volumes deviennent vraiment importants, tu n'as pas vraiment d'autre choix que les vecteurs, parce que tout le reste a une empreinte mémoire déraisonnable. Donc tu te retrouves avec un vecteur trié, et éventuellement un tri par insertion si tu ajoutes/supprimes par petits lots.

Comme tu le disais, sur de tous petits volumes, le conteneur a moins d'importance, si ce n'est qu'une interface peut être plus pratique qu'une autre (par exemple set, ou map).

En fait, le choix n'existe réellement que pour des volumes de données "moyens", quelque dizaines de milliers d'éléments... C'est un peu pareil pour les algorithmes, d'ailleurs.

Francois

[r0d]

La plupart des informaticiens ont du mal à lire du "code des autres" et encore plus à le lire en se disant que l'autre n'était peut être pas un imbécile qui codait avec les pieds.

C'est très vrai, malheureusement. Et c'est à cause de ça que tant de logiciel sont "refactored" alors que bien souvent ce n'était pas la peine.

Mais ce n'est pas toujours facile de se mettre à la place de la personne qui a écrit un code si cette personne n'est pas là pour expliquer. Et justement, les "best practices" et autres idiomes et concepts aident un peu en sens aussi, à normaliser un peu les codes sources.

[Invité]

Mais ce n'est pas toujours facile de se mettre à la place de la personne qui a écrit un code si cette personne n'est pas là pour expliquer. Et justement, les "best practices" et autres idiomes et concepts aident un peu en sens aussi, à normaliser un peu les codes sources.

Je suis d'accord, et c'est à mon avis leur principale utilité: produire un langage relativement commun, ou du moins, un petit nombre de styles parmi lesquels on se retrouve.

Note bien que c'est aussi pour cette raison que, dans pas mal d'entreprises, certains librairies, méthodes, ou approches plus ou moins modernes sont proscrites, officiellement ou officieusement. On préfère que toute l'équipe se concentre sur un sous ensemble cohérent du langage.

Maintenant, je reste convaincu que cette normalisation des styles est peine perdue tant qu'on ne formera pas davantage les développeurs à la lecture, et à l'écriture de code "à la manière de". Quand tu interviens dans un code homogéne, écrit dans un style différent du tien, le meilleur service que tu puisses rendre aux suivants c'est de rester dans le style, et dans le paradigme. Trop souvent le principal problème du code passé de main en main, c'est moins la qualité de ce qui est écrit que le fait qu'on a dix "manières" différentes, mélangées les unes aux autres, des approches incohérentes d'un module à l'autre, voire d'une strate à l'autre à l'intérieur du même module.

A ce compte, le code devient très vite illisible, et surtout devient difficile à maintenir parce que la cohérence d'ensemble se perd au fil des interventions.


Et c'est peut être là que les "best practices" et la foi des forums peuvent nuire. En inculquant aux jeunes programmeurs qu'il n'y a qu'une façon correcte de coder, la moderne, on ne leur donne pas envie de lire, de comprendre et encore moins de s'adapter à tout ce qui est écrit dans d'autres dialectes, soit, dans le cas du C++, la quasi totalité de ce qu'ils rencontreront en entreprise.

Francois

[el_slapper]

(..../....)
Maintenant, je reste convaincu que cette normalisation des styles est peine perdue tant qu'on ne formera pas davantage les développeurs à la lecture, et à l'écriture de code "à la manière de". Quand tu interviens dans un code homogéne, écrit dans un style différent du tien, le meilleur service que tu puisses rendre aux suivants c'est de rester dans le style, et dans le paradigme. Trop souvent le principal problème du code passé de main en main, c'est moins la qualité de ce qui est écrit que le fait qu'on a dix "manières" différentes, mélangées les unes aux autres, des approches incohérentes d'un module à l'autre, voire d'une strate à l'autre à l'intérieur du même module.

A ce compte, le code devient très vite illisible, et surtout devient difficile à maintenir parce que la cohérence d'ensemble se perd au fil des interventions.


Et c'est peut être là que les "best practices" et la foi des forums peuvent nuire. En inculquant aux jeunes programmeurs qu'il n'y a qu'une façon correcte de coder, la moderne, on ne leur donne pas envie de lire, de comprendre et encore moins de s'adapter à tout ce qui est écrit dans d'autres dialectes, soit, dans le cas du C++, la quasi totalité de ce qu'ils rencontreront en entreprise.

Francois

Amen.

Pour avoir maintenu, voire parfois refondu, du code de 36 ans d'âge, j'en suis arrivé à la conclusion suivante : "mieux vaut un mauvais style uniformément appliqué, qu'un mélange de 2 bons styles".

Spécialement à l'intérieur d'un composant(dans mon cas un programme, je fais du COBOL), mais c'est aussi vrai dans l'application entière. En ce moment, j'analyse un monstre de 15 applis - quelques milliers de programmes - et le fait que 100% des programmes commencent par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
PERFORM 10000-DEBUT
PERFORM 20000-TRAITEMENT UNTIL FIN-FICHIERMAITRE-OU-TABLEMAITRAISSE
PERFORM 30000-FIN
STOP RUN
.

m'aide considérablement. Surtout que ce dont j'ai besoin, c'est du critère de tri du fichier maitre..... En un coup d'oeil, j'identifie le fichier maitre. C'est 90% du boulot en un coup d'oeil, alors que sur un style plus, euh, varié, il me faudrait creuser à chaque fois. Sur des centaines de programmes.....

Je n'aurais pas fait comme ça(les chiffres me paraissent inutiles), mais si demain je dois créer un programme de production à cet endroit, je suivrais scrupuleusement le petit manuel.

[Jitou]

40 ans et en galère depuis plus d'1 an pour retrouver du taff malgré plus de 10 d'xp en développement.

Et comme handicap supplémentaire, je ne suis pas ingénieur, et je n'ai pas fait d'école d'info.

Une astuce, faites chef de projet, MOA, MOE, architecte ... bref des fonctions de "vieux" et puis arrangez vous pour vos octroyer des tâches purement technique dans vos missions afin de continuer à vous éclater dans la programmation ! Cette démarche a trois avantages, vous avez la crédibilité technique auprès des ptis jeunes loups qui vous entourent mais aussi auprès de votre management et de vos clients, vous êtes ultra-employable du fait de votre polyvalence enfin vous pouvez même prétendre à un salaire raisonnable !

[Golgotha]

Bonjour,

Je n'ai pas eu le courage de tout lire, je répondrais donc à la question principal du sujet.

Les développeurs âgés sont-ils bons pour le garage ?

Avec votre expérience personnelle, pourriez-vous valider le résultat de ces recherches ? Si non pourquoi ?

Cela fait maintenant quelques années (bientôt 10 ans) que je fais de la programmation et je crois que pendant toutes ces années, je ne me suis jamais ennuyé une seule seconde de faire ce métier. Prenons la programmation web, que j'ai appris à aimer il y a quelques années, aujourd'hui j'en suis amoureux... c'est un métier tellement passionnant, même en y consacrant tout sont temps, pendant 50 ans, je pense qu'on aurait à peine vu 10% de tout ce qu'il y a à voir et à savoir sur le développement. Et moi, au bout de quelques années à développer avec un framework, je commence seulement à me sentir vraiment à l'aise, à maîtriser mon oeuvre.

Non, notre métier ne s'apprend pas en suivant cinq tutoriels sur internet, cela s'apprend en posant tous les jours les mains sur le clavier, en essayant, en tâtonnant, en questionnant, la programmation n'est pas si éloigné que ça d'un art et un programme qui peu compter des milliers d'heures de travail et d'effort, c'est une oeuvre q'on façonne avec soin, et je peux vous dire que, quoi de plus riche qu'un artisan qui maîtrise sont art, quoi de plus beau qu'un souffleur de vert qui dessine devant vous un signe en cristal, qui joue avec du verre liquide pour en faire une oeuvre devant vous.

Le développeur âgé, saura vous transmettre sa passion, saura vous transmettre la maîtrise de sont art, je n'ai jamais autant appris qu'avec les anciens, et dans tous les domaines que ce soit, ils ont parfois vécu trois fois, quatre fois votre vie, et dieu sait que ces enseignement sont toujours bon à prendre.

[B.AF]

Vous voulez dire que les SSII ont compris depuis longtemps qu'elle pouvait faire plus de marge avec un gosse de 22 ans qu'avec un professionnel de 35 ?
Bravo, superbe déduction, quelle finesse d'analyse...

[Traroth2]

à par ça, quelle est la différence entre un pigeon ?

Une de ses pattes se ressemble.

[Traroth2]

Oui, mais si on devait suivre la logique qui a prévalu lors de la création du système (en gros, l'age de la retraite est autour de l'espérance de vie, un peu en dessous), l'âge de départ devrait être aux alentours de 75 ans aujourd'hui... Si c'était le cas, la retraite reviendrait à sa logique d'origine, et son financement cesserait d'être un problème.

Sauf que... on préfère faire rêver les quinquas, quitte à passer des lois sur l'élimination physique des vieux, ah pardon, la fin de vie et la mort dans la dignité...

Francois

Et si on contraint les gens à rester dans la vie active jusqu'à 75 ans (espérance de vie des hommes : 78 ans, hein), qu'est-ce qu'on va faire avec tous ces chômeurs ? Parce qu'on a déjà un véritable problème de chômage aujourd'hui, donc ajouter quelques millions de personnes aux actifs, je ne suis pas trop certain que ça va améliorer les choses...

De plus, comme à chaque débat sur la retraite, il y a un mot tabou. Et ce mot est : PIB. Le PIB de la France n'a JAMAIS été aussi élevé. Et pourtant, on nous dit qu'il n'y a pas d'argent pour financer les retraites. Comme est-ce possible ?

[r0d]

Oui, mais si on devait suivre la logique qui a prévalu lors de la création du système (en gros, l'age de la retraite est autour de l'espérance de vie, un peu en dessous), l'âge de départ devrait être aux alentours de 75 ans aujourd'hui...

Le raisonnement me parait aventureux. Les conditions sont tellement différentes que la comparaison est difficile. Par exemple, à l'époque les femmes ne travaillaient pas. Donc quoi? Maintenant que tout le monde travaille on devrait travailler 2 fois moins?