Discussion :

[Firwen]

Ne pas enseigner l'OO dès le début n'est pas une idée plus stupide que ne pas enseigner le fonctionnel dès le début

Mh pas vraiment,

La principal raison de l'apprentissage du fonctionnel dans les premières années vient de l'enseignement de l'algorithmique, on apprend rarement du fonctionnel pour l'utiliser en entreprise

Il est trés facile de mettre en œuvre les concepts de base lié à l'algorithmique ( récursivité, iteratif, notion de fonction ) dans un langage fonctionnel tel que OCaml ou Scheme pour un novice.
Ces langages font une abstraction quasi-totale du hardware (pointeurs, gestion mémoire, allocation), Ce qui a mon sens facilite l'implémentation d'algos et donc l'apprentissage de ceux-ci.

[psykoprof]

Je suis enseignant en BTS Informatique et reseau (IRIS) et on commence par leur apprendre le langage C et l'algorithmie en première année afin d'avoir les bases du développement (syntaxe, debugage, algorithmie, analyse, conception, etc...) ensuite vient en deuxieme année la POO en standard C++ mode console puis avec Qt pour le développement d'appli graphique. Ma collègue fait les MFC avec ses élèves.

Je m'aperçoit que cela correspond à cet article. Maintenant pour la prog parallèle, on est juste en BTS donc on leur fait faire des threads pour répondre à un problème mais c'est mode light. Ce ne sont pas des ingénieurs et le programme est vraiment lourd du coup on a pas le temps de s'attarder sur tous les concepts en détail.

[soft0613]

Pour m'a part, j'étudie dans une école d'informatique et on apprend pas la POO en première année... Je rejoins ce qui est dit plus haut vis-à-vis de l'ouverture d'esprit, apprendre à penser OO demande pas mal d'aprentissage et donc l'apprendre très tôt nous enferme dans le paradigme et nous rend difficile l'apprentissage des autres styles de programmation.
Je suis allé à la fac avant aussi et nous n'apprenions pas la POO en première année, je ne pense pas que se soit nécessaire pour former correctement les étudiants, ça peut même être "mettre la charrue avant les boeufs" de l'apprendre trop top.

[blbird]

Quand on fait de la programmation concurrente (sur architecture parallèles), ce genre de phrases n'a aucun sens, la POO est même un handicap dans certains cas. En programmation concurrente, on ne sépare pas les tâches en les encapsulant chacune dans une classe à laquelle on affecte une responsabilité, on les sépares en définissant les responsabilité via des contrats (protocoles) et on affect chaque tâche (bout de code) à un process (fut il un thread or vrai process ou ...) à part pour qu'il soit executé. La POO et son encapsulation devient un vrai handicap dans certains cas. C'est encore pire dans le cas des architectures ou l'on a besoin de faire du traitement parallèle et où ce traitement est piloté pas évènements!!!

Je ne vois pas en quoi c'est impossible en POO. Même en faisant de l'objet, il faut savoir sortir des schémas dirigistes. Tu peux très bien associer ton bout de code à une classe, utiliser un mécanisme de routage des demandes en multi-thread sur chacune de ces classes. Pas de notions d'évènements ici, mais de traitement du besoin au fur et à mesure. C'est un peu ce qui se passe au coeur même d'une JVM (mais aussi dans les serveurs d'application) ou de DotNet. Après tout ca est améliorable si on veut aller encore plus loin.
Bref, pour moi la POO et la programmation en architecture parallèle ne sont pas concurrentielles, elles sont chacune plus ou moins adaptées à certains types d'applications.

[wiztricks]

Je ne vois pas en quoi c'est impossible en POO. Même en faisant de l'objet, il faut savoir sortir des schémas dirigistes.

La POO propose des boîtes qui encapsulent un état auxquelles sont associées des méthodes qui induiront des changements d'état.

En programmation parallèle, on est plutôt dans une logique de traitements associées à des flux. La capacité à paralléliser dépendra de l'indépendance des différents traitements. Nous avons un modèle plutôt statefull d'un côté et un modèle plutôt stateless de l'autre.

