Discussion :

[Tommy31]

Néanmoins je pense qu'il y a quelque part une part de vérité

Bien évidement, sinon ce ne serait pas drôle.

[muad'dib]

La naïveté est un trait charmant mais dangereux pour toi.

Ce n'est pas de la naïveté mais de la curiosité. Même si Stroustrup dément sur son site officiel avoir donné cette interview (http://www.research.att.com/~bs/bs_faq.html#IEEE) rien ne prouve qu'il n'a jamais prononcé ces mots. Il peut très bien mentir, comme le peut celui qui a diffusé cette interview. On ne saura jamais où se trouve la vérité. Je me pose des questions, ne pas s'en poser, voilà ce qui serait de la naïveté !

[Jedai]

Ce n'est pas de la naïveté mais de la curiosité. Même si Stroustrup dément sur son site officiel avoir donné cette interview (http://www.research.att.com/~bs/bs_faq.html#IEEE) rien ne prouve qu'il n'a jamais prononcé ces mots. Il peut très bien mentir, comme le peut celui qui a diffusé cette interview. On ne saura jamais où se trouve la vérité. Je me pose des questions, ne pas s'en poser, voilà ce qui serait de la naïveté !

Oui oui, bien sûr, il est extrêmement difficile de prouver un négatif, néanmoins tu n'as présenté strictement aucun élément en faveur de la réalité de cette interview (que tu as d'ailleurs trouvé dans la section "Silly" du Smörgasbord de ce site...) et il y a plusieurs éléments visiblement exagérés (son histoire de DOS en C++ de 70 Mo, "Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient", "Whoever heard of memory leaks in a 'C' program?").

