Que vient faire la partie binaire dans la discussion? Ca n'a absolument rien à voir avec le source, qui n'a absolument pas à changer entre GCC 3.3 et GCC 3.4 (changement d'ABI d'un et un seul compilo)?
Certes, par contre il y a eu aussi des modifs côté source entre la version 3 et la version 4 (notamment dans la "tolérance" à certaines pratiques de développement qui s'est durcie).
Tu peux chercher toutes les raisons que tu veux, il n'empêche que le développement en C++ ne t'apporte pas plus de garantie qu'en Python, et que tout ce que tu trouves à y redire c'est ce que tu reproches au mec d'en haut que je sais plus qui c'est : dans la théorie, c'est pérenne, dans la pratique ça l'est pas.
Si tu veux tout savoir, je n'aime pas (plus, en fait) C++, mais pas pour ces questions de pérennité à la manque. De même que si j'aime Python, çà n'a rien à voir avec ça non plus, et ça m'agacera probablement aussi le jour où mon code ne sera plus compatible avec la version "mainstream". Pour moi, tout ce débat sur la pérennité du code est un faux problème, du moins tant qu'on ne fait pas entrer dans l'équation un langage pour lequel la dite pérennité a été un critère fondateur. Et ça n'est le cas ni de Python, ni du C++ (le C s'en sort un peu mieux, mais ça n'a pas non plus été une volonté exprimée au départ, il me semble).
Tu amènes des choses, des défauts sur un côté où Python a éliminé le problème : pas de compilation (donc un package de plusieurs Mo pour un simple "Hello world").
Ca repart toujours dans le truc "vive le monopole de Python, avec Python pas d'incompatibilité du au monopole")
Unmatched parenthesis ;)
Maintenant, oui, c'est vrai. Et après? Si le problème est éliminé, c'est l'essentiel? Et si la résolution a apporté d'autres soucis, on peut discuter de ceux-ci. Mais, au passage, le "simple hello world" qui fait plusieurs Mo, c'est de la mauvaise foi à l'état pur : le hello world "opérationnel" en Python ne fait que quelques octets (strlen('print "hello world"') + 1, à vue de nez). Si tu veux compter tout l'interpréteur dedans, et c'est ton droit, il ne faut pas oublier que ça te fournit l'environnement de développement pour le "même prix", et que pour être juste tu pourrais compter g++ dans le score du C++. On peut jouer à ce petit jeu là longtemps, et personne ne gagnera.
Avec ton argumentation, Linux c'est pourri il y a des problèmes tout le temps
Hein? Je défends un langage pour lequel les spécifications ne sont pas gravées dans le marbre, et tu arrives à en déduire que je critique le changement?!
Pour information, je n'ai pas prétendu que Python était immuable ni rien, j'ai juste fait remarquer que le langage que tu défendais ne brillait pas vraiment pas la stabilité de ses interfaces. Pour ce qui est de la compatibilité binaire sous win, c'est à peu près comme sous Linux : ça dépend. Des softs vieux de 13 ans qui tournent encore (modulo une recompilation, certes), ça peut se trouver. Des softs qui tournent tels quels, j'en ai qui datent de 1999/2000 environ. Et encore, je ne parle que des softs "compilés", j'ai des scripts shell plus anciens que ça qui marchent du feu de dieu. Et pareil, des programmes de 95 qui sont infoutus de tourner sur un Windows récent, j'en ai. Pas besoin d'aller chercher des merdes en mode DOS, il y a quantité de softs qui se basaient sur l'absence de protection mémoire de win9x et qui se vautrent comme des merdes depuis win2k.
C'est le truc rigolo : je retrouve exactement sur le principe les arguments des Windowsiens ici-même appliqués à Python. et ça ne vous choque pas?
Et je suis certain qu'on pourrait faire l'inverse et appliquer les arguments des Linuxiens (diversité, choix, libre accès au source, développement à la portée de tout un chacun). C'est vraiment une question de point de vue, et ça me déçoit un peu de voir ta prose, d'ordinaire assez douée pour éviter les œillères et autres intégrismes à deux balles, donner dans la dialectique de nightclub.
[^] # Re: La seule expérience Python de ma vie
Posté par Larry Cow . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 3.
Certes, par contre il y a eu aussi des modifs côté source entre la version 3 et la version 4 (notamment dans la "tolérance" à certaines pratiques de développement qui s'est durcie).
Tu peux chercher toutes les raisons que tu veux, il n'empêche que le développement en C++ ne t'apporte pas plus de garantie qu'en Python, et que tout ce que tu trouves à y redire c'est ce que tu reproches au mec d'en haut que je sais plus qui c'est : dans la théorie, c'est pérenne, dans la pratique ça l'est pas.
Si tu veux tout savoir, je n'aime pas (plus, en fait) C++, mais pas pour ces questions de pérennité à la manque. De même que si j'aime Python, çà n'a rien à voir avec ça non plus, et ça m'agacera probablement aussi le jour où mon code ne sera plus compatible avec la version "mainstream". Pour moi, tout ce débat sur la pérennité du code est un faux problème, du moins tant qu'on ne fait pas entrer dans l'équation un langage pour lequel la dite pérennité a été un critère fondateur. Et ça n'est le cas ni de Python, ni du C++ (le C s'en sort un peu mieux, mais ça n'a pas non plus été une volonté exprimée au départ, il me semble).
Tu amènes des choses, des défauts sur un côté où Python a éliminé le problème : pas de compilation (donc un package de plusieurs Mo pour un simple "Hello world").
Ca repart toujours dans le truc "vive le monopole de Python, avec Python pas d'incompatibilité du au monopole")
Unmatched parenthesis ;)
Maintenant, oui, c'est vrai. Et après? Si le problème est éliminé, c'est l'essentiel? Et si la résolution a apporté d'autres soucis, on peut discuter de ceux-ci. Mais, au passage, le "simple hello world" qui fait plusieurs Mo, c'est de la mauvaise foi à l'état pur : le hello world "opérationnel" en Python ne fait que quelques octets (strlen('print "hello world"') + 1, à vue de nez). Si tu veux compter tout l'interpréteur dedans, et c'est ton droit, il ne faut pas oublier que ça te fournit l'environnement de développement pour le "même prix", et que pour être juste tu pourrais compter g++ dans le score du C++. On peut jouer à ce petit jeu là longtemps, et personne ne gagnera.
Avec ton argumentation, Linux c'est pourri il y a des problèmes tout le temps
Hein? Je défends un langage pour lequel les spécifications ne sont pas gravées dans le marbre, et tu arrives à en déduire que je critique le changement?!
Pour information, je n'ai pas prétendu que Python était immuable ni rien, j'ai juste fait remarquer que le langage que tu défendais ne brillait pas vraiment pas la stabilité de ses interfaces. Pour ce qui est de la compatibilité binaire sous win, c'est à peu près comme sous Linux : ça dépend. Des softs vieux de 13 ans qui tournent encore (modulo une recompilation, certes), ça peut se trouver. Des softs qui tournent tels quels, j'en ai qui datent de 1999/2000 environ. Et encore, je ne parle que des softs "compilés", j'ai des scripts shell plus anciens que ça qui marchent du feu de dieu. Et pareil, des programmes de 95 qui sont infoutus de tourner sur un Windows récent, j'en ai. Pas besoin d'aller chercher des merdes en mode DOS, il y a quantité de softs qui se basaient sur l'absence de protection mémoire de win9x et qui se vautrent comme des merdes depuis win2k.
C'est le truc rigolo : je retrouve exactement sur le principe les arguments des Windowsiens ici-même appliqués à Python. et ça ne vous choque pas?
Et je suis certain qu'on pourrait faire l'inverse et appliquer les arguments des Linuxiens (diversité, choix, libre accès au source, développement à la portée de tout un chacun). C'est vraiment une question de point de vue, et ça me déçoit un peu de voir ta prose, d'ordinaire assez douée pour éviter les œillères et autres intégrismes à deux balles, donner dans la dialectique de nightclub.