Rayman Pirate-Community

Tout est dans le titre.

Il semblerait qu'on n'ait pas encore de topic sur ce thème de ce côté-ci du forum, mais mieux vaut tard que jamais !

Ouais mais on va pas parler boulot sur un forum de détente, merde...

Si on a un topic sur la programmation je suppose que je devrais raconter l'histoire de ma haine envers Python.

Je ne sais pas quand j'ai entendu parler de Python pour la première fois, mais ça ne m'a pas trop intéressé au début. (C'est vrai que je n'aspirais pas beaucoup à être « multilingue » quand j'étais jeune – le français ne m'intéressait pas trop au début non plus ) Quand j'ai commencé à utiliser Linux en 2011, les programmes en Python sont devenus assez importants pour moi, notamment PlayOnLinux, mais mon indifférence a continué.
En 2014, j'ai commencé à lire Linux Voice. Dans ce magazine, il y avait des tas de tutoriels dans lesquels la programmation jouait un rôle, et la plupart de ces tutoriels utilisaient Python. J'ai décidé d'en lire un vers la fin de 2014, ou peut-être vers le début de 2015, et j'ai remarqué que les blocs sont marqués seulement par l'indentation. Je trouvais que c'était une attaque insupportable sur la lisibilité, et aussi sur la liberté du programmeur. Je me suis donc dit que j'essaierais d'éviter d'utiliser ce langage.
À la fin de 2015, j'ai eu l'idée dingue de me faire un Linux from Scratch. Il a bientôt fallu installer un interpréteur Python, et j'ai suivi les instructions sur le wiki CBLFS pour compiler une version « multilib » de CPython. Pourtant ces instructions n'ont pas très bien fonctionné, et les conséquences m'ont donné pas mal de douleur, au moins jusqu'à l'anéantissement du système vers la fin de 2016. Les problèmes que j'ai eu avec Python en utilisant ce système LFS ont renforcé mes sentiments négatifs envers le langage. Bien sûr, c'était la configuration de CPython qui me donnait les problèmes, pas le langage lui-même, mais quand même il faut noter qu'aucun autre paquet ne m'a donné tant de problèmes à cause de la configuration multilib.
Suite à l'anéantissement déjà mentionné j'ai crée un nouveau système LFS et j'ai décidé de faire deux installations complètement séparées de CPython : une version 64-bits dans /usr et une version 32-bits dans /opt/python32. Pas trop beau, mais ça marche. Après ça ma haine a diminué un peu.

