In che modo il flusso di lavoro di un programmatore orientato alla CLI differisce da quello orientato alla GUI?

Ho sentito molto parlare dei vantaggi di svolgere meno lavoro di programmazione nelle app GUI e di utilizzare più strumenti da riga di comando (soprattutto per quanto riguarda l'esecuzione delle operazioni in modo più efficiente). Tuttavia, poiché non capisco in che modo il mio flusso di lavoro sarebbe diverso se dipendessi maggiormente dagli strumenti da riga di comando, non riesco a valutare prontamente se per me personalmente ho abbastanza payoff per investire tempo e fatica nell'apprendere un nuovo set di strumenti e cambiare il mio flusso di lavoro.

Proprio adesso:

• Codifico alcuni progetti secondari in linguaggi come C / C ++ / D / C # / Java / Python usando Visual Studio, Eclipse, ecc., E li eseguo configurando le impostazioni di compilazione e premendo F5 per compilare / eseguire.

• Sto sviluppando un programma web al lavoro, quindi ciò implica l'utilizzo di Django per configurare un server, connettersi a un database, ecc ... quasi tutto all'interno dell'editor di testo SciTE.

• Per l'avvio di programmi regolari, uso Launchy ... ancora nessun terminale. :)

• Per la copia di file e quant'altro, uso una normale ricerca / spostamento nel file manager grafico (Windows Explorer, Nautilus).

• Debug: utilizzo Visual Studio o strumenti di debug per Windows (se utilizzo Windows). Non ho fatto molto il debug su Linux, ma per le cose che ho fatto, ho usato Eclipse (anche per Java su Windows).

• Al lavoro: per connettermi al sistema di compilazione e impostare un progetto, utilizzo semplicemente strumenti che sono stati integrati in Eclipse per il mio uso, senza bisogno di un terminale o altro (anche se sono certamente il benvenuto ad usare un terminale se anzi voglio)

Com'è fare queste cose nella CLI? Quali parti diventano più / meno efficienti? Quali aspetti del mio flusso di lavoro dovrebbero essere modificati per ottenere il massimo vantaggio dal passaggio al lavoro principalmente nella CLI? In altre parole ... Se mi trasformassi magicamente in un guru della riga di comando, in che modo il mio nuovo flusso di lavoro di codifica sarebbe diverso dal mio modo attuale, incentrato sulla GUI, di fare le cose?

Non penso che questo sia più vero. L'interfaccia della riga di comando ha un vantaggio specifico: se sai in anticipo cosa stai cercando, puoi digitarlo più velocemente di quanto puoi navigare in un menu. Ciò significa che se si desidera in modo esplicito inviare comandi al programma che hanno un contesto limitato, è per lo più più veloce. Tuttavia, ci sono due problemi.

In primo luogo, i programmi GUI possono inferire il contesto per te. Ad esempio, la funzionalità Vai alla definizione di Visual Studio e Intellisense. Come hai potuto replicare quelle funzionalità in una CLI?

In secondo luogo, i programmi della GUI possono mostrarti molto di più. Ad esempio, Visual Studio Parallel Profiler, che è un grafico dell'utilizzo della CPU su più core nel tempo. Come hai potuto visualizzarlo in una CLI? Non avrebbe senso. Non appena i tuoi dati vengono espressi meglio come qualcosa di diverso dal testo, la CLI viene immediatamente persa. Un altro semplice esempio sono i punti di interruzione. In Visual Studio, fai clic sul margine della linea su cui desideri interrompere. Che cosa hai intenzione di fare in una CLI, provare a trovare il file e il numero di riga e inserire quel comando? Ti ci vorrà un decennio relativo. Questo non conta nemmeno alcune delle più recenti innovazioni della GUI, come il Debugger Canvas.

Una GUI potrebbe essere più lenta se si desidera passare il tempo a spingere ripetutamente Debug, ma non appena i casi d'uso diventano più complessi, non è possibile che la CLI tenga il passo.

Penso che la differenza più grande non risieda nei singoli compiti ma in due cose:

Innanzitutto, l'automazione. L'interfaccia della riga di comando è intrinsecamente gestibile tramite script, che di solito è più difficile su Windows. Ho sentito cose migliorate con PowerShell ma non l'ho usato.

In secondo luogo, la filosofia UNIX di "separazione delle preoccupazioni". Riesco a scrivere una piccola interfaccia basata su readline su qualcosa e usando emacs la shell Mx la usa all'interno della GUI di emacs. Ciò semplifica l'utilizzo di altri strumenti e funzionalità esistenti.

Per il debug gdb funziona bene ma di solito preferisco il debugger VS. È probabilmente il miglior software che Microsoft abbia mai fatto.

Per costruire e gestire cose: crea. O bash. Dovunque.

Per lo sviluppo: emacs (recente conversione da vi, oh vergogna!). Vi se stai facendo un lavoro attraverso ssh.

Non riesco davvero ad abituarmi a Eclipse. Penso che sia un problema di "forma d'animo": non si adatta al mio.

Per me, il passaggio a un flusso di lavoro della CLI da Visual Studio ha comportato la memorizzazione di molti comandi * nix. Ha anche comportato alcuni mal di testa ogni volta che ho incasinato un check-in SVN.

Ma la più grande differenza nel flusso di lavoro per me è che ho acquisito una migliore comprensione di come funziona un sistema operativo . Con un flusso di lavoro della GUI, era sufficiente fare clic sui pulsanti e attendere che il programma rispondesse. Nel mondo della riga di comando, mi sento come se stessi dicendo al computer direttamente di fare qualcosa.

In altre parole, un flusso di lavoro della GUI era il computer che ti comunicava, mentre un flusso di lavoro della CLI sembrava più come se stessi comunicando direttamente con il computer.

Uno non è migliore dell'altro, ma passare da un ambiente totalmente basato sulla GUI al terminale è stato sicuramente un viaggio.

Ecco altre osservazioni di un programmatore che ha vissuto in entrambi i mondi. Non ripeterò i punti già espressi in altre risposte:

Lo sviluppo basato sulla CLI tende a utilizzare una varietà di programmi, ognuno dei quali svolge 1 funzione. Lo sviluppo basato sulla GUI tende a utilizzare 1 grande programma (IDE), che esegue dozzine di funzioni diverse. Questa unica differenza ha diverse conseguenze:

Poiché un IDE è destinato a essere la tua unica "casa" in cui lavori continuamente, possono utilizzare un formato proprietario (forse binario) per conservare i tuoi dati. La compatibilità non è un grosso problema, perché non si aspettano che tu lavori in 2 IDE diversi sullo stesso progetto. Gli strumenti della CLI, d'altra parte, funzionano generalmente solo con file di testo semplice.

Con lo sviluppo basato sulla CLI, è possibile cambiare in modo incrementale strumenti o integrare nuovi strumenti nel flusso di lavoro, più facilmente. Scegliere un IDE è più o meno, e cambiare l'IDE è più doloroso.

L'uso di uno script di compilazione della CLI, piuttosto che del menu "Build" incorporato di IDE, rende più probabile che tu possa allontanarti dal tuo codice per alcuni anni, tornare su di esso e costruirlo senza problemi. Con lo sviluppo basato sulla GUI, è probabile che tu abbia già eseguito un IDE completamente diverso. Forse quello che stavi usando quando hai scritto il codice non funziona nemmeno sul tuo attuale sistema operativo.

In un IDE, costruire i propri strumenti significa apprendere un'API plug-in (probabilmente di grandi dimensioni) e magari usare una lingua specifica. Quando si utilizza l'interfaccia della riga di comando, non è necessario nulla di speciale per creare strumenti personalizzati.

D'altra parte, il vantaggio di un IDE è che è, ben, "integrato". Quindi puoi fare clic nella finestra dell'editor per impostare i punti di interruzione del debugger e così via.

Un altro punto: la tua scelta dipenderà anche dalla piattaforma di sviluppo, dal sistema operativo e dalle lingue che usi. Su alcune piattaforme, lo sviluppo basato su IDE è profondamente radicato nella cultura di sviluppo prevalente. In altri, lo sviluppo basato sulla CLI è prevalente. Se si utilizza una piattaforma in cui è prevalente lo sviluppo basato su IDE, è probabile che gli strumenti della CLI saranno poco sviluppati e scarsamente supportati. Anche il contrario è vero.

La maggior parte della mia infanzia non è stata trascorsa su un computer poiché non avevamo nemmeno internet nella fattoria. Ho iniziato a programmare tardi al liceo e praticamente ho sempre lavorato nelle GUI. Al college ho incontrato un ragazzo cresciuto alla CLI e fatto tutto così. Così ho deciso di configurare un server Linux piuttosto che ascoltare il prof. Dopo qualche anno il mio amico mi guardava mentre scrivevo del codice incorporato e non riuscivo a credere a come lo scrivessi.

In pratica utilizzo metà dell'interfaccia grafica e metà dell'interfaccia grafica. Ci sono alcune cose che gli ambienti in bundle della GUI fanno molto più velocemente e in modo più efficiente. E lo stesso vale per la CLI. La maggior parte della mia modifica del testo viene eseguita in VIM poiché gli editor CLI avanzati VIM / EMACS (nessuna guerra qui per favore) rendono la manipolazione del testo più efficiente. D'altra parte cose come il debug incorporato usando GDB, è doloroso come modificare il testo senza una tastiera. Sicuramente è potente e sicuro con abbastanza tempo troverai le informazioni che stai cercando ma avere una bella finestra della GUI con accesso istantaneo a qualsiasi blocco di memoria è inestimabile soprattutto quando cerchi di confrontarlo con un altro blocco di memoria.

Ad ogni modo, quello che sto davvero cercando di dire è che non dovrebbe essere la GUI contro la CLI, ma piuttosto cosa è meglio la CLI e cosa è meglio la GUI. Perché alla fine se il tuo IO è più lento del tuo processo di pensiero c'è un problema.

"convertito in un guru CLI dall'oggi al domani?" Sì, c'è il problema. Le GUI ben progettate tendono ad essere più rilevabili delle CLI e più indulgenti con il neofita.

Il mio flusso di lavoro, recentemente migliorato da un window manager di piastrellatura (dwm), consiste in molte digitazioni. Il mio laptop ora è effettivamente utilizzabile senza collegare un mouse (il trackpad è adeguato per ciò che resta del puntamento). Tengo molte app aperte e cambio con alt-tab. Non perdo tempo a spostare e ridimensionare le finestre.

Il più delle volte, utilizzo un browser, vim e un sacco di terminali. SSH mi dà molta flessibilità su dove lavoro (fisicamente). I desktop remoti possono offrire un'esperienza migliore quando tutti abbiamo 10Gigabit pipe in rete, ma non trattengo il respiro.

Non ho imparato abbastanza bene vim per sfruttare le sue complesse funzionalità, ma mi sto inclinando in quella direzione - voglio che vim salti sulla linea giusta # dopo un fallimento. (Tecnicamente vim è un'interfaccia visiva, anche se funziona in un terminale, ma lo guido con una tastiera, non con un mouse.)

Il vero problema sono le interfacce mal progettate . Le interfacce ben progettate sono difficili da creare, quindi non si verificano molto spesso in nessuno dei due campi. Ma dal momento che più maghi non-ux stanno progettando GUI oggi rispetto alle CLI, ....

(L'altra mia grande pipì da compagnia è gonfia. Quando ci vuole un programma da 19 MB per aiutarmi a svolgere la stessa attività di un programma da 200 kB, qualcosa non va. XTree Gold per DOS ha migliorato la mia produttività più di qualsiasi moderno file manager. Windows 2.11 usato solo piastrellato Windows. Turbo C era un IDE fantastico. Perché il mio Nook sembra funzionare più lentamente di un classico Mac? Perché ora il kernel da solo occupa più spazio su disco rispetto all'intero sistema utilizzato?)

Con le interfacce utente grafiche, sei costretto a interagire ripetutamente con il programma per eseguire più volte la stessa operazione. Con una shell, puoi automatizzare le cose più facilmente e far lavorare i programmi insieme tramite il piping, che potrebbe ad esempio essere usato per generare corrispondenze con espressioni regolari in un set di file o pacchetti di rete. Come detto, è più veloce per molte operazioni.

La programmazione nel terminale forse non è molto meglio che in un editor grafico, a meno che non si usi SSH.

Personalmente ho trovato la shell unix molto più accessibile rispetto alla tipica riga di comando di Windows, e ora sono molto immersa su di essa su un sistema Linux con un window manager di piastrellatura e molti terminali.

Tutti i tuoi esempi sono praticamente un processo in un solo passaggio. Nella maggior parte degli ambienti con interfaccia grafica, se si desidera spostare un file che non ha nulla a che fare con l'applicazione corrente in cui ci si trova, è possibile farlo dal menu file senza uscire dall'applicazione. Non ha senso andare al prompt dei comandi. Se volevi copiare il file e assegnargli un nome diverso, su una riga di comando puoi farlo tutto in una volta. Per inserirlo in un file batch, è necessario almeno sapere come fare, ma se lo si desidera è possibile eseguire il file batch dalla GUI.

Ho avuto un dibattito simile sui comandi da tastiera contro il mouse.

Il modo in cui lavoro favorisce di gran lunga la GUI.

Utilizzo tipico:

• Tre IDE per tre diverse piattaforme. Anche una finestra di Notepad ++ per alcuni script. Semplicemente non avrei modo di ricordare i comandi per tutti quei sistemi di compilazione. Il problema con la CLI è che devi conoscere molti dettagli solo per far funzionare una build. Gli IDES moderni normalmente hanno alcune opzioni appropriate per impostazione predefinita. Puoi sempre dare un'occhiata più da vicino quando arriva il momento.
• SVN o Git integrati. Ci sono così tante opzioni per un programma che è accessorio alla programmazione, e la maggior parte delle volte sto solo eseguendo il commit o l'aggiornamento.
• Roba di rete: per fortuna, riesco anche a fare tutte le impostazioni di rete nel nostro ufficio. La maggior parte delle schede di rete ti darà un sacco di comandi CLI, ma se c'è una cosa in cui hai bisogno di una panoramica dello stato, è il firewall e il routing. Per il routing posso quasi vivere con la riga di comando, ma i firewall diventano complicati e se c'è una cosa che le GUI sono brave a mostrare molte informazioni.
• Generalmente si passa molto da una cosa all'altra. Gli switch di contesti sono più facili con un contesto visivo.

Per quanto riguarda il principale vantaggio della CLI, lo scripting, non lo faccio quasi mai. Le attività ripetute che abbiamo sono solo app di cron job che abbiamo messo insieme in c # e che non sono cambiate spesso. Abbiamo modi per far funzionare le cose in Linux, ma principalmente è portato (boost), quindi fare casino con i file e cose del genere è ridotto al minimo. E se le cose diventano pelose, ci sono buoni IDE anche per Linux.