El Titi a écrit 3940 commentaires

J'ai reproduit ton nouveau cas:

def plop(a=3):
… a+=1
… print(a)
…
plop()
4
plop()
4

Effectivement, comme les arguments sont mis sur la pile,
dans le cas d'un type primitif, on place la valeur mais dans le cas d'un itérable, une référence j'imagine. Ce qui en soit fait sens (une liste de 10000 int sur la pile, ça fait mal)

Bref, certains langages font le choix de rendre le mode de passage de paramètre (valeur/ref) le plus implicite possible avec parfois des comportements moins prédictibles et d'autres le rendent explicite au prix de la lisibilité et d'une complexité accrue.

Tiens mois aussi j'ai envie de jouer:

package main

import (
"fmt"
)

func main() {
a := []int{1,2,3}
slice1 := a[:2]
slice2 := a[:2]
slice2 = append(slice2,4) // first append
slice2[0] = 8 // underlying array still the same, both slice 1 and slice 2 have element 0 == 8
fmt.Println("slice 1:", slice1) // slice 1: [8 2]
fmt.Println("slice 2:", slice2) // slice 2: [8 2 4]
slice2 = append(slice2,4) // array capacity now exceeded, new underlying array created
slice2[0] = 3 // slice1 still has element 0 == 8, but slice 2 has element 0 == 3
fmt.Println("slice 1:", slice1) // slice 1: [8 2]
fmt.Println("slice 2:", slice2) // slice 2: [3 2 4 4]
}

>>> plop
<function plop at 0x004F6270>

