Discussion :

[Freem]

Aujourd'hui, on est habité a travaillé en mode fenêtré, il ne faut pas oublié le mode console. On peut acquerrir des mauvaises habitudes autant en suivant l'un ou l'autre paradigme (procédural, programmation orienté objet).

Pour du calcul purement scientifique, ce qui prime c'est le résultat, ensuite on décide de l'afficher ou de l'imprimer ou l'enregistrer dans un format de fichier qu'on peut exploiter dans un logiciel graphique.

On peut également envisagé un apprentissage alterné des deux paradigmes, de sorte à avoir un regard simultannée sur les deux approches.

Je ne saisis pas du tout le parallèle console&fenêtre / procédural&objet?
J'ai même envie de dire qu'il y a plus de programme console qui respectent les paradigmes objet, surtout quand ils obéissent à la philosophie UNIX, qui n'est rien de plus que de l'objet, version ancestrale (ben oui, un programme ne fait qu'une seule chose mais la fait bien, et communique avec les autres au travers d'une interface claire...)

A part ça...

Perso, j'ai commencé par le QBasic, puis appris en auto-didacte le C, ensuite l'assembleur (que j'ai appris parce que je me prenais pour un guru en C depuis, j'ai perdu plus d'une taille de chaussettes ça coûte moins cher en tissu ).
J'ai sincèrement trouvé l'assembleur nettement plus simple que le C:
_ pas de prise de tête syntaxique
_ une instruction ne fait qu'une, et une seule chose

A partir de la, je me suis remis au C, et, étrangement, j'ai compris beaucoup de choses que je n'avais pas comprises auparavant, par exemple, les manipulations de la mémoire sont devenues vachement plus claires.
Ah, et l'art de déboguer un programme à la trace est aussi nettement plus efficace depuis.

Pour ce qui est de l'apprentissage, je ne pense pas que l'on doit enseigner un seul paradigme à la fois.
A mon humble avis, il serait intéressant d'enseigner les langages de scripts du genre shell, ou l'on combine de petits programmes de façon procédurale en même temps qu'un langage type ASM qui permet de comprendre comment la machine marche, en faisant de très petits trucs.

L'intérêt?
L'assembleur, c'est du pur procédural. Le Shell, c'est manipuler des objets par leur interface connue.
Une fois initié à ces deux techniques, je crois qu'en fait on a abordé comment se servir des objets, et comment implémenter une petite partie d'entre eux (les méthodes).
Quand on a ces notions, on peut passer à l'orienté objet, en expliquant aux étudiants qu'en fait, ils font de l'objet depuis qu'ils font du script. Il suffit de leur demander d'implémenter des classes qui reproduisent le comportement de commandes simples, et de faire un programme qui singe un des scripts qu'ils ont fait précédemment.
De cette façon, peut-être que les gens auront moins peur de l'objet.

Ah, oui, ça fait peur, quand je dis assembleur, ou apprendre comment marche une machine. Cela dis, pour moi, un mécano si on lui dis qu'il faut changer telle ou telle pièce dans tel ou tel cas, si il ne comprend pas pourquoi, il faudra le former à chaque nouvelle voiture.
Si il connaît les bases, il sera capable de comprendre d'instinct un certain nombre de choses.

Ok, c'est long. Mais j'aimerai savoir, à votre avis, la programmation, c'est un métier, ou pas?
D'ailleurs, les grandes lignes d'un ordinateur, ça n'est pas si complexe que ça. Et quand bien même... de nos jours, on a tendance à dire qu'il faut enseigner aux gens directement un truc utile en entreprise. Je le pensais aussi, *avant*. Pourquoi j'ai changé d'avis? Parce que les entreprises, ça change de techno, et que le temps qu'un type fasse ses 5 ans d'étude, la techno qu'il a utilisée peut très bien être complètement obsolète (sans compter le temps qu'il faut à l'éducation nationale pour admettre qu'une techno est obsolète).

Quand aux différents paradigmes...
Chacun est une façon de penser. Chaque problème peut se résoudre de plusieurs façons. Ok, le procédural, c'est la façon de penser la plus humaine et donc le paradigme le plus simple. N'empêche, je pense qu'on devrait apprendre plusieurs paradigmes, parce que sinon il est très difficile de s'y mettre quand on a pris des habitudes. J'essaie de me mettre au prolog... ben... j'ai un mal de chien, parce que le paradigme n'a juste rien à voir.
Pourtant, plusieurs paradigmes permettent d'attaquer un problème avec plusieurs angles, et de choisir le meilleur pour le résoudre.

