Wie unterscheidet sich der Workflow eines CLI-orientierten Programmierers von einem GUI-orientierten?

Ich habe viel über die Vorteile gehört, in GUI-Apps weniger Programmierarbeit zu leisten und mehr Befehlszeilentools zu verwenden (insbesondere im Hinblick auf eine effizientere Ausführung). Da jedoch verstehe ich nicht , wie mein Workflow wäre anders , wenn ich mehr auf Kommandozeilen - Tools angewiesen, kann ich nicht ohne weiteres beurteilen , ob es eine Auszahlung genug ist für mich persönlich Zeit und Mühe , das Erlernen einer neuen Toolset zu investieren und sich verändernden mein Workflow.

Jetzt sofort:

• Ich codiere einige Nebenprojekte in Sprachen wie C / C ++ / D / C # / Java / Python mit Visual Studio, Eclipse usw. und führe sie aus, indem ich die Build-Einstellungen einrichte und zum Erstellen / Ausführen F5 drücke.

• Ich entwickle bei der Arbeit ein Webprogramm, bei dem ich Django verwende, um einen Server einzurichten, eine Verbindung zu einer Datenbank herzustellen usw. Fast alles im SciTE-Texteditor.

• Zum Starten von regulären Programmen verwende ich Launchy ... noch kein Terminal. :)

• Zum Kopieren von Dateien und so weiter verwende ich ein reguläres Suchen / Verschieben im grafischen Dateimanager (Windows Explorer, Nautilus).

• Debugging: Ich verwende entweder Visual Studio oder Debugging-Tools für Windows (wenn ich unter Windows bin). Ich habe unter Linux nicht viel debuggt, aber für die Dinge, die ich getan habe, habe ich Eclipse verwendet (auch für Java unter Windows).

• Bei der Arbeit: Um eine Verbindung zum Build-System herzustellen und ein Projekt einzurichten, verwende ich nur in Eclipse integrierte Tools - kein Terminal oder ähnliches erforderlich (obwohl ich auf jeden Fall ein Terminal verwenden kann, wenn ich dies möchte) in der Tat wollen)

Wie ist es, diese Dinge in CLI zu tun? Welche Teile werden effizienter / weniger effizient? Welche Aspekte meines Workflows müssten geändert werden, um den größten Vorteil von einer Umstellung auf die Arbeit hauptsächlich in CLI zu erzielen? Mit anderen Worten ... Wenn Sie mich auf magische Weise in einen Kommandozeilen-Guru verwandelt hätten, wie würde sich mein neuer Codierungs-Workflow von meiner aktuellen, GUI-zentrierten Arbeitsweise unterscheiden?

Ich glaube nicht, dass das mehr stimmt. CLI hat einen besonderen Vorteil: Wenn Sie im Voraus wissen, wonach Sie suchen, können Sie es schneller eingeben, als Sie in einem Menü dorthin navigieren können. Das heißt, wenn Sie explizit Befehle an das Programm senden möchten, die wenig Kontext haben, ist dies meist schneller. Es gibt jedoch zwei Probleme.

Erstens können GUI-Programme auf den Kontext für Sie schließen. Zum Beispiel die Funktion Gehe zu Definition von Visual Studio und Intellisense. Wie können Sie diese Funktionen in einer CLI replizieren?

Zweitens können GUI-Programme Ihnen viel mehr anzeigen. Zum Beispiel der Visual Studio Parallel Profiler, ein Diagramm der CPU-Auslastung über mehrere Kerne hinweg. Wie können Sie das in einer CLI anzeigen? Es würde einfach keinen Sinn ergeben. Sobald Ihre Daten besser als etwas anderes als Text ausgedrückt werden, geht die CLI sofort verloren. Ein weiteres einfaches Beispiel sind Haltepunkte. In Visual Studio klicken Sie auf den Rand der Linie, auf die Sie einen Strich machen möchten. Was werden Sie in einer CLI tun, versuchen, die Datei und die Zeilennummer zu finden und diesen Befehl einzugeben? Dafür brauchen Sie ein relatives Jahrzehnt. Einige der neueren GUI-Innovationen, wie der Debugger-Canvas, zählen noch nicht einmal dazu.

Eine GUI ist möglicherweise langsamer, wenn Sie Ihre Zeit damit verbringen möchten, Debug immer wieder voranzutreiben. Sobald die Anwendungsfälle jedoch komplexer werden, kann CLI nicht mehr mithalten.

