El Titi a écrit 3953 commentaires

Pour l'exploiter réellement il faudrait investir des sommes délirantes pour que la moindre trace de vent ou de soleil

Tu veux dire celles que les lobbys de nos fleurons industriels réclament pour la recherche sans plus d'assurance d'aboutir ?

En plus on peut leur faire confiance, ils nous ont déjà maintes fois prouvé qu'on pouvait leur faire confiance.

Oui pis avec tous les "progrès" qui seront fait d'ici-là ça sera amusant de voir fleurir des petits Tchérnobyl comme on monterait une boulangerie c'est sûr.

• Mééé, tais-toi espèce de lobotomisé irrationnel terminé à la Verte Pisse

Non mais ça peut se faire d'ici 2050. Ce n'est pas plus fou que de croire qu'on peut planter assez d'éoliennes et de p

C'est vrai que si on n'y met pas le nerf de la guerre, l'investissement ça ne va pas progresser et ça ne progresse pa du tout d'ailleurs.
Sortir l'argument inverse (on progresse) pour projeter l'avenir du nucléaire au delà de 50 ans est juste fallacieux.

La réalité, c'est que ce plan national qui se rapproche de plus en plus d'un fiasco industriel pour notre denier public me rappelle un phénomène de psychologie sociale bien connu:
"On a tellement misé dessus qu'il faudrait remettre au pot."

Ca a un nom:
https://fr.wikipedia.org/wiki/Engagement_(psychologie_sociale)

Note pour moi-même:
Relire "le petit traité de manipulation à l'usage des honnête gens", cette perle

Le renouvelable c'est bien mais c'est intermittent et nécessite de gros investissements à cause de la faible densité énergétique. Cela impose d'investir dans du stockage qui est coûteux, polluant et qui a besoin d'espace. Et la technologie ne passe pas encore au niveau industriel (batterie, hydrogène ou Power to Gas).

Ah mais le nucléaire ne coûte presque rien en fait ?
Voilà, on a compris.
L'enjeu de société, c'est à qui on va filer nos impôts au final.

Le reste, le climat, l'hypothèse accessoire d'une planète inhabitable pour quelques autres raisons qu'on ne peut pas écarter si la solution nucléaire se généralisait (sans compter la tension sur les ressources, la FrancAfrique et autres sujets, géopolitiques et sociétaux) tout le monde s'en carre.

deux catastrophes qui ont plus de 30 ans
2011 c"était y'a 30 ans ?

On ne me dit jamais rien à moi.
C'est sûr qu'on a dû faire des progrès fulgurants depuis surtout en terme de savoir-faire d'ailleurs.

Y'a qu'à voir pour l'EPR par exemple.

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!