Si on a qu'une pioche pour percer un trou dans un mur, on y arrivera, mais c'est plus simple d'avoir un burin parfois. Alors que dans le sol, le burin sera presque inutile.

[gilwath]

Lors de ma formation le premier langage que j'ai appris c'est le pascal, je trouve que c'est une bonne introduction à la programmation et surtout un langage adapté pour faire des problèmes d'algorithmie simple. Mais je pense qu'au cours de sa formation un étudiant en informatique doit voir un peu tout les paradigmes existants (objet, procédural, fonctionnel) et être poussé à être curieux. Car je pense que ce qu'il manque aux étudiants sortant des écoles c'est justement cette curiosité d'aller apprendre par lui même des langages de programmation qu'il n'a pas appris en cours, des technologies qu'il n'a pas vu en cours, etc ... . Je viens de finir mon cursus et je pense qu'on est très peu dans notre promo à avoir appris des langages par pur culture (j'apprend actuellement le clojure), essayer de se renseigner sur des technologies inexistantes des cursus des écoles ( NoSQL et bigdata par exemple ).

[magnus2005]

Il faut proscrire la programmation procédurale comme 1er approche de l'apprentissage de la programmation j'en voie le désastre depuis trop d'années. Il apparait qu'une fois que l'esprit humain à acquis ce en premier concept il parvient difficilement à appréhender la POO. Les professeurs qui repende cette archaïsme de penser comme quoi ce serait plus simple, ne pense cela que parce qu'il ne parvienne pas eux même à appréhender la POO et ceci répète le schéma.

Apprendre la POO en tant que 1er approche permet ensuite de facilement appréhender les autres concepts. Je peux le vérifier tous les jours. A mon sens le paradigme de la POO finalement englobe le procédurale.

Effectivement il ne faut pas se tromper sur la question poser qui est sur l'apprentissage des paradigmes mais je ferais quand même la remarque suivante à Paul TOTH :

Oui d'un point de vue technique tous revient en général à C et à de l'assembleur, mais ce sont des techno qui ne réponde plus à la conception d'application pour les utilisateurs. Le C était du haut niveau, le C++ l'a fait descendre d'un cran, Java et .NET ont fait descendre le C++ d'un cran.

Tes remarques sont vrai uniquement sur le C++ qui est du C à la base et rappel les temps reculés ou la POO n’était pas utilisable faute de solution technique.
Effectivement avant les années 90 les langages de programmation n'offrait pas une gestion de la POO correcte mais depuis le C++ cela ne pose plus de problème.

Je croise tous les jours des personnes des personnes dans ton cas.
Finalement je ne sais ceux qui posent le plus de problème les adeptes du C ou les Ex-COBOLISTE.

[gangsoleil]

Bonjour,

Il faut proscrire la programmation procédurale comme 1er approche de l'apprentissage de la programmation j'en voie le désastre depuis trop d'années. Il apparait qu'une fois que l'esprit humain à acquis ce en premier concept il parvient difficilement à appréhender la POO.


Oui d'un point de vue technique tous revient en général à C et à de l'assembleur, mais ce sont des techno qui ne réponde plus à la conception d'application pour les utilisateurs. Le C était du haut niveau, le C++ l'a fait descendre d'un cran, Java et .NET ont fait descendre le C++ d'un cran.

Effectivement avant les années 90 les langages de programmation n'offrait pas une gestion de la POO correcte mais depuis le C++ cela ne pose plus de problème.

Je croise tous les jours des personnes des personnes dans ton cas.
Finalement je ne sais ceux qui posent le plus de problème les adeptes du C ou les Ex-COBOLISTE.

Il se trouve que je suis developpeur C, donc je me permet de repondre car je ne suis pas d'accord, dans la mesure ou tous mes programmes suivent une conception objet.

Certes, ca demande un peu plus de rigueur au developpeur C pour faire de l'assimile-objet, vu que tout (notamment les fonctions) est accessible de partout ; a lui donc de se restreindre et de ne pas faire n'importe quoi n'importe ou.

Et cela fonctionne tres bien, je n'ai pas eu trop de remarques negatives sur la qualite globale de mon code, ni sur la conception.


Et pour enfoncter le clou, j'ai appris le Pascal, puis le C, puis seulement la POO.

[Invité]