Ich denke, der größte Unterschied liegt nicht in den einzelnen Aufgaben, sondern in zwei Dingen:

In erster Linie Automatisierung. CLI ist von Natur aus skriptfähig, was unter Windows normalerweise schwieriger ist. Ich habe gehört, dass sich die Dinge mit PowerShell verbessert haben, aber ich habe es nicht verwendet.

Zweitens die UNIX-Philosophie der "Trennung von Bedenken". Ich kann eine kleine readline-basierte Schnittstelle für etwas schreiben und mit der emacs Mx-Shell in der emacs-GUI verwenden. Dies erleichtert die Nutzung anderer Tools und vorhandener Funktionen.

Für das Debuggen von GDB funktioniert gut, aber ich bevorzuge in der Regel VS-Debugger. Es ist wahrscheinlich die beste Software, die Microsoft jemals gemacht hat.

Zum Bauen und Laufen: machen. Oder bash. Wo auch immer.

Für die Entwicklung: Emacs (kürzlich von vi konvertiert, oh Schande!). Vi, wenn Sie Arbeit durch ssh tun.

Ich kann mich wirklich nicht an Eclipse gewöhnen. Ich denke, es ist ein "Form-von-Geist" -Problem: Es passt nicht zu meinem.

Für mich bedeutete der Wechsel von Visual Studio zu einem CLI-Workflow das Speichern vieler * nix-Befehle. Es brachte auch einige Kopfschmerzen mit sich, wenn ich einen SVN-Check-in versaut habe.

Der größte Unterschied für mich war jedoch, dass ich besser verstand, wie ein Betriebssystem funktioniert . Bei einem GUI-Workflow musste nur auf Schaltflächen geklickt und auf die Antwort des Programms gewartet werden. In der Kommandozeilen-Welt habe ich das Gefühl, ich fordere den Computer direkt auf, etwas zu tun.

Mit anderen Worten, ein GUI-Workflow war der Computer, der mit Ihnen kommuniziert, während ein CLI-Workflow eher so aussah, als würden Sie direkt mit dem Computer kommunizieren.

Das eine ist nicht besser als das andere, aber der Wechsel von einer vollständig GUI-basierten Umgebung zum Terminal war auf jeden Fall eine Reise.

Hier sind weitere Beobachtungen eines Programmierers, der in beiden Welten gelebt hat. Ich werde Punkte, die bereits in anderen Antworten gemacht wurden, nicht wiederholen:

Bei der CLI-basierten Entwicklung werden in der Regel verschiedene Programme verwendet, von denen jedes eine Funktion ausführt. GUI-basierte Entwicklung verwendet in der Regel ein großes Programm (die IDE), das Dutzende verschiedener Funktionen ausführt. Dieser eine Unterschied hat mehrere Konsequenzen:

Da eine IDE Ihr "Zuhause" sein soll, in dem Sie die ganze Zeit arbeiten, verwenden sie möglicherweise ein proprietäres (möglicherweise binäres) Format, um Ihre Daten zu speichern. Die Kompatibilität ist kein großes Problem, da nicht erwartet wird, dass Sie in zwei verschiedenen IDEs am selben Projekt arbeiten. CLI-Tools hingegen arbeiten im Allgemeinen nur mit Nur-Text-Dateien.

Mit der CLI-basierten Entwicklung können Sie Tools schrittweise austauschen oder neue Tools einfacher in Ihren Workflow integrieren. Die Auswahl einer IDE ist mehr Alles oder Nichts, und das Wechseln der IDE ist schmerzhafter.

Durch die Verwendung eines CLI-Erstellungsskripts anstelle des integrierten "Build" -Menüs einer IDE ist es wahrscheinlicher, dass Sie einige Jahre lang Ihren Code verlassen, wieder darauf zugreifen und ihn ohne großen Aufwand erstellen können. Bei einer GUI-basierten Entwicklung ist es wahrscheinlich, dass Sie bis dahin eine völlig andere IDE ausführen. Vielleicht läuft die, die Sie beim Schreiben des Codes verwendet haben, nicht einmal auf Ihrem aktuellen Betriebssystem.

In einer IDE bedeutet das Erstellen eigener Tools das Erlernen einer (wahrscheinlich großen) Plug-in-API und möglicherweise die Verwendung einer bestimmten Sprache. Bei Verwendung der CLI sind keine speziellen Tools erforderlich, um benutzerdefinierte Tools zu erstellen.

