Guillaum a écrit 472 commentaires

À une époque lointaine, je travaillais à (20-25) minutes de métro/tramway de chez moi. Porte à porte, la variation étant liée à l'attente du tramway à la correspondance. Beaucoup de mes collègues ne comprenaient pas que je ne déménage pas pour trouver un logement plus proche. Donc à Lyon, pour une certaine tranche de population, plus de 20 minutes / prendre les transport en commun est considéré comme long.

Maintenant je travaille à la maison (toujours de Lyon), mais il m'arrive des fois de prendre le train pour aller à Paris pour voir certains de mes collègues (un "hub" de ma boite est à la gare de Lyon). Je met 2h15 portes à porte en comptant le métro à Lyon. Mais sur ces 2h15, j'ai 2h où je travail bien tranquillement dans le TGV. De façon amusante cela ne viendrait à l'idée de personne que je vienne tous les jours au hub de Paris, alors que certains de mes collègues parisien font 1h45 de RER tous les jours pour venir, ce qui me semble largement moins confortable que mes 2h de TGV au calme, avec du wifi et du confort pour travailler.

Tu peux aussi citer ma version qui est vachement mieux: https://linuxfr.org/users/guillaum/journaux/taptempo-en-brainfuck

Moué, c'est pas impressionnant tant que c'est pas en brainfuck.

Changer de modèle tous les ans avec cette gamme d'ordinateur portable, c'est du luxe ! Je n'en connais pas beaucoup qui ont ce privilège…

Oui, enfin j’espère que ton employeur te fourni un nouveau PC quand le précédant n'est plus en état de fonctionner. En gros, me concernant, c'était un nouveau dev de chez nous qui voulait un 2017 (car il a des ports USB type B), alors j'ai échangé le mien contre un 2018 avec plaisir.

Après on parle d'un PC à 1500 euros. C'est entre 2 jours et une demi journée de consulting. Ce n'est pas le genre de décisions que je prend, mais si j'avais a les prendre, je dirais que si mon consultant à 1500 euros la journée a besoin d'un nouveau PC à 1500 euros pour gagner 2h d'autonomie, 20% de performance et doubler sa RAM, ce qui au final va lui faire gagner plusieurs minutes par jour, je paye tout de suite.

Actuellement, je teste Clear Linux qui a aussi une gestion de package atypique. (il n'y a pas grand chose dans /etc et c'est déroutant)

Sous nixos, c'est /usr/bin qui est vide ;). /etc contient des liens symboliques vers la configuration courante.

C'est typiquement le genre de chose que fait très bien NixOS: https://nixos.org/

Toute la configuration de ton système est décrite dans un (ou plusieurs) fichier de conf qu'il est facile de versionner. Il n'y a pas "d'étapes" lors de l'installation, ou de configuration à modifier, ton système est une unique configuration qui va être déployée de façon atomique.