Je suis assez d'accord avec l'article. Au début de l'apprentissage, l'approche procédurale est très naturelle, parce qu'elle correspond bien à l'idée qu'on se fait d'un programme : une petite machine qui "fait quelque chose". Elle permet aussi d'enseigner rapidement l'algorithmique, et la grammaire du langage, qui seront de toutes façons nécessaires.

En revanche, on peut dès le début parler de types de données, de structuration du code en regroupant données et traitements, voire d'encapsulation, ce qui prépare à l'objet.

A mon avis, l'objet apparait très naturellement un peu plus tard, comme solution aux problèmes d'architecture, et il est plus facile à comprendre dans ce contexte, un fois qu'on a rencontré ces problèmes. Un défaut des jeunes programmeurs "pur objet" est souvent qu'ils n'essaient de raisonner que de manière abstraite, ce qui marchera sur des problèmes simples, mais à peu près jamais quand ca se complique (l'abstraction, c'est très difficile).


Ce raisonnement est aussi valable lors de la conception initiale d'un projet. Un gros défaut des programmeurs "pur objet" est de chercher à spécifier l'architecture et les concepts au tout début, à un moment où l'on n'a généralement pas une vision claire des besoins et des contraintes. C'est ce qui mène aux architectures démentes qu'on voit ici et là, et avec lesquelles il faut vivre, parce qu'un "spécialiste" les a imaginées trop tôt.

Pour moi, la recommandation qu'on trouve dans certains manuels de commmencer par identifier les objets est très dangereuse en pratique. Les bons objets ne sont pas du tout intuitifs, et n'apparaissent qu'à l'usage.

Pour reprendre l'exemple de la voiture et du véhicule, la première charette à moteur n'était pas une "voiture", elle n'a pas été construite sur la base d'un cahier de spécifications pondu par un jeune administratif après des entretiens utilisateurs. C'était un assemblage hétéroclite, répondant à un besoin vague, qu'on a amélioré à l'usage.

C'est exactement pareil avec un programme un tant soit peu complexe.

Francois

[chaplin]

A mon avis, l'objet apparait très naturellement un peu plus tard, comme solution aux problèmes d'architecture, et il est plus facile à comprendre dans ce contexte, un fois qu'on a rencontré ces problèmes. Un défaut des jeunes programmeurs "pur objet" est souvent qu'ils n'essaient de raisonner que de manière abstraite, ce qui marchera sur des problèmes simples, mais à peu près jamais quand ca se complique (l'abstraction, c'est très difficile).


Ce raisonnement est aussi valable lors de la conception initiale d'un projet. Un gros défaut des programmeurs "pur objet" est de chercher à spécifier l'architecture et les concepts au tout début, à un moment où l'on n'a généralement pas une vision claire des besoins et des contraintes. C'est ce qui mène aux architectures démentes qu'on voit ici et là, et avec lesquelles il faut vivre, parce qu'un "spécialiste" les a imaginées trop tôt.

Pour moi, la recommandation qu'on trouve dans certains manuels de commmencer par identifier les objets est très dangereuse en pratique. Les bons objets ne sont pas du tout intuitifs, et n'apparaissent qu'à l'usage.

Pour reprendre l'exemple de la voiture et du véhicule, la première charette à moteur n'était pas une "voiture", elle n'a pas été construite sur la base d'un cahier de spécifications pondu par un jeune administratif après des entretiens utilisateurs. C'était un assemblage hétéroclite, répondant à un besoin vague, qu'on a amélioré à l'usage.

C'est exactement pareil avec un programme un tant soit peu complexe.

Francois

[magnus2005]

Oui il y aura toujours des développeurs capable d’appréhender tous les aspects techniques quelque que soit le langage ou les paradigmes utilisés. Ce sont des personnes qui avait reçu un enseignement basé sur le paradigme du procédural qui ont construit tous les programmes d'enseignements de la POO.

Mais le problème de l'enseignement est un problème globale comme l'enseignement de la lecture à l’école primaire. Il faut employer la méthode qui donne les meilleurs résultats sur la majorité des élèves. Passer par la POO en premier fait que passer au procédurale après se passe sans souci alors que pour le contraire la plupart des développeur procéduraux reste bloqués dans ce schéma mental.
Plus grave encore il y en a même qui sont bloqué dans des schéma du type (en utilisant des langages modernes) avec du code avec zéro fonctions. Le programme commence en haut et finit en bas plusieurs milliers de ligne après.