Ceci dit, cela signifie (peut être de) structurer son application en fonction d'un diagramme de séquence (les flux) plutôt qu'en fonction d'un diagramme de classe (la statique).

Cette emphase sur les flux est sans doute plus adaptée à des démarches d'intégration de composants, alors que la POO "classique" est plus orienté "construction" du composant i.e. développement.

De ce fait, les enseignements essaient de s'adapter pour refléter les réalités du travail des informaticiens d'aujourd'hui : plus d'intégration, moins de construction. Ce qui ne veut pas dire mettre la POO à la poubelle, juste que la construction devient une spécialité alors que l'intégration devient la règle.

- W

[blbird]

La POO propose des boîtes qui encapsulent un état auxquelles sont associées des méthodes qui induiront des changements d'état.

Ah bon? Et qui a dit que la POO devait s'arrêter à des automates?

C'est ta vision, mais elle à mon sens tronquée. Une classe peut très bien être seulement utilitaire ou fonctionnelle. Il suffit de voir le nombre d'étudiants qui sortent d'écoles prestigieuses et qui utilisent la POO comme un langage procédural.

[wiztricks]

Ah bon? Et qui a dit que la POO devait s'arrêter à des automates?

Un programme informatique est-il autre chose qu'un automate?
La POO est elle utile à autre chose qu'à construire des automates compliqués dont le comportement mime parfois celui des humains?

C'est vrai qu'avec Java, vous avez peut être cru que la POO faisait aussi du café... Ben non, juste des "automates" dont certains interagissent avec les humains.

Il suffit de voir le nombre d'étudiants qui sortent d'écoles prestigieuses et qui utilisent la POO comme un langage procédural.

Apprendre à utiliser une langage pour la POO tel que Java ou en C++ et penser "objet" sont des acquisitions différentes et font généralement l'objet d'enseignements ad hoc.

Un langage POO permettra d'écrire/traduire plus facilement une conception OO. Mais sa fonction première reste d'être un langage de programmation avec des "verbes" spécifiques qui faciliteront la construction de "gros" programme - si on sait bien les utiliser -.

Réciproquement, on peut concevoir suivant un modèle objet, fonctionnel,... et "réaliser" avec des langages faiblement "alignés" avec le modèle de conception.

La question soulevée par la décision des enseignants de CMU ou du MIT est: compte tenu de l'évolution des savoir faire quel langage d'initiation proposer à nos étudiants CS et EE? Certainement plus la même chose que ces 20 dernières années.

Le fait est que pour l'initiation, vous ne faites pas de choses suffisamment compliquées: passer par la POO n'est pas nécessaire. Mais, c'était déjà le cas au MIT ces 20 dernières années. Ils étaient sur Scheme et sont partis sur Python non pour ses qualités OO mais pour ses possibilités de glue.
- W

[pschiit]

Supprimer la programmation objet en premier cycle... cela me fait penser à ce que j'ai vécu à l'iut, en tout et pour tout on à eu 30 de java et 30 de C++ pour la programmation objet. Le tout avec 1 unique TP en java (histoire de voir comment utiliser eclipse). Et un projet basique en C++. Quand à apprendre ne serais-ce que ce qu'est la programmation fonctionnelle, c’était même pas la peine de rêver. C'est tellement mieux d'insister sur le C (normal), sur le COBOL et sur le VB.
Cela oblige juste les plus motivés des élèves à continuer leurs études pour avoir un niveau correct.

[psykokarl]

Cette démarche n'a rien de révolutionnaire, c'est celle dont j'ai profité à la fac...
Lors de mon cursus, j'ai abordé la programmation avec des langages impératifs: le C et assembleur entre autres.