À titre d'exemple, au travail nous utilisons des dell XPS 13. J'avais un modèle de 2017 qui m'a été changé vers un modèle de 2018. Lancement du live cd, copie de ma configuration, j'ai juste adapté une ligne ou deux pour prendre en compte la densité de l'écran qui n'est pas la même. nixos-install et quelques minutes plus tard, j'avais exactement ma configuration déployée, avec ma configuration d'emacs, mon .gitrc, mes comptes utilisateurs, mes images docker pre-chargés, mon installation de wine pour jouer à Diablo. Mes paramètres de configuration GTK sont aussi décrits (avec https://github.com/rycee/home-manager)

NixOS vient avec quelques autres avantages, comme nix prè-installé, la possibilité de booter sur une ancienne configuration (i.e. toutes les configuration précédentes sont sauvegardés). Dans le rare cas ou une mise à jour se passe mal (jamais arrivé en 2 ans), tu peux reprendre la dernière version et continuer à travailler.

Home-manager peut être utilisé sans NixOS pour seulement décrire son environnement personnel, c'est à dire toutes les applications installée pour un utilisateur particulier, ses services personnel (systemd --user) et la configuration de toutes ses applications.

Quelques contraintes pour NixOS, c'est une distribution linux différente, ce n'est donc pas la solution si vous devez absolument conserver un environnement debian ou autre. NixOS est aussi très strict sur la reproductibilité et n'expose dans l’environnement par défaut pour ainsi dire rien. Ainsi un binaire pré-compilé chargé sur NixOS a de grande chance de ne pas fonctionner. Je vois cela comme un avantage (i.e. cela force la reproducibilité), et en pratique c'est très rare que nixpkgs (i.e. la base de paquet de nix, donc NixOS) n'ai pas le paquet demandé.

Le auto n'est que de l'inférence de type. Pour le "dynamique" que tu cites, je ne vois pas de quoi tu parles.

C'est un autre probléme ;) Mais je suis d'accord avec toi.

Je me rappel lisant avec intérêt la spec sur le modèle mémoire. Avoir l'impression de comprendre quelque chose, implémenter, utiliser des contraintes relachée pour "plus de performance", être satisfait du résultat et me prendre une claque dans les dents 3 mois plus tard.

Surtout que on a la mauvaise tendance à implémenter / expérimenter sur x86_64 qui a nativement un modèle de mémoire différent d'arm et que certaines suppositions sur l'un ne sont pas valables sur l'autre.

Bref, ce truc c'est complexe.

Ce qui me choque c'est que l'égalité de référence, qui est un truc à la con utilisée seulement dans des cas particuliers, soit si facile d'accès et ai même son propre mot clé pour.

Le plus drôle c'est que cela casse des possibilité d'optimisation intéressantes. Par exemple, la notion de référence, souvent associée au pointeur en mémoire, n'a plus beaucoup de sens quand ton objet n'est pas "en mémoire", si il n'existe que dans un registre par exemple. Ou si ton objet change de place en mémoire dans le cours de sa vie.

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).

Pour le coup nous on fait du Haskell pour ce type de problématique. Le Haskell génère du C, mais avec des garanties et plus de généricité.

Ceci étant dis, je suis tout à fait d'accord avec toi sur le point performance de Python. C'est très souvent surfait et bien souvent Python est suffisamment performant pour beaucoup de cas.

99% d'accord avec toi. Le % qui manque c'est parce que C11 apporte, il me semble, le support du multi-threading. (i.e. une sémantique pour le modèle de concurrence).

Le typage statique étant un sur-ensemble du typage dynamique les langages statiques n'ont rien besoin de faire ;)

d'autant plus que les discussions qui en ont suivi ont été très intéressantes

Tu parles du troll vieux comme le monde sur le typage statique versus dynamique ? Alors que tous le monde sait pertinemment quelle est la meilleure solution.

Voilà pourquoi on a besoin des 2 !

Oui ! Mon interrogation dans ce débat c'est de savoir si il est mieux d'avoir un typage statique par défaut avec du dynamique optionnel, ou l'inverse.

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

Et tu fais souvent cela ? Je vois cet exemple tous le temps, mais qui fait vraiment ça ?

Je construis des nouveaux/les types/classes à la volée pour être manipulées par duck typing

Je veux bien un exemple aussi.

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.

Si. A un moment, tu vas utiliser ton objet et tu va vouloir une interface "commune", sinon tu ne peux rien faire.

Si j'ai une liste python [True, "hello", 10, [1,2,3]], c'est très bien, mais je peux faire quoi avec? Seulement des choses commune à tous ces types, comme, dans ce cas, les convertir avec str:

for i in [True, "hello", 10, [1,2,3]]:
   print(str(i))

A partir de ce moment là tu as donc une définition de type qui, en Haskell par exemple, serait un Show t => t, ou dit autrement: n'importe quel type t qui respecte la contrainte Show.

