Je confirme aussi, je bosse dans l'industrie de la carte à puce et les terminaux de paiement ont plutôt tendance à être des bêtes de courses surdimensionnées que des Z80 8 bits.
Il faut voir qu'un TPE doit aujourd'hui savoir faire du TCP/IP, du Wifi, du bluetooth, parfois de la 3G, du NFC bien sur pour le paiement sans-contact, des calculs RSA et DES assez rapide et du stockage relativement sécurisé (ça pèche encore pas mal de ce côté là). Pour toutes ces fonctions, c'est bien plus simple de prendre une stack hardware moderne où tu récupères tout ça dans un seul chip et tu n'as plus qu'à faire le cablage, que de tenter de réduire les coûts du chip pur.
Le soft et le moule plastique ont vite fait de dominer le coût du projet que le pur hardware.
Il faut dire qu'avec ses dîners au homard, il a vraiment dépassé les bornes. Par contre, je ne savais pas que François De Rugy jouissait d'une telle estime !
C'est plutôt perdre du temps avec des gens qui travestissent les mots pour s'ériger en défenseurs de la veuve et des orphelins.
Je travestis des mots ? Pourtant esclave, il n'y a qu'une seule définition, et c'est bien celle de l'oppression et de l'absence de liberté. Je te mets la définition du Larousse :
Personne de condition non libre, considérée comme un instrument économique pouvant être vendu ou acheté, et qui était sous la dépendance d'un maître. (Il existe encore officieusement de nos jours quelques dizaines de millions d'esclaves en Afrique, en Océanie et en Asie ; leur nombre varie selon les sources.)
Personne soumise à un pouvoir arbitraire.
Personne qui est sous la dépendance complète d'une autre personne : Être l'esclave d'une femme.
Personne entièrement soumise à quelque chose ; prisonnier : Les esclaves de l'argent.
Kerro continue avec :
Maître/esclave n'a jamais eu le moindre rapport avec l'esclavage des humains
Ah oui ? Pourtant, le Larousse n'est pas d'accord avec toi. Il faut croire que les termes techniques des architectures informatiques des années 80 ne sont pas parvenus jusqu'à eux, où qu'ils ont considéré l'usage comme trop mineur.
La réalité, c'est que le sens de ces termes en informatique a été créé par des blancs qui n'avaient pas conscience de prolonger de façon implicite l'oppression qui a régné sur les noirs. Ca n'a rien d'étonnant en soi. Des informaticiens noirs auraient sûrement choisi un autre terme. De même que des juifs n'utiliseront jamais les termes "solution finale" "nazis" et autres pour décrire une quelconque fonctionnalité informatique.
Par contre, continuer à utiliser le terme aujourd'hui alors qu'il y a des alternatives moins chargée, je trouve ça stupide.
Seuls des SJW ayant trop de temps libre (c'est un peu la définition des SJW) s'occupent de ce genre de problème.
Tu as du mal lire, j'ai fait une proposition dans le cadre de mon travail, donc rien à voir avec mon temps libre. Et il n'y avait rien de Warrior puisque c'est une proposition dans le cadre d'une équipe, qui a fait le choix de l'accepter. Et je ne vois pas en quoi c'est Social puisque c'est dans le cadre de mon travail.
En plus, les Social Justice Warrior sont souvent dans une logique de critiquer une personne, une organisation ou une action, ce qui n'est pas mon cas, je me contente de partager une de mes expériences.
Bref, pour moi, tu es complètement à côté de la plaque.
J'ai tout récemment poussé mon équipe à utiliser d'autres termes que Master/Slave dans le logiciel qu'on développe. Ces termes étaient à la fois incorrect d'un point de vue technique, et chargé d'une histoire qu'on a pas besoin de rappeler.
On a atteri sur "Factory" et "Product", le premier servant à fabriquer le 2e.
Bref quand faut brasser du vent il y à toujours du monde…
Ce n'est pas brasser du vent que faire cela. C'est faire preuve d'empathie envers d'autres personnes pour qui ces termes réveillent des souffrances.
En France, on est moins sensibilisé à l'esclavagisme donc ça tilte moins. Par contre, si qq'un utilise les termes "nazis" et "juifs" pour décrire le fonctionnement d'un "thread pool", je suis sûr qu'on perçoit mieux à quel point c'est inapproprié.
Autre raison: le rendu avec des tabs va varier d'un PC à l'autre suivant comment tu as configuré ton éditeur (2 colonnes ? très courant en java ou 8 colonnes obligatoire dans le kernel linux ?). Et comment intepréter la limites de 78 caractères avec des tabs dans une ligne ? Une ligne composé de 70 tabulations et de 7 caractères alphanumériques dépasse la limite de 78 colonnes mais pas de 78 caractères…
Les changements progressifs encouragent les dévs à ne pas se crisper sur une version.
Ha ha ha!
Dans quel monde vis-tu réellement ? En dehors de quelques geeks passionnés, la majorité des informaticiens ne s'amuse pas à changer de version pour le plaisir si ça marche déjà. C'est encore plus vrai dans le monde professionnel.
Du coup, tout le monde utilise des versions antidéluviennes et fait des grands bonds en terme de migrations.
A mon boulot, on est bloqué à Python 3.1 pour un certain nombres de logiciels, et ce n'est pas prêt de bouger: l’équipe qui les maintenait n'est plus là. Je vais avoir du mal à justifier auprès de mes chefs qu'on doit maintenir et faire évoluer un nouveau package Python qu'on connait mal, simplement parce qu'on veut utiliser une version plus récente de Python, alors même que celle qu'on utilise marche très bien.
Ce n'est que le couteau sur la gorge que ma boite envisagera cette migration…
Même des très grosses boites comme GitHub ou Dropbox, qu'on ne peut pas trop soupçonner d'être à la rue en terme de technologie ont mis beaucoup de temps pour migrer aux dernières version de Rails et Python.
utiliser ce langage pour autre chose que des applis de petite taille est handicapant.
Je note quand même que Dropbox et Instagram gèrent une base de plusieurs millions de lignes de Python. Ils ont pas l'air si handicapés que cela…
Perso, je l'utilise sur des applications de toutes tailles. J'ai parfois dépassé les 30 000 lignes. Le seul frein que j'ai rencontré sur Python sur de grosses applications est l'absence de typage des variables/arguments. Problème qui est résolu depuis 5 années avec MyPy.
Pourquoi tu exclues d'emblée l'antispam russe ? Ca parait un vecteur tout à fait naturel et plus simple qu'un keylogger pour récupérer les SMS de sécurité sur un tel. Les applications malveillantes aiment se réclamer de la sécurité, tout comme la Mafia te "protège". Je chercherai plutôt dans cette direction en premier abord.
Tes exemples sont tout à fait pertinents sur des trucs qu'il ne vaut mieux pas faire en Python. En même temps, je suis sûr que tu seras d'accord pour reconnaitre que parmi tout le code qui est écrit dans une semaine aujourd'hui dans le monde entier, la proportion qui concerne les exemples que tu cites est extrêmement infime. Et en dehors de ces cas précis, Python s'avère un langage où les performances sont largement suffisante pour les besoins de ses utilisateurs.
Mon expérience n'est pas universelle mais je peux quand même la partager: depuis 18 ans que je fais du Python, je n'ai fait du profiling pour accélerer mes programmes que 3 fois. Et une fois, j'ai renoncé à écrire un programme (un clone de vi en Python) parce que Python était trop lent. Mais je devais avoir un problème de design car SublimeText y arrive très bien.
D'un autre côté, mon boulot quotidien est d'écrire du code pour des cartes à puce, donc de l'embarqué contraint en vitesse, en taille de code et très fortement contraint en sécurité. On ne fera jamais de Python là-dedans très clairement, seul le langage natif de le puce est approprié (en mélange C / ASM).
Absoluement pas, car dans ce scénario tu fais du développement C/C++ un pré-requis au développement python pour les parties perf critical. Qui suivant ton secteur, peuvent arriver trés rapidement.
Performance, ça reste un terme très générique. De quelles performances on parle réellement ?
D'avoir le plus petit runtime en mémoire ? Python est clairement un mauvais candidat, comme tous les langages interprétés et tous les langages à VM.
De faire des gros calculs numériques ? Python est très très bien équipé avec pandas, numpy, pytorch et autres projets de calcul scientifique. Ces projets sont écrits en C/C++, leur utilisation en Python te permet donc de bénéficier des perf d'une implémentation native. Il faut vraiment avoir besoin de calculs haute performance très très spécifiques pour tomber en dehors des service fournies par l'écosystème déjà présent.
De faire beaucoup de processing io-bound ? Python s'en sort aussi très bien, en particulier avec les apports des modes asynchrones des dernières versions.
De faire beaucoup de processing cpu-bound ? Clairement, Python n'est pas le meilleur candidat mais c'est quand même assez rare d'avoir des jobs cpu-bound pour lesquels il n'existe pas d'implémentation native.
De faire une interface graphique réactive ? Je fais régulièrement du Python avec PyQt et mes interfaces sont très réactives. Par exemple, j'ai utilisé récemment une vue sur des tableaux de plusieurs dizaines de milliers d'items sans problème visible.
De fournir un produit fonctionnel à un client à un coût moindre ? Python, avec sa rapidité de développement et l'immense bibliothèque de package disponible est certainement un candidat intéressant à considérer.
La soi-disant lenteur de Python est un vieux mythe qui continue de planer, déconnecté des réalités. Python est moins rapide que d'autres langages pour certaines tâches très précises, mais pour la majorité des programmes qui sont écrits, il est tout à fait suffisant.
Petite anecdote, j'ai participé à la "battle dev" ( https://battledev.blogdumoderateur.com/ ) sous le nom de ma boite et certains collègues habitués au C/C++ ont été choqués qu'on puisse résoudre la plupart des problèmes en Python, alors même qu'ils nécessitaient pas mal de calcul et de parcours de structures de données.
Je suis super d'accord. J'évite à tout prix de me reposer sur le typage dynamique en Python et ne l'utilise qu'en de très rares exceptions. Par contre, quand tu en as besoin, t'es content quand ça fasse partie du langage !
Dans ma vie de développeur C et C++, je suis régulièrement confronté au fait que les entiers soient un type "faible", c'est à dire sans limite précise.
Typiquement, j'ai un offset dans un tableau de taille fixe, mais il est représenté par un unsigned int (et encore, c'est quand je fais propre, le reste du temps, c'est un signed int). Et il peut circuler d'une fonction à une autre sous forme d'entier non signé, perdant complètement la notion de limite intrinsèque pour laquelle il a été défini. Le buffer overflow nous tend les bras et le compilateur ne peut rien faire pour le prévenir, c'est dans la définition du langage.
Beaucoup de bugs découlent de cette absence de typage, et les langages C/C++/Java ne font rien pour y remédier. Elle se retrouve sous plein de variantes : les Enum qui sont gérés comme des int par le compilateur, une structure définie avec des types ouverts (int, float, std::string), alors qu'en fait, seul un petit nombre de valeur sont autorisés pour ces champs, etc etc.
J'ai entendu dire que le bon langage pour tenir compte de ce genre de contrainte s'appelle Ada. J'ai encore jamais pris le temps ni l'énergie de m'y mettre, mais je suis persuadé que si je dois écrire un programme "sur", c'est vers lui que le me tournerai.
Quand on me dit que le C++ est typé, c'est vrai mais je me sens toujours pas en sécurité quand je l'utilise. Les buffers overflow et les déréferencements de pointeurs ont encore une longue vie devant eux.
Jusqu'à récemment, j'avais aussi la sensation de prendre des risques à coder un gros projet en Python. Depuis l'arrivée de Mypy et du typage dynamique, je suis plus tranquille. Je n'ai pas encore la sureté d'un langage compilé mais je trouve que le compromis "sureté / rapidité de développement / facilité de test" est très correct.
Quand je retourne au C et C++, je perds beaucoup sur les deux derniers points, et de mon point de vue, je ne gagne pas assez en sureté.
Je génère systématiquement des exécutables quand je livre des outils écrits en Python. En effet, sinon, la tambouille d'installation est trop rebutante. Py2exe, Py2app et Pyinstaller sont tes amis.
Il y a tout un tas de test que tu fais en python qui sont simplement inutiles en C++ du fait du typage statique de C++.
Ca, c'est du troll pur non ?
J'ai beau réfléchir, sur 15 ans de Python, les fois où j'ai du faire un test de typing pur en Python doivent se compter sur les doigts d'une main. Par contre, je profite régulièrement de la souplesse du typage de Python dans mes fonctions pour faire des trucs assez complexes qui, à faire en C++, demanderaient soit une classe dédiée, soit des template, soit d'être un expert C++18, soit les trois en même temps. Il y a beaucoup moins de boilerplate en Python.
Et mes tests Python sont souvent bien plus poussés que ceux que j'écris en C++ pour des fonctionnalités équivalentes, et ce pour plusieurs raisons:
Python dispose d'un écosystème très étendu, permettant d'avoir pas mal de fonctionnalités déjà testées dans des lib externes, ce qui me permet de me concentrer sur des parties de mon code plus sensibles.
En jouant sur les Mock et les propriétés dynamiques de Python, il est plus facile d'aller tester du code en profondeur.
comme c'est plus rapide d'écrire du code en Python, l'écriture du code de test est aussi plus rapide, et à budget temps constant, je peux écrire plus de test, ou des tests qui vont plus en profondeur.
Il existe aussi des outils pour t'aider à améliorer ton code (il te propose même de patcher ton code directement).
Ca tombe bien, Python aussi. Ca va du simple Linter à MyPy ou PyCharm qui te permet de vérifier la cohérence des types utilisés dans ton projet (à peu près comme un compilo C++). D'ailleurs, il y a un français qui a fait une super conférence à ce sujet au PyData Paris 2018: https://www.youtube.com/watch?v=URP2e7hEUFw&list=PLzjFI0G5nSsry3cm_k1tPOi9SRaAXsZAt&index=6 (disclaimer: c'est moi qui présente).
Bah, ici, on est bloqué à Visual Studio 2011 en terme de licences. Alors du C++ moderne … je suis pas prêt d'en faire :-).
Par contre, ils sont un peu plus ouverts sur le Python bien que la version majoritairement déployée soit la version … 3.1 . Oui oui, le truc plus maintenu depuis 2012.
Pour Git, je suis d’accord, mais pour Mercurial, il me semble qu'il stocke justement un ensemble de patch et que le sha porte sur les patches qui permettent d'arriver à une version donnée.
En lisant la doc, ce qui me vient, c'est que en effet, sous Git, dès que tu pète un coup, tu changes le hash de ton snapshot et tu dois passer derrière par des phases de publications, fusion, distribution etc. Pour pas mal de cas triviaux, c'est assez ennuyeux.
Après, de là à justifier un autre DVCS, je reste un brin sceptique. Même mercurial qui tenait bien la route s'est fait enterrer par Git…
Je m'interroge aussi sur un point : il m'a semblé saisir que si deux patchs sont commutatables, les échanger ne change pas l'identifiant du résultat final. Cela veut dire qu'on peut réécrire l'ordre de l'historique d'un projet ? Et si c'est le cas, n'est-ce pas une anti-feature ?
Ce n'est pas une histoire d'être passionné ou pas, c'est une histoire de faire évoluer ses outils pour pouvoir bénéficier des avancées qu'ils proposent.
Perso, je partage plutôt le point de vue que c'est bien de se tenir à jour et de faire des outils plus performant et que ça va impacter de façon positive l'entreprise, la productivité, l'innovation, etc.
Par contre, objectivement, une entreprise qui a des outils qui lui donnent satisfaction n'a pas tant de raison que ça de s'intéresser à des nouvelles générations d'outils. Une petit citation pour la route : If it ain't broken, don't fix it - si ce n'est pas cassé, ne le répare pas.
En fait, tu crois savoir et tu répètes des choses que tu as entendu dans les couloirs sans jamais avoir fait l'effort de te mettre dedans pour avoir ton propre avis. […] La complexité du langage n'a pas augmenté, il y a juste des nouvelles fonctionnalités, comme dans beaucoup d'autres langages qui évoluent. Et tu n'as juste pas pris le temps de comprendre.
Tu te trompes sur un point, c'est que j'ai fait l'effort de tenter de comprendre les nouveautés du C++. Je lis avec passion les articles de linuxfr qui en parlent, et j'ai lu la pages de nouveautés expliquée par … j'ai un doute, Herb Sutter ou Bjarne Soustroup (je ne retrouve pas le lien, je me souviens que c'était assez fouillé mais incomplet en tout cas). Il y a un certain nombre d'améliorations qui me parlent (la sémantique du move par exemple), d'autres où je saisis l'idée mais où j'ai du mal à rentrer dans les détails (les lambda, les constexpr) et d'autres où vraiment, c'est complètement au dessus de mon niveau de compréhension du langage.
On va avoir un débat sur le mot complexité vs quantité. On est au moins d'accord que la quantité de fonctionnalité augmente à chaque révision. Je maintiens que la complexité augmente aussi car il y a plus de façon de se tromper dans la façon d'écrire du code. Et il y a plus d'interactions possibles entre les nouvelles fonctionnalités.
Il est courant en Python de ne pas s'embêter avec un gros formalisme quand ce n'est pas nécessaire.
La façon la plus simple de représenter une paire est d'utiliser un tuple de deux éléments. C'est une structure non-modifiable, donc ça correspond bien à la définition d'une paire.
Si on se retrouvait avec un programme manipulant des paires ayant des significations variées, on serait amené à utiliser une structure de plus haut niveau, genre un NamedTuple ou une DataClass qui permettrait d'accéder aux deux éléments de la paire avec un nom qui les représente, genre x/y ou first/second, ou encore firstName/lastName.
Genre :
d[k] = Point(x=v.y, y=v.x) Dans le cas où on manipulerait des coordonnées et qu'on veuille faire une transposition.
Mais bon, souvent, les structure de Python sont suffisamment élaborées pour pouvoir les utiliser longtemps en l'état.
On peut trouver dans différents langages les if, unless, switch, l'opérateur ternaire, des opérateurs de déréférencement null-safe, du pattern matching, le given de perl est une sorte de pattern matching bizarre, bash a ${identifiant:-defaultValue} et d'autres, etc. Ce sont autant de constructions qui permette au développeur d'exprimer des choses différentes, alors qu'elles sont compilée (ou du moins compilables) en un simple saut conditionnel.
Ok, je saisis mieux. Après, je comprends toujours pas en quoi ça range le C++ dans la catégorie des langages expressifs, il reste pour moi associé à un trucs très complexe avec des erreurs très très absconses (genre tu oublies de mettre un espace entre deux > >, tu pleures). Mais je salue les progrès faits ces dernières années, même si je ne peux pas en tirer partie dans mon entreprise (cf mon autre commentaire).
Concernant l'expressivité, après être passé du BASIC/Assembleur au Pascal, puis au C, puis au C++, puis au Python (avec un détour par Caml Light), j'ai eu l'impression de progresser à chaque étape à pas de géant en terme de correspondance "ce que j'ai dans la tête" et "comment je l'exprime dans le langage". Avec Python, je ne ressens plus aucune limitation d'expressivité, et c'est probablement pour cela que ton commentaire ne résonne pas plus que cela en moi. Je reste cependant conditionné par le langage et je saisis bien qu'un programmeur familier des langages fonctionnels purs sera certainement très frustré par le manque d'expressivité de Python en la matière.
Il existe certes des structures plus complexes ou plus élaborées comme le pattern matching en OCaml mais je n'en ressens pas le manque. Avec les années, je ressens aussi l'importance de garder le code dans la catégorie du "moyennement complexe" afin de rester intelligible. Si j'écris du code qui va être partagé entre plusieurs développeurs, plusieurs équipes, qui va vivre pendant plusieurs années, je sais que je suis réticent à utiliser des constructions très puissantes du langage car je ne suis pas sur d'être lisibles pour mes collègues, ou même pour moi dans 10 ans.
Après oui le C++ n'est pas le langage le plus concis qui existe (c'est ce que tu voulais me faire dire ?)
Oui :-)
Tu y as mis du temps !
et le python n'est pas le langage le plus verbeux (c'est l'autre truc que tu voulais me faire dire ?).
Aussi oui.
C'est surtout que ce que tu as écris est à l'exact opposé de mon ressenti sur ces deux langages. Je suis assez ébahi qu'on puisse avoir des expériences aussi éloignées. Sois tu as tort, sois …. il y a une autre explication (non, je n'ai pas tort :-) ).
C'est quoi une classe copiable ? Faire une deep/shall copy ?
C'est vrai que quand j'y pense, une grande partie de mes classes en C++ sont soit des "Plain Old Data" copiables par copie simple, soit des trucs plus complexes mais déjà gérés par la lib que j'utilises (Qt, boost, etc).
C'est juste que je me rappelle du gros warning que j'ai eu lors de l'apprentissage du langage sur les copies de classes.
Tu nous fais un bel homme de paille. Les gens sérieux qui font du C++ utilisent tous C++11 de nos jours
C'est quoi la définition de sérieux ? Si je prends mon entreprise, où on parle quand même de développeurs qui gagnent leur vie en écrivant du code … on peut penser qu'il s'agit de gens sérieux non ? Et pourtant, côté C++, on est loin du C++11. Je pense même pas que la plupart des mes collègues immédiats connaissent le sigle. Si je leur montre un bout de code avec des lambdas et des templates, ils ne comprendront juste rien. On fait de la carte programmation pour carte à puce, ce qui veut dire beaucoup de C, un peu d'assembleur, un peu de JavaCard, et un peu de Python pour nos tests.
Aujourd'hui un collègue développeur a vu mon écran et m'a demandé pourquoi je regardais un forum sur le jeu de Go. Il n'avait jamais entendu parlé du langage…
On utilise un peu de Python mais le seul qui est installé sur leurs postes, c'est Python 3.1 . Et je ne m'avance pas à utiliser des syntaxes avancées de Python (décorateurs, getter/setters, comprehensions, …) si je ne veux pas les perdre en route.
Je tiens donc à souligner la grande distance qu'il y a entre des passionnés qui suivent les évolutions de l'informatique et des entreprises qui restent avant tout consommatrices d'outils en l'état.
(GCC utilise par défaut C++14, tout comme Clang, et même MSVC utilise du C++ moderne par défaut).
Côté Visual Studio, on utilise la version … 2011 Professional. Et je crois pas que C++11 soit bien supporté dans cette version. :-)
Les nouvelles fonctionnalités apportent non seulement de la lisibilité, mais également des constructions nécessaires pour faire du code performant (comme la sémantique de déplacement). Tu peux refuser de les considérer mais tu passes à côté de l'essentiel quand tu fais du C++.
Il y a pas de refus de ma part. C'est juste que le C++, globalement, je ne l'utilise pas. Et je sais que c'est un langage complexe, dont la complexité ne fait que grandir au cours du temps.
Déjà, j'avais noté que le C++ de mon époque était plus complexe que ce que mon cerveau pouvait encaisser en une seule fois. Je sais que je ne me hasarderai pas à lever une exception en C++ sans relire un bouquin entier sur le sujet tellement il y a de façon de mal le faire.
Alors maintenant, de savoir que la complexité du langage a augmenté (ce que je vois quand je lis des exemples dans quelques journaux, je comprends juste rien), ça me motive pas vraiment à m'y mettre. Après, si j'avais un boulot qui l'exige, je me lancerai à fond dedans avec plaisir.
Paradoxalement, j'ai fait pas mal de Qt/C++. Et je bénis Trolltech/Nokia/Digia/Qt d'avoir rendu le C++ utilisable même par des gens peu experts en la matière.
Hum… Certaines choses comme l'une des règles du Zen of python : « There should be one-- and preferably only one --obvious way to do it ». Ne vont pas vraiment dans ce sens.
Tu pourrais être plus explicite ? Je ne vois pas en quoi le fait de favoriser "une façon évidente et si possible unique" de faire une tâche nuit à l'expressivité du langage. Au contraire, si il y une façon évidente et unique de faire une tâche, tout le monde va utiliser cette façon et l'intention du programmeur sera claire.
J'ai tendance à toujours le comparer à perl qui a la règle parfaitement inverse, le TMTOWTDI.
Cette règle a été écrite (à mon avis) en réaction à Perl qui a en effet le TMTOWTDI. Et côté Perl, je vois ça plus comme un constat qu'il existe mille et une façon de faire une tâche que comme quelque chose que le créateur de langage a volontairement instillé dans la conception.
Hum… Je n'ai pas trop cette sensation (encore une fois je peux me planter). Quand je vois les exemples de serge_sans_paille je ne vois pas de boiller plate justement.
Tu n'a pas réagi sur mon exemple pourtant ? C++, c'est pas le langage où quand on veut faire une classe copiable, il faut définir 4 méthodes différentes ? Mais pas de boiler-plate hein ?
Les constructions nouvelles du langage apportées dans C++11 et consorts sont certainement bien pratiques, mais dans les faits, elles sont très récentes dans l'histoire du langage (si on prend 1985 comme date de première visibilité, on est à 34 ans d'existence alors que le C++11 n'est là que depuis 8 ans). Elles restent encore peu connues, apportent leurs propres problèmes de lisibilité et de compréhension. Côté lisibilité, on repassera. Ça ajoute en plus énormément à la complexité du langage.
J'ai du mal à voir C++ et expressivité dans la même phrase, et Python dans la catégorie "inexpressivité". Pour le reste du commentaire, je suis plutôt d'accord.
J'exprime mon désaccord sur les deux points:
Python est au contraire un langage très expressif, le programmeur peut manifester son intention en très peu de lignes de code. Le boiler-plate code en Python est quasiment inexistant.
A l'opposé, à chaque fois que j'utilise la STL en C++, mes yeux pleurent, je me dis que 120 colonnes pour une ligne, c'est bien peu quand tu veux manipuler une structure un tant soit peu élaborée.
Allez, au hasard, parcourons une map/un dict de string vers des paires de string en Python et en C++ et inversons les paires:
En Python:
# on parcours le dictionnaire, k est la clé, v est la valeurfork,vind.items():# v est une paire, on peut accéder aux deux éléments et les inverserd[k]=(v[1],v[0])
En C++:
// on parcours le dictionnaire/map avec un iterateur, it.first est la clé, it.value est la valeurfor(map<string,pair<string,string>>::iteratorit=d.begin();it!=it.end();it++){// la paire est dans it.second, c'est elle qu'il faut inverserd[it.first]=make_pair(it.second.second,it.second.first);}
En terme d'expressivité et lisibilité, je trouve que la version Python s'en sort beaucoup beaucoup mieux.
Et encore, il aurait été de bon ton d'expliciter l'instanciation de make_pair<> .
Alors, certes, en C++11, on peut faire plus compact en utilisant des auto et surement avec d'autres trucs (lambda ? foreach ?). Mais tout le monde ne les connait pas.
On peut aussi faire bien plus compact en Python mais on tombe sur le même problème: la syntaxe des Python compréhensions est peu connue (par exemple, aucun de mes collègues de travail ne connait): d = { k:(v[1],v[0]) for k,v in d.items()}
[^] # Re: Z80, le meilleur processeur post-apo ?
Posté par Philippe F (site web personnel) . En réponse au journal Collapse OS : un système d’exploitation pour rebâtir la civilisation. Évalué à 7.
Je confirme aussi, je bosse dans l'industrie de la carte à puce et les terminaux de paiement ont plutôt tendance à être des bêtes de courses surdimensionnées que des Z80 8 bits.
Il faut voir qu'un TPE doit aujourd'hui savoir faire du TCP/IP, du Wifi, du bluetooth, parfois de la 3G, du NFC bien sur pour le paiement sans-contact, des calculs RSA et DES assez rapide et du stockage relativement sécurisé (ça pèche encore pas mal de ce côté là). Pour toutes ces fonctions, c'est bien plus simple de prendre une stack hardware moderne où tu récupères tout ça dans un seul chip et tu n'as plus qu'à faire le cablage, que de tenter de réduire les coûts du chip pur.
Le soft et le moule plastique ont vite fait de dominer le coût du projet que le pur hardware.
# Non au homard
Posté par Philippe F (site web personnel) . En réponse au journal Tristesse. Évalué à 2.
Il faut dire qu'avec ses dîners au homard, il a vraiment dépassé les bornes. Par contre, je ne savais pas que François De Rugy jouissait d'une telle estime !
[^] # Re: Plus gros problème du libre
Posté par Philippe F (site web personnel) . En réponse au journal Richard Stallman, l'affaire Epstein et des positions franchement douteuses. Évalué à -3.
Kerro nous dit:
Je travestis des mots ? Pourtant esclave, il n'y a qu'une seule définition, et c'est bien celle de l'oppression et de l'absence de liberté. Je te mets la définition du Larousse :
Kerro continue avec :
Ah oui ? Pourtant, le Larousse n'est pas d'accord avec toi. Il faut croire que les termes techniques des architectures informatiques des années 80 ne sont pas parvenus jusqu'à eux, où qu'ils ont considéré l'usage comme trop mineur.
La réalité, c'est que le sens de ces termes en informatique a été créé par des blancs qui n'avaient pas conscience de prolonger de façon implicite l'oppression qui a régné sur les noirs. Ca n'a rien d'étonnant en soi. Des informaticiens noirs auraient sûrement choisi un autre terme. De même que des juifs n'utiliseront jamais les termes "solution finale" "nazis" et autres pour décrire une quelconque fonctionnalité informatique.
Par contre, continuer à utiliser le terme aujourd'hui alors qu'il y a des alternatives moins chargée, je trouve ça stupide.
Tu as du mal lire, j'ai fait une proposition dans le cadre de mon travail, donc rien à voir avec mon temps libre. Et il n'y avait rien de Warrior puisque c'est une proposition dans le cadre d'une équipe, qui a fait le choix de l'accepter. Et je ne vois pas en quoi c'est Social puisque c'est dans le cadre de mon travail.
En plus, les Social Justice Warrior sont souvent dans une logique de critiquer une personne, une organisation ou une action, ce qui n'est pas mon cas, je me contente de partager une de mes expériences.
Bref, pour moi, tu es complètement à côté de la plaque.
[^] # Re: Plus gros problème du libre
Posté par Philippe F (site web personnel) . En réponse au journal Richard Stallman, l'affaire Epstein et des positions franchement douteuses. Évalué à 3.
Le produit en question n'a strictement rien à voir avec une base de donnée en effet.
[^] # Re: Plus gros problème du libre
Posté par Philippe F (site web personnel) . En réponse au journal Richard Stallman, l'affaire Epstein et des positions franchement douteuses. Évalué à -2.
J'ai tout récemment poussé mon équipe à utiliser d'autres termes que Master/Slave dans le logiciel qu'on développe. Ces termes étaient à la fois incorrect d'un point de vue technique, et chargé d'une histoire qu'on a pas besoin de rappeler.
On a atteri sur "Factory" et "Product", le premier servant à fabriquer le 2e.
Ce n'est pas brasser du vent que faire cela. C'est faire preuve d'empathie envers d'autres personnes pour qui ces termes réveillent des souffrances.
En France, on est moins sensibilisé à l'esclavagisme donc ça tilte moins. Par contre, si qq'un utilise les termes "nazis" et "juifs" pour décrire le fonctionnement d'un "thread pool", je suis sûr qu'on perçoit mieux à quel point c'est inapproprié.
[^] # Re: Retour sur des grosses applications
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 5.
Autre raison: le rendu avec des tabs va varier d'un PC à l'autre suivant comment tu as configuré ton éditeur (2 colonnes ? très courant en java ou 8 colonnes obligatoire dans le kernel linux ?). Et comment intepréter la limites de 78 caractères avec des tabs dans une ligne ? Une ligne composé de 70 tabulations et de 7 caractères alphanumériques dépasse la limite de 78 colonnes mais pas de 78 caractères…
[^] # Re: Retour sur des grosses applications
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 5.
Parce que tu gagnes un meilleur salaire si tu utilises des espaces plutôt que des tabulations!
Cf https://stackoverflow.blog/2017/06/15/developers-use-spaces-make-money-use-tabs/
[^] # Re: Pas trop tôt
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python — partie 2 ―Python 2. Évalué à 7.
Ha ha ha!
Dans quel monde vis-tu réellement ? En dehors de quelques geeks passionnés, la majorité des informaticiens ne s'amuse pas à changer de version pour le plaisir si ça marche déjà. C'est encore plus vrai dans le monde professionnel.
Du coup, tout le monde utilise des versions antidéluviennes et fait des grands bonds en terme de migrations.
A mon boulot, on est bloqué à Python 3.1 pour un certain nombres de logiciels, et ce n'est pas prêt de bouger: l’équipe qui les maintenait n'est plus là. Je vais avoir du mal à justifier auprès de mes chefs qu'on doit maintenir et faire évoluer un nouveau package Python qu'on connait mal, simplement parce qu'on veut utiliser une version plus récente de Python, alors même que celle qu'on utilise marche très bien.
Ce n'est que le couteau sur la gorge que ma boite envisagera cette migration…
Même des très grosses boites comme GitHub ou Dropbox, qu'on ne peut pas trop soupçonner d'être à la rue en terme de technologie ont mis beaucoup de temps pour migrer aux dernières version de Rails et Python.
Quelques lectures intéressantes : https://blogs.dropbox.com/tech/2018/09/how-we-rolled-out-one-of-the-largest-python-3-migrations-ever/
J'ai pas retrouvé le blog où la mise à jour Rails était décrite mais j'ai souvenir que c'est étalé sur plus d'une année.
[^] # Re: Stats
Posté par Philippe F (site web personnel) . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 10.
Je note quand même que Dropbox et Instagram gèrent une base de plusieurs millions de lignes de Python. Ils ont pas l'air si handicapés que cela…
Perso, je l'utilise sur des applications de toutes tailles. J'ai parfois dépassé les 30 000 lignes. Le seul frein que j'ai rencontré sur Python sur de grosses applications est l'absence de typage des variables/arguments. Problème qui est résolu depuis 5 années avec MyPy.
# Russie
Posté par Philippe F (site web personnel) . En réponse au journal Validations frauduleuses de codes 3D Secure. Évalué à 5.
Pourquoi tu exclues d'emblée l'antispam russe ? Ca parait un vecteur tout à fait naturel et plus simple qu'un keylogger pour récupérer les SMS de sécurité sur un tel. Les applications malveillantes aiment se réclamer de la sécurité, tout comme la Mafia te "protège". Je chercherai plutôt dans cette direction en premier abord.
[^] # Re: Performance
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Tes exemples sont tout à fait pertinents sur des trucs qu'il ne vaut mieux pas faire en Python. En même temps, je suis sûr que tu seras d'accord pour reconnaitre que parmi tout le code qui est écrit dans une semaine aujourd'hui dans le monde entier, la proportion qui concerne les exemples que tu cites est extrêmement infime. Et en dehors de ces cas précis, Python s'avère un langage où les performances sont largement suffisante pour les besoins de ses utilisateurs.
Mon expérience n'est pas universelle mais je peux quand même la partager: depuis 18 ans que je fais du Python, je n'ai fait du profiling pour accélerer mes programmes que 3 fois. Et une fois, j'ai renoncé à écrire un programme (un clone de vi en Python) parce que Python était trop lent. Mais je devais avoir un problème de design car SublimeText y arrive très bien.
D'un autre côté, mon boulot quotidien est d'écrire du code pour des cartes à puce, donc de l'embarqué contraint en vitesse, en taille de code et très fortement contraint en sécurité. On ne fera jamais de Python là-dedans très clairement, seul le langage natif de le puce est approprié (en mélange C / ASM).
[^] # Re: Performance
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 4.
Performance, ça reste un terme très générique. De quelles performances on parle réellement ?
D'avoir le plus petit runtime en mémoire ? Python est clairement un mauvais candidat, comme tous les langages interprétés et tous les langages à VM.
De faire des gros calculs numériques ? Python est très très bien équipé avec pandas, numpy, pytorch et autres projets de calcul scientifique. Ces projets sont écrits en C/C++, leur utilisation en Python te permet donc de bénéficier des perf d'une implémentation native. Il faut vraiment avoir besoin de calculs haute performance très très spécifiques pour tomber en dehors des service fournies par l'écosystème déjà présent.
De faire beaucoup de processing io-bound ? Python s'en sort aussi très bien, en particulier avec les apports des modes asynchrones des dernières versions.
De faire beaucoup de processing cpu-bound ? Clairement, Python n'est pas le meilleur candidat mais c'est quand même assez rare d'avoir des jobs cpu-bound pour lesquels il n'existe pas d'implémentation native.
De faire une interface graphique réactive ? Je fais régulièrement du Python avec PyQt et mes interfaces sont très réactives. Par exemple, j'ai utilisé récemment une vue sur des tableaux de plusieurs dizaines de milliers d'items sans problème visible.
De fournir un produit fonctionnel à un client à un coût moindre ? Python, avec sa rapidité de développement et l'immense bibliothèque de package disponible est certainement un candidat intéressant à considérer.
La soi-disant lenteur de Python est un vieux mythe qui continue de planer, déconnecté des réalités. Python est moins rapide que d'autres langages pour certaines tâches très précises, mais pour la majorité des programmes qui sont écrits, il est tout à fait suffisant.
Petite anecdote, j'ai participé à la "battle dev" ( https://battledev.blogdumoderateur.com/ ) sous le nom de ma boite et certains collègues habitués au C/C++ ont été choqués qu'on puisse résoudre la plupart des problèmes en Python, alors même qu'ils nécessitaient pas mal de calcul et de parcours de structures de données.
[^] # Re: Performance
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Je suis super d'accord. J'évite à tout prix de me reposer sur le typage dynamique en Python et ne l'utilise qu'en de très rares exceptions. Par contre, quand tu en as besoin, t'es content quand ça fasse partie du langage !
[^] # Re: Performance
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 5.
Dans ma vie de développeur C et C++, je suis régulièrement confronté au fait que les entiers soient un type "faible", c'est à dire sans limite précise.
Typiquement, j'ai un offset dans un tableau de taille fixe, mais il est représenté par un unsigned int (et encore, c'est quand je fais propre, le reste du temps, c'est un signed int). Et il peut circuler d'une fonction à une autre sous forme d'entier non signé, perdant complètement la notion de limite intrinsèque pour laquelle il a été défini. Le buffer overflow nous tend les bras et le compilateur ne peut rien faire pour le prévenir, c'est dans la définition du langage.
Beaucoup de bugs découlent de cette absence de typage, et les langages C/C++/Java ne font rien pour y remédier. Elle se retrouve sous plein de variantes : les Enum qui sont gérés comme des int par le compilateur, une structure définie avec des types ouverts (int, float, std::string), alors qu'en fait, seul un petit nombre de valeur sont autorisés pour ces champs, etc etc.
J'ai entendu dire que le bon langage pour tenir compte de ce genre de contrainte s'appelle Ada. J'ai encore jamais pris le temps ni l'énergie de m'y mettre, mais je suis persuadé que si je dois écrire un programme "sur", c'est vers lui que le me tournerai.
Quand on me dit que le C++ est typé, c'est vrai mais je me sens toujours pas en sécurité quand je l'utilise. Les buffers overflow et les déréferencements de pointeurs ont encore une longue vie devant eux.
Jusqu'à récemment, j'avais aussi la sensation de prendre des risques à coder un gros projet en Python. Depuis l'arrivée de Mypy et du typage dynamique, je suis plus tranquille. Je n'ai pas encore la sureté d'un langage compilé mais je trouve que le compromis "sureté / rapidité de développement / facilité de test" est très correct.
Quand je retourne au C et C++, je perds beaucoup sur les deux derniers points, et de mon point de vue, je ne gagne pas assez en sureté.
[^] # Re: Livraison facile en Python ??
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 3.
Je génère systématiquement des exécutables quand je livre des outils écrits en Python. En effet, sinon, la tambouille d'installation est trop rebutante. Py2exe, Py2app et Pyinstaller sont tes amis.
[^] # Re: Performance
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 8.
Ca, c'est du troll pur non ?
J'ai beau réfléchir, sur 15 ans de Python, les fois où j'ai du faire un test de typing pur en Python doivent se compter sur les doigts d'une main. Par contre, je profite régulièrement de la souplesse du typage de Python dans mes fonctions pour faire des trucs assez complexes qui, à faire en C++, demanderaient soit une classe dédiée, soit des template, soit d'être un expert C++18, soit les trois en même temps. Il y a beaucoup moins de boilerplate en Python.
Et mes tests Python sont souvent bien plus poussés que ceux que j'écris en C++ pour des fonctionnalités équivalentes, et ce pour plusieurs raisons:
Ca tombe bien, Python aussi. Ca va du simple Linter à MyPy ou PyCharm qui te permet de vérifier la cohérence des types utilisés dans ton projet (à peu près comme un compilo C++). D'ailleurs, il y a un français qui a fait une super conférence à ce sujet au PyData Paris 2018: https://www.youtube.com/watch?v=URP2e7hEUFw&list=PLzjFI0G5nSsry3cm_k1tPOi9SRaAXsZAt&index=6 (disclaimer: c'est moi qui présente).
[^] # Re: Mon avis (professionnel)
Posté par Philippe F (site web personnel) . En réponse au journal Moi, expert C++, j'abandonne le C++. Évalué à 2.
Bah, ici, on est bloqué à Visual Studio 2011 en terme de licences. Alors du C++ moderne … je suis pas prêt d'en faire :-).
Par contre, ils sont un peu plus ouverts sur le Python bien que la version majoritairement déployée soit la version … 3.1 . Oui oui, le truc plus maintenu depuis 2012.
[^] # Re: Soit j'ai rien compris soit...
Posté par Philippe F (site web personnel) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Pour Git, je suis d’accord, mais pour Mercurial, il me semble qu'il stocke justement un ensemble de patch et que le sha porte sur les patches qui permettent d'arriver à une version donnée.
[^] # Re: Difference Pijul vs Git
Posté par Philippe F (site web personnel) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 9.
En lisant la doc, ce qui me vient, c'est que en effet, sous Git, dès que tu pète un coup, tu changes le hash de ton snapshot et tu dois passer derrière par des phases de publications, fusion, distribution etc. Pour pas mal de cas triviaux, c'est assez ennuyeux.
Après, de là à justifier un autre DVCS, je reste un brin sceptique. Même mercurial qui tenait bien la route s'est fait enterrer par Git…
Je m'interroge aussi sur un point : il m'a semblé saisir que si deux patchs sont commutatables, les échanger ne change pas l'identifiant du résultat final. Cela veut dire qu'on peut réécrire l'ordre de l'historique d'un projet ? Et si c'est le cas, n'est-ce pas une anti-feature ?
[^] # Re: Expressivité
Posté par Philippe F (site web personnel) . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 2.
Perso, je partage plutôt le point de vue que c'est bien de se tenir à jour et de faire des outils plus performant et que ça va impacter de façon positive l'entreprise, la productivité, l'innovation, etc.
Par contre, objectivement, une entreprise qui a des outils qui lui donnent satisfaction n'a pas tant de raison que ça de s'intéresser à des nouvelles générations d'outils. Une petit citation pour la route : If it ain't broken, don't fix it - si ce n'est pas cassé, ne le répare pas.
Tu te trompes sur un point, c'est que j'ai fait l'effort de tenter de comprendre les nouveautés du C++. Je lis avec passion les articles de linuxfr qui en parlent, et j'ai lu la pages de nouveautés expliquée par … j'ai un doute, Herb Sutter ou Bjarne Soustroup (je ne retrouve pas le lien, je me souviens que c'était assez fouillé mais incomplet en tout cas). Il y a un certain nombre d'améliorations qui me parlent (la sémantique du move par exemple), d'autres où je saisis l'idée mais où j'ai du mal à rentrer dans les détails (les lambda, les constexpr) et d'autres où vraiment, c'est complètement au dessus de mon niveau de compréhension du langage.
On va avoir un débat sur le mot complexité vs quantité. On est au moins d'accord que la quantité de fonctionnalité augmente à chaque révision. Je maintiens que la complexité augmente aussi car il y a plus de façon de se tromper dans la façon d'écrire du code. Et il y a plus d'interactions possibles entre les nouvelles fonctionnalités.
[^] # Re: Expressivité
Posté par Philippe F (site web personnel) . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 3.
Il est courant en Python de ne pas s'embêter avec un gros formalisme quand ce n'est pas nécessaire.
La façon la plus simple de représenter une paire est d'utiliser un tuple de deux éléments. C'est une structure non-modifiable, donc ça correspond bien à la définition d'une paire.
Si on se retrouvait avec un programme manipulant des paires ayant des significations variées, on serait amené à utiliser une structure de plus haut niveau, genre un NamedTuple ou une DataClass qui permettrait d'accéder aux deux éléments de la paire avec un nom qui les représente, genre x/y ou first/second, ou encore firstName/lastName.
Genre :
d[k] = Point(x=v.y, y=v.x)
Mais bon, souvent, les structure de Python sont suffisamment élaborées pour pouvoir les utiliser longtemps en l'état.
[^] # Re: Expressivité
Posté par Philippe F (site web personnel) . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 1.
Ok, je saisis mieux. Après, je comprends toujours pas en quoi ça range le C++ dans la catégorie des langages expressifs, il reste pour moi associé à un trucs très complexe avec des erreurs très très absconses (genre tu oublies de mettre un espace entre deux > >, tu pleures). Mais je salue les progrès faits ces dernières années, même si je ne peux pas en tirer partie dans mon entreprise (cf mon autre commentaire).
Concernant l'expressivité, après être passé du BASIC/Assembleur au Pascal, puis au C, puis au C++, puis au Python (avec un détour par Caml Light), j'ai eu l'impression de progresser à chaque étape à pas de géant en terme de correspondance "ce que j'ai dans la tête" et "comment je l'exprime dans le langage". Avec Python, je ne ressens plus aucune limitation d'expressivité, et c'est probablement pour cela que ton commentaire ne résonne pas plus que cela en moi. Je reste cependant conditionné par le langage et je saisis bien qu'un programmeur familier des langages fonctionnels purs sera certainement très frustré par le manque d'expressivité de Python en la matière.
Il existe certes des structures plus complexes ou plus élaborées comme le pattern matching en OCaml mais je n'en ressens pas le manque. Avec les années, je ressens aussi l'importance de garder le code dans la catégorie du "moyennement complexe" afin de rester intelligible. Si j'écris du code qui va être partagé entre plusieurs développeurs, plusieurs équipes, qui va vivre pendant plusieurs années, je sais que je suis réticent à utiliser des constructions très puissantes du langage car je ne suis pas sur d'être lisibles pour mes collègues, ou même pour moi dans 10 ans.
Oui :-)
Tu y as mis du temps !
Aussi oui.
C'est surtout que ce que tu as écris est à l'exact opposé de mon ressenti sur ces deux langages. Je suis assez ébahi qu'on puisse avoir des expériences aussi éloignées. Sois tu as tort, sois …. il y a une autre explication (non, je n'ai pas tort :-) ).
C'est vrai que quand j'y pense, une grande partie de mes classes en C++ sont soit des "Plain Old Data" copiables par copie simple, soit des trucs plus complexes mais déjà gérés par la lib que j'utilises (Qt, boost, etc).
C'est juste que je me rappelle du gros warning que j'ai eu lors de l'apprentissage du langage sur les copies de classes.
[^] # Re: Expressivité
Posté par Philippe F (site web personnel) . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 3.
C'est quoi la définition de sérieux ? Si je prends mon entreprise, où on parle quand même de développeurs qui gagnent leur vie en écrivant du code … on peut penser qu'il s'agit de gens sérieux non ? Et pourtant, côté C++, on est loin du C++11. Je pense même pas que la plupart des mes collègues immédiats connaissent le sigle. Si je leur montre un bout de code avec des lambdas et des templates, ils ne comprendront juste rien. On fait de la carte programmation pour carte à puce, ce qui veut dire beaucoup de C, un peu d'assembleur, un peu de JavaCard, et un peu de Python pour nos tests.
Aujourd'hui un collègue développeur a vu mon écran et m'a demandé pourquoi je regardais un forum sur le jeu de Go. Il n'avait jamais entendu parlé du langage…
On utilise un peu de Python mais le seul qui est installé sur leurs postes, c'est Python 3.1 . Et je ne m'avance pas à utiliser des syntaxes avancées de Python (décorateurs, getter/setters, comprehensions, …) si je ne veux pas les perdre en route.
Je tiens donc à souligner la grande distance qu'il y a entre des passionnés qui suivent les évolutions de l'informatique et des entreprises qui restent avant tout consommatrices d'outils en l'état.
Côté Visual Studio, on utilise la version … 2011 Professional. Et je crois pas que C++11 soit bien supporté dans cette version. :-)
Il y a pas de refus de ma part. C'est juste que le C++, globalement, je ne l'utilise pas. Et je sais que c'est un langage complexe, dont la complexité ne fait que grandir au cours du temps.
Déjà, j'avais noté que le C++ de mon époque était plus complexe que ce que mon cerveau pouvait encaisser en une seule fois. Je sais que je ne me hasarderai pas à lever une exception en C++ sans relire un bouquin entier sur le sujet tellement il y a de façon de mal le faire.
Alors maintenant, de savoir que la complexité du langage a augmenté (ce que je vois quand je lis des exemples dans quelques journaux, je comprends juste rien), ça me motive pas vraiment à m'y mettre. Après, si j'avais un boulot qui l'exige, je me lancerai à fond dedans avec plaisir.
Paradoxalement, j'ai fait pas mal de Qt/C++. Et je bénis Trolltech/Nokia/Digia/Qt d'avoir rendu le C++ utilisable même par des gens peu experts en la matière.
[^] # Re: Expressivité
Posté par Philippe F (site web personnel) . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 2.
Tu pourrais être plus explicite ? Je ne vois pas en quoi le fait de favoriser "une façon évidente et si possible unique" de faire une tâche nuit à l'expressivité du langage. Au contraire, si il y une façon évidente et unique de faire une tâche, tout le monde va utiliser cette façon et l'intention du programmeur sera claire.
Cette règle a été écrite (à mon avis) en réaction à Perl qui a en effet le TMTOWTDI. Et côté Perl, je vois ça plus comme un constat qu'il existe mille et une façon de faire une tâche que comme quelque chose que le créateur de langage a volontairement instillé dans la conception.
Tu n'a pas réagi sur mon exemple pourtant ? C++, c'est pas le langage où quand on veut faire une classe copiable, il faut définir 4 méthodes différentes ? Mais pas de boiler-plate hein ?
Les constructions nouvelles du langage apportées dans C++11 et consorts sont certainement bien pratiques, mais dans les faits, elles sont très récentes dans l'histoire du langage (si on prend 1985 comme date de première visibilité, on est à 34 ans d'existence alors que le C++11 n'est là que depuis 8 ans). Elles restent encore peu connues, apportent leurs propres problèmes de lisibilité et de compréhension. Côté lisibilité, on repassera. Ça ajoute en plus énormément à la complexité du langage.
[^] # Re: Expressivité
Posté par Philippe F (site web personnel) . En réponse au journal Les 7 étapes pour devenir un programmeur Go.. Évalué à 5.
J'ai du mal à voir C++ et expressivité dans la même phrase, et Python dans la catégorie "inexpressivité". Pour le reste du commentaire, je suis plutôt d'accord.
J'exprime mon désaccord sur les deux points:
Python est au contraire un langage très expressif, le programmeur peut manifester son intention en très peu de lignes de code. Le boiler-plate code en Python est quasiment inexistant.
A l'opposé, à chaque fois que j'utilise la STL en C++, mes yeux pleurent, je me dis que 120 colonnes pour une ligne, c'est bien peu quand tu veux manipuler une structure un tant soit peu élaborée.
Allez, au hasard, parcourons une map/un dict de string vers des paires de string en Python et en C++ et inversons les paires:
En Python:
En C++:
En terme d'expressivité et lisibilité, je trouve que la version Python s'en sort beaucoup beaucoup mieux.
Et encore, il aurait été de bon ton d'expliciter l'instanciation de make_pair<> .
Alors, certes, en C++11, on peut faire plus compact en utilisant des auto et surement avec d'autres trucs (lambda ? foreach ?). Mais tout le monde ne les connait pas.
On peut aussi faire bien plus compact en Python mais on tombe sur le même problème: la syntaxe des Python compréhensions est peu connue (par exemple, aucun de mes collègues de travail ne connait):
d = { k:(v[1],v[0]) for k,v in d.items()}