Python ou C++ ?

Salut !

Je connais déja un peu le C et le Java, mais j'aimerai apprendre un langage de POO, mais pas de 100% POO comme Java.

Donc voila, j'hésite entre Python et C++; pourriez vous me faire un peu le comparatif ? Merci d'avance !

Bonjour : que désires-tu faire?

Salut,

Comme l'a dit Artagis, ton choix se fera en fonction de tes besoins. Si tu veux une comparaison entre les deux langages, ce sera difficile d'être objectif. Je ne pense pas que l'un soit meilleur que l'autre, ils sont différents.

Si tu n'as pas de projet en tête, apprend les deux. Tu n'es pas obligé d'apprendre seulement un langage. Si tu as une idée derrière la tête, alors il faudra en parler.

Dans tous les cas, il n’existe pas une seule et unique façon de faire de la POO, chaque langage réinvente à sa manière le concept de POO (même si on retrouve les principes généraux entre la plupart des langages caractérisés OO).

Donc apprendre le Python et le C++ ne peut être que bénéfique et tu pourras d'ailleurs apprendre deux manières différentes de faire de l'orienté objet.

Salut, y a t-il le concept de pointeur en python? Je dois dire que j'y ai accroché …

Sinon, non, je n'ai pas de projet précis en tête, mais j'aimerai apprendre le langage utilisé par le plus de projet open-source et/ou libres, afin de m'entrainer à les comprendre, voir même le temps venu, y contribuer

Pas de pointeurs en Python, pas explicites du moins.

Pour la deuxième partie, je suis incapable de te répondre, je dirais que ça se vaut en termes de projets actifs, avec probablement un avantage au C++ (GNU/Linux étant en C++ par exemple).

@ez613: ne le prends pas mal, mais ce raisonnement est idiot. Comme je l'ai dit, si tu souhaites contribuer à des projets, autant apprendre les deux langages. Maintenant si tu dois faire un choix, il faut qu'il y ait d'autres raisons.

Ce sera d'autant plus facile pour toi pour contribuer à des projets.

Si tu veux contribuer à un projet libre, tu n'as qu'à regarder du côté de Zeste de Savoir qui est, le hasard fait bien les choses, écrit en Python ;p.

Pas de pointeur en Python mais tout est passé par référence.

Comme l'on dit d'autres avant moi, c'est un choix impossible à faire. Les deux langages sont très différent. En réalité ils sont complémentaires. Ce sont les deux langages que j'utilise le plus (professionnellement), mais pas dans la même situation. J'utilise Python pour a peu pret tout et je passe les parties critiques en terme de perf en C++ (ou je commence directement en C++ quand je sais que ça va pas le faire en Python, en particulier pour le traitement d'images/vidéos).

L'idéal serait d'apprendre les deux. Mais par apprendre j’entends maîtriser, faire plusieurs projets avec.

Si je devais en choisir un, et parce que tu as déjà fais du C, je te conseillerai Python pour apprendre à maitriser un langage bien plus haut niveau.

@poliorcetics : Non, le projet GNU est en grande majorité en C et Linux est totalement en C. Pas de C++ dedans.

Non, le projet GNU est en grande majorité en C et Linux est totalement en C

Je sais que ce débat a dû déjà être abordé, mais suis-je le seul à trouver le langage C horriblement difficile comparé au C++ ?

Le style purement impératif est assez horrible, dès lors qu'on doit structurer un minimum le projet, l'absence de RAII, etc… tout ça fait beaucoup de source d'erreurs, et c'est se priver des outils du C++. La gestion des tableaux et chaînes de caractères en C est juste monstrueuse, alors qu'en C++ c'est bien plus simple avec <string> et <vector>, pas à se soucier de la taille ou de la mémoire. Même les IO sont plus sûres.

Faire le choix de ne pas déclarer trop de classes (autre que des petits structures utilitaires avec quelques méthodes, mais sans polymorphisme ni héritage) est une chose que je peux comprendre (la plupart de mes projets C++ ressemblent à ça), mais se priver d'une bibliothèque aussi fournie que la STL (smart pointers et containers) là je comprends moins.

