Como o fluxo de trabalho de um programador orientado a CLI difere do fluxo orientado a GUI?

Eu ouvi muito sobre as vantagens de fazer menos trabalho de programação em aplicativos de GUI e usar mais ferramentas de linha de comando (especialmente no que diz respeito a fazer as coisas com mais eficiência). No entanto, como eu não entendo como meu fluxo de trabalho seria diferente se eu dependesse mais das ferramentas de linha de comando, não posso avaliar prontamente se há uma recompensa suficiente para mim pessoalmente investir tempo e esforço para aprender um novo conjunto de ferramentas e mudar meu fluxo de trabalho.

Agora mesmo:

• Codifico alguns projetos paralelos em linguagens como C / C ++ / D / C # / Java / Python usando o Visual Studio, Eclipse etc., e os executo definindo as configurações de compilação e pressionando F5 para compilar / executar.

• Estou desenvolvendo um programa web no trabalho, de modo que envolve o Django para configurar um servidor, conectar-se a um banco de dados, etc ... quase tudo no editor de texto SciTE.

• Para iniciar programas regulares, eu uso o Launchy ... ainda sem terminal. :)

• Para copiar arquivos e outros enfeites, eu uso uma busca / movimentação regular no gerenciador de arquivos gráficos (Windows Explorer, Nautilus).

• Depuração: eu uso o Visual Studio ou as ferramentas de Depuração no Windows (se estiver no Windows). Não fiz muita depuração no Linux, mas, pelas coisas que fiz, usei o Eclipse (também para Java no Windows).

• No trabalho: para conectar-se ao sistema de compilação e configurar um projeto, apenas uso ferramentas que foram integradas ao Eclipse para meu uso - sem necessidade de um terminal ou qualquer coisa (embora eu seja certamente bem-vindo a usar um terminal, se realmente quer)

Como é fazer essas coisas na CLI? Quais partes se tornam mais / menos eficientes? Quais aspectos do meu fluxo de trabalho precisariam ser alterados para obter a maior vantagem de uma mudança para trabalhar principalmente na CLI? Em outras palavras ... Se você magicamente me transformasse em um guru da linha de comando, como meu novo fluxo de trabalho de codificação seria diferente da minha maneira atual, centrada na GUI, de fazer as coisas?

Acho que isso não é mais verdade. A CLI tem uma vantagem específica: se você souber com antecedência o que está procurando, poderá digitá-la mais rapidamente do que navegá-la em um menu. Isso significa que, se você deseja emitir explicitamente comandos para o programa que possuem pouco contexto, é mais rápido. No entanto, existem dois problemas.

Em primeiro lugar, os programas da GUI podem inferir o contexto para você. Por exemplo, o recurso Ir para definição do Visual Studio e o Intellisense. Como você pode replicar esses recursos em uma CLI?

Em segundo lugar, os programas GUI podem exibir muito mais informações para você. Por exemplo, o Visual Studio Parallel Profiler, que é um gráfico do uso da CPU em vários núcleos ao longo do tempo. Como você pode exibir isso em uma CLI? Isso simplesmente não faria sentido. Assim que seus dados forem melhor expressos como algo diferente de texto, a CLI será perdida instantaneamente. Outro exemplo fácil são os pontos de interrupção. No Visual Studio, você clica na margem da linha na qual deseja quebrar. O que você fará em uma CLI, tente encontrar o número do arquivo e da linha e insira esse comando? Isso vai levar uma década relativa. Isso nem conta algumas das inovações mais recentes da GUI, como o Debugger Canvas.

Uma GUI pode ser mais lenta se você deseja gastar seu tempo pressionando Debug repetidas vezes, mas assim que os casos de uso se tornarem mais complexos, não haverá como a CLI acompanhar.

Eu acho que a maior diferença não está nas tarefas individuais, mas em duas coisas:

Em primeiro lugar, automação. A CLI é inerentemente programável, o que geralmente é mais difícil no Windows. Ouvi dizer que as coisas melhoraram com o PowerShell, mas não o usei.

Segundo, a filosofia UNIX de "separação de interesses". Posso escrever uma pequena interface baseada em linha de leitura para algo e usando o shell do emacs Mx, use-o dentro da GUI do emacs. Isso simplifica o aproveitamento de outras ferramentas e da funcionalidade existente.

Para a depuração, o gdb funciona bem, mas geralmente prefiro o depurador do VS. É provavelmente o melhor software que a Microsoft já fez.

Para construir e administrar coisas: faça. Ou festança. Onde quer que seja.

Para o desenvolvimento: emacs (recente conversão do vi, que pena!). Vi se estiver trabalhando através do ssh.

Eu realmente não posso me acostumar com o Eclipse. Eu acho que é um problema de "forma mental": não se encaixa no meu.

