El Titi a écrit 3948 commentaires

Le projet va être développé en Elixir, un langage dynamique.
https://framagit.org/framasoft/mobilizon/

Fais gaffe quand même !

J'ai jeté un coup d'oeil et y'a quand même un sacré taf.

Apparement, tu te lances sur un portage de JSP vers du REST + Angular, c'est bien ça ?
https://github.com/airsonic/airsonic-ui
C'est plutôt ambitieux mais prometteur.

Pour le coup, tu n'aurais pas meilleur temps de repartir d'une branche dédiée pour y voir plus clair, en mettant en place des tests en épingle au niveau de l'API ?
Tiens, ça me permet de faire un peu de pub pour ce projet génial:
https://github.com/intuit/karate

Je te souhaite le meilleur pour la suite car l'original (Subsonic) que je viens de découvrir est déjà cool.

Ca c'est du structural typing, non ? J'avoue que la syntaxe est tellement absconse que je pige pas tout le bout de code.

https://en.wikipedia.org/wiki/Duck_typing

Duck typing is similar to, but distinct from structural typing. Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time.

The OCaml, Scala, Go, Elm,[4], Gosu and PureScript languages support structural typing to varying degrees.

Comme je pige pas tout, tu dois tout de même "statiquement" associer ce sous-ensemble de méthodes si je saisis bien.

Je conviens cependant que c'est déjà plus intéressant (et peut-être suffisant, à creuser) que ce que propose les langages OO statiquement typés mainstream. Java, C# et C++ par exemple. C'est drôlement handicapant.
Un peu moins de verbosité, de lisibilité et on y est peut-être. Je vois que Scala est dans la liste. Je vais peut-être l'explorer du coup.

Question naïve (pas de piège):
Pourquoi OCaml reste si confidentiel s'il est si génial ?

Python s'en sort aussi très bien, en particulier avec les apports des modes asynchrones des dernières versions.

Sans compter les green threads (Gevent) qui avec un petit monkeypatch et 2 lignes de code te transforment un code séquentiel en asynchrone gratis.
Même pas besoin de te lancer dans un gros refactoring pour tout passer en asynchrone explicite.

Au risque de me répéter :) A partir du moment où tu fais du duck typing, même en statique, tu n'as plus de contrôle de type.
Il n'y a plus de hiérarchie de types. Donc plus de vérification à la compilation… ce qui rend le typage statique caduque pour ce cas, alourdit le code et permet difficilement de concilier les 2 approches.

Ce n'est pas pour rien que Go ne supporte que le duck typing, en s'appuyant sur une forme de composition sans le moindre héritage d'implémentation.
Avec Python, on concilie le duck typing avec l'héritage multiple, ce qui d'ailleurs permet de se passer de la généricité.

Par contre, j'attends l'exemple dans un langage statiquement typé orienté objet (donc pas le Go) qui permet de se passer de l'héritage du type racine et du casting à posteriori.
Un truc quasi-quotidien dans les langages dynamiques.

Autres classiques:

1- Je veux des conteneurs de n'importe quel type que je veux pouvoir manipuler en duck typing.

l=list([1, "a", {"dudulle":"schmoll"}])

Pas d'héritage à la con d'Object avec re-cast (qui ne garantissent rien à la compil du coup), pas d'interface à rajouter à toutes les classes, pas de templating. Bref moins de code pour le prototypage.

J'utilise un itérateur pour optimiser la mémoire,… quand je le décide et je réfléchis à une solution plus blindée… quand c'est nécéssaire (Lean).

Voilà: 2 lignes vs 200 lignes de code imbitables

2- Méta-programmation: Je construis des nouveaux/les types/classes à la volée pour être manipulées par duck typing
Le typage statique n'apporte rien au niveau qualité … à part du boilerplate code
…

Ce qu'apporte le typage dynamique ?
L'expressivité, la souplesse et la productivité.

Ce qu'il enlève ?
Lire les autres commentaires

Voilà pourquoi on a besoin des 2 !

https://stackoverflow.com/questions/306313/is-operator-behaves-unexpectedly-with-integers

Des petits plagiaires se cachent dans les recoins ;-)

Et l'explication détaillée de ce cas est dans le lien que j'ai envoyé plus tôt (Valeurs par défaut et référence)

Je reprends la recommandation;

Bref, évitez les mutables dans les paramètres par défaut à moins de savoir ce que vous faites (cache ou memoization).

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.