Autre point professionnellement parlant le type de développement les plus répandus sont ceux du type application gestion ou il faut vraiment proscrire l'utilisation des langages de développement systèmes (C et C++) pour utiliser les langages POO adaptés (Ex : C#, Java, PHP) et vice versa faire un kernel d'un OS en Java ou en PHP c'est pas gagné. Donc apprendre la procédurale est vain car ces développeurs eux car il ne devront faire que de la POO.

Autre point ce sont des développeurs qui n'ont pas conscience de l'existence de la gestion de la mémoire et des pointeurs. Je prend l'exemple des BTS et des DUT il vaut mieux passer 2 ans pour former un développeur d'application de gestion correcte qu'un développeur systèmes médiocres car il est constaté que d’élèves sont souvent été perdu par la gestion de la mémoire en C/C++ ce qui les empêche de se concentrer sur le fonctionnement globale des applications.
Je prend un exemple tous simple le C++ n'a jamais été en mesure de concurrencé le COBOL dans le monde professionnel et pourtant techniquement parlant le C++ est très supérieur au COBOL (c'est ce que pensais à mes début en tant que développeur C++). Java (et d'autre) ont permis une transition réel vers la fin du COBOL car il solutionne la plupart des problèmes du C++ (du point de vue du COBOL) qui finalement est trop puissant et permet de fait tout (et surtout n'importe quoi, bienvenue dans le monde réel).

J'aimerais faire remarquer ceci des gens qui lisent une discussion du type :
Faut-il éviter de distraire les débutants avec l'orientée objet ?
C'est ce je voudrais avoir comme membre des équipes mais force de constaté que la plupart des développeurs lambda ne sont pas passionné par leur boulot et font un dump mémoire dès qu'il ont franchi la porte hors du bureau (parfois même avant).

A mon sens il y a 3 niveau de développeurs :

1. Les développeurs qui ne cherchent absolument pas à comprendre ce qu'il font du point de vue technique mais force de constaté que cela ne les empêche de livré dans les temps des applications répondant à un cahier des charges.
   
2. Ceux qui comprennent le fonctionnel et la technique (l'idéal mais c'est une minorité) .
   
3. Ceux qui font acharné de la technique. Eux il ne livrent jamais dans les délais et ce n'est jamais ce qu'on demandé les utilisateurs.

Le développement c'est des humains et des langages et des paradigmes. Commencer par la POO fait que le mixage de tous ça donne les résultats les plus solides. C'est une question de gestion RH.

Ce serait bien que tous les développeurs maitrise toutes les bases mais ça c'est vrai dans le monde bisounours, dans le monde de l'entreprise les gens sont spécialisés et le deviennent de plus en plus avec le temps et pour la plupart des gens se remettent difficilement en question. En apprenant la POO en premier il n'est pas nécessaire de remettre tout à plat pour faire du procédurale.

Exemple final :
Les acharnés sont toujours pénibles :
mais les acharnés de l'objet le sont moins que ceux du procédurale parce qu'ils comprennent toujours le procédurale.

[magnus2005]

Je suis désole pour fcharton mais c'est typiquement la schéma de réflexion que l'on retrouve par ceux qui ont commencé par apprendre du procédurale.
Le mode de fonctionnement d'un CPU n'est pas naturelle pour un humain. Il parait cohérent pour un développeur après acquisition de nombreux concept.

Il est naturel pour un humain :
D'utiliser une cafetière pour faire :

• un café
• un cappucino

D'utiliser une voiture pour faire :

• demarrer
• avancer

D'utiliser une Fichier (objet)pour faire :

• deplacer (méthode)
• effacer (méthode)

Cela est naturel pour tous les gens impliqués dans un projet :
Les clients, les analystes , les développeurs.

Ma démonstration est simple et il y a que les gens qui sont primo formés au procédural qui argue que cela n'est pas naturel.
Êtes vous d'accord ?

Je suis d'accord avec transgohan chaque paradygme à son utilité
mais la POO doit être le primo enseignement.

[Invité]

Je suis désole pour fcharton mais c'est typiquement la schéma de réflexion que l'on retrouve par ceux qui ont commencé par apprendre du procédurale.

Non, c'est le raisonnement de tous ceux qui voient l'informatique comme une généralisation du calcul, tel qu'on l'apprend au primaire. Ou de la façon dont on a appris à lire (des lettres qui font des syllabes qui font des mots, qui font des phrases, qui font du sens, de façon assez linéaire, je crois).