Para mim, a mudança para um fluxo de trabalho da CLI do Visual Studio envolveu a memorização de muitos comandos * nix. Também envolvia algumas dores de cabeça sempre que eu estragava um check-in de SVN.

Mas a maior diferença no fluxo de trabalho para mim foi que compreendi melhor como o sistema operacional funciona . Com um fluxo de trabalho da GUI, bastava clicar nos botões e aguardar a resposta do programa. No mundo da linha de comando, sinto que estou dizendo ao computador diretamente para fazer alguma coisa.

Em outras palavras, um fluxo de trabalho da GUI era o computador se comunicando com você, enquanto um fluxo de trabalho da CLI parecia mais com você se comunicando diretamente com o computador.

Um não é melhor que o outro, mas mudar de um ambiente totalmente baseado em GUI para o terminal foi definitivamente uma viagem.

Aqui estão mais observações de um programador que viveu nos dois mundos. Não repetirei pontos já apontados em outras respostas:

O desenvolvimento baseado em CLI tende a usar uma variedade de programas, cada um dos quais executa 1 função. O desenvolvimento baseado em GUI tende a usar um grande programa (o IDE), que executa dezenas de funções diferentes. Essa diferença tem várias consequências:

Como um IDE deve ser sua "casa" onde você trabalha o tempo todo, ele pode usar um formato proprietário (talvez binário) para armazenar seus dados. A compatibilidade não é uma grande preocupação, porque eles não esperam que você trabalhe em 2 IDEs diferentes no mesmo projeto. As ferramentas CLI, por outro lado, geralmente funcionam apenas com arquivos de texto sem formatação.

Com o desenvolvimento baseado na CLI, é possível alternar gradualmente as ferramentas ou integrar novas ferramentas ao seu fluxo de trabalho com mais facilidade. Escolher um IDE é mais do que tudo ou nada, e trocar seu IDE é mais doloroso.

O uso de um script de construção da CLI, em vez do menu "Construir" incorporado do IDE, aumenta a probabilidade de você se afastar do código por alguns anos, voltar a ele e construí-lo sem problemas. Com o desenvolvimento baseado em GUI, é provável que você esteja executando um IDE completamente diferente até então. Talvez o que você estava usando quando escreveu o código nem seja executado no seu sistema operacional atual.

Em um IDE, criar suas próprias ferramentas significa aprender uma API de plug-in (provavelmente grande) e, talvez, usar um idioma específico. Ao usar a CLI, nada de especial é necessário para criar ferramentas personalizadas.

Por outro lado, a vantagem de um IDE é que ele é bem "integrado". Assim, você pode clicar na janela do editor para definir pontos de interrupção do depurador e assim por diante.

Outro ponto: sua escolha também dependerá da plataforma de desenvolvimento, SO e idioma (s) que você usa. Em certas plataformas, o desenvolvimento baseado em IDE está profundamente arraigado na cultura de desenvolvimento predominante. Em outros, o desenvolvimento baseado em CLI é predominante. Se você estiver usando uma plataforma em que o desenvolvimento baseado em IDE é predominante, é provável que as ferramentas CLI sejam pouco desenvolvidas e com pouco suporte. O inverso também é verdadeiro.

A maior parte da minha infância não foi passada em um computador, pois tínhamos internet na fazenda. Comecei a programar tarde no ensino médio e basicamente trabalhava em GUIs o tempo todo. Na faculdade, conheci um cara que cresceu na CLI e fez tudo dessa maneira. Então, decidi configurar um servidor linux em vez de ouvir o prof. Depois de alguns anos, meu amigo estava me observando escrever algum código incorporado e não conseguia acreditar em como escrevi.

Basicamente, eu uso metade CLI, metade GUI. Há algumas coisas que os ambientes agrupados pela GUI fazem muito mais rapidamente e com mais eficiência. E o mesmo vale para a CLI. A maior parte da minha edição de texto é feita no VIM, pois os editores avançados da CLI VIM / EMACS (sem guerras aqui, por favor) tornam a manipulação de texto a mais eficiente. Por outro lado, coisas como a depuração incorporada usando o GDB é tão doloroso quanto a edição de texto sem teclado. Certifique-se de que é poderoso e seguro, com o tempo necessário, você encontrará as informações que procura, mas ter uma boa janela da GUI com acesso instantâneo a qualquer bloco de memória é inestimável, especialmente ao tentar compará-lo a outro bloco de memória.

De qualquer forma, o que realmente estou tentando dizer é que não deve ser GUI versus CLI, mas sim o que é melhor para CLI e qual é melhor para GUI. Porque, no final, se o seu pedido de informação for mais lento que o seu processo de pensamento, haverá um problema.

"convertido em um guru da CLI da noite para o dia?" Sim, há o problema. GUIs bem projetadas tendem a ser mais detectáveis ​​que as CLIs e mais tolerantes para o novato.