C'est en effet un exemple intéressant !

Si tu veux un proxy parfait qui prend n'importe quel objet et remplace toutes les méthodes par une méthode wrappée qui ajoute du comportement, en effet, tu feras cela très facilement en python, plus difficilement que dans d'autres langages moins dynamiques.

Si tu en veux faire un proxy de seulement une méthode / fonction. C'est assez simple (et tu peux le faire de façon assez générique) en C++ en créant un "functor" et en exploitant des templates variadics. Cependant le type de l'objet va changer (i.e. ce sera celui du Proxy) et donc il faudra que tes fonctions acceptants l'objet initial puisse accepter le nouveau. Si tes fonctions sont initialement "templatées", c'est faisable, sinon, c'est mort. Point de plus pour le langage dynamique.

Un point où un langage statique s'en sort très bien ce serait le cas du proxy d'une fonction. En prog fonctionelle, on a très souvent tendance à passer des fonctions en argument d'autres fonctions. Le type d'une fonction étant défini juste par ses arguments / valeur de retour, si ton proxy à la même interface, cela passera sans problème.

Par exemple, en Haskell, la fonction databaseQuery :: DbHandle -> Query -> IO DBResult qui prend une requete SQL et retourne un résultat, pourra être remplacée en ajoutant du log de la façon suivante:

log f arg = do
   putStrLn "Avant la fonction"
   res <- f arg
   putStrLn "Après la fonction"
   pure res

Ainsi, que tu passes dataBaseQuery handle ou log (dataBaseQuery handle) (i.e. ton proxy) en argument d'une autre fonction, le système de type sera satisfait.

Cependant cela demande de penser son interface en avance et c'est donc moins souple. De mon expérience, je suis rarement limité par ce point, mais j'admet cette limitation.

Merci de m'avoir fourni un exemple valide de l’intérêt d'un typage dynamique.

Merci, je repond dans la discussion.

Beaucoup de monde dans cette discussion disent que le typage dynamique quand tu en a besoin tu es content de l'avoir,. Mais personne ne donne d'example.

J'ajouterais qu'un langage statique (comme Haskell) peut très bien avoir des constructions pour faire du typage dynamique au besoin. Cela existe, je n'en ai jamais eu besoin en 4 ans d'expérience en Haskell sur de grosses base de code.

Je me sers du typage dynamique dans quelques cas (bien bordés) pour simplifier la vie.

Quels cas ? Je suis vraiment curieux. Depuis que je fais du haskell professionnellement, je n'ai jamais eu besoin de typage dynamique.

Je suis convaincu que des outils comme mypy sont une grosse avancé pour python.

