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

Non penso che questo sia più vero. La CLI ha un vantaggio specifico: se sai in anticipo cosa stai cercando, puoi digitarlo più velocemente di quanto tu possa navigare in un menu. Ciò significa che se desideri esplicitamente impartire comandi al programma che hanno un piccolo contesto, allora è per lo più più veloce. Tuttavia, ci sono due problemi.

In primo luogo, i programmi della GUI possono dedurre il contesto per te. Ad esempio, la funzionalità Vai alla definizione di Visual Studio e Intellisense. Come potresti replicare queste 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 potresti mostrarlo in una CLI? Non avrebbe senso. Non appena i tuoi dati saranno espressi meglio come qualcosa di diverso dal testo, la CLI viene immediatamente persa. Un altro semplice esempio sono i breakpoint. In Visual Studio, fai clic sul margine della linea che vuoi spezzare. Che cosa hai intenzione di fare in una CLI, provare a trovare il numero di file e linea e inserire quel comando? Ti prenderà un decennio relativo. Questo non significa nemmeno contare alcune delle più recenti innovazioni della GUI, come Debugger Canvas.

Una GUI potrebbe essere più lenta se si vuole passare il tempo a spingere Debug più e più volte, ma non appena i casi d'uso diventano più complessi, allora non c'è modo che la CLI possa tenere il passo.

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

Prima di tutto, l'automazione. La CLI è intrinsecamente programmabile, 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". Posso scrivere una piccola interfaccia basata su readline su qualcosa e usare la shell M-x di emacs usarla nella GUI di emacs. Ciò rende più semplice sfruttare altri strumenti e funzionalità esistenti.

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

Per costruire e gestire le cose: make. O bash. Dovunque.

Per lo sviluppo: emacs (recente conversione da vi, oh vergogna!). Vi se lavori con ssh.

Non riesco davvero ad abituarmi a Eclipse. Penso che sia un problema di "forma della mente": non è adatto al mio.

Per me, passare a un flusso di lavoro CLI da Visual Studio comportava la memorizzazione di molti comandi * nix. Ha anche coinvolto alcuni mal di testa ogni volta che ho incasinato un controllo SVN.

Ma la più grande differenza nel flusso di lavoro per me è stata la 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 comunicare direttamente con il computer.

Uno non è migliore dell'altro, ma fare il passaggio da un ambiente totalmente GUI al terminale è stato sicuramente un viaggio.

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