Meu fluxo de trabalho, recentemente aprimorado por um gerenciador de janelas lado a lado (dwm), consiste em muita digitação. Agora, meu laptop é realmente utilizável sem conectar um mouse (o trackpad é adequado para o que resta de apontar). Eu mantenho muitos aplicativos abertos e alterno com alt-tab. Não perco tempo movendo e redimensionando janelas.

Na maioria das vezes, eu uso um navegador, vim e vários terminais. O SSH me dá muita flexibilidade sobre onde eu trabalho (fisicamente). Os desktops remotos podem oferecer uma experiência melhor quando todos nós temos um tubo de 10Gigabit na rede, mas não prendo a respiração.

Não aprendi o vim o suficiente para tirar proveito de seus recursos complexos, mas estou inclinado nessa direção - quero fazer com que o vim salte para a linha certa # após uma falha na criação. (Tecnicamente, o vim é uma interface visual, embora seja executada em um terminal, mas eu o dirijo com um teclado, não um mouse.)

O verdadeiro problema são interfaces mal projetadas . É difícil criar interfaces bem projetadas, portanto elas não acontecem com muita frequência em nenhum dos campos. Mas como mais assistentes não-ux estão projetando GUIs hoje do que CLIs, ....

(Meu outro grande problema é o inchaço. Quando é preciso um programa de 19 MB para me ajudar a realizar a mesma tarefa que um programa de 200 kB, algo está errado. O XTree Gold para DOS aprimorou minha produtividade mais do que qualquer gerenciador de arquivos moderno. O Windows 2.11 usado apenas em mosaico O Turbo C era um IDE incrível. Por que meu Nook parece mais lento que um clássico do Mac? Por que agora o kernel ocupa agora mais espaço em disco do que todo o sistema usado?)

Com interfaces gráficas do usuário, você é forçado a interagir com o programa repetidamente para executar a mesma operação repetidamente. Com um shell, você pode automatizar as coisas com mais facilidade e fazer com que os programas funcionem juntos por meio de canalizações - que podem, por exemplo, ser usadas para gerar correspondências para expressões regulares em um conjunto de arquivos ou pacotes de rede. Como dito, é mais rápido para muitas operações.

A programação no terminal talvez não seja muito melhor do que em um editor gráfico, a menos que você use o SSH.

Pessoalmente, achei o shell unix muito mais acessível do que a linha de comando típica do Windows e agora estou imerso nele em um sistema Linux com um gerenciador de janelas lado a lado e muitos terminais.

Todos os seus exemplos são basicamente um processo de uma etapa. Na maioria dos ambientes de GUI, se você deseja mover um arquivo que não tem nada a ver com o aplicativo atual em que está, você pode fazê-lo no menu Arquivo sem sair do aplicativo. Não faz sentido ir a um prompt de comando. Se você deseja copiar o arquivo e atribuir um nome diferente, em uma linha de comando, você pode fazer isso de uma só vez. Para colocar isso em um arquivo em lotes, você precisa pelo menos saber como fazer isso, mas poderá executar o arquivo em lotes a partir da GUI, se desejar.

Eu tive um debate semelhante sobre os comandos do teclado versus o mouse.

A maneira como trabalho favorece a GUI de longe.

Uso típico:

• Três IDEs para três plataformas diferentes. Também uma janela do Notepad ++ para alguns scripts. Simplesmente não há como eu lembrar de comandos para todos esses sistemas de compilação. O problema com a CLI é que você precisa conhecer muitos detalhes apenas para que uma construção funcione. O IDES moderno normalmente possui algumas opções apropriadas por padrão. Você sempre pode olhar mais de perto quando chegar a hora.
• SVN ou Git integrado. Existem muitas opções para um programa que é auxiliar na programação e, na maioria das vezes, estou apenas realizando commit ou update.
• Material de rede: Por sorte, eu também faço toda a configuração de rede em nosso escritório. A maioria das placas de rede fornece vários comandos da CLI, mas se há uma coisa em que você precisa de uma visão geral do estado, é firewall e roteamento. Para o roteamento, posso viver com a linha de comando, mas os firewalls ficam complicados e, se há uma coisa em que as GUIs são boas, é a exibição de muitas informações.
• Geralmente, há muita mudança de uma coisa para outra. Os comutadores de contexto são mais fáceis com um contexto visual.

Quanto ao principal benefício da CLI, scripts, quase nunca faço isso. As tarefas repetidas que temos são apenas aplicativos de trabalho cron que lançamos juntos em c # e nem sempre mudamos. Nós temos maneiras de fazer as coisas rodarem no Linux, mas principalmente é portado (boost), então mexer com arquivos e essas coisas são minimizadas. E se as coisas ficarem peludas, também existem bons IDEs para Linux.