C'est pour cela que je dis qu'il est naturel.

L'approche procédurale fait sens pour un très grand nombre d'applications de l'informatique. En fait, partout où l'on raisonne en termes de "traitement" ou de "calcul".

L'approche objet est adaptée à des situations particulières. A mon avis, elle est avant tout utile pour les interfaces utilisateur, les programmes de type "simulation" (où l'on a par nature des objets qui interréagissent de façon indépendante, cette situation est courante dans les jeux), et *éventuellement* des structures de très grande taille, de façon à réduire les interactions entre modules distincts. Mais dans ce dernier cas, elle n'est qu'une solution à la mode parmi d'autres.

Mais, en fin de compte, tout émane du procédural, parce que ce type de raisonnement qui sépare données et traitements, et découpe chaque traitement en fonctions est à la base du raisonnement humain. Regardez la grammaire : on a des noms (données) et des verbes (traitements) qu'on applique en des procédures linéaires (phrases). C'est pareil en maths, en comptabilité aussi...

Alors, on peut reprocher à ce formalisme scientifique de mal représenter le monde réel, de ne pas savoir qu'un cappucino est un café, ou qu'une porte peut d'ouvrir, comme un livre, ou une boite de conserve. Mais c'est un mauvais procès, car en dehors d'applications de simulation où l'on demande au programme de "faire comme dans le monde réel", ce n'est pas l'objet de l'informatique.

On a maintenant du recul sur les générations "formées à l'objet". Mon impression c'est que les grandes promesses de simplification du code, d'amélioration de la maintenance, n'ont pas plus été tenues par l'objet que par les solutions miracles qui l'ont précédé, ce qui fait qu'on a aujourd'hui de la POO une vision plus modeste qu'il y a une vingtaine d'années. Par ailleurs, on peut constater que l'insistance mise sur l'objet, surtout quand on lui ajoute l'UML comme point de passage obligé, et les design pattern comme évangile, renforce chez certains un gout de l'abstrait pour l'abstrait qui produit rarement du bon travail (en informatique comme ailleurs).

Bref, l'objet est passé dans les moeurs, tout le monde en fait, à des niveaux différents. Mais ceux qui lui accordent une trop grande importance font l'objet d'une méfiance assez générale.

Francois

[Tryph]

Je suis désole pour fcharton mais c'est typiquement la schéma de réflexion que l'on retrouve par ceux qui ont commencé par apprendre du procédurale.
Le mode de fonctionnement d'un CPU n'est pas naturelle pour un humain. Il parait cohérent pour un développeur après acquisition de nombreux concept.

Il est naturel pour un humain :
D'utiliser une cafetière pour faire :

• un café
• un cappucino

D'utiliser une voiture pour faire :

• demarrer
• avancer

D'utiliser une Fichier (objet)pour faire :

• deplacer (méthode)
• effacer (méthode)

Cela est naturel pour tous les gens impliqués dans un projet :
Les clients, les analystes , les développeurs.

Ma démonstration est simple et il y a que les gens qui sont primo formés au procédural qui argue que cela n'est pas naturel.
Êtes vous d'accord ?

Je suis d'accord avec transgohan chaque paradygme à son utilité
mais la POO doit être le primo enseignement.

voila quelqu'un qui, de mon point de vue, a réellement compris le concept de POO.
la philosophie objet, c'est avant tout de faire un modéle de la réalité et donc de reproduire (dans une certaine mesure) les objets réels et leurs interactions.

il me semble que pour un cerveau humain, il est beaucoup plus simple d'appréhender un chat comme une entité à part entière qui possède des caractéristiques (couleur, taille, nombre de pattes...) et des comportements (marcher, manger, dormir...).

et c'est juste ça l'objet... représenter la réalité (avec un certain degré de précision à adapter en fonction du projet) autant que nécessaire/possible.

pour moi, ceux qui affirment que l'objet, c'est juste mettre des données et des traitements dans une même classe pour résoudre un problème architectural n'ont tout simplement rien compris à l'objet. et quand on comprend pas grand chose à l'objet, effectivement on n'en voit pas l'intérêt.

bon par contre j'irai pas jusqu'à dire qu'il faut apprendre l'objet en premier (c'est pas ce que j'ai fait). mais apparemment faut mieux former les gens aux concepts vraiment basiques de l'objet par ce que c'est clair que c'est loin d'être acquis pour un grand nombre de devs.

[h_fabrice]