Andererseits ist der Vorteil einer IDE, dass sie "integriert" ist. Sie können also in Ihr Editorfenster klicken, um Debugger-Haltepunkte usw. festzulegen.

Ein weiterer Punkt: Ihre Wahl hängt auch von der Entwicklungsplattform, dem Betriebssystem und der Sprache (n) ab, die Sie verwenden. Auf bestimmten Plattformen ist die IDE-basierte Entwicklung in der vorherrschenden Entwicklungskultur tief verwurzelt. In anderen Ländern ist die CLI-basierte Entwicklung weit verbreitet. Wenn Sie eine Plattform verwenden, auf der IDE-basierte Entwicklung vorherrscht, werden CLI-Tools wahrscheinlich schlecht entwickelt und schlecht unterstützt. Das Gegenteil ist auch wahr.

Die meiste Zeit meiner Kindheit verbrachte ich nicht am Computer, da wir auf der Farm sogar Internet hatten. Ich habe spät in der High School angefangen zu programmieren und habe im Grunde die ganze Zeit in GUIs gearbeitet. Im College habe ich einen Mann getroffen, der mit CLI aufgewachsen ist und alles so gemacht hat. Also habe ich beschlossen, einen Linux-Server einzurichten, anstatt den Prof zu hören. Nach ein paar Jahren beobachtete mein Kumpel, wie ich eingebetteten Code schrieb und konnte nicht glauben, wie ich schrieb.

Ich benutze grundsätzlich halb CLI, halb GUI. Es gibt einige Dinge, die GUI-Umgebungen wesentlich schneller und effizienter erledigen. Gleiches gilt für die CLI. Der größte Teil meiner Textbearbeitung erfolgt in VIM, da die erweiterten CLI-Editoren VIM / EMACS (hier bitte keine Kriege) die Textbearbeitung am effizientesten machen. Dinge wie das eingebettete Debuggen mit GDB sind genauso schmerzhaft wie das Bearbeiten von Text ohne Tastatur. Sicher, es ist leistungsstark und sicher, dass Sie mit genügend Zeit die Informationen finden, nach denen Sie suchen, aber ein nettes GUI-Fenster mit sofortigem Zugriff auf jeden Speicherblock ist von unschätzbarem Wert, insbesondere wenn Sie versuchen, ihn mit einem anderen Speicherblock zu vergleichen.

Auf jeden Fall versuche ich wirklich zu sagen, dass es nicht GUI gegen CLI sein sollte, sondern vielmehr, was CLI besser kann und was GUI besser kann. Denn am Ende, wenn Ihr IO langsamer ist als Ihr Denkprozess, gibt es ein Problem.

"Über Nacht in einen CLI-Guru verwandelt?" Ja, da ist die Reibung. Gut gestaltete GUIs sind in der Regel besser erkennbar als CLIs und für Neulinge eher nachsichtig.

Mein Workflow, der kürzlich durch einen Kachel-Fenstermanager (dwm) erweitert wurde, besteht aus vielen Eingaben. Mein Laptop ist jetzt tatsächlich ohne Anschließen einer Maus verwendbar (das Trackpad ist ausreichend für die verbleibenden Punkte). Ich halte viele Apps offen und wechsle mit Alt-Tab. Ich verschwende keine Zeit damit, Fenster zu verschieben und ihre Größe zu ändern.

Die meiste Zeit benutze ich einen Browser, VIM und eine Reihe von Terminals. SSH gibt mir viel Flexibilität, wo ich (physisch) arbeite. Remote-Desktops bieten vielleicht eine bessere Erfahrung, wenn wir alle eine 10-Gigabit-Leitung zum Netz haben, aber ich werde nicht den Atem anhalten.

Ich habe vim nicht gut genug gelernt, um die komplexen Funktionen zu nutzen, aber ich lehne mich in diese Richtung - ich möchte, dass vim nach einem fehlgeschlagenen Make in die richtige Zeile # springt. (Technisch gesehen ist vim ein visuelles Interface, obwohl es in einem Terminal ausgeführt wird, aber ich treibe es mit einer Tastatur und nicht mit einer Maus.)

Das eigentliche Problem sind schlecht gestaltete Schnittstellen. Gut gestaltete Schnittstellen sind schwer zu erstellen, daher kommen sie in beiden Camps nur selten vor. Aber da heutzutage mehr Nicht-UX-Assistenten GUIs entwerfen als CLIs, ...

