Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C++ Pédagogie : C++ ou Java ?

Pédagogie : C++ ou Java ?

133 réponses
Avatar
Gilles
Bonjour à tous.

J'ai beaucoup apprécié le fil "Avis sur les include files" où ont été
abordées entre autres des questions sur l'enseignement du C++ et les "bonnes
habitudes" à enseigner en TP, ce qui m'incite à poster ce message.

Voici la situation : je suis enseignant en IUT - DUT informatique (Bac+2 à
vocation professionnelle). Jusqu'à maintenant la programmation était
enseignée au travers du C++. Il est fortement question de changer ce choix
dans notre IUT pour remplacer C++ par Java (actuellement un enseignement de
Java existe, mais en seconde année seulement, donc avec déjà une pratique du
C++ et les bases de la POO).

J'aimerais vos avis sur ces deux questions :
- quels sont les arguments en faveur (ou en défaveur) du C++ (par rapport à
Java) pour enseigner la POO à des débutants complets en programmation ? (et
pour qui, pour reprendre une remarque apparue dans le fil auquel je faisais
référence, il n'y a plus en majorité "de passion ou de réelle envie de faire
de l'informatique"...)
- est-il raisonnable de lâcher sur le marché du travail des informaticiens
"Bac+2" qui n'aient jamais programmé en C++ ?

Note personnelle : je ne suis pas le chargé de cours concerné, j'ai une
tendance à préférer le C++ (par mon parcours et par mon activité quotidienne
en recherche), mais je n'aurai aucune réticence à faire pratiquer Java si je
suis convaincu que c'est un meilleur choix pour mes étudiants.

Merci d'avance pour vos contributions qui nourriront sûrement le débat que
nous devrions avoir au sein de l'équipe pédagogique.

Gilles
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
10 11 12 13 14
Avatar
Sylvain SF
Marc Espie a écrit :
In article <49a1d3fd$0$17769$,
Sylvain SF wrote:
voila ! que l'auteur expie cette injure au bon sens - et surtout
le fait d'utiliser le format d'un méchant éditeur qui fait des
sous en vendant cher des softs douteux jamais ouvert ! btw, on
aurait pu flamber aussi le flash dans ce fil, non ?



Euh la, par contre, tu ferais mieux de te taire.



je suis entièrement d'accord ... puisque je reprenais des arguments
que je ne partage pas du tout.

Sylvain.
Avatar
Fabien LE LEZ
On Sun, 22 Feb 2009 22:54:06 +0100, Wykaaa :

Exact. Quand on voit comment est utiliser le html, on peut se poser des
questions sur la bonne santé mentale de 90% des webmestres...



Faut dire aussi que dès qu'on veut faire de l'argent avec un site, le
côté "flashy" compte très largement plus que le contenu ou la
lisibilité d'icelui.

Il y a une petite différence entre PDF et Flash. L'un est un quasi
standard, l'autre sert aux neuneus à fabriquer des arbres de Noël !



En pratique, les deux sont des standards de fait. Et tant que le W3C
tourne en rond avec HTML5, utiliser Flash est la seule manière fiable
d'afficher de la vidéo sur une page web.
Avatar
Jean-Marc Desperrier
Fabien LE LEZ wrote:
On Sun, 08 Feb 2009 00:38:48 +0100, Wykaaa:

C'est bizarre si ce n'est pas abordé car c'est plein de pièges.
personnellement, et je ne suis pas le seul, j'en déconseille l'emploi
sauf dans des cas très particuliers.



Ce qui explique peut-être pourquoi ce n'est pas abordé...



Ne pourrait-on pas en dire presque autant d'un certain nombre des
différences entre C++ et Java ?

Dans l'approche présentée ici, n'y-a-t-il pas un risque de surcharge de
l'apprenant moyen, détourné vers des subtilités pas essentielles
(constructeur faisant de l'allocation dynamiques) et qui à l'arrivée
aura retenu une version plus ou moins foireuses des concepts compliqués
(et inutilisable car c'est des trucs où on ne peut pas se permettre une
seule erreur quand on s'en sert), mais ne maitrisera réellement pas les
bases ?

Si dans quelques années, les languages (ou version de languages) à
garbage collector se sont définitivement imposées (sauf pour quelques
applications très pointues), toute la partie passée à expliquer ces
subtilité sur l'allocation dynamique ne sera-t-elle pas un peu ridicule ?

Franchement personnellement je préfererais passer deux fois plus de
temps à être sûr que l'apprenant à *vraiment* compris les concept de
développement par couches, de conception des interfaces de manière à
réllement isoler les objets, de ne pas d'un seul coup exposer dans
l'objet A un truc qui manifestement devrait être interne mais voilà en
fait finalement l'objet B en a besoin et il ne voit pas comment faire
autrement que de le rendre publique, le concept de comment rendre
générique mais de ne pas de faire des couches de généricité pour le
plaisir sans aucun intérêt, de comment on peut refactoriser un code
quand on se rend compte qu'on s'était planté au départ, et de pourquoi
définir dès le départ les fonctionnalités attendus et écrire les tests
qui s'assurent qu'elles sont réalisées devient un énorme gain de
productivité à la fin.

Tiens les deux entrées de blog suivant sur le dévelopement d'un outils
python qui duplique le fonctionnement de gmake (et de presque
l'intégralité des subtilités de gmake) est une bonne illustration des
ces derniers principes (par exemple sur le fait que même les très, très
bons hackers savent tôt ou tard ils trouveront une erreur de conception
qui les obligera à refactoriser du code) :
http://benjamin.smedbergs.us/blog/2009-02-23/sanity-and-testcases-for-pymake/
http://vocamus.net/dave/?p97

D'ailleurs on pourrait se demander si aujourd'hui le meilleur language à
enseigner ne serait pas javascript, à condition de le faire proprement
en partant du concept de programmation par prototype et des liens avec
Self http://en.wikipedia.org//wiki/Self_(programming_language) et sur
une plate-forme en JIT, qui fait concurrence à pas mal d'autres
languages en rapidité d'exécution, ainsi qu'en utilisant les mécanismes
avancés piqués à Python (générateurs, itérateurs, assignation
déstructurante, expressions génératrices
http://fr.wikipedia.org/wiki/JavaScript#Version_1.7
https://developer.mozilla.org/fr/Nouveautés_dans_JavaScript_1.7
Avatar
espie
In article ,
Fabien LE LEZ wrote:
On Sun, 08 Feb 2009 00:38:48 +0100, Wykaaa :

C'est bizarre si ce n'est pas abordé car c'est plein de pièges.
personnellement, et je ne suis pas le seul, j'en déconseille l'emploi
sauf dans des cas très particuliers.





Ce qui explique peut-être pourquoi ce n'est pas abordé...



Il faudrait au moins mentionner a quoi ca sert, et quand.

Mais bon, je suis encore un peu plus extreme: je suis pour passer beaucoup
de temps sur l'encapsulation et l'abstraction, nettement moins de temps
sur l'heritage (qui est deja assez dangereux), et apres expliquer les pattern
utiles (l'inversion de dependances, et l'heritage implementation/interface,
seul cas "raisonnable" d'heritage multiple).

Le chiendent des notions complexes, comme la surcharge ou l'heritage
multiple, c'est qu'on ne voit jamais aucun soucis sur de petits projets.
C'est seulement lorsqu'on a deja 500 lignes de code qu'on voit les soucis
architecturaux qui, a terme, forcent a tout mettre a la poubelle et a
recommencer a partir de rien...
Avatar
Fabien LE LEZ
On Thu, 26 Feb 2009 16:12:49 +0100, Jean-Marc Desperrier
:

Si dans quelques années, les languages (ou version de languages) à
garbage collector se sont définitivement imposées [...]

[...] de conception des interfaces de manière à
réllement isoler les objets



Et si dans quelques années, un nouveau paradigme (programmation
fonctionnelle ? Autre chose ?) a fait oublier la POO ?
Avatar
Wykaaa
Jean-Marc Desperrier a écrit :
Fabien LE LEZ wrote:
On Sun, 08 Feb 2009 00:38:48 +0100, Wykaaa:

C'est bizarre si ce n'est pas abordé car c'est plein de pièges.
personnellement, et je ne suis pas le seul, j'en déconseille l'emploi
sauf dans des cas très particuliers.



Ce qui explique peut-être pourquoi ce n'est pas abordé...



Ne pourrait-on pas en dire presque autant d'un certain nombre des
différences entre C++ et Java ?

Dans l'approche présentée ici, n'y-a-t-il pas un risque de surcharge de
l'apprenant moyen, détourné vers des subtilités pas essentielles
(constructeur faisant de l'allocation dynamiques) et qui à l'arrivée
aura retenu une version plus ou moins foireuses des concepts compliqués
(et inutilisable car c'est des trucs où on ne peut pas se permettre une
seule erreur quand on s'en sert), mais ne maitrisera réellement pas les
bases ?

Si dans quelques années, les languages (ou version de languages) à
garbage collector se sont définitivement imposées (sauf pour quelques
applications très pointues), toute la partie passée à expliquer ces
subtilité sur l'allocation dynamique ne sera-t-elle pas un peu ridicule ?

Franchement personnellement je préfererais passer deux fois plus de
temps à être sûr que l'apprenant à *vraiment* compris les concept de
développement par couches, de conception des interfaces de manière à
réllement isoler les objets, de ne pas d'un seul coup exposer dans
l'objet A un truc qui manifestement devrait être interne mais voilà en
fait finalement l'objet B en a besoin et il ne voit pas comment faire
autrement que de le rendre publique, le concept de comment rendre
générique mais de ne pas de faire des couches de généricité pour le
plaisir sans aucun intérêt, de comment on peut refactoriser un code
quand on se rend compte qu'on s'était planté au départ, et de pourquoi
définir dès le départ les fonctionnalités attendus et écrire les tests
qui s'assurent qu'elles sont réalisées devient un énorme gain de
productivité à la fin.

Tiens les deux entrées de blog suivant sur le dévelopement d'un outils
python qui duplique le fonctionnement de gmake (et de presque
l'intégralité des subtilités de gmake) est une bonne illustration des
ces derniers principes (par exemple sur le fait que même les très, très
bons hackers savent tôt ou tard ils trouveront une erreur de conception
qui les obligera à refactoriser du code) :
http://benjamin.smedbergs.us/blog/2009-02-23/sanity-and-testcases-for-pymake/

http://vocamus.net/dave/?p97

D'ailleurs on pourrait se demander si aujourd'hui le meilleur language à
enseigner ne serait pas javascript, à condition de le faire proprement
en partant du concept de programmation par prototype et des liens avec
Self http://en.wikipedia.org//wiki/Self_(programming_language) et sur
une plate-forme en JIT, qui fait concurrence à pas mal d'autres
languages en rapidité d'exécution, ainsi qu'en utilisant les mécanismes
avancés piqués à Python (générateurs, itérateurs, assignation
déstructurante, expressions génératrices
http://fr.wikipedia.org/wiki/JavaScript#Version_1.7
https://developer.mozilla.org/fr/Nouveautés_dans_JavaScript_1.7





Ce que tu dis pourrait ouvrir un nouveau fil et il me semble que tu n'as
pas tout à fait tort, dans un premier temps. Il me semble cependant que,
dans nombres de cas de la vie réelle, les développeurs vont devoir vivre
encore longtemps avec la manipulation, certes délicate, de la mémoire et
l'allocation dynamique explicite.
Pour moi, ça fait partie de la "culture" du développeur, au moins encore
aujourd'hui.
Avatar
Wykaaa
Marc Espie a écrit :
In article ,
Fabien LE LEZ wrote:
On Sun, 08 Feb 2009 00:38:48 +0100, Wykaaa :

C'est bizarre si ce n'est pas abordé car c'est plein de pièges.
personnellement, et je ne suis pas le seul, j'en déconseille l'emploi
sauf dans des cas très particuliers.





Ce qui explique peut-être pourquoi ce n'est pas abordé...



Il faudrait au moins mentionner a quoi ca sert, et quand.



On ne peut effectivement pas éviter ce niveau de compréhension pour les
futurs développeurs.

Mais bon, je suis encore un peu plus extreme: je suis pour passer beaucoup
de temps sur l'encapsulation et l'abstraction, nettement moins de temps
sur l'heritage (qui est deja assez dangereux), et apres expliquer les pattern
utiles (l'inversion de dependances, et l'heritage implementation/interface,
seul cas "raisonnable" d'heritage multiple).



Tout à fait d'accord que l'encapsulation et l'abstraction sont les
concepts les plus fondamentaux d'un développement logiciel "propre".
Cependant, il y a des cas autres que ceux que tu cites où l'héritage
multiple peut être utile à condition qu'il reste très localisé. Ce qu'il
faut faire bien comprendre aux débutants c'est qu'il ne faut pas baser
la conception générale, quel que soit le logiciel, sur l'héritage
multiple aux niveaux les plus hauts (les couches les plus externes).

Le chiendent des notions complexes, comme la surcharge ou l'heritage
multiple, c'est qu'on ne voit jamais aucun soucis sur de petits projets.
C'est seulement lorsqu'on a deja 500 lignes de code qu'on voit les soucis
architecturaux qui, a terme, forcent a tout mettre a la poubelle et a
recommencer a partir de rien...


Pour moi, un petit logiciel, c'est jusqu'à, environ, 10 kloc de code...

C'est bizarre de dire "C'est seulement lorsqu'on a deja 500 lignes de
code qu'on voit les soucis architecturaux" car, quand on fait de
l'architecture, on n'a pas encore codé et si l'on fait de l'architecture
"proprement" (c'est-à-dire en respectant bien les principes
d'abstraction et d'encapulation) on ne devrait pas rencontrer de gros
soucis quel que soit le nombre de lignes de code final.
Avatar
pjb
Wykaaa writes:

Marc Espie a écrit :
Le chiendent des notions complexes, comme la surcharge ou l'heritage
multiple, c'est qu'on ne voit jamais aucun soucis sur de petits projets.
C'est seulement lorsqu'on a deja 500 lignes de code qu'on voit les soucis
architecturaux qui, a terme, forcent a tout mettre a la poubelle et
a recommencer a partir de rien...


Pour moi, un petit logiciel, c'est jusqu'à, environ, 10 kloc de code...

C'est bizarre de dire "C'est seulement lorsqu'on a deja 500 lignes de
code qu'on voit les soucis architecturaux" car, quand on fait de
l'architecture, on n'a pas encore codé et si l'on fait de
l'architecture "proprement" (c'est-à-dire en respectant bien les
principes d'abstraction et d'encapulation) on ne devrait pas
rencontrer de gros soucis quel que soit le nombre de lignes de code
final.



Quand on a 500 LOC on peut tout réécrire dans l'après midi.

Quand on a 500 kLOC, on ne peut pas. C'est là que les problème
prennent toute leur dimention.


Ceci dit, on peut faire comprendre le problème sur un programme de 500
lignes: il suffit de faire évoler les spécifications.

Donc, pour rejoindre le sujet, on pourrait proposer un schéma de
travaux pratiques sur quatre semaines.

1e semaine: énoncé du problème, vous avez une semaine pour implémenter.
2e semaine: c'est bien, mais le client veut changer telle et telle choses.
3e semaine: ah, il avait oublié de dire qu'il veut aussi telle et telle fonctions.
3e semaine et trois jours: et aussi, ceci ne va pas, il veut en fait autre chose.
4e semaine: alors, où il est le programme? le client attend! Ah, au
fait, il faut aussi bien sur que le programme fasse ceci et celà.

Après deux ou trois "refactorisation", ils devraient comprendre, même
sur seulement 500 lignes et trois ou quatre classes...

--
__Pascal Bourguignon__
Avatar
Fabien LE LEZ
On Fri, 27 Feb 2009 14:42:25 +0100, Wykaaa :

Il me semble cependant que,
dans nombres de cas de la vie réelle, les développeurs vont devoir vivre
encore longtemps avec la manipulation, certes délicate, de la mémoire et
l'allocation dynamique explicite.



Un certain nombre de programmeurs va continuer à s'en occuper. Mais
même aujourd'hui, pour la majorité des programmeurs, ça ne sert pas.
Avatar
Jaco
On 6 fév, 11:48, Wykaaa wrote:

Je ne suis pas d'accord sur "plus C# que Java" car Java est maintenant
presque dans le domaine du libre alors que C# est propriétaire et que
son langage intermédiaire (MSIL, l'équivalent du bytecode) n'est pas
très "inter-langages" (.NET supporte d'autres langages mais pas
l'ensemble de leurs bibliothèques, ce qui est très piégeant).



Ce n'est pas tout à fait vrai non plus... Mono est libre (Ce n'est pas
encore le cas de Java, loin s'en faut, à moins de n'utiliser que
certaines plate-formes).
D'ailleurs, je m'en sers pour remplacer Java dans mon cours de cette
année car, personnellement, je trouve le langage "mieux foutu" que
Java (peut-être aussi parce que ça me gave de voir du Java partout et
à toutes les sauces).
10 11 12 13 14