Je suis un jeune programmeur de trois ans, de mon experience et ma facilité d'évolution je suis pour le fait de commencer par les langages non orientée objet tels aue Pascal, C pour apprendre a se concentrer sur la résolution des problemes (pétits problèmes bien sur ) que de réflechir pendant des heures sur l'aspect structurelle d'une application. Présentement je fais de la POO parce que mes applications sont complexes et elles doivent etre maintenables, evolutives.

[SLiM_ViNCe]

Je ne comprends pas le sujet. Il y a plusieurs paradigmes de développement dont l'orienté objet mais je ne comprends pas qu'il n'y ait que deux choix : soit apprendre QUE ça, soit ne pas du tout l'apprendre. On commence pour la plupart avec du procédural/impératif type Pascal pour finir sur de l'objet.

La gestion de la mémoire n'a rien à voir avec tel ou tel paradigme, c'est une constante de l'infrastructure. Les deux doivent donc être enseignés, de préférence la gestion de la mémoire précédemment mais pas nécessairement puisque tant que la formation n'est pas achevée, on n'est pas sensé être des cadors du dév... Et puis la gestion de la mémoire, c'est pas juste du malloc ou autres primitives du C... C'est aussi des algorithmes de recherche de données, de pagination, etc (types SGBD et autres). Bref, je trouve la vision "gestion de mémoire pour un dév => C/malloc" beaucoup trop réductrice. La mémoire c'est pas juste la taille d'un objet et la suppression de celui-ci quand il est inutilisé en RAM... Il se passe beaucoup d'autres choses qui méritent elles-aussi de la considération même pour des dévs...

Peu importe l'ordre d'apprentissage finalement AMHA, ce qui compte, c'est d'être conscient de l’existence de ces concepts. Apprendre le procédural, l'impératif ou l'objet en premier, c'est une question qui n'a pas réponse certaine mais il est certain qu'il faut tous les apprendre... Puisque ce sont des approches différentes permettant de résoudre les problèmes...

[niarkyzator]

Le titre est quand même bête.

Sauf erreure de ma part, la programmation objet c'est quand meme l'immense majorité du développement de nos jours.

Si la majorité des développeurs font de la POO, alors l'objectif des études d'informatique c'est d'apprendre la POO (entre autres choses).

Or le principe de la "distraction" (en partant de principe que le titre ne parlait pas de distraction au sens récréatif) c'est de détourner quelqu'un de son objectif initial.

C'est comme dire "le missile à été distrait par un avion ennemi et l'a détruit", ça n'a pas de sens.

[Côme]

Procéder par étape ne peut pas faire de mal, mais il serait dommage à mon sens de réfréner des envies. Pourquoi ne pas imaginer qu’un programmeur puisse rapidement se trouver un gout pour ce style de programmation ? Quelqu’un maitrisant parfaitement l’objet s’accommodera très bien, il me semble, d’une programmation procédurale. L’inverse est moins évident.

Python me semble être un bon langage pour apprendre les deux styles de programmation même si personnellement mon choix s’est porté sur Ruby.
En revanche, il me semble assez difficile de résister à l’objet bien longtemps avec ces deux langages. Peut-être est-ce plus simple avec Python, qui me semble plus « multiparadigme » que ne l’est Ruby ?

[magnus2005]