Les langages impératifs ont l'avantage d'être ceux qui dénaturent le moins le type d'instructions que pourrait recevoir un cpu. Je ne dis pas qu'il faut savoir coder en assembleur pour valoir quelque chose, mais il me parait important de savoir que stocker des données en mémoire et les rafraichir sans les corrompre ne se fait pas tout seul.
En cours de programmation avancée en C, j'ai appris des techniques pour structurer, protéger les données et assurer la modularité du code. Parallèlement j'ai appris d'autres paradigmes de programmation dont la POO, la programmation fonctionnelle, la "programmation" logique...
Il en ressort que tout est une question de syntaxe. J'ai eu la chance de savoir faire l'équivalent de ce que permettent ces autres langages avec du C avant ou en même temps que je les ai appris. J'apprécie d'autant plus la POO parce qu'elle m'évite de faire du code pour du code en m'affranchissant d'avoir à utiliser certaines de ces techniques.

Ce qui me désole un peu avec certains développeurs objet "pur jus", hormis le fait que la plupart ne savent pas ce qu'est programmer purement objet, c'est qu'on leur à vendu la POO pour ce qu'elle n'est pas. Un moyen de faire du code modulaire et j'ai déjà vu du code en langage objet qui se révélait être un casse tête pour ce qui est de la compréhension et de la maintenance.
Pour ma part, je fais une distinction claire et nette entre coder de façon structurer et la nature du langage.
Si le second facilite la mise en œuvre du premier elle ne l'assure aucunement et je préfère ne pas parler de tout ce qui est optimisation...
Bref, il ne faut pas abandonner la POO loin de la mais il faut savoir revenir au fondamentaux.

Sinon à la limite du hors sujet: La façon qu'on certains étudiants d'être obnubilé par le fait de trouver un emploi m'inquiète un peu. Pour peu que le F# s'impose de nouveaux intervenants s'insurgeront quand on parlera de rendre facultative la programmation fonctionnelle. Je crains qu'a terme les créatifs soient trustés par Oracle, Google ou Microsoft le reste ne devenant que de simple utilisateur de leurs produits.

[Flaburgan]

La question soulevée par la décision des enseignants de CMU ou du MIT est: compte tenu de l'évolution des savoir faire quel langage d'initiation proposer à nos étudiants CS et EE? Certainement plus la même chose que ces 20 dernières années.

Pour ma part, à Grenoble, que ce soit l'IUT ou l'ENSIMAG, la réponse est l'ADA. Très fortement typé, avec un compilo qui détaille absolument tous les problèmes si on lui met les bonnes options, et des programmes qui sont la traduction en anglais de l'algo écrit en français, ce langage permet un apprentissage rigoureux des bases de la programmation. Après, ya toujours ceux qui savent déjà coder un minimum et qui arrivent en râlant "on doit apprendre une syntaxe complétement différente que plus aucune entreprise utilise..."

[ztor1]

Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum.

Vrai que vu comme cela ...

Mais si l'on creuse un peu plus ce "courses"

http://www.cs.cmu.edu/~fp/courses/15122-f10/

http://www.cs.cmu.edu/~15150/

Ainsi que les projets et intérêts de l'auteur :

http://www.csd.cs.cmu.edu/research/f...ch/harper.html

On remet tout cela dans le contexte de cette unif

http://www.cs.cmu.edu/

Je ne pense pas qu'il remette en question l'OO Mais que celui-ci n'est pas pertinent dans le programme des cours de monsieur Harper.

@+

[souviron34]

il n'y a pas d'opposition de fond, et justement c'est pourquoi je me bat également à longueur de débats sur cette quasi-religion OO ..

Comme cela avait été cité ailleurs dans :

Les avantages du procédural par rapport à l'orienté objet


un des posteurs a établit un post résumant très bien la situation :

http://www.developpez.net/forums/m3930485-61/

Mais il n'y en a pas de réelle différence !
Il y a une différence entre percevoir le monde d'après le paradigme objet et percevoir le monde d'après le paradigme procédural. Dans le premier cas tu vois le monde comme des objets qui communiquent entre eux pour résoudre une tâche. Chaque objet connait ce qu'il a à faire et comment il a à le faire. Il envoie des messages, à lui ou aux autres pour demander quelquechose. La paradigme procédural voit le monde comme une ensemble de fonctions qui collaborent. C'est une vision plus « mathématique » bien qu'il faille faire attention à ne pas faire un parallèle sans nuance. Résoudre un problème c'est appeler la bonne fonction qui elle-même appellera les autres qui lui sont nécessaires.

