J'ai beaucoup entendu parler des avantages de faire moins de travail de programmation dans les applications GUI et d'utiliser plus d'outils de ligne de commande (en particulier en ce qui concerne les choses à faire plus efficacement). Cependant, comme je ne comprends pas en quoi mon flux de travail serait différent si je dépendais davantage des outils de ligne de commande, je ne peux pas facilement évaluer s'il y a suffisamment de gains pour moi personnellement pour investir du temps et des efforts à apprendre un nouvel ensemble d'outils et à changer mon flux de travail.
Maintenant:
Je code certains projets secondaires dans des langages comme C / C ++ / D / C # / Java / Python en utilisant Visual Studio, Eclipse, etc., et les exécute en configurant les paramètres de construction et en appuyant sur F5 pour construire / exécuter.
Je suis en train de développer un programme web au travail, ce qui implique d'utiliser Django pour configurer un serveur, se connecter à une base de données, etc ... presque tous dans l'éditeur de texte SciTE.
Pour lancer des programmes réguliers, j'utilise Launchy ... toujours pas de terminal. :)
Pour copier des fichiers et ainsi de suite, j'utilise une recherche / déplacement régulière dans le gestionnaire de fichiers graphiques (Windows Explorer, Nautilus).
Débogage: j'utilise Visual Studio ou des outils de débogage pour Windows (si je suis sous Windows). Je n'ai pas fait beaucoup de débogage sous Linux, mais pour les choses que j'ai faites, j'ai utilisé Eclipse (également pour Java sur Windows).
Au travail: pour me connecter au système de construction et mettre en place un projet, j'utilise juste des outils qui ont été intégrés dans Eclipse pour mon usage - pas besoin de terminal ou quoi que ce soit (même si je suis certainement le bienvenu d'utiliser un terminal si je veux vraiment)
Comment est-ce de faire ces choses en CLI? Quelles pièces deviennent plus / moins efficaces? Quels aspects de mon flux de travail devraient être modifiés pour tirer le meilleur parti d'un passage à un travail principalement en CLI? En d'autres termes ... Si vous m'avez transformé par magie en un gourou de la ligne de commande, en quoi mon nouveau flux de travail de codage serait-il différent de ma façon de faire actuelle, centrée sur l'interface graphique?
Réponses:
Je ne pense plus que ce soit vrai. CLI a un avantage spécifique: si vous savez à l'avance ce que vous recherchez, vous pouvez le saisir plus rapidement que vous ne pouvez y accéder dans un menu. Cela signifie que si vous voulez explicitement émettre des commandes au programme qui ont peu de contexte, alors c'est surtout plus rapide. Cependant, il y a deux problèmes.
Premièrement, les programmes GUI peuvent déduire le contexte pour vous. Par exemple, la fonctionnalité Aller à la définition de Visual Studio et Intellisense. Comment pourriez-vous répliquer ces fonctionnalités dans une CLI?
Deuxièmement, les programmes GUI peuvent vous afficher beaucoup plus. Par exemple, le Visual Studio Parallel Profiler, qui est un graphique de l'utilisation du processeur sur plusieurs cœurs au fil du temps. Comment pouvez-vous afficher cela dans une CLI? Cela n'aurait aucun sens. Dès que vos données seraient mieux exprimées comme autre chose que du texte, la CLI est instantanément perdue. Un autre exemple simple est celui des points d'arrêt. Dans Visual Studio, vous cliquez dans la marge de la ligne que vous souhaitez interrompre. Qu'allez-vous faire dans une CLI, essayez de trouver le fichier et le numéro de ligne et entrez cette commande? Cela va vous prendre une décennie relative. Cela ne compte même pas certaines des innovations GUI les plus récentes, comme le Canvas Debugger.
Une interface graphique peut être plus lente si vous voulez passer votre temps à pousser le débogage encore et encore, mais dès que les cas d'utilisation deviennent plus complexes, alors il n'y a aucun moyen que CLI puisse suivre.
la source
Je pense que la plus grande différence ne réside pas dans les tâches individuelles mais sur deux choses:
D'abord et avant tout, l'automatisation. CLI est intrinsèquement scriptable, ce qui est généralement plus difficile sous Windows. J'ai entendu des choses s'améliorer avec PowerShell mais je ne l'ai pas utilisé.
Deuxièmement, la philosophie UNIX de «séparation des préoccupations». Je peux écrire une petite interface basée sur une ligne de lecture sur quelque chose et en utilisant le shell emacs Mx, utilisez-le dans l'interface graphique emacs. Cela simplifie l'utilisation d'autres outils et fonctionnalités existantes.
Pour le débogage, gdb fonctionne bien mais je préfère généralement le débogueur VS. C'est probablement le meilleur logiciel que Microsoft ait jamais conçu.
Pour construire et faire fonctionner: faites. Ou bash. Partout où.
Pour le développement: emacs (conversion récente de vi, oh dommage!). Vi si vous travaillez via ssh.
Je ne peux vraiment pas m'habituer à Eclipse. Je pense que c'est un problème de "forme d'esprit": il ne correspond pas au mien.
la source
Pour moi, le passage à un flux de travail CLI à partir de Visual Studio impliquait de mémoriser de nombreuses commandes * nix. Cela impliquait également des maux de tête chaque fois que je gâchais un enregistrement SVN.
Mais la plus grande différence dans le flux de travail pour moi, c'est que j'ai acquis une meilleure compréhension du fonctionnement d'un système d'exploitation . Avec un workflow GUI, il suffisait de cliquer sur les boutons et d'attendre que le programme réponde. Dans le monde en ligne de commande, j'ai l'impression de dire directement à l'ordinateur de faire quelque chose.
En d'autres termes, un flux de travail GUI était l'ordinateur qui communiquait avec vous, tandis qu'un flux de travail CLI semblait plus comme si vous communiquiez directement avec l'ordinateur.
L'un n'est pas meilleur que l'autre, mais le passage d'un environnement entièrement basé sur une interface graphique au terminal était définitivement un voyage.
la source
Voici plus d'observations d'un programmeur qui a vécu dans les deux mondes. Je ne répéterai pas les points déjà soulevés dans d'autres réponses:
Le développement basé sur CLI a tendance à utiliser une variété de programmes, chacun remplissant 1 fonction. Le développement basé sur une interface graphique a tendance à utiliser 1 gros programme (l'IDE), qui exécute des dizaines de fonctions différentes. Cette seule différence a plusieurs conséquences:
Parce qu'un IDE est destiné à être votre "maison" unique où vous travaillez tout le temps, ils peuvent utiliser un format propriétaire (peut-être binaire) pour stocker vos données. La compatibilité n'est pas un gros problème, car ils ne s'attendent pas à ce que vous travailliez dans 2 IDE différents sur le même projet. Les outils CLI, en revanche, ne fonctionnent généralement qu'avec des fichiers en texte brut.
Avec le développement basé sur CLI, vous pouvez changer progressivement d'outils ou intégrer de nouveaux outils dans votre flux de travail, plus facilement. Choisir un IDE est plus tout ou rien, et changer d'IDE est plus douloureux.
L'utilisation d'un script de construction CLI, plutôt que le menu intégré de construction d'un IDE, rend plus probable que vous puissiez vous éloigner de votre code pendant quelques années, y revenir et le construire sans chichi. Avec le développement basé sur une interface graphique, il est probable que vous exécutiez un IDE complètement différent d'ici là. Peut-être que celui que vous utilisiez lorsque vous avez écrit le code ne fonctionne même pas sur votre système d'exploitation actuel.
Dans un IDE, créer vos propres outils signifie apprendre une API de plug-in (probablement grande) et peut-être utiliser un langage spécifique. Lorsque vous utilisez l'interface CLI, rien de spécial n'est nécessaire pour créer des outils personnalisés.
D'un autre côté, l'avantage d'un IDE est qu'il est bien "intégré". Vous pouvez donc cliquer dans la fenêtre de votre éditeur pour définir les points d'arrêt du débogueur, etc.
Autre point: votre choix dépendra également de la plate-forme de développement, du système d'exploitation et des langues que vous utilisez. Sur certaines plateformes, le développement basé sur l'IDE est profondément ancré dans la culture de développement en vigueur. Dans d'autres, le développement basé sur CLI est répandu. Si vous utilisez une plate-forme où le développement basé sur l'IDE est répandu, il est probable que les outils CLI seront mal développés et mal pris en charge. L'inverse est également vrai.
la source
La majeure partie de mon enfance n'a pas été consacrée à un ordinateur, car nous avions même accès à Internet à la ferme. J'ai commencé à programmer tard au lycée et j'ai essentiellement travaillé dans les interfaces graphiques. Au collège, j'ai rencontré un gars qui a grandi sur CLI et a tout fait de cette façon. J'ai donc décidé de configurer un serveur Linux plutôt que d'écouter le prof. Après quelques années, mon copain me regardait écrire du code intégré et ne pouvait pas croire comment j'écrivais.
J'utilise essentiellement la moitié de la CLI et la moitié de l'interface graphique. Il y a certaines choses que les environnements groupés GUI font beaucoup plus rapidement et plus efficacement. Et la même chose est vraie pour la CLI. La plupart de mes modifications de texte sont effectuées dans VIM car les éditeurs CLI avancés VIM / EMACS (pas de guerre ici s'il vous plaît) rendent la manipulation de texte la plus efficace. Des choses comme le débogage intégré à l'aide de GDB, d'autre part, sont aussi pénibles que l'édition de texte sans clavier. Bien sûr, il est puissant et sûr avec suffisamment de temps, vous trouverez les informations que vous recherchez, mais avoir une belle fenêtre GUI avec un accès instantané à n'importe quel bloc de mémoire est inestimable, surtout lorsque vous essayez de le comparer à un autre bloc de mémoire.
Quoi qu'il en soit, ce que j'essaie vraiment de dire, c'est que cela ne devrait pas être GUI vs CLI mais plutôt ce qui est le meilleur CLI et ce qui est mieux GUI. Parce qu'au final, si votre E / S est plus lente que votre processus de réflexion, il y a un problème.
la source
"converti en un gourou CLI du jour au lendemain?" Oui, il y a le hic. Les interfaces graphiques bien conçues ont tendance à être plus faciles à découvrir que les CLI, et plus indulgentes pour les débutants.
Mon flux de travail, récemment amélioré par un gestionnaire de fenêtres en mosaïque (dwm), consiste en beaucoup de saisie. Mon ordinateur portable est maintenant réellement utilisable sans brancher une souris (le trackpad est suffisant pour ce qui reste de pointage). Je garde beaucoup d'applications ouvertes et passe avec alt-tab. Je ne perds pas de temps à déplacer et redimensionner les fenêtres.
La plupart du temps, j'utilise un navigateur, vim et un tas de terminaux. SSH me donne beaucoup de flexibilité quant à l'endroit où je travaille (physiquement). Les bureaux à distance peuvent offrir une meilleure expérience lorsque nous avons tous un tuyau 10Gigabit sur le net, mais je ne retiens pas mon souffle.
Je n'ai pas assez bien appris vim pour profiter de ses fonctionnalités complexes, mais je penche dans cette direction - je veux que vim saute sur la bonne ligne # après un make échoué. (Techniquement, vim est une interface visuelle, même si elle s'exécute dans un terminal, mais je la pilote avec un clavier, pas une souris.)
Le vrai problème, ce sont les interfaces mal conçues . Les interfaces bien conçues sont difficiles à créer, donc elles ne se produisent pas très souvent dans les deux camps. Mais comme plus d'assistants non-ux conçoivent aujourd'hui des GUI que des CLI, ....
(Mon autre gros animal domestique est ballonné. Quand il faut un programme de 19 Mo pour m'aider à accomplir la même tâche qu'un programme de 200 Ko, quelque chose ne va pas. XTree Gold pour DOS a amélioré ma productivité plus que tout gestionnaire de fichiers moderne. Windows 2.11 utilisé uniquement en mosaïque Windows. Turbo C était un formidable IDE. Pourquoi mon Nook semble-t-il fonctionner plus lentement qu'un Mac classique?
la source
Avec les interfaces utilisateur graphiques, vous êtes obligé d'interagir avec le programme à plusieurs reprises pour effectuer la même opération encore et encore. Avec un shell, vous pouvez automatiser les choses plus facilement et faire fonctionner les programmes ensemble par le biais de canalisations - qui pourraient par exemple être utilisées pour générer des correspondances avec des expressions régulières dans un ensemble de fichiers ou de paquets réseau. Comme dit, c'est plus rapide pour de nombreuses opérations.
La programmation dans le terminal n'est peut-être pas tellement meilleure que dans un éditeur graphique, sauf si vous utilisez SSH.
Personnellement, j'ai trouvé le shell Unix beaucoup plus accessible que la ligne de commande Windows typique, et je suis maintenant très immergé dans un système Linux avec un gestionnaire de fenêtres en mosaïque et de nombreux terminaux.
la source
Tous vos exemples sont à peu près un processus en une seule étape. Dans la plupart des environnements GUI, si vous souhaitez déplacer un fichier qui n'a rien à voir avec l'application actuelle dans laquelle vous vous trouvez, vous pouvez le faire à partir du menu fichier sans quitter l'application. Aucun sens d'aller à une invite de commande. Si vous souhaitez copier le fichier et lui donner un nom différent, vous pouvez le faire en ligne de commande en une seule fois. Pour mettre cela dans un fichier batch, vous devez au moins savoir comment faire, mais vous pouvez ensuite exécuter le fichier batch depuis l'interface graphique si vous le souhaitez.
J'ai eu un débat similaire sur les commandes du clavier contre la souris.
la source
La façon dont je travaille favorise de loin l'interface graphique.
Utilisation typique:
Quant au principal avantage de la CLI, les scripts, je ne fais presque jamais cela. Les tâches répétées que nous avons ne sont que des applications cron job que nous avons regroupées en c # et qui ne sont pas souvent modifiées. Nous avons des moyens de faire fonctionner les choses sous Linux, mais principalement il est porté (boost), donc déconner avec des fichiers et de telles choses est minimisé. Et si les choses deviennent poilues, il existe également de bons IDE pour Linux.
la source