il FAUT enseigner aux élèves comment fonctionne une machine, ce que sont les pointeurs (bé oui, on manipule que ça en java/c#)

Il faut avant leur enseigner comment analyser une demande client et comment y répondre.

C'est assez désolant de voir la quantité de développeurs (en devenir ou non) qui n'ont pas la moindre idée de comment est géré leur objet par la vm. Qui n'ont pas non plus la moindre idée de comment fonctionne leur PC,

A titre personnel je suis à 100% d'accord.
A titre de chef de projet sur des applications de gestion, finalement force de constater que ce n'est absolument pas un critère discriminant pour attribuer des primes et évaluer un développeur.
Critère qui sont à mon avis :

• Livré du code maintenable
• Livré dans les temps

Pour être clair, j'ai fait du COBOL et du C, je n'ai aucun grief contre les pratiquants de ces langages.
Quelque soit la méthode à enseigner il faut avant avoir les bases de l'analyses, de factorisation et de rationalisation ça demeure très largement au dessus de paradigme de présentation de l'information.

Merci Tryph et aux autres aussi je me sens moins seul

Un point sur mon expérience perso :
je viens de faire passer une équipe du développement procédurale à la POO. maintenant mes supérieurs entende des délais de type semaine/mois à la place d'année/voir jamais. Il serait simpliste de dire que ce n'est uniquement de la POO mais à mon avis il y a contribué grandement. Cela reste mon avis et je le partage. C'est pour ça que j'ai fait référence au difficultés de différent profil de s'adapter à la POO c'est nous sommes encore dedans pour une minorité des équipes. Équipes très très hétéroclites.

[Invité]

Il faut avant leur enseigner comment analyser une demande client et comment y répondre.

Aux élèves? Ca me parait très présomptueux, car suivant le métier qu'ils feront les clients et leurs demandes varieront.

Et j'éviterai aussi de mettre ce genre de sujet dans des cursus universitaires où une partie des enseignants a une idée assez approximative du monde de l'entreprise.

A titre de chef de projet sur des applications de gestion, finalement force de constater que ce n'est absolument pas un critère discriminant pour attribuer des primes et évaluer un développeur.

Ca me parait être davantage un argument contre le travail dans des structures comme la tienne que pour la POO...

Parce que, "code maintenable" ça ne veut à peu près rien dire à court terme. En fait, neuf fois sur dix, ca veut juste dire respecter la charte stylistique, et mettre un maximum de commentaires inutiles. C'est sur le moyen terme qu'on juge de la maintenabilité, et on l'obtient presque toujours au prix de délais supplémentaires (en fait de réécritures en milieu de projet, quand on commence à avoir un peu de visibilité sur les vrais problèmes, les limites de l'existant, et la direction des évolutions futures).

Ensuite, "livré dans les temps", ça veut presque toujours dire bâclé, parce que les prévisions sont toujours optimistes, les difficultés sous estimées, les fonctionnalités "complétées" en cours de route. Et la victime idéale de ce genre de situation, c'est justement la maintenabilité.

En tant que développeur, j'éviterais une telle structure...

En tant que patron, j'ai tendance à récompenser, dans cet ordre
- la fiabilité du code produit
- la capacité à tester, et ne pas se noyer dans un compte rendu de bug
- l'équilibre entre ambition (ne pas toujours maintenir et faire du code "petit bras") et réalisme

Les délais, c'est à moi de les faire passer aux clients, pas aux développeurs de les tenir. Et la maintenabilité, ce n'est pas assez mesurable à court terme pour servir de base à des primes (mais c'est un excellent critère pour décider des évolutions à long terme).

je viens de faire passer une équipe du développement procédurale à la POO. maintenant mes supérieurs entende des délais de type semaine/mois à la place d'année/voir jamais. Il serait simpliste de dire que ce n'est uniquement de la POO mais à mon avis il y a contribué grandement.

Sérieusement, si la POO était la solution magique qui transforme les années hommes en mois hommes et rendait les solutions maintenable, ce débat n'existerait pas, et on ne dirait pas POO, mais programmation tout court.

Je ne connais pas ta situation, mais je pense que la principale raison du gain de temps est probablement la mise au pas d'une équipe hétéroclite, par la mise en place de méthodes communes. Le passage à une méthodologie nouvelle (la POO ici) est une solution classique.

Mais j'ai quand même un doute... Mon expérience, c'est que l'objet, sur les sujets où il fonctionne, nécessite souvent un investissement plus lourd (donc des délais plus longs) mais permet une meilleure évolution du code (par l'encapsulation et les hiérarchies de classe). Inversement, on peut produire très vite, en objet, du code très sale et parfaitement non maintenable (en multipliant les classes et les liens forts).

Francois

[Paul TOTH]

Mais j'ai quand même un doute... Mon expérience, c'est que l'objet, sur les sujets où il fonctionne, nécessite souvent un investissement plus lourd (donc des délais plus longs) mais permet une meilleure évolution du code (par l'encapsulation et les hiérarchies de classe). Inversement, on peut produire très vite, en objet, du code très sale et parfaitement non maintenable (en multipliant les classes et les liens forts).

j'ai travaillé sur de gros projets objets et de gros projets procéduraux tous les deux vieux de plus de 10 ans, ça donne le même bazar toute une partie du code mal adaptée aux nouveaux besoins est devenu imbuvable, sans documentation avec plus personne qui ose y toucher de peur que l'existant ne fonctionne plus. Dans les deux cas tout le monde était parfaitement conscient que le mieux aurait été de tout reprendre à zéro mais que ça ne serait fait qu'à grands frais pour un bénéfice à long terme...et donc toujours repoussé à plus tard, quand on aura moins le nez dans le guidon...ce qui n'arrive jamais.