(Mein anderer großer Liebling ist aufgebläht. Wenn ich mit einem 19-MB-Programm die gleiche Aufgabe wie mit einem 200-KB-Programm ausführen kann, stimmt etwas nicht. XTree Gold für DOS hat meine Produktivität mehr gesteigert als jeder moderne Dateimanager. Windows 2.11 wurde nur gekachelt verwendet Windows. Turbo C war eine großartige IDE. Warum scheint mein Nook langsamer zu laufen als ein Mac-Klassiker? Warum belegt der Kernel allein jetzt mehr Speicherplatz als das gesamte System früher?)

Bei grafischen Benutzeroberflächen müssen Sie wiederholt mit dem Programm interagieren, um denselben Vorgang immer wieder auszuführen. Mit einer Shell können Sie die Dinge einfacher automatisieren und Programme über Piping zusammenarbeiten lassen - beispielsweise um Übereinstimmungen mit regulären Ausdrücken in einer Reihe von Dateien oder Netzwerkpaketen auszugeben. Wie gesagt, ist es für viele Operationen schneller.

Die Programmierung im Terminal ist vielleicht nicht so viel besser als in einem grafischen Editor, es sei denn, Sie verwenden SSH.

Ich persönlich fand die Unix-Shell viel zugänglicher als die typische Windows-Befehlszeile und bin jetzt auf einem Linux-System mit einem Kacheln-Fenstermanager und vielen Terminals sehr darin vertieft.

Alle Ihre Beispiele sind so ziemlich ein einstufiger Prozess. Wenn Sie in den meisten GUI-Umgebungen eine Datei verschieben möchten, die nichts mit der aktuellen Anwendung zu tun hat, in der Sie sich befinden, können Sie dies über das Dateimenü tun, ohne die Anwendung zu verlassen. Es macht keinen Sinn, zu einer Eingabeaufforderung zu gehen. Wenn Sie die Datei kopieren und einen anderen Namen vergeben möchten, können Sie dies in einer Befehlszeile auf einmal tun. Um dies in eine Batch-Datei einzufügen, müssen Sie zumindest wissen, wie dies getan wird, aber Sie können die Batch-Datei dann über die GUI ausführen, wenn Sie dies möchten.

Ich hatte eine ähnliche Debatte über Tastaturbefehle gegenüber der Maus.

Die Art und Weise, wie ich arbeite, begünstigt bei weitem die grafische Benutzeroberfläche.

Typische Verwendung:

• Drei IDEs für drei verschiedene Plattformen. Auch ein Notepad ++ Fenster für einige Skripte. Es gibt einfach keine Möglichkeit, mir Befehle für all diese Build-Systeme zu merken. Das Problem mit CLI ist, dass Sie viele Details kennen müssen, damit ein Build funktioniert. Moderne IDES bieten standardmäßig einige geeignete Optionen. Sie können jederzeit einen genaueren Blick darauf werfen, wenn die Zeit gekommen ist.
• SVN oder Git integriert. Es gibt so viele Optionen für ein Programm, die zusätzlich zur Programmierung verfügbar sind, und die meiste Zeit mache ich nur ein Commit oder ein Update.
• Netzwerkmaterial: Zum Glück kann ich das gesamte Netzwerk auch in unserem Büro einrichten. Die meisten Netzwerkkarten bieten eine Vielzahl von CLI-Befehlen. Wenn Sie jedoch einen Überblick über den Status benötigen, sind dies Firewall und Routing. Beim Routing kann ich fast mit der Befehlszeile leben, aber Firewalls werden kompliziert, und wenn es eine Sache gibt, die GUIs können, werden viele Informationen angezeigt.
• Im Allgemeinen gibt es eine Menge Bewegung von einer Sache zur anderen. Kontextwechsel sind mit einem visuellen Kontext einfacher.

Was den Hauptnutzen von CLI und Skripten angeht, mache ich das kaum. Die wiederholten Aufgaben, die wir haben, sind nur Cron-Job-Apps, die wir in c # zusammengefasst und nicht oft geändert haben. Wir haben zwar Möglichkeiten, Dinge unter Linux zum Laufen zu bringen, aber hauptsächlich ist es portiert (Boost), so dass das Herumspielen mit Dateien und solchen Dingen minimiert wird. Und wenn es mal haarig wird, gibt es auch für Linux gute IDEs.