>>> dir(plop)
['__annotations__', '__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format
__', '__ge__', '__get__', '__getattribute__', '__globals__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__kwdefaults__', '__le__', '__lt__', '_
_module__', '__name__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclassh
ook__']

>>> plop.__defaults__
([],)

Tadaaaa !!!

KISS

Si on refait l'exemple avec un entier, e.g. plop(a=3), on a les même contrainte que tu donnes et pourtant un comportement différent. Donc véritablement tu te fais avoir par ta propre explication.

a.append(3) ?

A mon avis, tu chopes simplement une erreur puisqu'un int n'est pas une liste, mais je creuserai à tête reposée quand même pour voir ce qu'il en est. Je ne connais pas non plus le modèle par coeur mais c'est quand même assez simple de l'explorer avec le REPL

Non puisqu'il est dans la même portée et que le nom "a" est dans le même dictionnaire de variables de la fonction définie, pourquoi ?

Au contraire, les langages interprétés décuplent le potentiel de méta-programmation et le modèle sur lequel s'appuie python est super simple et bien fichu.

Pour te dire, je n'avais sincèrement pas pensé que ce point précis était votre questionnement.

Par contre, j'ai bien noté qui ici fait du python bashing intensif et je crois que je vais nous concocter une petite réponse gratinée à propos de son petit jouet.

Ce n’est clairement pas évident pour quelqu’un qui ne maîtrise pas le langage. Note que cette remarque peut-être valable sur d’autre langage, je pense notamment au Java.

C'est ça. Moi depuis 15 ans que je ne fais plus de C ou de … Go mais du Python et du Java, ce qui me choque c'est de devoir encore penser à ce que je veux comme type de passage de paramètre et être obligé de faire une gymnastique intellectuelle incessante pour penser à des indirections, voire jouer avec l'arithmétique des pointeurs.

Allez Dr Sam à la rescousse:
http://sametmax.com/valeurs-et-references-en-python/

Quelle est ta surprise exactement ?
Le passage de paramètres par référence ?

Le fait qu'une liste soit mutable ou c'est parce que t'es nostalgique des pointeurs et des références.

J'aurais plutôt pensé à de la programmation pas contrat comme le proposait Eiffel pour ma part:
https://www.eiffel.com/values/design-by-contract/introduction/

Ou alors je n'ai pas bien compris.

Quand est-ce qu'on invente le point Lénine ?

S'il y a bien un domaine où Rust a ses chances pourtant, c'est bien là.
Quasi aussi performant que le C/C++, multi-paradigme (le fonctionnel n'est pas juste une Rust-ine), bien plus expressif , toute une batterie de garde-fou contre le bloat code …

Déjà,
Vous partez d'axiomes différents.

Tu veux un exe mais on poses comme préambule qu'in tu veux du python avec des libs implémentées dans un autre langages et donc fortement liées à l'OS

Je vais pas être désagréable et rappeler comme il est simple d'utiliser toute la batterie des outils C/C++ de cross-compiling pour rire. Je t'invite à lire la liste à la Prévert de l'auteur du journal

Python est un langage interprété tout comme java a besoin de son runtime.
Que ça ne te plaise pas, soit!
Mais si tu fais du pur python c'est pas le bout du monde de faire un pip install (en plus tu peux virtualiser tes envs) ou pondre une exe. Au besoin il est capable de choper des libs natives tout comme un apt-get dis-donc.
De la part de linuxiens qui ont toujours bavé sur les exe windows et autres .dmg, ça me fait légèrement sourire comme argument.

C'est sûr avec du Go par exemple, on se retrouve avec 1 binaire. Je sais pas ce qu'il en est de l'édition dynamique, mais ça n'était visiblement pas la priorité il y a quelques temps et pour la portabilité tu repasseras (J'ai qu'à utiliser Docker, c'est ça ?)
https://medium.com/learning-the-go-programming-language/writing-modular-go-programs-with-plugins-ec46381ee1a9

C'est peut être pas un hasard que ça ne perce que sur les micro-service du coup.
Par contre, je le vois pas trop décoller dans tous les domaines où l'expressivité prime bizarrement (les data science par exemple) et coté Devops python est toujours devant on dirait.

Bref ça correspond pas à ton besoin très bien. En 2019 le dev qui n'a qu'un marteau pour enfoncer des vis ne va pas très loin mais surtout te fatigue pas à "lire des docs". Les autres le font à ta place.

Pour rétablir cette injustice criante je te propose de vider l'ensemble de tes comptes épargne vers un RIB que je t'envoie sous peu.

Je complète car tu sembles avoir oublié un morceau.

Pour rétablir cette injustice criante je te propose de ponctionner quelques-uns de tes comptes épargne vers un RIB que je t'envoie sous peu…une fois que tu auras passé l'arme à gauche.

Tu manies la rhétorique de l'homme de paille à la perfection. Bravo!

Une société juste aussi, c'est aussi reconnaître les efforts que fait quelqu’un qui cherche à créer de la richesse par rapport au type qui passe ses journées au PMU.

C'est ta description du rentier qui boursicote ?
Pas bien!

Je l'ai bien saisi. J'ai d'ailleurs mis un bémol. Juste que la formulation était ambigüe et l'idée reprise par d'autres.
Accessoirement, c'était aussi un prétexte pour placer ma tirade ;-)

ais bon, trouver honteux que certains n'aient pas besoin de bosser, c'est un peu comme se plaindre que des beaux gosses n'aient pas de truquer leur compte Tinder avec de belles photos. C'est un luxe qu'ils ont, tant mieux pour eux, mais ça n'a strictement rien à voir avec l'égalité des chances.

Il y a quelques léger biais dans ton raisonnement.

1- Déjà, il faut dissocier le fait de trouver ça "normal", du fait de vouloir "redistribuer" un peu les cartes. (piège grossier dans lequel certains tombent hélas)

2- Si j'éborgne un beau gosse, je touche à son intégrité physique. Si je prélève au même gosse un peu de fric, avant même qu'il n'en soit propriétaire, je ne lui enlève rien puisqu'il ne le possède pas encore et encore moins je n'atteins son intégrité physique.

Il n'y a que les libéraux pour ériger la propriété privée comme droit suprême.

Au point même d'inventer des nouvelles formes de propriétés complètement virtuelles pour coller à leur modèle de laboratoire: Par exemple leur solution pour régler le problème du réchauffement climatique, quand ils ne s'évertuent pas à simplement nier qu'une de ses causes est d'origine anthropique ou à minimiser son effet. "L'ecologie, c'est la dernière lubie des "socialistes".
Là aucune gêne à monter artifices (si j'osais, des"usines à gaz") pour régler le pb, alors que les mêmes dénoncent les inepties liées aux systèmes de prélèvements.
L'argument est symétrique. Qu'ils n'objectent pas les droits "naturels" (dans lesquels la propriété ne s'inclue pas) contre les prélèvements alors qu'ils y opposent des droits propriétés tout aussi artificiels. Mais on a bien compris que cette vision ne profite pas aux mêmes et accroît les déséquilibres (Je prends soins d'éviter d'écrire le mot tabou "inégalité").
Le monde est plus complexe qu'un modèle économique bancal dans un univers restreint qui voudrait voler au secours d'une idéologie. L'économie n'a rien d'une science.

Moi je trouve étonnant que sur Linuxfr, on trouve encore des gens :)
https://linuxfr.org/users/minimock/journaux/dlfp-is-dying-6269f7fe-4e79-4aa7-ae37-d5080ff80d10

=> []

Je vais profiter de ton commentaire pour rebondir sur celui-ci quelques autres ainsi que sur une remarque de l'auteur :)

donner des clef sur comment se débrouiller sans documentation

Même si tu donnes quelques éléments pour étayer, on peut pas laisser passer çà :)

L'agilité n'a jamais prétendu qu'il fallait se "passer" de la documentation, bien au contraire.
Le principe, comme pour le reste, est de faire ce qui est suffisant au bon moment çar le changement peut, enfin non, va, arriver. Tout comme on n'se fait pas plaisir avec une archi géniale qui servira jamais (overdesign) et qu'on fait "juste ce qu'il faut".

En effet, une carte sur un Trello n'a jamais constitué une spécification pour moi. A la limite, si le manager/client avait su étoffer ces cartes

Voilà, ca tombe bien, pour l'agilité non plus. Si tu as des contraintes réglementaires, on ne va pas te dissuader d'en faire.
Une US c'est juste morceau de fonctionnalité dont on peut mesurer la valeur ajoutée et qu'on peut livrer à temps pour plaire à celui qui paye, le métier. Point barre
Qu'on en fasse une unité de tâche n'empêche pas qu'on puisse la découper en sous-tâches ou même qu'on la retravaille.
https://www.youtube.com/watch?v=rP9AlpFwvSM

A mon avis c'est comme ça pour plus de la moitié des boites qui disent être agiles : pour elles lorsqu'elles ontpassé le délai de mise à disposition d'une nouvelle appli de 6 mois à 4 mis, elles peuvent se prétendre agile.

Petit "test":
- On est super agile, on a des sprints de 2 semaines
- Vous avez des tests ?
- Bin non tu rigoles avec le pressing de l'AMO , on n'a pas le temps
- J'ai une bonne nouvelle comme vous êtes agile, on va se lancer dans un petit refactoring des familles, parce que là ça pue le syndrome du copier-coller
- OMG!

Nous l’avons peut-être déjà tous constaté, l’utilisateur final ne sait pas vraiment ce qu’il veut, et a beaucoup de difficulté à exprimer clairement par écrit ses attentes.
Un intermédiaire (MOA, MOE, BA, PO, Archi) est nécessaire pour lui permettre de prendre du recul
et pour traduire une demande fonctionnelle en exigence technique.
Mais l’intermédiaire rajoute une couche intermédiaire !
C’est humain, l’intermédiaire aura tendance à se rendre indispensable.

Allez, on reprend les bases: le manoifesto
Working software withoutover comprehensive documentation
Customer collaboration over contract negotiation

Voilà, on privilégie ce qui marche plutôt que la paperasse inutile: un doc de spec de 500 pages que l'AMO n'ose pas tamponner de peur de s'être planté ou à balancer parce que le business a déjà changé. Un modèle UML aux petits oignons que le métier pige pas et qui sera complètement obsolète au moment de la livraison.

Si documentation il y a, il faut qu'elle reflète l'état du projet à l'instant t, bref qu'elle soit "vivante" ET qu'elle serve. Quoi de mieux qu'un exemple élaboré avec toutes les parties prenantes pour être sûr qu'on a tous pigé le même truc sans "intermédiaire". S'autoriser à challenger le PO sur cette base pour être sûr qu'il sait ce qu'il veut ou lui montrer que ça tient pas debout.

Allez un petit rituel pour bien s'accorder sur les règles métier avant de valider que la US est "Ready" et s'assurer qu'on va pas (moins) se planter sur le planning (la "cistomer collaboration"):
https://www.youtube.com/watch?v=gID0boETxJQ
https://cucumber.io/blog/example-mapping-introduction/

Le PO/AMO est pas jouasse ? Et bin on se protège:
https://www.youtube.com/watch?v=C9XoZQdnKbA&list=PLxTb_ZC4kmrSBKSyz3N4rtYjdE7EaI0Uu

Et comment qu'on fait pour s'assurer que ces règles sont bien respectées ?
Et bin on les teste (non la vocation du BDD Bevaviour Driven Design n'est pas le test mais bien piger ce que veut le client), on les rend "executables". La voilà la living documentation:
https://www.youtube.com/watch?v=p1Tl8kfkjGM

Et ca veut pas dire qu'il faut "tout" tester en Cucumber et écrire des tests d'IHM en Ghekin, hein

Allez, on pousse encore un peu le truc avec l'archi. Un peu de sketch modeling pour le début du sprint (ton exemple est quand même très orienté EDA ca correspond pas à tout les projets)

Et puis pour le newbie, quoi de mieux que de lire les TUs pour se mettre dans le code ? En voilà une autre de belle "living documentation" à base d'exemples pour peu qu'on soigne un peu le présentation (Clean code, domain driven). Oui on soigne ses tests et on les refactore avec le même soin que le code.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Le "Done Done", c'est pas pour la déco, …

Voilà le truc, c'est de faire du bottom-up et plus du top-down (on oublie le MDA)

Ca tombe bien, un petit français nous a fait un super talk dessus:
https://www.youtube.com/watch?v=Tw-wcps7WqU&list=PLTbQvx84FrAS5clN9i8_LFUQxcMY7qXAO&index=118

et a même pondu un bouquin au financement libre:
https://leanpub.com/livingdocumentation
A consommer sans modération, avec par exemple comment rétrogénerer de la doc d'archi avec un bon framework des famille et quelques annotations, DDD, Documenation by convention, …
Une mine d'or.

Alors c'est sûr la 1ere fois si on fait l'impasse sur tout ça, l'AMO, le PO, il s'habitue: "Vous avez pulsé , les gars!" et on ne pourra pas revenir dessus. Les bugs tombent, la dette technique s'accumule on fait l'impasse sur la doc en crachant sur la méthode et l'agilité Ultime et Universelle se met en place aka:
http://www.la-rache.com/

Déjà il faut voir les usages. Il n'est pas toujours nécessaire d'avoir des dépendances sur du code natif pour bon nombre de projet et le cas échéant ces libs sont plutôt bien empaquetées (par exemple dans le Big Data, PySpark…).

On ne parle pas forcément de livrer un exe.
Tu peux vouloir déployer sur un serveur Web, dans un cluster K8S ou simplement un script.

Ce ne sont pas forcément les même usages.

Mais ce n'est pas ce que l'auteur voulait exprimer je pense. Il voulait peut-être juste signifier que l'expressivité du langage le rend autrement plus productif et permet donc de livre des incréments plus souvent. Avant la réplique, je n'ai pas dit qu'il était plus performant.

Ayant quitté le monde C++ depuis Mathusalem, je serais intéressé de comprendre ce "monde" qui sépare les différentes moutures du C++.
Quelques pistes à m'indiquer ?

Certains te l'ont déjà évoqué mais la principale motivation pour passer au C++ est le support du paradigme objet.

De base le C n'est qu'un langage procédural. Lorsque tu programmes dans certains domaines l'approche objet est assez "naturelle".
Même si c'est théoriquement possible avec le C tu te retrouves très vite limité par le langage. Si tu es intéressé cet ouvrage est fait pour toi: https://www.cs.rit.edu/~ats/books/ooc.pdf)

Simuler un héritage rudimentaire et le polymorphisme à base de "cast" est à peu près tout ce que tu peux atteindre, simplement.

Au delà tu réinventes tellement de truc qu'il vaut mieux se poser la question de savoir s'il ne faut pas passer à autre chose. C'est la vocation de C++ et d'ObjectiveC

Avec le C++ tu auras automatiquement:
* la redéfinition des méthodes, statiques ou virtuelles (bon courage avec les pointeurs de fonction dans tes structures en C)
* l'héritage multiple
* La généricité qui te permet d'instancier de nouveaux types abstraits
* la surcharge des opérateurs ainsi que de nouveaux (>>)
…

Il y aussi tous les frameworks autours qui peuvent te faciliter la vie (ramasse-miette, …)

Tu as une belle base de comparaison aujourd'hui avec les 2 toolkits graphiques mainstream sur Linux: GTK ecrit en C prouve que c'est possible. Qt a fait le choix de s'appuyer sur le C++ et déborde largement le cadre de l'interface graphique aujourd'hui.

C'est donc à toi d'évaluer ton besoin sachant que ça peut-être superflu. Par exemple le multi-héritage a aussi ses inconvénients et on peut s'en passer simplement avec la notion d'interfaces. Java est là pour en attester. (Et je n'aborde pas les design pattern, composition vs héritage, …)
De même l'approche objet ne résout pas tout. Aujourd'hui, le paradigme fonctionnel revient en force et on s'appuie aussi beaucoup sur la programmation par aspect pour compléter l'approche objet de manière orthogonale (Spring AOP en java, …).

En revanche si tu n'appréhendes pas la programmation objet et que tu veux comprendre, je ne suis pas certain que le C++ soit le langage le plus adapté étant donné sa complexité. GTK est peut-être un 1er point d'entrée pour ça.

Mais il vaut peut-être mieux aussi commencer par des langages plus simple et plus productifs (l'auteur m'en est témoin) comme le Ruby (pur objet) et le python (qui prend quelques libertés avec le duck typing par exemple) et qui offrent en plus l'avantage d'être multi-paradigme et moins contraignants au début de par leur typage dynamique .

A partir de là, peut-être que l'abord du C++ sera moins rugueux.

Tout à fait d'accord. Et tu la finances comment cette belle égalité des chances (encore que ça se discute) si tu ne prélèves pas là où c'est le moins douloureux ?
On est loin du taux confiscatoire que tu dénonces avec le prélèvement sur les successions et d'autres ici t'ont montré que tu avais déjà une belle marge de manoeuvre en donnant de ton vivant (Souvent là où c'est le plus utile, quand les enfants démarrent dans la vie).

Mais évidemment tu repars dans la caricature.
On est loin de "freiner" ou alors tout prélèvement est un frein (rhétorique libérale). On est dans le subjectif.

On va s'arrêter là pour ma part. Les points de vue se figent et les arguments tournent en boucle.
Merci pour ta participation (parfois virulente) qui apporte au débat toutefois.

Mais c'est quoi le problème d'enfant rentier ? Qu'est ce que cela peut bien te faire que quelqu'un vive sans travailler grâce à ses parents ?

Tu sais: la compétition, l'égalité … des chances qui font que l'argent ne va pas qu'à l'argent (les crédits faciles, …)
Toutes ces choses qui ne visent pas à punir mais à stimuler l'innovation, le mérite, car on sait que l'égalité des "capacités" est une chimère.

Tout le contraire de cet argumentaire (jaloux, frustré, assistanat…) que l'on ressert ad-nauseum dans certaines franges électorales.

Mais le job de l'état n'a jamais été de sauver les cons.

Qui a prétendu le contraire ?

Trump aurait reçu un million ou autre somme significative de ses parents, le reste serait allé à l'état.

Trump aurait peut-être être tout raté et fini fauché, il serait au chômage ou autre comme d'autres. L'argent imposé à la mort de ses parents aurait payé son minimum vital et son chômage.

Voilà, Ca tombe bien, le système français fait exactement ça.

Par contre ton argumentaire, que j'ai juste développé à l'extrême: "je fais ce que je veux avec ma "propriété". Pas touche!

C'est typiquement, celui des libéraux (au sens français du terme). Tu ne fais qu'apporter de l'eau à leur moulin avec ce même raisonnement. Tu as le droit d'avoir cette position, mais assume. Ce n'est pas du socialisme. Et ta manière d'amalgamer socialisme et communisme me laisse à penser que tu te rapproches plus de leur position que le contraire. Don't Act!

Moi frustré ?

Qui est-ce qui se plaint du système de prélèvement obligatoire français à grand renfort de tournures indignées ici ?

mais de s'assurer qu'ils ne tomberont jamais dans la pauvreté.

Je continue avec l'exemple de Trump pour te montrer comme ton raisonnement est foireux.
Dans son cas, avec un tel degré de crétinisme, on aurait explosé tes critères. Heureusement que papa était multi-milliardaire sinon il serait "tombé dans la pauvreté".

Donc si ça ne ne suffit pas pour lui, il faut encore rabaisser le plafond d'imposition, à 0% ?

A ce niveau là, on peut se demander s'il n'est pas tout simplement nuisible pour ses congénères et, avec la 3e guerre larvée qu'il nous prépare (le piège de Thucydide), y'en a d'autres qui vont bientôt passer pour des enfants de choeur.
A croire que "Dead Zone" était une prophétie.

La réalité est que si on taxait de sorte qu'il soit très dur d'être milliardaires ou millionnaire en centaines de millions il y aurait largement de quoi aider toute la population tout en permettant a certains d'être aisé.

C'est ça et chez les Bisounours, on pourrait pas se barrer où l'herbe est plus verte comme notre idole nationale.

Alors comme çeux-là (Comme chacun sait, l'altruisme est la valeur fondamentale chez l'Homme) se barrent et ben faut bien se rabattre sur ceux qui restent. Oh ben merde alors, c'est I-NI-QUE qui disait. Rassure-toi en France aussi on ne ponctionne pas tout.
Et le fils à papa peut encore dilapider sa fortune.
Faut dire que Trump est la + belle illustration qu'il faut pas les laisser faire: https://www.franceinter.fr/monde/usa-2016-les-faillites-de-trump