Ce qui est rigolo, c’est que les “détracteurs” de PowerShell sont… les utilisateurs de bash ! (et compatible).

Cela a déjà été dit, donc tant pis pour la répétition, mais PowerShell n’est pas bash, et ne repose pas du tout sur le même paradigme. Bash, c’est la notion de flux. PowerShell, c’est la notion d’objet.

Oui, le nom des CmdLets “pue” quand on est habitué aux noms courts. Idem pour les options à rallonge. Maintenant que ça a été dit, les avantages de PowerShell :

• les noms sont uniformisés


• les noms sont beaucoup plus parlant, même si on ne connait pas la commande


• comme tout est objet, il est facile de récupérer une information précise. Pas besoin de cut, de awk et autres joyeuseries de ce genre que l’on pipe à tout va


• on peut utiliser toute la puissance du .Net pour développer très facilement ses propres CmdLets

Oui, PowerShell casse les habitudes, donc, pour ceux qui ont l’habitude de Bash, c’est “difficile / nul / tout ce que vous voulez” . Mais PowerShell est tellement puissant quand on s’y intéresse un temps soit peu et qu’on surmonte cette résistance au changement…

(quote:2093716:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Non, je suis détracteur de PowerShell parce que je suis programmeur. Et le programmeur que je suis se désespère de voir un concept puissant (les objets) martyrisé par une syntaxe à la con.

Que reproches-tu à la syntaxe ? La syntaxe “classique” pointée est utilisable.

Il existe déjà une syntaxe pratique pour manipuler des objets, mais elle est complexifiée à mort parce que Powershell ne sait pas sur quel pied danser et tente de montrer des objets en les traitant à la ligne de commande comme s’il s’agissait de simple collections de records.

Il existe des syntaxes complexes pour gérer les cas complexes, notamment lorsqu’il y a des collections, où la notation pointée est insuffisante.

On se ramasse des noms de cmdlets à dormir à la rue parce que notamment la notation pipe ne sait pas correctement gérer le polymorphisme.

C’est-à-dire ? Car je ne vois pas du tout de quel problème tu parles…

Bah voui, alors pourquoi ne pas une fois pour toutes proposer un langage de programmation cohérent qui permet tout ? Pourquoi devoir jongler d’un côté avec la notation “pipe” et d’un autre la notation pointée pour extraire les données ?

Peut-être parce que les deux ne font pas la même chose ? Entre extraction et manipulation, il y a une énorme différence. Une extraction est un cas particulier de manipulation. Une manipulation n’est pas forcément une extraction.

Un pipe sert à connecter deux manipulations ensembles (transmettre la sortie standard d’un programme vers l’entrée standard d’un autre). La notation pointée permet d’accéder directement aux propriétés et méthodes d’un objet.

Voilà, c’est ce non-aboutissement typiquement microsoftien que je reproche à Powershell.

J’ai l’impression de lire les propos d’une personne restée dans les années 90-2000. Microsoft a quand même bien changé et parler de non-aboutissement me semble plus refléter d’un aveuglement idéologique que d’une réelle argumentation…

(quote:2093863:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Pourquoi la notation pointée serait-elle insuffisante ? En C# tu as de collections et tu les manipules en notation pointée via les extensions Linq, et rien ne t’empêche d’ajouter des extensions pour exécuter une même fonction sur tous les éléments (je pourrais écrire une fonction Cos qui s’applique sur un itérable de flottants et renvoie un itérable de flottants qui sont les cosinus des éléments…)

Linq sont des méthodes d’extensions. Du sucre syntaxique pour éviter de devoir écrire des trucs du style Math.Cos(maCollection) et pouvoir faire maCollection.Cos().

Sauf que :

• En C#, ce n’est que du sucre syntaxique


• Powershell n’est pas C# (même si la syntaxe semble proche)


• les méthodes d’extensions ne sont utilisables que parce qu’il y a des clauses using. Donc le sucre syntaxique que tu as à un endroit nécessite une compléxité supplémentaire ailleurs (en début du fichier).

Pourquoi gérer le même problème par deux méthodes différentes ? Pourquoi ne pas ajouter les petits détails qui manquent à la syntaxe C# pour la rendre encore plus “fluent” sur les collections ?

Tu veux sans doute dire PowerShell ;) Car c’est déjà pas mal fluide en C# avec Linq et les méthodes d’extensions. Et en C#, les méthodes d’extensions sont pleines de petits pièges (traitement différent du null, attention à la surcharge, impossible à utiliser en cas d’ambiguïté, etc…)

La notation pipe permet de relier entre eux deux cmdlets qui se veulent indépendants, mais en pratique le cmdlet récepteur doit être un minimum au courant de ce qu’il reçoit.

Imaginons que j’aie une commande Get-Machins (qui renvoie des machins) et Get-Bazars (qui renvoient des bazars) et que ces deux choses soient écrits par des personnes indépendantes. Imaginons maintenant que les machins et les bazars puissent tous deux être frobulés. Avec une notation pipe, je vais être obligé d’avoir deux cmdlets avec des noms différents Frobulate-Machins et Frobulate-Bazars :

Get-Bazars | Frobulate-Bazars

Get-Machins | Frobulate-Machins

tandis qu’avec une notation pointée, le typage va désambiguer naturellement les deux fonctions malgré qu’elles ont le même nom. Je ne risque pas de me tromper en appliquant la mauvaise fonction de frobulation. Je n’ai pas besoin de répéter le type.

Bazars.Get(…).Frobulate()

Machins.Get(...).Frobulate()

Alors, j’ai envie de dire oui et non (réponse de Normand, mais il faut m’excuser, je le suis :p). Je pense que nos divergences d’opinions viennent des attentes différentes que nous avons l’un l’autre d’un langage de script. Comme PowerShell se rapproche énormément de C#, tu attends d’avoir un comportement à la C#. Comme PowerShell est un langage de script, je m’attends à ce qu’il soit facile à utiliser (et potentiellement, avec le paradigme objet, plus simple que bash).

Le problème que tu soulèves se pose également en Bash. Et même en C# tu ne pourras pas avoir la solution aussi simple (sauf à définir explicitement une méthode d’extension sur des collections de type Bazar et Machin) et il faudra utiliser du Linq (Select) et un delegate ou une lamba.

Non, frustration. À chaque problème similaire, chaque produit basé sur .Net vient avec une solution ad-hoc plutôt que d’une fois pour toutes exploiter un tronc commun. Microsoft possède une solution simple propre et efficace à un nombre incroyable de cas et s’obstine à ne pas l’utiliser: c#

Ben non, pour les fichiers csproj on réinvente des tags xml conditionnels, des ItemGroups, au lieu d’écrire

if (Target.Platform == Platforms.X64) { Packages.Include(“System.Text.Json”); Packages.Include(“System.Text.Xml”); }

qui serait 1000 fois plus lisible.

Tu reproches au fichier csproj de ne pas être en C#. Mais du coup, les fichiers vbproj il faut les écrire en quoi ? Et les fsproj ? Et les vcxproj ? Pourquoi privilégier le C# à un autre langage ?

Le XML, qu’on l’aime ou ne l’aime pas, permet d’harmoniser la structure des fichiers projets au sein de Visual Studio / Visual Studio Code. C’est un choix. Tu n’es pas d’accord avec, c’est ton droit. Mais dire que c’est de l’obstination, là je ne suis pas d’accord. Les fichiers projet, qu’ils soient pour du .Net ou non, ont aujourd’hui TOUS la même forme.

Ben, non, pareil pour Powershell, avec des syntaxes ad-hoc pour effectuer des transformations un peu poussées. Si en c# je veux déplacer tous les fichiers d’un répertoire dans un sous-répertoire en fonction de l’extension, je pourrais écrire :

\(extensions = (Get-ChildItem -Path \)sourceFolder -File | Group-Object {\(\_.Extension.TrimStart(".")}).Name foreach (\)ext in \(extensions) { \)targetDir = Join-Path -Path \(sourceFolder -ChildPath \)ext robocopy \(sourceFolder \)targetDir “*.\(ext" /MOV /NFL /NDL /NJH /NJS /NC /NS /NP /R:0 /W:0 > \)null }

Euh… “Join-Path -Path -ChildPath” ??? Honnêtement ? C’est de l’aveuglement que trouver ça ridiculement verbeux et inabouti ???

Oui, c’est de l’aveuglement, car la commande PowerShell pour y arriver est extrêmement simple par rapport à ce que tu as proposé :
Get-ChildItem \(sourceFolder -File | ForEach-Object -Process {Move-Item -WhatIf -Path \).FullName -Destination “\(sourceFolder/\)($.Extension.TrimStart(”.“))”}

Et la versions répertoire courant (puisque c’est avec cette version que tu compares la version C# :
Get-ChildItem . -File | ForEach-Object -Process {Move-Item -WhatIf -Path \(_.FullName -Destination \)_.Extension.TrimStart(“.”)}

J’ai juste mis un -WhatIf pour que cela ne déplace pas les fichiers mais que cela affiche ce qui va être fait.

De plus, cette commande, quiconque avec de légère connaissance en programmation devinera assez facilement ce qu’elle fait simplement en la lisant, justement parce que c’est verbeux.

Et maintenant, je t’invite à penser la même chose en bash. Cela risque d’être très rigolo également ! Et par contre, complètement abscons, car il faut connaître le positionnement des paramètres, les syntaxes raccourci des options, etc… bref, une relecture difficile

(quote:2093899:33A20158-2813-4F0D-9D4A-FD05E2C42E48)
Je suis pas coutumier de la procédure (envoie-moi le lien de l’item pour que je puisse monitorer l’avancement)

Finalement, je n’ai rien à faire. Quelqu’un à déjà proposé l’idée dès 2017. Il y a eu des commentaires jusqu’en 2020.