@ez613: si tu as déjà fait du C le passage au C++ sera plus rapide pour des raisons purement syntaxiques, et plus longue pour le changement de paradigme. Perso je trouve l'OO du C++ "plus propre" avec les possibilités de surcharge des constructeurs (en Python je crois pas que ce soit possible, il n'y a qu'une seule fonction init je crois ?), tu peux gérer finement l'encapsulation (là où en Python tout est public, mais c'est un choix fait dès le début), le polymorphisme nécessite plus de boulot mais tu peux le gérer finement aussi grâce aux pointeurs et références. Mais bon, j'aime trop le C++ et je connais trop mal l'OO Python pour que mon avis soit objectif.

(en Python je crois pas que ce soit possible, il n'y a qu'une seule fonction init je crois ?)

Oui mais c'est beaucoup moins gênant en python du fait du coté dynamique du langage. Il est très rare que je me dise "tiens là je surchargerais bien la méthode…"

Pour le reste le modèle objet de Python est très complet mais radicalement différent de celui du C++. Simplement parce qu'il est difficile de faire deux langages plus différent que le C++ et Python (aux langages fonctionnels pret)

Bon a vrai dire C++ et Python ont tous les deux quelques petits trucs en commun : ils n'imposent pas de paradigmes et font confiance au développeur. C'est une différence fondamental vis a vis du Java par exemple qui tente de forcer un paradigme objet tout encapsulé.

Mais c'est peut être leur seul point commun.

C++ et Java: langages procéduraux objets. Python aussi, mais pas au point d'être fonctionnel OO comme l'était CLOS.

C++ et Java sont compilés, Python est interprété. Python est plus proche de l'"extreme late-binding of all things" d'Alan Kay. En effet, comme ruby, il va avoir (si je ne me plante pas dans le vocabulaire) des Open Classes (et object?), c'est à dire des classes où l'on peut rajouter, voire supplanter des fonctions déjà en place.

Les 3 sont des langages OO à classes et pas à prototypes.

L'encapsulation du Java est copiée du C++ : on encapsule (l'objectif de l'encapsulation est de protéger les invariants) en cachant des attributs et fonctions via les accessibilités public, protected, private (et package aussi). En Python, on cache/protège par convention de nommage. (En Eiffel, on a l'accès en lecture à tous les attributs, mais seuls les membres ont droit à l'écriture). Cacher, est plus proche du principe d'abstraction que d'encapsulation.

C++ et Python supportent l'héritage multiple. Java supporte l'héritage multiple d'interfaces – mais pas vraiment de contrats avant Java 8 vu que les interfaces ne pouvaient pas encore posséder de code et donc suivre le pattern NVI).

C++ dispose d'un héritage qui permet uniquement l'import de code (héritage privé). Java dispose d'un héritage qui ouvre uniquement au sous-typage (avec les interfaces) – initialement, l'héritage sert à importer du code, mais dans les langages OO mainstreams c'est le seul moyen de faire du sous-typage.

Etant dynamique, Python ne s'intéresse pas aux notions d'interfaces. On est dans un monde de Duck Typing et de polymorphisme paramétrique également) (en C++, on a le polymorphisme paramétrique (/et du Duck Typing) au niveau des templates, c'est la notion de concept qui remplace la notion d'interface). Python a d'ailleurs des notions de mixins/modules que l'on retrouve différemment en Ruby – je laisse d'autres rentrer plus dans les détails vu que je risque de dire des bêtises.

C++ et Java ne supportent pas le dispatch multiple sans sortir des tables de fonctions (ou équivalent) ou le pattern visiteur pour l'émuler. Le framework COS pour le C, et CLOS dont il est inspiré) supportent le dispatch multiple. Pour Python, je ne sais plus à quel point il est supporté. Avec le Duck Typing qui est de la partie, j'aurais tendance à dire que c'est supporté.

Après, il y a d'autres aspects qui permettent de distinguer/comparer ces langages (gestion des ressources en situation exceptionnelle, support des divers paradigmes (généricité, fonctionnel), richesse des bibliothèques, frameworks de tests, …

@Kje, GNU gcc a été réécrit/transformé en C++.

@Ez613, Java n'est pas 100% OO, Alan Kay (qui a posé le terme "OO") tend au contraire à dire que Java n'est pas OO (ni C++ d'ailleurs). Java force à employer le mot clé class, ce qui donne une illusion de OO. Mais ce n'est qu'une illusion. Il y a beaucoup de code Java qui est Orienté Données, ou purement procédural qui tourne.

C++ et Java sont compilés, Python est interprété.

CPython est interprété, Python peut être compilé.

L'encapsulation du Java est copiée du C++ : on encapsule (l'objectif de l'encapsulation est de protéger les invariants) en cachant des attributs et fonctions via les accessibilités public, protected, private (et package aussi). En Python, on cache/protège par convention de nommage.

oui et non. Essaie d'accéder depuis un enfant à une propriété qui commence par __.

Java supporte l'héritage multiple d'interfaces – mais pas vraiment de contrats avant Java 8 vu que les interfaces ne pouvaient pas encore posséder de code et donc suivre le pattern NVI).