Un mois plus tard, j'ai commencé mon stage, et j'ai vite appris à utiliser le logiciel qu'ils ont pour analyser les données mesurées dans le labo. J'ai vite appris aussi que ça a été programmé, en Python, par un mec qui a quitté l'entreprise pendant mon premier semaine ! J'ai vu quelques inefficacités dans le logiciel que j'ai mentionnées à mes collègues et à mon superviseur. On m'a dit de mettre des bogues sur notre Bugzilla, et quelqu'un s'y mettrait. Pourtant je me suis vite rendu compte qu'il n'y avait personne qui saurait (ou aurait suffisamment de temps pour) modifier ce drôle de programme. Mon superviseur m'a dit que l'entreprise allait recruter quelqu'un pour s'occuper de notre logiciel, mais après quelques mois (et un dessert très sucré à un déjeuner de l'équipe !) j'ai décidé que j'en avais marre et j'ai commencé à faire des patchs, malgré mes problèmes avec le langage.
Mes supérieurs ont remarqué ce que j'ai pu faire, et m'ont dirigé vers un autre logiciel presque oublié, créé par le même mec, pour faire des simulations optiques. Pendant les semaines et mois suivants, j'ai fait beaucoup de simulations différents, tout en apprenant (et maudissant !) peu à peu ce langage avec lequel il me fallait tout faire. L'indentation m'a bien sûr donné des problèmes. Je ne sais pas quel éditeur le mec a utilisé, mais toutes ses indentations sont de quatre espaces. Moi j'utilise Gedit (oui, j'aurais préféré Vim, mais ça n'est pas installé sur nos ordis ) qui garde de vrais '\t' quand j'appuie sur Tab. Dans l'éditeur, un Tab a la même apparence que quatre espaces, mais Python ne sait pas que ce sont la même chose. J'ai amusé mes collègues je ne sais combien de fois en hurlant quand après avoir reçu des « IndentationError » !
Malgré tout je suis devenu le « Python go-to guy » et j'ai maintenant fait beaucoup de modifications au logiciel d'analyse, qui simplifient ma vie et les vies des autres ingénieurs. Aujourd'hui j'ai ajouté un fonctionnement qui utilise des regex, que j'avais en tête depuis quelques semaines. À vrai dire, j'atermoyais cette modification particulière, parce que je savais que ce serait une déception de devoir utiliser des regex en Python, au lieu de mon Perl bien aimé. Et j'avais raison. Je trouve beaucoup moins naturel que

Alors, malgré mes objections morales, malgré tous les problèmes que j'ai eu en 2016, malgré les problèmes que je continue à avoir chaque jour, le langage Python est au cœur de tout le travail important que je fais en ce moment. Quelle ironie !

Effectivement, beaucoup de gens trouvent Python carrément naze quand ils commencent à l'utiliser et pour les mêmes raisons que toi. Je sais que Hunch fait partie de ces gens là.

J'étais un peu dans le même cas que toi d'ailleurs, j'ai du réaliser un gros projet, un prototype de slicer avec Python et j'ai donc fini par apprécier quelque peu le langage, notamment sa simplicité, sa concision et sa puissance grâce à numpy. Et puis bon comme je ne connaissais pas vraiment d'autre langages de script, ça ne m'a pas dérangé plus que ça. Puis j'ai découvert R.

Au fait, quelqu'un a-t-il une idée de ce qui se passe dans la tête des créateurs de python, pour avoir implémenté plein de trucs qui ne servent à rien genre yield, mais de n'avoir toujours pas fait des trucs urgents et basiques comme le cast implicite de nombres vers des chaînes de caractères ?

Un truc qui m'a toujours fait péter des cables avec Python, c'est la coexistence de deux versions (2.x et 3.x) complètement incompatibles qui, combinées à la loi de Murphy, faisaient que tu trouvais toujours ce que tu cherchais dans la version autre que celle que tu avais choisie. Après, ça date un peu, et peut-être que 3.x a pris plus d'importance depuis, mais à l'époque cette mascarade datait déjà d'un moment.

Pas vraiment eu de problème avec ça, le seul truc qui me fait chier c'est que quand j'exécute python ou pip dans un shell ca me sort les versions 2.x, du coup il faut que je spécifie la version. Fin bon je suppose que c'est réglable.

Python 2 et 3, ça existe toujours, oui. Alors quand j'ai dit que j'ai fait deux installations sur mon système LFS, j'aurais dû dire quatre : deux Python 2 et deux Python 3 !
Ça me donne des problèmes aussi… Quand « mon » programme de simulation a été écrit premièrement (en 2013), ça utilisait Python 2, avec lequel la bibliothèque EMpy était compatible. Pourtant la version de cette bibliothèque qui existe maintenant est écrit pour Python 3, et c'est difficile de l'utiliser avec 2. Je n'ai les permissions suffisantes ni pour utiliser pip ni pour installer Python 3 sur notre station de travail et alors j'ai tout foutu avec une copie de la bibliothèque, et de future, dans mon répertoire personnel. Ça marche, mais quand même quelques simulations me donnent des résultats incontestablement dingues, et je me demande si ce n'est pas à cause d'une version incorrecte de Python/numpy…
EDIT 1 SEMAINE PLUS TARD : J'ai découvert le vrai problème : le mec qui a écrit le programme a utilisé les indices de réfraction complexes de la forme n+ik, alors que la bibliothèque s'attendait à n–ik. Alors la lumière se faisait amplifier au lieu d'atténuer.

Les langages de script… Pour moi, c'est Perl ou Matlab/Octave, ou rien. Au moins, c'est ça que j'aurais dit au début de janvier…
J'ai entendu parler du Perl Data Language, qui, à ce que je comprends, a des fonctionnalités comparables à Matlab, mais qui utilise Perl, et est beaucoup plus rapide. C'est un truc que j'aimerais essayer un jour…

Quelqu'un connaîtrait-il une utilité concrète de constexpr pour des variables locales en c++ ?

Tout ce qui requiert une évaluation à la compilation, comme un paramètre de modèle (templates, les types génériques en C++) ou la taille d'un tableau.

Ah j'avais pas pensé au tableaux typés C, je ne les utilise jamais en C++ de toutes façons, il n'y a aucun gain de performance par rapport à un std::Array et je trouve que la sémantique est moins agréable que ces derniers.
Pour les paramètres de templates, je suppose que tu parles du cas ou tu veux spécifier une valeur par défaut ? J'avais pas percuté que ça nécessitait une constexpr, mais de toutes façons les rares fois où j'ai besoin d'une valeur par défaut je préfère l'hardcoder, je vois pas trop l'utilité sinon.

Tiens d'ailleurs pour les templates, vous séparez les définitions de fonctions des déclarations ou pas du tout ?

LoveMetal wrote:Ah j'avais pas pensé au tableaux typés C, je ne les utilise jamais en C++ de toutes façons, il n'y a aucun gain de performance par rapport à un std::Array et je trouve que la sémantique est moins agréable que ces derniers.

Tiens, j'utilise jamais std::array, vu que std::vector est déjà très bien pour l'accès direct et l'ajout/retrait d'élements à la fin. Faudrait que je regarde s'il y a une réelle différence de performance et dans quels cas. Sinon, j'utilise std::deque s'il faut en plus pouvoir ajouter/retirer au début, ou std::list pour l'ajout/retrait partout si on peut se passer de l'accès direct.

LoveMetal wrote:Pour les paramètres de templates, je suppose que tu parles du cas ou tu veux spécifier une valeur par défaut ? J'avais pas percuté que ça nécessitait une constexpr, mais de toutes façons les rares fois où j'ai besoin d'une valeur par défaut je préfère l'hardcoder, je vois pas trop l'utilité sinon.

Si cette valeur est utilisée à plein d'endroits, autant ne l'écrire qu'une fois.

LoveMetal wrote:Tiens d'ailleurs pour les templates, vous séparez les définitions de fonctions des déclarations ou pas du tout ?

Normalement non, mais un pratique assez répandue et d'utiliser des fichiers .inc quand le tout devient trop gros.

Hunchman801 wrote:Faudrait que je regarde s'il y a une réelle différence de performance et dans quels cas.

Apparemment non.

std::Array c'est quand tu veux une taille fixe surtout, la classe consiste en un wrapper tout simple autour d'un tableau C avec surchage d'opérateurs.
La je suis en train de coder une bibliothèque audio où l'utilisateur peut avoir accès à des buffers de ce qui va être joué, imagine qu'il décide comme ça de modifier la taille de mon buffer je suis bien dans la merde.

J'étais même pas au courant que deque était devenue standard, faut vraiment que je pense à faire le ménage dans mon utilisation de boost.

Hunchman801 wrote:Si cette valeur est utilisée à plein d'endroits, autant ne l'écrire qu'une fois.

Good point.