Est-ce qu'il y a opposition ? Non. Car les objets aussi doivent faire des actions et donc employer des procédures si on veut. Les fonctions elle s'appliquent sur des données et donc on retrouve des agrégats et d'autres données complexes qui peuvent être vu comme des « objets » aussi du monde.
...
...
L'OO, c'est mettre les données en avant et décomposer le problème selon les relations (la complexité) entre ces données. Le procédural, c'est mettre les fonctionnalités en avant et décomposer le problème selon la complexité fonctionnelle. En pratique, on fait toujours un peu des deux. Les langages mettent juste plus l'emphase (attention anglicisme) sur l'une ou l'autre de ces points de vue en offrant une syntaxe et des propriétés qui s'y prêtent mieux. Mais finalement, on fait la même chose.

c'est pour ça que ça fait riech cette religion de l'OO...

[GCSX_]

A mon avis, retirer purement et simplement de la formation une méthode très utilisée est tout simplement stupide. Tout ces étudiant qui n'auront jamais fait de POO (s'il n'en font plus du tout) ne gagnerons que des problème pour trouver du travail en sortant de l'école.

De plus, POO et parrallelisme ne sont pas antinomique, il suffit de se mettre à jour et d'apprendre à utiliser des threads en environnement objet.

Et enfin, dernier point : rien n'empèche de faire du fonctionnel avec des langages objet, ce qui est impossible (ou très difficile) dans l'autre sens.
Je préfère donc apprendre la POO et revenir au fonctionnel pure si le travaille qui m'est demandé le nécessite, plutôt que d'être complètement paumé si on me demande de faire de l'objet.

