Discussion :

[white_tentacle]

Euh je pense que si les formations exigent des stages c'est pas pour faire joli et embêter les étudiants. Ce premier point n'est pas un intérêt des stages mais une conséquence des intérêts des stages.

En fait, c'est un cercle vicieux.

Comme certaines écoles ont lancé des stages obligatoires, grâce au point 3, elles se sont retrouvées avec de meilleurs taux d'embauche en sortie. Du coup, les autres ont tous fait pareil --> le taux est redescendu à la normale pour tout le monde, et l'étudiant a gagné le droit d'être exploité pendant 6 mois plutôt que de travailler en étant payé décemment.

Il y a aussi un autre intérêt pour l'école, un étudiant en stage, c'est autant d'heures de cours (et donc de coût) en moins.

[hegros]

En fait, c'est un cercle vicieux.

En fait c'est une vision et une réponse à l'ancienne (comprendre pas moderne)

[loufoque]

Du code en bonne santé, c'est quelque chose qui vit.
Ça doit être détruit, ré-écrit, refactorisé, etc. en permanence.

Plus un code est vieux, plus il a de chances d'être pourri. Le code que j'écris maintenant, aussi moderne soit-il, j'espère bien que si y'a des gens qui le réutilisent dans 10 ans il aura été retravaillé au moins une fois.
Bien sûr, ça arrive quand même assez souvent de ce traîner du code de 10 ans ou plus, et comme les entreprises ne veulent pas investir dans une modernisation il faut vivre avec, mettre les mains dans le cambouis et souvent bricoler des solutions ; ce n'est pas super jouissif, mais ça se fait et ça marche.

J'espère pour toi que tu ne deviendras pas à 40 ans quelqu'un qui n'a plus rien appris depuis ses 25 ans parce qu'il savait tout alors.

J'en apprends tous les jours, comme tout bon informaticien. Il faut évoluer en permanence.