Si tu es toujours convaincu objectivement de la réalité de cette interview (et pas juste parce que tu n'apprécies pas C++, position parfaitement compréhensible) j'ai quelques propriétés du côté du 70e parallèle sud que j'aimerais te vendre.

--
Jedaï

[muad'dib]

Je n'ai jamais dit que j'en étais convaincu ! Je me pose des questions, rien de plus.

Quoiqu'il en soit, vraie ou pas, cette interview met en avant la difficulté de maintenir un projet écrit en C++, et sur ce point je suis plutôt d'accord. De mon point de vue la POO (pas seulement le C++), n'est que poudre aux yeux, elle ne fait que donner une impression de contrôle sur le code et de rapidité de développement. Au final on se retrouve, de mon point de vue, avec un concept qui créé plus de problèmes qu'il n'en résoud.

Cela ne m'empêche pas d'utiliser Java attention, la POO peut s'avérer très pratique, mais développant également en C il n'y a pas grand chose que la POO puisse faire qu'un langage procédural ne puisse pas recréer. À moins d'avoir des exigences très spécifiques je ne vois pas l'intérêt de choisir C++ plutôt que C. Je crois que le vrai thème du débat ici devrait être "Pour ou contre la POO?" ou "Pourquoi faire en C++ ce que l'on peut faire en C?"

[souviron34]

Euh... Quel rapport ?

Pourquoi faire simple quand on peut faire compliqué, voilà le rapport

[Luc Hermitte]

À moins d'avoir des exigences très spécifiques je ne vois pas l'intérêt de choisir C++ plutôt que C. Je crois que le vrai thème du débat ici devrait être "Pour ou contre la POO?" ou "Pourquoi faire en C++ ce que l'on peut faire en C?"

Dans l'autre sens, on peut aussi se poser la question de la pertinence du C vu que tout ce que l'on peut faire en C on peut le faire à l'identique voire plus simplement en C++ ...
Rien que la bibliothèque standard générique du C++ et le RAII justifient pour moi l'abandon du C dans mes petits projets. Et se débarrasser des fonctions anti-DRY que sont printf & cie, ce n'est que la cerise sur le gâteau.

Je crois que tu as zappé un élément du C++ : c'est bien plus que du C saupoudré de POO. Mais alors bien plus. Ton raccourci rejoint des messages d'il y a une page ou deux : trop souvent le C++ est employé comme un C à classes sans profiter d'autres éléments qui apportent grandement à la robustesse et à la maintenabilité (généricité, RAII, ...)
(chose évoquée une quantité hallucinante de fois dans ce fil de discussion que tu n'as pas lu nous as-tu dit)

[pour en revenir à la question de l'OO] Dans les gros projets je finis toujours par avoir besoin de points variabilité dynamiques, voire même statiques. Les statiques à coups de macros, si je peux éviter, non merci. Pour les dynamiques, ils sont plus simples à mettre en œuvre dans les langages ouvertement OO que dans les langages où il faut jongler avec des tableaux de (pointeurs) de fonctions pour réaliser le mécanisme à la main.

[Invité]

mais développant également en C il n'y a pas grand chose que la POO puisse faire qu'un langage procédural ne puisse pas recréer

A ce compte, il n'y a rien qu'on ne puisse faire en assembleur, et pourtant on développe en C (ou en C++ ou en Java)...

Des choses que je trouve quand même bien pratique avec le C++

1- la syntaxe : ouais parce que les struct avec des pointeurs de fonction façon pour faire de l'interface, j'en ai fait en mon temps, et c'était pas agréable à écrire, et encore moins à relire
2- le controle de type à la compilation : ca gagne du temps dès qu'on commence à faire des choses sales : les programmeurs sont notoirement mauvais sur les tests à l'exécution, tout ce qu'on peut controler à la compilation, c'est bien
3- les librairies haut niveau et les classes pour tout ce qui n'a pas besoin d'aller vite, mais qui a une structure compliquée, typiquement l'interface. Une IHM sans POO c'est possible, mais c'est assez désagréable (been there, done that)
4- les template, c'est plus propre et plus maintenable que les macros...

Maintenant, des choses que je n'aime pas...

1- en C, si ton algorithme n'est pas trop mal gaulé, ca va vite, toujours... En C++, rien de cela, ca peut être atrocement lent, parce qu'il se passe des tas de choses dans ton dos, des copies, du code instancié dans tous les sens. On peut bien sur l'éviter, mais c'est lourd.
2- le caractère très abstrait des conceptions C++. Ce n'est pas bon, car ca rend l'analyse complexe, et les erreurs fréquentes.
3- les débats incessant sur ce qui est bien, et ce qui ne l'est pas (les guerres de religion, quoi). Y'en a quand meme moins en C...

Francois

[souviron34]

Des choses que je trouve quand même bien pratique avec le C++

1- la syntaxe : ouais parce que les struct avec des pointeurs de fonction façon pour faire de l'interface, j'en ai fait en mon temps, et c'était pas agréable à écrire, et encore moins à relire
...
3- les librairies haut niveau et les classes pour tout ce qui n'a pas besoin d'aller vite, mais qui a une structure compliquée, typiquement l'interface. Une IHM sans POO c'est possible, mais c'est assez désagréable (been there, done that)

Je ne sais pas..

J'ai fait énormément d'IHM en C avec X11 (et Motif), et je n'ai jamais utilisé des pointeurs de fonctions, ni des structures compliquées...

J'ai utilisé des pointeurs de fonctions, mais pour faire des fonctions enregistrées.. (hors IHM)

Et une IHM sans "OO", oui, c'est dur à faire.. Sans langage objet, si, c'est tout à fait possible et (au moins) aussi clair...


Maintenant, je ne parlerais pas (j'ai déjà dit pourquoi : je ne l'ai pas appris ni utilisé) du C++.. Mais justement, ce qui moi me rebute c'est ce que tu dis à la fin : le caractère très abstrait...


La formalisation du langage, pas du tout intuitif, de même que celles de concepts tout aussi peu intuitifs...

Mais ce n'est même pas par rapport au langage que je me bloque, mais par rapport à l'espèce de "religion" qui s'est faite autour de lui... ou de ces concepts...

[Invité]

Mais justement, ce qui moi me rebute c'est ce que tu dis à la fin : le caractère très abstrait...

Je suis d'accord. En fait, ce n'est pas tant l'abstraction (au fond, je n'ai rien contre) que son caractère gratuit... Réimaginer le monde en termes d'invariants, de classes (qui intègrent données et traitements), de types ou de conteneurs et d'itérateurs, ça résoud parfois les problèmes, mais généralement ça remplace un problème complexe par un autre problème, tout aussi complexe, mais plus abstrait... Cette traduction prend du temps, et introduit des erreurs.

Enfin bon, y'a pire, y'a les design patterns (ou, comment donner un nom compliqué à un problème simple).

Mais ce n'est même pas par rapport au langage que je me bloque, mais par rapport à l'espèce de "religion" qui s'est faite autour de lui... ou de ces concepts...

Pour être juste, on retrouve ceci un peu partout dans l'informatique... Religion des OS, religion des langages, religion des concepts... Je ne sais pas si c'est le métier qui veut cela, mais je ne donnerais pas mes filles en mariage à un informaticien, moi...

Francois

[souviron34]

Enfin bon, y'a pire, y'a les design patterns (ou, comment donner un nom compliqué à un problème simple).

et maintenant le Aspect Programming ...

Pour être juste, on retrouve ceci un peu partout dans l'informatique... Religion des OS, religion des langages, religion des concepts... Je ne sais pas si c'est le métier qui veut cela, mais je ne donnerais pas mes filles en mariage à un informaticien, moi...

[Luc Hermitte]

et maintenant le Aspect Programming ...

Ce n'est pas déjà dépassé au profit de choses comme le MDA ?

[souviron34]

Ce n'est pas déjà dépassé au profit de choses comme le MDA ?

je ne sais pas..

Je laisse passer... (l'un comme l'autre, d'ailleurs)..


Mais je vois passer (comme toi certainement) des posts dans les forums...

[Tommy31]

Ce n'est pas déjà dépassé au profit de choses comme le MDA ?

Pas comparable (l'un est un paradigme, l'autre une démarche de développement centrée sur le modèle).

[gl]

Enfin bon, y'a pire, y'a les design patterns (ou, comment donner un nom compliqué à un problème simple).

Le nom est certes un peu pompeux, mais personnellement je trouve que l'émergence des design pattern est plutôt une bonne chose.

Je m'explique, il est clair que les design pattern ne sont grosso-modo que la formalisation de "constructions" déjà connues et utilisées depuis très longtemps [1] et qu'au final les design pattern n'apportent pas grand chose d'un point de vue technique. Par contre ils apportent :

• Un formalisme relativement claire et universel là où avant on avait des appellations et "dialectes" différents en fonction des équipes voire des personnes. Avec bien souvent de longues explications et descriptions pour parler de constructions qui ont maintenant un nom utilisé et compris par un nombre important de développeurs.
• Un éclairage sur des méthodes pour résoudre des problèmes classiques qui sont maintenant apprises et connues très tôt alors qu'auparavant ces méthodes (ou une forme approchante de ces méthodes) étaient apprises voire découvertes sur le tas lorsque l'on rencontrait le problème en question.

Au final, les design pattern n'ont peut-être rien apporté techniquement par contre c'est un plus indéniable en terme de communication.

Le gros problème est effectivement la palanqué de "simili-développeurs" qui cherchent à utiliser à tout prix tel ou tel design pattern même là où il n'est pas adapté et qui n'arrivent pas à concevoir que l'implémentation donnée dans leur cours/livre n'est pas celle qui est pertinente dans un cas particulier.



[1] J'ai plus de mal à utilisé le qualificatif "simple" dans ce contexte. Les problèmes et leurs solutions sont peut-être connus, mais de la à dire que c'est simple, c'est un pas que je me garderais de franchir.

[Invité]

Je suis assez d'accord sur l'analyse. Le défaut à mon avis, apparait quand on élève ce "catalogue de modèles réutilisables" au rang de solution générale, applicable à tout problème.

En fin de compte, on se retrouve avec une indirection supplémentaire : étant donné un problème réel, on le traduit d'abord en design patterns, pour pouvoir ensuite l'implémenter (en fait, souvent pour pouvoir le traduire ensuite en jargon OO, et enfin l'implémenter).

Beaucoup de projets supportent mal un tel traitement (ceux qui ont des budgets et des délais contraints, en fait...)

Un autre problème que je vois avec les design pattern, c'est que pour bien les apprécier, et les reconnaitre, il faut généralement les avoir rencontrés et avoir au moins tenter de les résoudre... (et souvent, on sera arrivé à la "bonne solution") Ils sont donc peu utiles pour des apprenants...

Mais bon, sur l'aspect langage commun, je suis d'accord.

Francois

[chaplin]

Un autre problème que je vois avec les design pattern, c'est que pour bien les apprécier, et les reconnaitre, il faut généralement les avoir rencontrés et avoir au moins tenter de les résoudre... (et souvent, on sera arrivé à la "bonne solution") Ils sont donc peu utiles pour des apprenants...

Mais bon, sur l'aspect langage commun, je suis d'accord.

J'ai découvert les design pattern avec John Colibri lors d'une formation. Leur connaissance m'a plus ouvert les yeux. Bien que j'apprécie le Pascal pour sa clarté et plus lisible pour mes yeux, le C++ introduit pas mal de concepts compliqués certes, mais interessants et la compréhension de la POO en C++ ne me gène pas du tout, à en oublier presque la syntaxe ( ).

Tous les ouvrages dédiés aux Designs patterns présentent des codes soit en C++, soit en JAVA.

Après, il faut pratiquer. Je ne me cite pas en exemple, mais je suis certain qu'on peut en tirer un très grand bénéfice sans en faire une religion non plus cependant on a des outils en plus face à des problèmes.
Quand je vois les exemples en procédural de Paul TOTH, je me dis qu'un bon raisonnement basé sur les procédures s'avère tout aussi bon que de faire de la POO et surtout beaucoup plus pédagogique dans certains cas de figure, pour ne pas dire plus facile à comprendre dans d'autres cas. Faire du code "réutilisable", c'est peut être dans certains cas pi..er du code inutilement alors que quelques procédures auraient fait l'affaire avec moins de code.

Le principal reproche que je peux faire à la POO, c'est qu'il faut tapper du code au km, du coup la représentation par des dessins (ie UML) résume de façon graphique le "charabias" des programmes.

Si je me suis permis de rentrer dans cette discussion, c'est qu'on retrouve des similitudes entre c->c++ et Pascal -> Pascal Objet.

EDIT: pour ne pas faire de jaloux, je citerais aussi bruno_pages pour ses contributions.

[bricecol]

Entre C et C++, je conseillerais C++ seulement si le programmeur sait utiliser pleinement la notion objet.

[jabbounet]

je pense que cela va dépendre du besoin et du type d'appli à faire.

pour des choses très proche du système il vaux mieux le C basique

pour des application de plus haut niveau avec api graphique, ... je prendrais plutôt c++

[Echap]

Commences par le C car rien ne s'y passe "derrière ton dos",
gère cela mieux.

salut
Je débarque dans le fil de discussion et je n'ai pas tout lu j'ai une petite remarque pour Musaran, c'est vrais mais rien s'y passe derrière son dos mais:
1-il est débutant
2-il veux la programmations sous linux et la programmation réseaux
d'après ma petit expérience en langage C je le conseil d'apprendre un langage proche de l'algorithme comme pascal, il est très très proche de l'algorithme, c'est bien comme départ avant de passé a un langage "proche" de la machine, puis il passe a la programmation en C ensuite le C++
donc algo + ( C et/ou C++) c'est bien sous linux et pour la programmation réseaux
cordialement

[arutan]

j'ai une petite remarque pour Musaran,

En même temps ça fait plus de 7 ans.. tout de même...

Avant de sortir je voudrais juste rajouter :

Parce que le C est plus accessible aux débutants (pas de notions OO etc..) mais que le C++ permet de faire plus de choses (je ne rentre pas dans les détails...) ; pourquoi ne pas faire du C en C++, c'est à dire, commencer dans un environnement C++ mais en ne faisant que du procédural ?

Comme ça dès que le niveau sera atteint plus besoin de changer, on pourra faire du C++

Ca permettrait de clôturer la discussion, non ?