Guido van Rossum, créateur de Python, passe chez Microsoft
Le 13 novembre 2020 à 10h42
1 min
Logiciel
Logiciel
C’est via un tweet que le principal intéressé a annoncé la nouvelle : « J'ai décidé que la retraite était ennuyeuse et j'ai rejoint la Developer Division de Microsoft. Pour faire quoi ? Trop de réponses à donner ! Mais cela améliorera l'utilisation de Python à coup sûr (et pas seulement sous Windows :-) . Il y a beaucoup d'open source ici ».
Selon son compte LinkedIn, il était auparavant chez Google pendant sept ans, puis chez Dropbox pendant six ans, avant de prendre sa retraite en octobre 2019.
Le 13 novembre 2020 à 10h42
Commentaires (34)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 13/11/2020 à 09h29
La photo semble issue de Wikimedia Commons (https://commons.wikimedia.org/wiki/File:Guido-portrait-2014-drc.jpg?uselang=fr). Comme elle est publiée sous licence CC by-sa, cela implique de citer l’auteur et de republier la photo sous la même licence. Donc si c’est bien l’origine de cette photo, merci de respecter la licence.
Le 13/11/2020 à 09h54
Il y a beaucoup d’open source ici
Il y avait aussi beaucoup d’amerindiens chez les colons espanols.
Le 13/11/2020 à 15h59
Décidément Microsoft attire les pointures des langages de programmation 😊
Après Anders Hejlsberg (créateur du Turbo-Pascal, puis de Delphi chez Borland, et devenu l’architecte en chef de la plateforme .NET chez MS), la venue de Guido van Rossum chez Microsoft est un joli coup pour cette société !
Le 13/11/2020 à 17h29
c’est pour preparer le passage a linux
Le 13/11/2020 à 18h23
Non, du tout ! Une réécriture de Windows en Python
Le 14/11/2020 à 16h17
Ouais ! La version 2.8 enfin !
Le 14/11/2020 à 10h29
Le prochaine Windows sera basé sur Linux, c’est une certitude, et ce sera la future révolution chez M$. Par contre ça arrivera progressivement , par petites touches.
Le 14/11/2020 à 11h39
Le 14/11/2020 à 12h38
Visual Python for .NET ?
Le 14/11/2020 à 13h10
Je sais pas ce qu’il vaut, mais y a déjà Python.Net
Le 14/11/2020 à 13h38
Vu comment Python est devenu un langage incontournable sur les systèmes Linux (beaucoup d’outils développés avec, installé nativement, etc, là où il y a une décennie j’entendais encore parler de Perl comme complément à Bash), j’imagine que Microsoft apprécierait d’avoir un équivalent pour son monde.
J’ai cru comprendre que le Powershell est un langage de scripting assez puissant sur Windows. (j’ai pas touché à un Windows depuis 2008, je précise…)
Le 14/11/2020 à 18h03
probablement, ceux qui le maitrise sont ditirambiques dessus. Perso lorsque j’ai besoin de faire un script a la con -> WSL avec bash c’est tellement plus simple que d’apprendre des valeurs a la windows genre :
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
et comme c’est super bien documenté les clé de registre, tu te régal !
Le 15/11/2020 à 09h56
Puis je j’ai toujours pas compris l’intérêt de singer des commandes Unix sans proposer des options compatibles. Essaie un ls -alrt sous PS pour rire.
C’est un peu comme la vieille pu Canada-Dry ce truc. Ca ressemble… mais pas besoin de creuser longtemps pour voir que presque rien ne sera réutilisable.
=> Exit et on prends peut-être WSL désormais et Cygwin historiquement.
Les afficionados du truc te dirons bien que l’accès aus “windows internals” est un point fort. Mais AMHA non: Ca peut changer, d’ou la merde pour avoir un truc compatible toutes versions/variantes windoze. Si on a besoin de taper dans les tréfonds de l’OS hote, on code une nouvelle commande qui manque avec un vrai language de programmation et on le fait remonter upstream. Point.
Le reste n’est qu’emplâtres sur OS en bois.
Le 15/11/2020 à 10h22
Ce n’est pas une envie de singer, c’est un simple allias. T’as aussi l’alias dir. Le but n’est pas de reprendre la syntaxe de ls ou de dir. C’est juste que quand tu ne connais pas PowerShell, tu entres la commande que tu connais, et t’as accès à l’aide correspondant à l’équivalant dans PowerShell.
Le 15/11/2020 à 11h40
Faudra m’expliquer le rapport entre Powershell et le registre Windows et en quoi tu as besoin d’avoir la doc du registre pour comprendre Powershell.
Mais bon, apparemment, ce qui vient de Microsoft te répugne tant, que pour faire un pauvre script tu préfères passer par un langage alambiqué comme bash quitte à le faire tourner dans un sous-système linux plutôt que de prendre le temps d’honnêtement te pencher sur la doc de Powershell.
Pour info bash existe nativement sous Windows, pas besoin de passer par WSL.
Et PowerShell est opensource et est tellement lié aux “valeurs de Windows” que tu peux l’installer sous Linux et macOS en un coup d’
apt-get install
Le 15/11/2020 à 18h16
comme tu demande gentiment, je t’explique :
tu dois interagir avec ton environement, et forcement il te faut les clé de registre. Pour faire un hello world forcément tu n’en n’as besoin, mais pour faire des scripts un peu couillu qui automatise des actions sur des programmes tu dois FORCEMENT travailler sur les clé de registre.
Le 15/11/2020 à 18h35
T’as un exemple de ton besoin, et de son contexte si il est impactant, qui t’obliges à passer par l’accès au registre au lieu d’utiliser les objets qui vont bien STP ?
Ça m’intrigue et je suis curieux.
Le 15/11/2020 à 11h51
Je sais pas si tu as regardé plus de 4 secondes à quoi ressemble un script PowerShell (qui est un langage objet) histoire de te rendre compte que ce que tu critiques est juste un alias pour quelque chose comme
Get-ChildItem /ton/chemin | Sort-Object -Property LastWriteTime
. Qui est au passage bien plus lisible dans un fichier de script que “ls -alrt” qui ne veut rien dire pour le quidam moyen contrairement au PowerShell qui est lisible y compris pour quelqu’un qui ne l’a jamais utilisé.Le 15/11/2020 à 16h46
Si Powershell est un langage de programmation orienté objet (et non de scripting comme je pensais), dans ce cas il n’a aucun rapport avec Bash et donc la comparaison avec Python me semble plus pertinente.
Bash n’est qu’un langage de commandes (aussi puissant soit-il), ils n’ont absolument pas la même finalité et sont donc incomparables.
Bref, je pense que Microsoft doit être contente d’avoir récupéré un développeur aussi talentueux et reconnu.
Le 15/11/2020 à 17h22
Je me fous de la manière dont cela fonctionne, pour des tâches ligne de commande basique voir administratives venant d’Unices ce truc ne permet de rien réutiliser niveau scripts tout en reprenant les noms de pas mal de commandes. C’est donc pour cet usage un mauvais plagiat, point.
Puis ce n’est pas moi qui l’ait appelé un shell? Ni qui lui ait fait un terminal ou suis parti d’un paradigme discutable (cf ma remarque: Pas le bon utilitaire en rootfs… coder l’utilitaire avec un vrai langage et remonter upstream)..
Le 15/11/2020 à 17h51
Et les commandes que l’on retrouve sur Ubuntu et d’autres, comme la commande Dir, c’est aussi un mauvais plagiat ?
Non elles sont là pour faciliter le passage de l’un à l’autre et moi, je trouve ça bien.
Le 15/11/2020 à 18h22
Powershell est bien un langage de scripting/cli. La grosse différence avec l’existant, et là où il innove justement, c’est que les commandes, au lieu d’avoir des inputs/outputs sous forme de texte (comme bash) vont avoir des i/o sous forme d’objets. Mes ces objets sont bien affichés de manière lisible dans la console.
Par exemple le
Get-ChildItem /ton/chemin
ne renvoie pas, comme le ferait ls, une sortie texte avec une liste de fichiers/répertoires, mais bien une “vraie” liste d’objets que tu peux piper dans une autre commande qui pourra l’utiliser telle quelle sans avoir à d’abord interpréter l’entrée texte.Par contre le shell powershell va bien t’afficher les objets retournés sous forme d’un joli tableau bien lisible pour un humain.
Donc dans mon exemple complet
Get-ChildItem /ton/chemin | Sort-Object -Property LastWriteTime
tu récupères d’abord tous les éléments de ton répertoire, que tu pipes vers Sort-Object selon une certaine propriété.C’est donc bien un langage de shell / scripting du même acabit de bash sauf que les i/o ne sont pas du texte et sont donc plus faciles à gérer. Par exemple pour itérer sur la sortie d’un programme en bash, t’as pas intérêt à ce que le programme précédent ait ajouté une ligne informative que tu aurais oublié de filtrer. Ensuite t’es bon pour te taper le parsing de chaque ligne pour en faire de la donnée à peu près exploitable. En Powershell tu peux juste itérer sur les objets retournés par la commande précédente et accéder à leurs propriétés dont les noms sont clairs.
Et je n’utilise même pas PS au quotidien, mais ça me gonfle de lire des âneries de gens qui ne savent rien faire d’autre que glorifier une techno pour l’unique raison qu’ils la maitrisent et qu’ils s’enferment dans un schema mental de ce qui est bien et qui ne l’est pas.
Le 15/11/2020 à 18h46
Merci pour la précision.
Mais au final PowerShell et le shell Unix restent complètement incomparables de mon point de vue. Il y a une forte différence philosophique entre l’architecture des systèmes.
Sur Unix, tout est fichier, et donc tout est manipulation via I/O comme tu l’indiques. Sur Windows, tout est API pour dialoguer avec le système si je ne m’abuse, et l’orientation objet de Powershell est parfaitement logique avec la manipulation d’objets résultants de ces appels. Et surtout apporte un vrai scripting sous Windows, perso j’ai des vieux souvenirs de batch où il fallait compenser avec du VBS pour pouvoir faire un truc exploitable … Qui tombait de temps en temps en marche.
Après, le reste c’est de la bataille de clochers. Personnellement j’estime qu’il faut choisir l’outil adapté au besoin en fonction du besoin. Raison pour laquelle j’alterne principalement entre Bash ou Python. Même si j’ai déjà eu l’occasion de faire des trucs plutôt cool avec Bash ou ksh et que le one-liner est toujours un sympathique challenge intellectuel, vient un moment où un langage comme Python sera plus performant ou simple pour effectuer des opérations complexes.
Le 15/11/2020 à 19h25
100% d’accord sur à peu près toute la ligne. Python ayant l’avantage d’être interoperable. Je me surprends à faire aussi pas mal de scripting en JS de temps en temps pour faire de l’asynchrone sans prise de tête. Mais Python garde l’avantage d’une lib standard plus fournie que celle de NodeJS ou t’as rapidement besoin d’aller taper dans npm, ce qui n’est pas hyper envisageable pour du scripting.
Le 15/11/2020 à 18h26
Donc tu dois faire une tâche sous Windows (parce que sinon on n’en serait pas là) que t’arrive à faire en bash dans WSL sans toucher au registre, mais la même tâche sous PowerShell, impossible de la faire sans aller dans le registre ?
Je pense que c’est faux.
Le 15/11/2020 à 19h15
VBScript donnait accès à pas mal de chose, mais la doc était pourrie.
Il fallait penser à aller chercher du côté de la doc de VB, et pour pas mal de besoin dans celle de WMI.
Et pour faire des trucs qui se faisaient en 1 ou 2 lignes sur d’autres plateformes, il t’en fallait parfois bien plus en VBScript, sans atteindre forcément un équivalant.
De mon point de vue, c’était une solution assez batarde, et ça se sentait dans son utilisation.
Le 15/11/2020 à 19h50
Ubuntu ça a été 5 ans… jusqu’à la LTS 2010. Ensuite, à vouloir résoudre leur “bug nb1”, ils ont finit par l’imiter.
Les unices existaient bien avant le DOS, son dir et ses .bat avec une structure qu’on ne retrouve plus gère que dans les scripts UEFI: Wintel strike back… avec qq “space-cowboys” de l’époque DOS à occuper avant la retraite à l’époque ou cette horreur a été spécifiée!
Et ils existeront quand cette passade de sous informatique personnelle construite par IBM (avec l’OS le plus affreux qu’ils puissent alors trouver) pour ne pas saper trop tôt son marché station de travail sera finie: Microsoft passant à de l’applicatif et services tournant sur un OS ou ils ne seront que contributeurs.
Le 15/11/2020 à 20h04
Sauf entre versions… Quand on voit que n’importe quel exemple du K&R d’il y a 30 ans compile et s’exécute encore, on se dit qu’il y avait sans doute moyen de mieux faire quand même.
Vouloir singer un langage trop naturel est en l’espèce un défaut (quand un autre reprends le code et pense/parle différemment). De même que des fixettes comme l’absence de séparateur de bloc ou de typage: On peut dans certains cas se retrouver à exécuter un truc qui n’est pas ce qui apparaît visuellement dans son éditeur et ne pas savoir quelle donnée on traite est source de pb aussi.
Faut prendre Python comme il est: Un truc utile pour coder rapidement sans besoin de performance ce qui en bash ou autre commencerait à devenir pénible.
Cela permet aussi de comprendre la fixette de test des process de développement actuels: Si on veut du à peu près fiable en python, il faut tendre vers 100% de couverture de test. Retour vers le futur aussi: pylint et autres ramènent là l’époque ou on passait un coup de lint car le moindre petit programme en C mettait plusieurs minutes à compiler (ou pas, avec une preuve minimale de correction).
En Python, il attrape bien des choses que l’interpréteur ne voit pas avant l’exécution de la branche de code considérée.
Bon, pour ma part j’ai qq habitudes ailleurs mais Python et sérieux je pense que ça le fait pas. Et les fixettes du concepteur (séparateurs de blocs en particulier) y sont parfois pour qqchose.
Le 15/11/2020 à 20h09
Oui oui “windoze c’est de la bouze, Unix c’est génial”.
L’informatique avance, mais y a toujours quelques “informaticiens” laissés au bord du chemin.
Le 15/11/2020 à 21h13
Ha, t’as loupé le commentaire juste au dessus où il démontre que Python c’est franchement pas sérieux et que c’est à cause de Python qu’on doit tester notre code.
Après c’est sûr que si ton projet c’est de réécrire Google, YouTube, ou Reddit ou Dropbox c’est pas Python qu’il te faut. Ah si pardon, tout ça est écrit en Python… Même pas foutus d’écrire un pauvre moteur de recherche avec le bon langage de programmation chez Google. Ces blaireaux.
Le 15/11/2020 à 21h19
C’est moi que tu veut citer, et ce commentaire là ? Tu t’es pas trompé ?
Le 15/11/2020 à 22h13
Je me suis un peu embrouillé tout seul désolé 😅
Le deuxième paragraphe ne t’est en effet pas destiné :)
Il est temps d’aller dormir je crois !
Le 16/11/2020 à 06h50
Non mais en fait, en relisant, je me rends compte que j’avais mal compris et que j’aurais aussi due aller me coucher plus tôt
Le 19/11/2020 à 06h30
Bon ben, on dirait bien que je vais pouvoir m’asseoir dessus, que le “forcement” n’est en fait pas si concret que ça, qu’il est probablement plus due au problème rependue d’interface chaise clavier.