[Invité]

j'ai travaillé sur de gros projets objets et de gros projets procéduraux tous les deux vieux de plus de 10 ans, ça donne le même bazar.

Je crois qu'on est tous d'accord. L'objet ne garantit pas plus que le procédural la maintenabilité du code. Je crois que le principal problème vient du fait qu'on a tendance à laisser le code vieillir.

Mon expérience, c'est que pour garder du code maintenable, il faut investir entre le quart et le tiers de son temps de maintenance en améliorations non visibles de celui ci. Eliminer les redondances, refaire des petits bouts, documenter, parfois simplement prendre le temps de lire et comprendre le code original.

La responsabilité, en ce domaine, est partagée. L'encadrement a souvent peu envie de "perdre de l'argent" sur des développements non directement vendables, mais les développeurs vont souvent au plus simple, et ont tendance à ne pas améliorer le "code des autres".

C'est d'ailleurs une chose qu'il faudrait enseigner (plutôt que la POO, à mon avis): lire du code, le comprendre, et y intervenir sans tout massacrer, en s'adaptant à un style qui n'est pas le sien.

j Dans les deux cas tout le monde était parfaitement conscient que le mieux aurait été de tout reprendre à zéro mais que ça ne serait fait qu'à grands frais pour un bénéfice à long terme...et donc toujours repoussé à plus tard, quand on aura moins le nez dans le guidon...ce qui n'arrive jamais.

Reprendre à zétro terrifie tout le monde (en fait tous les seniors) parce qu'on a tous en tête les produits qu'on a tués au passage "V1-V2 par réécriture complète". Il me semble que la bonne solution est presque toujours une réécriture par morceaux.

C'est généralement plus sûr parce qu'on passe d'un code qui marche à un code qui marche et qu'on peut tester au fil du temps. Ca prend en fait moins de temps que la réécriture, si on tient compte des tests, des régressions, des mauvaises surprises. Et c'est moins déstabilisant pour l'utilisateur (quand la réécriture implique une évolution d'interface).

Mais là encore, c'est le genre de chose que beaucoup de développeurs détestent faire, et que beaucoup de chef de projets trouvent peu valorisant.

Francois

[chaplin]

C'est sur le moyen terme qu'on juge de la maintenabilité, et on l'obtient presque toujours au prix de délais supplémentaires (en fait de réécritures en milieu de projet, quand on commence à avoir un peu de visibilité sur les vrais problèmes, les limites de l'existant, et la direction des évolutions futures).

Ensuite, "livré dans les temps", ça veut presque toujours dire bâclé, parce que les prévisions sont toujours optimistes, les difficultés sous estimées, les fonctionnalités "complétées" en cours de route. Et la victime idéale de ce genre de situation, c'est justement la maintenabilité.

CQFD

J'ajouterais que lorsqu'on travail en équipe, chaque développeur à son style de développement, mais si plusieurs développeurs travaillent sur les mêmes fonctionnalités, il est indispensable de mettre en commun tout ce qui peut l'être. En POO, les événements sur les objets servent justement à traiter les parties non communes, en laissant la main au développeur le reste étant implémenté dans la classe, c'est à dire la partie commune.

[MarieKisSlaJoue]

Il faut avant leur enseigner comment analyser une demande client et comment y répondre.

N'oublie pas que les heures de cours ne sont pas forcément extensibles et souvent chargées. revenons dans le contexte, il est dit débutant, donc on va partir sur aucune connaissance en info alors il faut en 2/3 ans lui donné toutes les bases pour faire fonctionner son pc. Travailler correctement dessus. Résoudre les problèmes les plus mineures qui pourrai arriver. Sans parler que on à beau être dev, les cours de réseau ça fait pas de mal. Vu que le dev c'est pas que de la programmation on rajoute les heures pour apprendre tous sur les bases de données, le sql toussa toussa.

Du coup les cours de programmation pour les débutants ils sont assez light, et faut les rendre près à travailler en entreprise à la sortie. Comment gagné du temps ? En abordant directement l'objet.

Souvent on entend que les jeunes diplômés ne savent rien faire. C'est pas en abordant tard l'objet au risque qu'il passe à la trappe que ça va s’améliorer.


Et encore on oublie pas les cours de math/Anglais/Linux/Windows