On ne parle pas vraiment d'héritage du coup pour les interface, mais d'implémentation.

initialement, l'héritage sert à importer du code, mais dans les langages OO mainstreams c'est le seul moyen de faire du sous-typage.

Sans prétendre connaître les buts des créateurs du concept OO, l'héritage n'est pas créé pour l'import de code (c'est même une erreur courante des débutants de l'utiliser ainsi), sauf en Python (les Mixins, tout ça) mais pour le polymorphisme.

J'ai pas tout compris aux notions dont vous parlez mais merci beaucoup !

Je m’intéresse plus, a priori, au dev de jeux, pour ça j'en ai vu en C++ et en python…

au dev de jeux

Quel genre de jeux désires-tu faire?

C++ et Java sont compilés, Python est interprété. CPython est interprété, Python peut être compilé.

Oui, j'ai voulu aller à l'essentiel.

L'encapsulation du Java est copiée du C++ : on encapsule (l'objectif de l'encapsulation est de protéger les invariants) en cachant des attributs et fonctions via les accessibilités public, protected, private (et package aussi). En Python, on cache/protège par convention de nommage. oui et non. Essaie d'accéder depuis un enfant à une propriété qui commence par __.

En réinjectant le nom de la classe, on y arrive

Java supporte l'héritage multiple d'interfaces – mais pas vraiment de contrats avant Java 8 vu que les interfaces ne pouvaient pas encore posséder de code et donc suivre le pattern NVI). On ne parle pas vraiment d'héritage du coup pour les interface, mais d'implémentation.

Déviation de vocabulaire par Java et UML. Cela reste du sous-typage. Et techniquement, c'est de l'héritage virtuel public, potentiellement multiple. Les interfaces sont le contournement de Java à l'absence d'héritage multiple.

C'est le problème de l'héritage dans les langages modernes. Il mélange import de code et sous-typage. L'héritage est le moyen technique qui permet de faire les deux. Et dans le discours marketing de "avec l'héritage vous factorisez & cie", on voit avant tout l'import de code. Le sous-typage (celui qui ouvre la porte au polymorphisme si tu préfères), c'est autre chose normalement. (cf. p.ex. http://www.cmi.ac.in/~madhavan/courses/pl2006/lecturenotes/lecture-notes/node28.html )

D'où comme tu dis, l'approche erronée (AMA) dans les cours pour débutants est de focaliser sur l'organisation des données et non sur les comportements.

Qu'appelles-tu 100% POO ? Car en Python, contrairement au Java, tout ce que tu manipuleras sera objet.

Il me semble que le projet GNU, tout comme le C++, ont débuté en 1983. Ils ont donc dû préférer se baser sur un langage sûr et reconnu, que C++ dont personne ne devait avoir entendu parler à l'époque.

Python est compilé vers du bytecode et exécuté par une machine virtuelle, au même titre que Java.

En fait, la vérité est que je n'ai jamais fait de réel "projet", et je n'en ai pas l'intention a court terme. Ce que je fait, c'est des algo et des petits prog pour m'entrainer aux notions que j'apprends.

Les __ ne rendent pas le membre privé, ils renomment juste le champ en le préfixant du nom de la classe à l'extérieur. L'attribue reste parfaitement accessible.

Il n'y a pas vraiment d'interface en Python, le ducktyping + conventions permettant de s'en passer. Cependant depuis certaines versions ont à des classes abstraites qui peuvent donc tenir ce rôle. Mais c'est implémenté avec des métaclasses et decorateurs donc sans toucher au langage.

Enfin non il n'y a pas de multiple dispach en Python. En réalité il y a un décorateur de dispo pour faire du simple dispach (sur un seul argument donc) dispo dans la lib standard. En soit le multiple dispach ne serait pas dur à implémenté. De part sa nature dynamique, pas besoin de modifier le langage. Si il n'est pas dispo c'est que les dev ce sont confronté à des problèmes d'ambiguïté et de complexité forte de résolution lorsque ça a été envisagé ce qui a amené à la version simple actuellement disponible.

Mais encore une fois de par sa nature il est rare d'en avoir besoin. C'est dynamique, on peut tester le type ou regarder le nombre d'arguments nommés ou positionnelles facilement. Le fait que le type ne soit pas donné dans la signature, le duck typing et les différents types d'arguments rend le besoin beaucoup moins présent.

Édit: @lmghs oui je sais que GCC est passé au c++ mais c'est pas tout le projet GNU et c'est pour ça que je dis "en majorité".