Ce que je n'apprécie pas, c'est que la compétence ou la maîtrise de certaines technologies, et pire la rémunération, soient associées au nombre d'années passées avec un contrat.
Il y a des gens qui apprennent plus vite ou qui ont des connaissances plus diversifiées que d'autres.
Cela fait 5 ans que je lis beaucoup d'articles, participe à des communautés, étudie du code open source, rapporte des bugs et réalise des contributions, etc. et je pense avoir appris ainsi plus que ce que l'ingénieur moyen apprend dans ce laps de temps (en dehors du domaine scientifique en question dans les projets, s'il y en a un), sauf que bien sûr, cela n'est pas valorisé sur mon CV et ça m'énerve d'être jugé de la même manière qu'un mec qui sort tout juste d'école et qui est plutôt incompétent.

[Klaim]

Ce que je n'apprécie pas, c'est que la compétence ou la maîtrise de certaines technologies, et pire la rémunération, soient associées au nombre d'années passées avec un contrat.

Etant plus ou moins dans la même situation (autodidacte, pas/peu de diplome, ne peut valoriser que mon experience pro et projets persos) je suis en grande partie d'accord.

Le problème avec la rémunération c'est aussi qu'on considère (de base) que plus tu es agé plus tu dois être bien payé. Je suis pas sur des raisons ou si c'est spécifique à la france. C'est peut-être rapport au modèle familiale : plus tu es agé plus tu as de bouches a nourrir........."normalement".

En tout cas on digresse à mort du sujet initial qui était déjà assez vague de toutes façons.

[Jean-Marc.Bourguet]

Ce que je n'apprécie pas, c'est que la compétence ou la maîtrise de certaines technologies, et pire la rémunération, soient associées au nombre d'années passées avec un contrat.

C'est un facteur qui intervient. Il faut bien trier -- les interviews coutent beaucoup trop cher. On utilise les CV puis des interviews telephoniques avant de faire venir les gens. Mais c'est l'impression que tu fais en interview en personne qui determinera ce qu'on te proposera effectivement.

Il faut savoir que la premiere question qu'on se pose, c'est "est-ce que j'ai envie de travailler avec lui?". Et la deuxieme, c'est "est-ce qu'il est capable d'apprendre?" On sait qu'il faudra former les gens.

Il y a des gens qui apprennent plus vite ou qui ont des connaissances plus diversifiées que d'autres.

Si tu arrives a le faire savoir, ca peut decider du fait qu'on te propose ou non le poste. Et ca peut te pousser dans le haut de la fourchette de salaire plutot que dans le bas. Et si tu montres que c'est bien le cas, tu evolueras plus vite aussi.

ça m'énerve d'être jugé de la même manière qu'un mec qui sort tout juste d'école et qui est plutôt incompétent.

On a trop vu de mecs sortant de l'ecole, plutot incompetents et dotes d'une tres haute opinion d'eux-meme et de ce qu'ils avaient fait pour faire confiance sur parole.

[white_tentacle]

Ce que je n'apprécie pas, c'est que la compétence ou la maîtrise de certaines technologies, et pire la rémunération, soient associées au nombre d'années passées avec un contrat.

Tu as oublié "et à un diplome" .

[Invité]

Cela fait 5 ans que je lis beaucoup d'articles, participe à des communautés, étudie du code open source, rapporte des bugs et réalise des contributions, etc. et je pense avoir appris ainsi plus que ce que l'ingénieur moyen apprend dans ce laps de temps (en dehors du domaine scientifique en question dans les projets, s'il y en a un), sauf que bien sûr, cela n'est pas valorisé sur mon CV et ça m'énerve d'être jugé de la même manière qu'un mec qui sort tout juste d'école et qui est plutôt incompétent.

Il y a deux choses distinctes... L'embauche, et la progression.

L'embauche, surtout pour un premier emploi, ca se fait essentiellement sur l'âge/la durée de travail précédent et les diplômes (enfin surtout pour les jeunes, les diplomes, avec l'âge, ils se dévaluent). Et le niveau de salaire, à l'embauche, c'est presque toujours sur cette base. On peut le regretter, mais c'est comme çà.

L'idée générale, c'est que les diplomes sont quand même assez corrélés au niveau scientifique, et que pour une exception (comme toi), qui en sait plus que son CV, tu en as 20 qui en savent nettement moins. Aucun recruteur n'a envie de perdre son temps à tirer cela au clair, de toutes façons on a la période d'essai pour se faire une idée précise.

Après l'embauche, tout peut arriver. Mais on est souvent déçus par les recrutements, donc, le petit gars qui s'avère mieux que ce qu'on croyait, on va l'augmenter vite pour le garder (et sinon, il trouvera très vite ailleurs, dès qu'il pourra mettre un peu d'expérience sur son CV).

Le truc, c'est de prendre dès le début, une boite où tu peux évoluer... Les grosses SSII, avec leur gestion très standardisée des profils, ne sont pas ce qu'il te faut. Et les PME, faut bien tomber, et etre parfois capable d'attendre...

L'ironie de la chose, c'est que, vue de l'autre côté de la barricade, la situation n'est pas meilleure... En PME, on voit passer des tas de CV tous aussi ronflants, qui cachent souvent des personnes qui ont du mal en français, qui ne savent pas l'anglais, qui connaissent un demi des 12 langages qu'ils mettent sur leur CV, et qui se noient dans la première flaque qu'ils rencontrent. Il y a peut être des génies planqués dans le lot, mais on n'a pas toujours trois mois de période d'essai à perdre pour en être surs...

Inversement, les vraiment gros CV nous expliquent que de toutes façons ils veulent bosser dans des grands groupes (je n'ai jamais compris pourquoi ils postulaient), qu'ils ne veulent pas rester programmeurs plus de quelques années (dommage, nous on fait du dev...), ou qu'ils veulent une sécurité qu'aucune PME ne peut offrir (quand on a un an de visibilité devant nous, en PME, on est heureux...)

Au global, on se retrouve souvent à procéder par relations, et à embaucher des gens déjà expérimentés, recommandés par d'autres... Ou alors, on n'embauche pas.

Pas facile, moi je dis...


@klaim: l'idée que le salaire est corrélé à l'âge est un peu liée à la législation... Dans une entreprise, ton salaire ne peut qu'augmenter (on n'a pas le droit de le réduire). Quand tu changes d'emploi, tu demandes généralement au moins ce que tu avais avant (sinon, tu restes au chomage, en fait...). Donc, mécaniquement, les plus âgés gagnent mieux que les plus jeunes.

Ce qui est mystérieux, c'est que, à compétence égale, ceci devrait avantager les jeunes, qui pourtant sont assez souvent au chomage...

Francois

[hegros]

L'embauche, surtout pour un premier emploi, ca se fait essentiellement sur l'âge/la durée de travail précédent et les diplômes (enfin surtout pour les jeunes, les diplomes, avec l'âge, ils se dévaluent).

tu ne peux pas retenir comme critère d'évaluation pour un premier emploi la durée de travail, si c'est un premier emploi la durée de travail est forcément nulle cela ne peut pas être autrement sinon ce n'est pas un premier emploi.

je tiens à te signaler aussi qu'en matière d'embauche c'est l'employeur qui fixe lui même ses propres critères du moment qu'ils ne sont pas discriminatoires, l'âge et les diplômes ne sont pas imposés par la législation.(on parle bien ici d'informatique)


Les diplômes permettent en principe de s'assurer des domaines de compétence de la personne et d'avoir une estimation de son niveau sur une échelle.

@klaim: l'idée que le salaire est corrélé à l'âge est un peu liée à la législation...

Le salaire est corrélé le plus souvent avec le nombre d'année d'expérience pas avec l'âge directement puis dans les limites cela est toujours autant absurde et contradictoire.

Dans une entreprise, ton salaire ne peut qu'augmenter (on n'a pas le droit de le réduire). Quand tu changes d'emploi, tu demandes généralement au moins ce que tu avais avant (sinon, tu restes au chomage, en fait...). Donc, mécaniquement, les plus âgés gagnent mieux que les plus jeunes.

tu ne peux plus refuser un emploi avec un salaire inférieur depuis les nouvelles lois de modernisation en vigueur, quand tu as une certaine période déjà passée au chômage, puis j'ai déjà accepté un emploi avec un salaire inférieur, et dans l'avenir probablement encore, je ne sais pas d'où tu sors toutes ces affirmations.

en fait tu as des statistiques pour avancer que les vieux gagnent plus que les jeunes ou que leur salaire évolue mieux ?

[Invité]

Hehe tu trolles un peu, là, non?

tu ne peux pas retenir comme critère d'évaluation pour un premier emploi la durée de travail, si c'est un premier emploi la durée de travail est forcément nulle cela ne peut pas être autrement sinon ce n'est pas un premier emploi.

Premier dans le sens les emplois du début de ta carrière... En général, une offre n'est jamais libellée "sans expérience", quand on recherche un jeune, on va prendre soit des gens sans expérience, soit des gens avec une première expérience... Du point de vue de l'employeur, tu prends en compte l'âge *et* l'expérience (qui peut être nulle).

je tiens à te signaler aussi qu'en matière d'embauche c'est l'employeur qui fixe lui même ses propres critères du moment qu'ils ne sont pas discriminatoires, l'âge et les diplômes ne sont pas imposés par la législation.(on parle bien ici d'informatique)

Effectivement... mais si tu regardes les offres d'emploi, tu risques de les voir figurer. Et puis, si tu lances une recherche, par exemple par l'APEC, tu seras surpris de voir que si tu ne précises ni l'age ni les diplomes ni l'expérience, ils te demanderont de l'ajouter...

Comme quoi, y'a pas que la loi...

Le salaire est corrélé le plus souvent avec le nombre d'année d'expérience pas avec l'âge directement puis dans les limites cela est toujours autant absurde et contradictoire.

Les années d'expérience sont assez corrélées à l'âge, et les diplomes aussi d'ailleurs (un bac+7 à expérience égale, c'est plus âgé qu'un bac+2) non?

Donc, plus diplomé = plus vieux (à expérience égale), plus expérimenté = plus vieux (à diplome égal), et diplomes+expériences sont corrélés aux salaires...

Moi je veux bien tout ce qu'on veut, mais...

tu ne peux plus refuser un emploi avec un salaire inférieur depuis les nouvelles lois de modernisation en vigueur, quand tu as une certaine période déjà passée au chômage, puis j'ai déjà accepté un emploi avec un salaire inférieur, et dans l'avenir probablement encore, je ne sais pas d'où tu sors toutes ces affirmations.

Oui, si tu te retrouves en chomage de longue durée. Dans une entreprise, chaque année, ton salaire peut augmenter ou stagner, mais il ne peut être renégoocié à la baisse (sauf cas tout à faire exceptionnels).

Et quand on change d'emploi, la coutume veut qu'on augmente son salaire. Il y a bien sur des contre exemples, mais ils sont minoritaires. J'ai du mal à voir comment tu peux argumenter le contraire.

en fait tu as des statistiques pour avancer que les vieux gagnent plus que les jeunes ou que leur salaire évolue mieux ?

Bon allez... Quelques chiffres (idéalement, faut aller sur le site de l'INSEE, voir l'enquête Emploi)

Selon l'étude Ipsos IT (enquête auprès de cadres de l'informatique), en 2007, 42% des cadres de l'informatique de moins de 35 ans gagnaient moins de 24 000 euros par an, et 8% plus de 42 000 euros. Sur les plus de 50 ans, les chiffres étaient 7% et 45%...

Sur un groupe un peu plus large, les cadres actifs, une autre étude Ipsos (la France des Cadres Actifs) indiquait, toujours en 2007, que 51% des 25-30 ans (cadres actifs en entreprise, soit environ 900 000 personnes) gagnaient moins de 24 000 euros, et 75% moins de 36 000.

Pour les 40-45 ans (environ un million de personnes), seuls 15% gagnaient moins de 24 000 euros, et 35% moins de 36 000, 45% gagnaient plus de 42 000 euros (contre 10% chez les 25-30).

Francois

[hegros]

Troller sur un sujet trollesque me paraît d'une logique de bon sens.


En tout cas, et ce débat en aparté se termine, je ne reconnais en aucun cas une personne plus âgée comme plus expérimentée, plus experte ou plus connaisseuse par rapport à un jeune, c'est que du vent l'âge et purement spéculatif.


Je sais que beaucoup d'anciens se complaisent dans "plus vieux plus expérimenté ou plus expert" mais pour la dernière fois dans ce fil : ce n'est que du vent et du gros pipo.

[Seb des Monts]

bonjour à tous,

j'ai pas tout lu...

A mon avis, les notions de technique et de conception ne s'opposent pas.

Je me rappelle avoir contribué à des sujets où les questions techniques étaient manifestement au service de la conception (questions sur les classes amies, le polymorphisme...).

[hegros]

A mon avis, les notions de technique et de conception ne s'opposent pas.

Je me rappelle avoir contribué à des sujets où les questions techniques étaient manifestement au service de la conception (questions sur les classes amies, le polymorphisme...).

Les choix techniques orientent forcément la conception (l'inverse moins), tu as parfaitement raison, et d'une manière ou d'une autre tu fais toujours de la conception même quand tu ne le dis pas explicitement dans un document, c'est intrinsèque à la programmation.

La différence se fait probablement dans : est-ce que je commence par me préoccuper des soucis technique ou de conception ? Est-ce que les programmeurs C++ se préoccupent plus de la technique que de la conception ?

Comme dis plus haut commencer par la technique c'est une façon de concevoir, on peut l'ignorer mais la conception s'y mélange forcément.

[Issam_Lahlali]

A mon avis, les notions de technique et de conception ne s'opposent pas.

effectivement ils se complètent,il faut juste ne pas tomber dans le piege d'aborder le projet d'un point vue technique et dans ce cas le but premier est de faire fonctionner la fonctinalité techniquemet quelle que soit la maniére.

par exemple pour la construction d'une maison , on voit un architecte pour faire un bon plan, et après on le réalise techniquement, la realisation technique peut être nikel avec la dernière technologie de construction, mais si le plan d'architecte n'est pas bien fait , rester a l'intérieur de la maison peut être un calvaire ( espace mal exploité, impossibilité de faire des modifications d'une manière simple,...)

pour revenir a l'informatique si par exemple dans un interface graphique on mélange tout et on isole pas les classes métiers, on aura de gros soucis après si on veut réutiliser ces fonctionnalités dans un autre contexte et aussi toute maintenance va être très compliqué.


penser juste a faire fonctionner techniquement une fonctionnalité était compréhensible il y a des années ou le manque de ressources ,librairies , non maturité encore des approches objet et générique ,documentation faisait que le risque etait focalisé coté technique.

mais actuellement il faut se libérer du complexe de la technique et elle doit être plus transparente que se qu'on voit encore pour se concentrer sur la vrai valeur ajoutée d'une application.

[hegros]

effectivement ils se complètent,il faut juste ne pas tomber dans le piege d'aborder le projet d'un point vue technique et dans ce cas le but premier est de faire fonctionner la fonctinalité techniquemet quelle que soit la maniére.

Cela dépends des organisations en fait et de la façon dont on peux apprécier un modèle de développement. j'ai l'impression que le C++ se pratique mieux ou le plus souvent avec le prototypage ce qui implique du temps techniquement puisque à la fin d'un cycle de prototypage c'est censé produire un exécutable.

par exemple pour la construction d'une maison , on voit un architecte pour faire un bon plan, et après on le réalise techniquement, la realisation technique peut être nikel avec la dernière technologie de construction, mais si le plan d'architecte n'est pas bien fait , rester a l'intérieur de la maison peut être un calvaire ( espace mal exploité, impossibilité de faire des modifications d'une manière simple,...)

Ceci n'est pas ignoré il ne faut pas se laisser berner, le triangle cout-délai-qualité n'y est pas pour rien non plus c'est connu. L'entreprise veut toujours baisser les coûts et les délais, la qualité elle en prends forcément un gros coup. Probablement que pour bien faire en C++ il faudrait trop de temps et trop d'anciens (qui selon notre ami mécaniquement coûte plus cher) et de ce fait on mets les gaz et la qualité saute.

cela se ressent sur des classes ou fonctions qui ne veulent rien dire du tout, des morceaux de code un peu partout en commentaire, des erreurs de compilation/édition que personne ne comprends, une perte accrue de réutilisabilité, une mauvaise utilisation d'un gestionnaire de source, etc ...


j'ai l'impression que trop souvent les coûts d'exploitation et de maintenance ne sont pas considérés à leur juste valeur, le chef de projet a un budget développement et la maintenance le client ne veut pas en entendre parler ce n'est heureusement pas spécifique à un langage/technologie particulière, probablement que cela coûte plus cher en C++.

[Issam_Lahlali]

comme c'était mentionné plusieurs fois le C++ est multi paradigme et le C++ moderne s'oriente de plus en plus vers l'approche des generics vue qu'elle apporte plus de flexibilité par rapport a l'approche objet, et une librairie développé par les generics peut être combiné avec d'autres plus facilement qu'une autre basé sur l'abstraction et le polymorphisme dynamique qui tot ou tard contient un couplage fort avec des classes par heritage.

et l'orientation de C++0x montre bien cette voie ou on essaye de combler les lacunes des generics avec les concepts, ce manque rend le design par generics fragile vu qu'on peut pas bien spécifier les contraintes ,malheureusement ça va trainer pour les adopter et des solutions de contournement existe même si c'est un peu compliqué.

et le comité de standardisation ne pense pas trop a évoluer l'approche par contrat (DbC) qui est géré nativement par d'autres langages.

a mon avis pour énormément d'applications l'approche objet fait bien l'affaire , et d'un autre coté la majorité des développeurs commence a bien assimiler cette approche vu que ce qu'ils étudient le plus a l'école.

et pour les generics elles sont utilisés surtout pour factoriser le code, vu la méconnaissance des techniques de polymorphisme statique,type erasure ,traits,policy, concept, ainsi de suite.

j'aurai préférer qu'on améliore aussi la gestion native de la conception par contrat ou il ya plus de maitrise et reste suffisante pour la majorité de projets, et bien sur les generics sont d'une grande utilité pour plusieurs librairies et aussi on peut mixer les 2 bien sur.

on parle trop de C++ moderne qui lui se base beaucoup sur le design par les generics, mais concrètement qui utilise les generics d'un point de vu design , elles sont surtout utiliser pour factoriser le code, déjà on a du mal avec l'approche objet alors quoi dire des generics.

et bien sur je ne parle pas des librairies basés sur l'approche générique qui sont bien conçu comme STL ou Boost ou autre qu'il faut utiliser bien sur mais de nos projets ou une non maitrise des techniques de conception par generic rend le projet très compliqué.

[koala01]

On l'a dit et répété: la liberté a un prix...

Même dans la vie courante, la liberté individuelle est associée à un certain nombre de devoirs (et assez bizarement à un certain nombre d'interdictions).

C++ te laisse libre de choisir le ou les paradigmes que tu veux utiliser.

Tu peux tout à fait décider de ne pas utiliser l'un ou l'autre (voir deux sur trois des) paradigmes proposés, mais le prix de cette décision sera sans doute de te limiter dans les possibilités d'évolution de ton projet.

Si tu décide au contraire d'utiliser tous les moyens proposés, tu gagnera en souplesse au prix d'une difficulté de choix du point de vue accrue.

L'idéal étant, sans doute, de prendre "le meilleur" des différents paradigmes selon tes besoins et tes connaissances:

Si tu maitrise d'avantage la conception OO que la conception générique, démarre ton projet en conception OO.

Si, en cours de conception, tu viens à constater une certaine une certaine redondance au niveau des comportements, que tu arrive à déterminer les concepts génériques qui pourraient s'appliquer ET que tu te sens capable de les mettre en oeuvre, n'hésite pas, mets les en oeuvre, tu gagnera surement en souplesse et tu t'évitera bien des lignes de code (et donc bien des erreurs éventuelles)

Mais je reste convaincu que le fait de faire de la programmation exclusivement générique (ou OO ou séquentielle) uniquement pour en faire reste la pire des solutions...

C++ te donne le choix, mais s'arrête là: Il t'appartient de décider quelle optique tu va envisager selon tes capacités propres (ou celles de ton équipe)

Est-ce que cela rend la conception plus compliquée Peut être, mais, si c'est le cas, c'est clairement parce qu'il faut à un moment donné faire un choix, et que c'est le choix qui est difficile

[Luc Hermitte]

a- comme c'était mentionné plusieurs fois le C++ est multi paradigme et le C++ moderne s'oriente de plus en plus vers l'approche des generics vue qu'elle apporte plus de flexibilité par rapport a l'approche objet, et une librairie développé par les generics peut être combiné avec d'autres plus facilement qu'une autre basé sur l'abstraction et le polymorphisme dynamique qui tot ou tard contient un couplage fort avec des classes par heritage.

b- a mon avis pour énormément d'applications l'approche objet fait bien l'affaire , et d'un autre coté la majorité des développeurs commence a bien assimiler cette approche vu que ce qu'ils étudient le plus a l'école.

c- et le comité de standardisation ne pense pas trop a évoluer l'approche par contrat (DbC) qui est géré nativement par d'autres langages.
[...]
j'aurai préférer qu'on améliore aussi la gestion native de la conception par contrat ou il ya plus de maitrise et reste suffisante pour la majorité de projets, et bien sur les generics sont d'une grande utilité pour plusieurs librairies et aussi on peut mixer les 2 bien sur.

a- on parle trop de C++ moderne qui lui se base beaucoup sur le design par les generics, mais concrètement qui utilise les generics d'un point de vu design , elles sont surtout utiliser pour factoriser le code, déjà on a du mal avec l'approche objet alors quoi dire des generics.

a- encore une fois je ne reconnais pas la modernité d'un code à ses <>, mais à ses absences de delete, et de new[].
Pour moi vous confondez C++ moderne (par opposition à historique) qui pourrait être pratiqué par monsieur tout le monde avec le C++ expérimental de boost qui n'est pas pratiqué/recommandé en entreprise.

b- Je dois être trop vieille école. J'avais officiellement commencé avec l'Ada, sa généricité, et ses TADs.

c- Je dois être trop vieille école bis, le langage OO que j'avais vu était l'Eiffel et non le C++ ou les langages à la mode comme le Java qui sont en plus incapables de PpC native -- au moins le C++ permet d'en faire nativement grâce au pattern NVI.
Maintenant, je ne serais pas surpris que la PpC ne soit pas plus comprise par les élèves d'aujourd'hui. Il faut une certaine expérience et recul pour en percevoir l'intérêt et systématiser son utilisation.

[yan]

Ca veut dire quoi Ppc???

[Jean-Marc.Bourguet]

a- encore une fois je ne reconnais pas la modernité d'un code à ses <>, mais à ses absences de delete, et de new[].
Pour moi vous confondez C++ moderne (par opposition à historique) qui pourrait être pratiqué par monsieur tout le monde avec le C++ expérimental de boost qui n'est pas pratiqué/recommandé en entreprise.

Effet de perspective qui explique peut-être une partie de la mécompréhension. Il y a beaucoup d'articles sur les techniques génériques, parce qu'elles sont moins matures et qu'on ressent encore des manques dans le langage en ce qui les concerne. Donc on publie ce qu'on découvre et des work around pour les manques. C'est quand on arrêtera de les commenter qu'elles seront matures et pourront se répandre en dehors de cercles d'initiés.

c- Je dois être trop vieille école bis, le langage OO que j'avais vu était l'Eiffel et non le C++ ou les langages à la mode comme le Java qui sont en plus incapables de PpC native -- au moins le C++ permet d'en faire nativement grâce au pattern NVI.

Pas vu d'OO à l'école. (Mais bon, je n'ai pas une orientation informatique non plus)

Maintenant, je ne serais pas surpris que la PpC ne soit pas plus comprise par les élèves d'aujourd'hui. Il faut une certaine expérience et recul pour en percevoir l'intérêt et systématiser son utilisation.

Attention, prétendre que l'expérience apporte quelque chose vexe certains participants...

[Luc Hermitte]

Attention, prétendre que l'expérience apporte quelque chose vexe certains participants...

Disons alors que je généralise à partir de mon expérience personnelle.