Si on met de coté tous les autres points de comparaison (c'est arbitraire), quel serait la raison de choisir un langage dynamique par défaut avec du typage optionnel limité vis à vis d'un système statique par défaut, avec un système de type plus développé, mais avec du typage dynamique optionel plus rébarbatif.

Je n'arrive pas à trouver d'argument en faveur du dynamique par défaut, et pourtant j'essaye.

Je suis allé voir ta présentation et j'ai remis un œil dans la doc de mypy que je n'avais pas lue depuis très longtemps. Cela à vraiment progressé, c'est vraiment pas mal.

L'approche des Union est intéressante car elle permet de facilement ajouter / enlever des constructeurs. En contrepartie cela fait des union ouvertes ce qui force à mettre plus de signatures. C'est le sentiment que j'ai avec mypy, il faut mettre des informations de type partout si tu veux que cela fonctionne.

La documentation me dit que "User-defined generics are a moderatly advanced feature" et cela m'attriste car c'est juste la base du typage (et des trucs amusants). Note: mypy utilise le terme Generic là ou une énorme partie de la littérature utilise le mot polymorphisme.

Je trouve que beaucoup de choses sont verbeuses, mais c'est principalement une limitation de python qui n'a pas de syntaxe pour faire du pattern matching.

@dataclass
class Left(Generic[T]):
    left: T


@dataclass
class Right(Generic[T]):
    right: T

either = Union[Left[V], Right[T]]

def tortue(d: T, v : either[T, V]) -> T:
    if isinstance(v, Left):
        return v.left
    else:
        return d

Donnerais, en Haskell:

data Either v t = Left v | Right t

tortue d e = case e of
   Left v -> v
   Right _ -> d

Dans le précèdent exemple, je n'ai pas encore réussi à comprendre comment il s'en sort pour affecter V et T à str et int respectivement. L'inférence est assez bonne, je n'arrive à la mettre en défaut que dans quelques rares cas.

Je n'arrive pas à faire de types calculés ? Par exemple, une fonction type:

def bar(t1, t2):
   return ...


def foo(a: T1, b: T2) -> bar(T1, T2)

J'ai essayé rapidement sans succès. Avec bar(T1, T2) il refuse et me demande d'utiliser bar[..] et avec cette approche (et bar une instance de class avec __getitem__), il refuse.

Merci de m'avoir donné envie de donner une nouvelle chance à mypy, cela à fait du progrès. Je le sortirais la prochaine fois que je ferais une intervention chez un client qui refuse de faire du Haskell ;)

Par contre il faut s'assurer de faire un dockerfile reproductible, parce que sinon tu va livrer quelque chose différent de ce que tu peux avoir testé.

Je suis d'accord avec toi que la technologie reste un simple moyen et non pas un but.

Concernant le C++, j'en ai fais de nombreuses années et dans un contexte amusant ou il est vraiment justifié : celui du calcul haute performance pour le cinéma d'animation. Sans entrer dans les détails, mais un contrat avec un client peut se perdre si tu es 5% plus lent que la concurrence. Quand le budget alloué aux fermes de rendus pour un film est non négligeable par rapport au budget total du film, on parle de millions d'euros qui se jouent sur 5% de performance.

Tu parles de reconversion, c'est ce que j'ai fais. Il y tout juste un an, j'ai décidé de quitter ce domaine et de faire autre chose, je voulais changer.

Depuis, je fais principalement de l'embarqué pour l’aéronautique. Un domaine pour lequel le C++ est sensé être aussi le roi. Sauf qu'en fait non. Dans ce contexte, le C++ est un langage intermédiaire généré par un langage de plus haut niveau (ici Haskell) pour au final avoir un code plus simple (on profite de la souplesse d'Haskell) et plus robuste (On peut prouver de nombreuses choses statiquement pendant la phase de génération du code, choses qu'il nous aurait été impossible de prouver en C++).

Mes anciennes compétences C++ sont ici utilisées dans l'outil de génération de code C++.

En ce qui concerne les outils pour le C++, je suis biaisé car je travaille pour une société de consulting qui vend du bazel et du nix, ( https://www.tweag.io/) donc :

• Bazel, dont tu parles, est un très bon outil pour gérer le build sur une grosse base de code hétérogène. Il saura autant faire cohabiter du C++, que du python, du haskell, du node et que sais-je encore, et ce sur plusieurs architectures. À titre d'exemple, le générateur de code C++ dont je parlais avant est écrit en Haskell, le code C++ est généré sur x86_64 puis compilé en cross compilation pour différentes architectures pour l'embarqué. Tout cela dans bazel.

• Nix (https://nixos.org/nix/) pour ta gestion de dépendance. En gros, nix va te créer un environnent reproductible contenant les dépendances de ton projet.

L’expérience windows est correct dans le subsystem for linux. En dehors, j'ai déjà cross compilé des binaires natif windows avec, mais jamais essayé de faire plus. Tout ce qui se lie statiquement facilement doit pouvoir être faisable.

Le problème de la distribution est réglé avec nix si ta cible peut installer nix. Sinon, tu es dans la même situation que pour tous les autres outils de gestion de dépendance / build et je ne connais qu'une unique solution: faire un binaire statiquement lié qui contient tout. Et nix peut t'aider à faire ça.

Même ainsi, je me demande quelle doit être le mode par défaut : lier avec la lib blas système si elle est présente ? Les blas statiques empaquetées par mes soins ?

C'est là ou je ne veux plus avoir ce type de choix à faire. Au final tu vas complexifier ton système de build pour une heuristique qui risque de ne pas marcher, et quand elle ne marchera plus, tu la changeras en casant les cas où cela marchait déjà.

De mon coté, je fournis des règles nix que les gens peuvent utiliser avec nix. Et si ils ne veulent pas de nix, ils peuvent suivre le "readme" fourni dans mon nix. Je garde un setup.py, makefile le plus simple du monde, qui peut donc être surchargé pour que l'utilisateur passe ses chemins maison. Si je met mon paquet dans pypi, soit il est full python, et pas de souci, soit je le garde simple et je précise les dépendances "systèmes" que l'utilisateur doit fournir (i.e. en lisant le .nix ;)

Je reste néanmoins persuadé qu'il est plus facile pour l'utilisateur de rentrer un simple pip install pythran et que ça juste marche :-/ C'est un peu le problème du standard de fait.

pip est le standard de fait pour la distribution de paquet python, et il fait cela très bien. Mais dés que les paquets sont plus complexes (Python + autre chose), pip ne répond plus du tout à la problématique.

En gros, soit ton utilisateur va utiliser les packets de sa distrib pour installer ton projet, et là tu fais confiance aux packageurs de la distribution (cela peut être toi).

Soit tu demandes à ton utilisateur d'installer des choses lui même, et quitte à ce qu'il install quelque chose à la main, autant que ce soit nix https://nixos.org/nix/ (ou guix) qui ensuite fera marcher ton projet de la manière que tu as décidé, sans erreur possible.

Mon avis c'est que dés que tu commences à essayer de hacker un truc qui marche un peu près partout, tu complexifies ton projet et au final tu va aussi complexifier l'installation un peu près partout. Fournir une description de paquet avec nix permet de fournir:

• Quelque chose qui marche partout, les utilisateurs pouvant installer nix partout (modulo windows: dans le subsystem for linux. Ce qui peut être un problème)

• Un readme d'installation complet et testé. Pour ceux qui choisirons de ne pas installer nix, le fichier de configuration de nix peut être vu comme un readme d'installation exhaustif, tu listes absolument toutes les dépendances avec leur version ainsi que les étapes du build, et à jour, puisque tu t'en sers tous les jours pour travailler. Fini les readmes incomplet et obsolètes.

J'ai vraiment hate de voir ce que cela va apporter en terme de performance, support matériel (GPU en particulier). J'aimerais vraiment avoir un pipeline de build / dépendance unifié entre linux et windows.

Or, quel système, en pratique, fournirait /usr/bin/env et pas /bin/sh

J'allais te dire nixos, mais en fait non ;)

guillaume@paddle:~]$ ls -alh /bin
total 20K
drwxr-xr-x 1 root root   4 Apr 30 14:36 .
drwxr-xr-x 1 root root 110 Feb 28 16:29 ..
lrwxrwxrwx 1 root root  75 Apr 30 14:36 sh -> /nix/store/jx8g6cjv2y5rs69ym08b0pj3ngxvnhhg-bash-interactive-4.4-p23/bin/sh

[guillaume@paddle:~]$ ls -alh /usr/bin
total 4.0K
drwxr-xr-x 1 root root  6 Apr 30 14:36 .
drwxr-xr-x 1 root root  6 Jul  4  2018 ..
lrwxrwxrwx 1 root root 66 Apr 30 14:36 env -> /nix/store/baylddnb83lh45v3fz15ddhbpxbdb7m7-coreutils-8.31/bin/env