On peut à mon avis le qualifier de langage de programmation en bon est dû forme du fait qu’il soit « Turing-complet ». Ceci dit le Brainfuck l’est également, ce dernier est d’ailleurs le plus dépouillé que l’on puisse faire comme langage Turing-complet à ma connaissance (et c’est très beau, àmha ^^).
Mais un shell est conçu, et de plus configuré par défaut, pour servir d’interface entre l’utilisateur et le système, pour une utilisation « interactive ». Pour prendre un des exemples les plus parlant : en Python, Perl ou d’autres langages interprétés, une erreur de syntaxe entraîne la fin de l’exécution de l’interpréteur, il « n’ira pas plus loin », alors qu’en Bash (et autres), à moins de lui spécifier de s’arrêter sur tout code d’erreur (via set -e), et donc pas uniquement les erreurs de syntaxe... il continuera, en passant à la commande suivante. C’est compréhensible : si une erreur de syntaxe stoppait ton shell, par exemple que tu te trompais et essayais d’exécuter une commande qui n’existe pas, et que tu devais alors de re-logger au système à chaque fois, tu deviendrais fou.
Une autre manière de saisir la différence : essaye d’utiliser l’interpréteur Python comme shell de connexion, à la place de Bash. C’est techniquement tout à fait possible. Tu lances en automatique un import os histoire d’avoir des commandes (qui seront des fonctions Python donc) pour afficher/copier/supprimer/etc des fichiers, etc, etc... tu te rendras vite compte que ce n’est pas fait pour.
Entendons nous bien, je ne veux décourager personne d’écrire des programmes en shell, c’est le langage que j’utilise moi-même le plus, mais ce que je souhaite faire passer comme message, c’est que sans prendre conscience de cela, je ne crois pas qu’on puisse avoir une bonne expérience avec Bash. On ne peut pas comparer sur un pied d’égalité un shell d’un côté, et de l’autre un langage de programmation conçu comme tel « dès le départ ».
Certes il a un rôle particulier mais n'est-ce pas le cas de tout les langages?
Sans aller jusqu’au Brainfuck, qui est d’abord un jeu et clairement pas un outil qui puisse rendre le moindre service en dehors de l’exercice intellectuel, oui, des langages il en existe de toute sorte (on peut prendre CommonLisp ou Erlang par exemple, relativement exotiques comparé aux langages les plus répandus), peu se ressemblent vraiement. Mais « shell interactif » c’est vraiment un rôle (et pas un paradigme de programmation...), assez à part. Selon moi, on est pas obligé de voir les choses de la même manière.
[^] # Re: Debian ne pip plus ?
Posté par Marotte ⛧ . En réponse au journal La galère de Python en déploiement. Évalué à 5.
On peut à mon avis le qualifier de langage de programmation en bon est dû forme du fait qu’il soit « Turing-complet ». Ceci dit le Brainfuck l’est également, ce dernier est d’ailleurs le plus dépouillé que l’on puisse faire comme langage Turing-complet à ma connaissance (et c’est très beau, àmha ^^).
Mais un shell est conçu, et de plus configuré par défaut, pour servir d’interface entre l’utilisateur et le système, pour une utilisation « interactive ». Pour prendre un des exemples les plus parlant : en Python, Perl ou d’autres langages interprétés, une erreur de syntaxe entraîne la fin de l’exécution de l’interpréteur, il « n’ira pas plus loin », alors qu’en Bash (et autres), à moins de lui spécifier de s’arrêter sur tout code d’erreur (via
set -e), et donc pas uniquement les erreurs de syntaxe... il continuera, en passant à la commande suivante. C’est compréhensible : si une erreur de syntaxe stoppait ton shell, par exemple que tu te trompais et essayais d’exécuter une commande qui n’existe pas, et que tu devais alors de re-logger au système à chaque fois, tu deviendrais fou.Une autre manière de saisir la différence : essaye d’utiliser l’interpréteur Python comme shell de connexion, à la place de Bash. C’est techniquement tout à fait possible. Tu lances en automatique un
import oshistoire d’avoir des commandes (qui seront des fonctions Python donc) pour afficher/copier/supprimer/etc des fichiers, etc, etc... tu te rendras vite compte que ce n’est pas fait pour.Entendons nous bien, je ne veux décourager personne d’écrire des programmes en shell, c’est le langage que j’utilise moi-même le plus, mais ce que je souhaite faire passer comme message, c’est que sans prendre conscience de cela, je ne crois pas qu’on puisse avoir une bonne expérience avec Bash. On ne peut pas comparer sur un pied d’égalité un shell d’un côté, et de l’autre un langage de programmation conçu comme tel « dès le départ ».
Sans aller jusqu’au Brainfuck, qui est d’abord un jeu et clairement pas un outil qui puisse rendre le moindre service en dehors de l’exercice intellectuel, oui, des langages il en existe de toute sorte (on peut prendre CommonLisp ou Erlang par exemple, relativement exotiques comparé aux langages les plus répandus), peu se ressemblent vraiement. Mais « shell interactif » c’est vraiment un rôle (et pas un paradigme de programmation...), assez à part. Selon moi, on est pas obligé de voir les choses de la même manière.