Qui peut le plus peut le moins comme on dit. (Sans dire que le fonctionnel est moins "bien" que l'objet. Ce sont 2 approches différentes, aussi puissantes l'une que l'autre, mais chacune à ses avantages et inconvénients).

[bugsan]

Je ne pense pas qu'il faille opposer langages OO et fonctionnels, comme si ils s'excluaient.

Aujourd'hui j'ai l'impression qu'on va dans une direction où on va mixer les technologies et les langages pour tirer le meilleur de chacun. Par exemple au départ on pouvait penser que NoSQL s'opposait aux SGBD. Maintenant il semble que la démarche soit de mixer les deux dans une même application (c'est l'avis de Rod Johnson).

En technologie web on est déjà habitué à ce que l'ensemble de l'application soit écrite en plusieurs langages différents (html, css, js, java ou php, etc ...). Qu'ils soient orienté objet, composition, ou spécifique au domaine comme les stylesheets ...

Et j'en viens donc à la JVM, qui supporte dorénavant plusieurs langages. Donc rien n'empêche de faire une partie de l'appli en Java, et des morceaux en Scala...
Pour des calculs parallèles j'imagine que ça implique un soucis de performance, donc plutôt du CUDA avec un wrapper java ...


Ma conclusion c'est que tout devrait être enseigné

[Flaburgan]

J'ai l'impression qu'il y a une confusion entre programmation impérative et programmation fonctionnelle, pour moi ce n'est pas la même chose..

[SpiceGuid]

Si mes souvenirs sont exacts, au MIT ils ont remplacé tous les cours en Scheme par des cours en Python. Alors est-ce que ça voudrait dire que la programmation fonctionnelle est dépassée ?

Ben non, ça veut juste dire que l'enseignement n'assure pas de continuité dans les langages supports de cours. C'est souvent une mauvaise nouvelle pour les redoublants, car le programme est le même mais ils ne s'en rendent pas compte tellement le langage est différent.

[Laurent.B]

Hé les gars ! L'objectif ultime est de faire en sorte que les machines nous rendent efficacement service, peu importe le langage ou les façons de faire !

AMHA, je pense que les dirigeants de cette école sont pragmatiques et de fait, s'ils ont fait ce choix, c'est tout simplement parce qu'il y a la demande ! A la sortie, les étudiants de cette école auront des compétences attendues ! Bien entendu, ils n'iront pas dans des SSII ou des éditeurs de logiciels classiques mais dans des services de R&D de sociétés HiTech.

La programmation OO est et restera un grand pas par rapport à la programmation procédurale. Elle a permis d'aller plus loin dans l'architecture des applications, en les rendant plus modulaires, plus évolutives, plus faciles à maintenir.... Ce qu'étaient déjà les avantages de la programmation procédurale, par rapport à la programmation séquentielle. Bien ! Mais c'est évident que ce n'est qu'une étape ! Fondamentalement, ça ne peut pas rester figé !
Et les étudiants qui passeront directement à l'étape fonctionnelle, feront implicitement du séquentiel, du procédural et de l'objet. C'est pas compliqué ?! Il faudra surtout qu'ils assimilent le côté multiplication des "dimensions", en quelque sorte.

Alors quand je vois les premiers commentaires... On va avancer avec vous, c'est sûr

[vemPierchen]

De mon avis ca ne sert pas à grand chose d'apprendre du OO dès le début: Peut-être du code OO est facile est intuitif à comprendre, mais vraiment comprendre le paradigme OO, ses avantages, sa puissance, requiert des connaissances en software engineering, des mauvaises expériences personnelles dans des projets assez dynamiques du côté des spécifications et plus grand que les exercices ou TP proposés en générale dans les cours.
Et pour y arriver à maîtriser la programmation ou le paradigme OO à fond, on a finalement besoin d'expérience et un tic de perfectionnisme!

De ce que j'ai vu jusqu'à présent, j'ai l'impression que même environ un quart des développeurs pro programment dans un language OO sans se servir trop des méchanismes OO. La majorité des étudiants en première année qui sont obligés de passer par un cours de programmation OO ne vont rien en sortir à part de faire tourner des petits programmes procédurales enveloppés dans une méthode main() d'une classe écrite en Java... complêtement rater le point important. Ce temps pourrait être investit beaucoup plus utile!

J'en ai parler à un certain nombre de développeurs dans mon entourage avec des bonnes réputations pour leurs style OO trés élégant et trés exigeant et on était tous assez d'accord que quasiment tout le monde rate le message OO dans les cours qui justement sont sensée de l'apprendre à l'étudiant, qu'on ne se rend compte qu'on n'avait pas du tout capté l'OO qu'à la fin de ses études ou début de sa carrière pro et que, à part de quelques exceptions extrémement rares, si on pense après beaucoup d'années d'expérience dans la programmation OO que l'on avait bien compris en première année, c'est qu'on ne l'a toujours pas vraiment compris!!!

[tomlev]

Ca me fait doucement rigoler ce genre de débat : "la POO c'est mal, l'impératif c'est mal, le fonctionnel c'est mal..."

Chaque paradigme a ses avantages et ses inconvénients, il faut tirer parti de chacun (si possible au sein du même langage). C'est complètement idiot d'éliminer complètement l'un au profit de l'autre alors que chacun est plus ou moins bien adapté pour résoudre tel ou tel type de problème.

Personellement je développe essentiellement en C#, et à mon avis ce langage combine bien les différentes approches, surtout depuis l'arrivée de LINQ qui permet de faire du fonctionnel dans un langage qui est au départ purement orienté objet.

[Caribensila]

« Une école américaine des sciences décide de ... »

De toute façon, on s'en fout !

Que les américains continuent de dire « le two, two à Asnières » plutôt que « le 22 à Asnières », ou « 8 et demi du soir » au lieu de « 20:30 », ça ne changera pas le monde : les USA importent ses élites scientifiques et leur enseignement (sauf pour les débouchés) n'a jamais été une référence !