Lo sviluppo basato su CLI tende a utilizzare una varietà di programmi, ognuno dei quali esegue 1 funzione. Lo sviluppo basato su GUI tende ad utilizzare 1 grande programma (l'IDE), che esegue decine di funzioni diverse. Questa differenza ha diverse conseguenze:

Poiché un IDE è inteso come la tua unica "casa" in cui lavori sempre, possono utilizzare un formato proprietario (forse binario) per conservare i tuoi dati. La compatibilità non è una grande preoccupazione, perché non si aspetta che tu lavori in 2 IDE diversi sullo stesso progetto. Gli strumenti CLI, d'altra parte, generalmente funzionano solo con file di testo semplice.

Con lo sviluppo basato su CLI, è possibile cambiare gradualmente gli strumenti o integrare nuovi strumenti nel flusso di lavoro, più facilmente. La scelta di un IDE è più "tutto-o-niente" e il passaggio dell'IDE è più doloroso.

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

In un IDE, creare strumenti propri significa apprendere un'API plug-in (probabilmente di grandi dimensioni) e magari utilizzare una lingua specifica. Quando si utilizza la CLI, non è necessario nulla di speciale per creare strumenti personalizzati.

D'altro canto, il vantaggio di un IDE è che è, beh, "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 utilizzi. Su alcune piattaforme, lo sviluppo basato su IDE è profondamente radicato nella cultura dello sviluppo prevalente. In altri, lo sviluppo basato sulla CLI è prevalente. Se si utilizza una piattaforma in cui lo sviluppo basato su IDE è prevalente, è probabile che gli strumenti CLI siano poco sviluppati e poco supportati. Anche il contrario è vero.

La maggior parte della mia infanzia non è stata spesa su un computer poiché avevamo anche l'accesso a Internet nella fattoria. Ho iniziato a programmare fino a tardi alle superiori e praticamente continuavo a lavorare in GUI. All'università ho incontrato un ragazzo cresciuto in CLI e ha fatto tutto in quel modo. Così ho deciso di installare un server Linux piuttosto che ascoltare il prof. Dopo alcuni anni il mio amico mi guardava scrivere un codice incorporato e non potevo credere a come scrivevo.

In pratica uso metà mezza 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 del mio editing di testo è fatto in VIM come gli editor di CLI avanzati VIM / EMACS (non ci sono guerre qui per favore) rendendo la manipolazione del testo la più efficiente. Cose come il debugging incorporato con GDB d'altra parte, sono dolorose quanto la modifica del testo senza tastiera. Certo è potente e sicuro con il tempo necessario per trovare le informazioni che stai cercando, ma avere una bella finestra GUI con accesso immediato a qualsiasi blocco di memoria ha un valore inestimabile, specialmente quando si prova a confrontarlo con un altro blocco di memoria.

Comunque, quello che sto cercando di dire è che non dovrebbe essere la GUI o la CLI, ma piuttosto che cos'è la CLI migliore e che cos'è la GUI migliore. Perché alla fine, se il tuo IO è più lento del tuo processo mentale, c'è un problema.

"convertito in un guru della CLI durante la notte?" Sì, c'è il problema. Le GUI ben progettate tendono ad essere più facilmente individuabili delle CLI e più indulgenti verso i principianti.

Il mio flusso di lavoro, recentemente migliorato da un gestore di finestre affiancate (dwm), consiste in un sacco di digitazione. 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 spreco tempo a spostare e ridimensionare le finestre.

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

Non ho imparato abbastanza bene da trarre vantaggio dalle sue complesse funzionalità, ma mi sto appoggiando in quella direzione - voglio fare un salto sulla linea destra # dopo un fallimento. (Tecnicamente vim è un'interfaccia visiva, anche se gira su un terminale, ma la 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 accadono molto spesso in entrambi i campi. Ma dal momento che più maghi non-ux stanno progettando GUI oggi che CLI, ....

(Il mio altro grosso cruccio è ingigantito. Quando ci vuole un programma da 19 MB per aiutarmi a svolgere lo stesso compito di un programma da 200kB, qualcosa non va. XTree Gold per DOS ha migliorato la mia produttività più di qualsiasi gestore di file moderno. usato solo finestre affiancate Turbo C era un IDE fantastico, perché il mio Nook sembra funzionare più lentamente di un classico Mac? Perché il kernel da solo occupa più spazio su disco rispetto a tutto il sistema utilizzato?)

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

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

Personalmente ho trovato la shell unix molto più accessibile della tipica linea di comando di Windows, e ora sono molto immersa in esso su un sistema Linux con un gestore di finestre di piastrellatura e molti terminali.

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

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

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

Uso tipico:

• Tre IDE per tre diverse piattaforme. Anche una finestra di Notepad ++ per alcuni script. Semplicemente non potrei ricordare i comandi per tutti quei sistemi di costruzione. Il problema con la CLI è che devi conoscere molti dettagli solo per far funzionare una build. Gli IDES moderni normalmente hanno alcune opzioni appropriate in questo caso 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 è ancillare alla programmazione, e il più delle volte sto facendo solo commit o update.
• Reti di rete: mi ha fatto piacere, riesco a eseguire tutte le impostazioni di rete anche nel nostro ufficio. La maggior parte delle schede di rete fornirà un carico di comandi CLI, ma se c'è una cosa in cui è necessaria una panoramica dello stato, è il firewall e il routing. Per il routing posso quasi vivere con la riga di comando, ma i firewall si complicano e se c'è una cosa su cui le GUI sono buone mostra molte informazioni.
• Generalmente c'è molto movimento da una cosa all'altra. Le opzioni dei contesti sono più semplici con un contesto visivo.

Per quanto riguarda il vantaggio principale della CLI, lo scripting, lo faccio quasi mai. I compiti ripetuti che abbiamo sono solo app di cron job che abbiamo gettato insieme in c # e non sono cambiati spesso. Abbiamo dei modi per far funzionare le cose in Linux, ma principalmente è porting (boost), quindi fare casino con i file e tali cose sono ridotte al minimo. E se le cose si complicano, ci sono buoni IDE anche per Linux.