CLI指向のプログラマーのワークフローはGUI指向のワークフローとどう違うのですか？

GUIアプリでプログラミング作業を減らし、より多くのコマンドラインツールを使用することの利点（特に、より効率的に作業を行うことに関して）について多くのことを聞きました。ただし、コマンドラインツールにさらに依存する場合、ワークフローがどのように異なるかがわからないため、新しいツールセットを学習して変更する時間と労力を個人的に投資するのに十分な見返りがあるかどうかをすぐに評価することはできません私のワークフロー。

たった今：

• Visual Studio、Eclipseなどを使用してC / C ++ / D / C＃/ Java / Pythonなどの言語でいくつかのサイドプロジェクトをコーディングし、ビルド設定をセットアップし、F5キーを押してビルド/実行して実行します。

• 私は職場でWebプログラムを開発しています。そのためには、Djangoを使用してサーバーのセットアップ、データベースへの接続などを行います。ほとんどすべてがSciTEテキストエディター内で行われます。

• 通常のプログラムを起動するには、Launchyを使用します...まだ端末はありません。:)

• ファイルなどをコピーするには、グラフィカルファイルマネージャー（Windowsエクスプローラー、Nautilus）で通常の検索/移動を使用します。

• デバッグ：Windows用のVisual Studioまたはデバッグツールを使用します（Windowsを使用している場合）。Linuxでのデバッグはあまりしていませんが、やったことのために、Eclipse（Windows上のJavaでも）を使用しました。

• 仕事中：ビルドシステムに接続してプロジェクトをセットアップするには、使用するためにEclipseに統合されたツールを使用するだけです。端末などは必要ありません（ただし、本当にしたい）

CLIでこれらのことを行うのはどのようなものですか？どの部品がより効率的/効率的になりますか？主にCLIでの作業から最大の利点を得るには、ワークフローのどの側面を変更する必要がありますか？言い換えれば... 魔法のように私をコマンドラインの第一人者に変えたなら、私の新しいコーディングワークフローは、現在のGUI中心の物事のやり方とどう違うのでしょうか？

これはもう真実だとは思わない。CLIには特定の利点があります。探しているものが事前にわかっている場合、メニューでナビゲートするよりも速く入力できます。これは、コンテキストがほとんどないプログラムにコマンドを明示的に発行したい場合、ほとんどの場合に高速であることを意味します。ただし、2つの問題があります。

まず、GUIプログラムはコンテキストを推測できます。たとえば、Visual StudioのGo To Definition機能とIntellisense。CLIでこれらの機能をどのように複製できますか？

第二に、GUIプログラムはより多くの情報を表示できます。たとえば、Visual Studio Parallel Profilerは、複数のコアにわたるCPU使用率の経時的なグラフです。CLIでどのように表示できますか？意味がありません。データがテキスト以外のものとしてより適切に表現されるとすぐに、CLIはすぐに失われます。別の簡単な例は、ブレークポイントです。Visual Studioでは、分割する行の余白をクリックします。CLIで何をし、ファイルと行番号を見つけてそのコマンドを入力しようとしますか？それはあなたに比較的10年かかります。それは、デバッガキャンバスのような、新しいGUIの革新を数えていません。

何度も何度もDebugをプッシュすることに時間を費やしたい場合、GUIは遅くなるかもしれませんが、ユースケースがより複雑になるとすぐに、CLIが追いつく方法がありません。

最大の違いは個々のタスクにあるのではなく、次の2つの点にあると思います。

何よりもまず、自動化。CLIは本質的にスクリプト可能です。これは通常、Windowsではより困難です。PowerShellで改善されたと聞きましたが、使用していません。

第二に、「懸念の分離」というUNIXの哲学。私は何かに対する小さなreadlineベースのインターフェースを書くことができ、emacs Mxシェルを使用してemacs GUI内でそれを使用します。これにより、他のツールや既存の機能をより簡単に活用できます。

デバッグにはgdbはうまく機能しますが、私は通常VSデバッガを好みます。これは、おそらくマイクロソフトがこれまで行った中で最高のソフトウェアです。

ものを構築して実行するには：make。またはバッシュ。どこでも。

開発の場合：emacs（最近のviからの変換、残念！）。sshを介して作業を行う場合はVi。

私は本当にEclipseに慣れることができません。私はそれが「心の形」の問題だと思う：それは私には合わない。

私にとって、Visual StudioからCLIワークフローに切り替えるには、多くの* nixコマンドを記憶する必要がありました。また、SVNチェックインを台無しにしたときの頭痛の種もありました。

しかし、私にとってのワークフローの最大の違いは、オペレーティングシステムがどのように機能するかをよりよく理解できたことです。GUIワークフローでは、ボタンをクリックしてプログラムが応答するのを待っていました。コマンドラインの世界では、コンピューターに何かをするよう直接指示しているように感じます。

言い換えると、GUIワークフローはコンピューターと通信しているのに対して、CLIワークフローはコンピューターと直接通信しているように見えます。

1つは他のものよりも優れていませんが、完全にGUIベースの環境からターミナルに切り替えることは間違いなく旅行でした。

両方の世界に住んでいるプログラマーからのより多くの観察がここにあります。私は他の回答で既に述べたポイントを繰り返しません：

CLIベースの開発では、それぞれが1つの機能を実行するさまざまなプログラムを使用する傾向があります。GUIベースの開発では、多くの異なる機能を実行する1つの大きなプログラム（IDE）を使用する傾向があります。この1つの違いには、いくつかの結果があります。

IDEは常に作業を行う「ホーム」になることを目的としているため、独自の（おそらくバイナリ）形式を使用してデータを保持できます。同じプロジェクトの2つの異なるIDEで作業することを期待しないため、互換性は大きな問題ではありません。一方、CLIツールは通常、プレーンテキストファイルでのみ機能します。

CLIベースの開発では、ツールを段階的に切り替えたり、新しいツールをワークフローに簡単に統合したりできます。IDEを選択することはすべてか無かであり、IDEを切り替えることはより苦痛です。

IDEのビルトイン「ビルド」メニューではなくCLIビルドスクリプトを使用すると、数年間コードから離れて戻ってきて、大騒ぎせずにビルドできます。GUIベースの開発では、それまでにまったく異なるIDEを実行している可能性があります。おそらく、コードを記述したときに使用していたものは、現在のOSでさえ実行されません。

IDEで独自のツールを構築するということは、（おそらく大きな）プラグインAPIを学習し、おそらく特定の言語を使用することを意味します。CLIを使用する場合、カスタムツールを作成するために特別なものは必要ありません。

一方、IDEの利点は、「統合」されていることです。そのため、エディタウィンドウ内をクリックして、デバッガブレークポイントなどを設定できます。

もう1つのポイント：選択は、使用する開発プラットフォーム、OS、および言語によっても異なります。特定のプラットフォームでは、IDEベースの開発は一般的な開発文化に深く根付いています。他では、CLIベースの開発が普及しています。IDEベースの開発が普及しているプラ​​ットフォームを使用している場合、CLIツールの開発とサポートが不十分になる可能性があります。その逆も同様です。

私たちは農場でインターネットさえ利用していたので、私の子供時代のほとんどはコンピューターに費やされませんでした。私は高校の後半でプログラミングを始め、基本的にGUIで常に働いていました。大学でCLIで育った男に出会い、すべてをそのようにやりました。そこで、教授の話を聞くのではなく、Linuxサーバーをセットアップすることにしました。数年後、私の仲間は私に埋め込みコードを書くのを見ていましたが、私が書いた方法を信じることができませんでした。

基本的に、ハーフCLIハ​​ーフGUIを使用します。GUIバンドル環境では、はるかに高速かつ効率的に処理できることがいくつかあります。また、CLIについても同様です。テキスト編集のほとんどはVIMで行われます。高度なCLIエディターVIM / EMACS（ここでは戦争はありません）がテキスト操作を最も効率的にしています。一方、GDBを使用した組み込みデバッグなどは、キーボードなしでテキストを編集するのと同じくらい苦痛です。その強力で確かな時間であなたが探している情報を見つけることができますが、特に他のメモリブロックと比較しようとする場合、任意のメモリブロックに瞬時にアクセスできる素敵なGUIウィンドウを持つことは非常に貴重です。

とにかく、私が本当に言おうとしているのは、GUI対CLIではなく、CLIの優れた点とGUIの優れた点であるべきだということです。最終的に、IOが思考プロセスより遅い場合は問題があるためです。

「一晩でCLIの第一人者になりましたか？」はい、こすれがあります。適切に設計されたGUIは、CLIよりも発見しやすく、初心者にも寛容です。

タイリングウィンドウマネージャー（dwm）によって最近強化された私のワークフローは、多くの入力で構成されています。私のラップトップは、マウスを接続することなく、実際に使用できます（トラックパッドは、指さしの余地に適しています）。私は多くのアプリを開いたままにし、alt-tabで切り替えます。ウィンドウの移動とサイズ変更に時間を無駄にしません。

ほとんどの場合、ブラウザ、vim、および多数の端末を使用します。SSHを使用すると、作業場所（物理的に）に関して非常に柔軟になります。私たち全員が10Gigabitのパイプをネットに持っていると、リモートデスクトップはより良いエクスペリエンスを提供するかもしれませんが、私は息を止めません。

私はその複雑な機能を十分に活用できるほどvimを学んでいませんが、その方向に傾いています-makeに失敗した後、vimを正しい行にジャンプさせたいです。（技術的には、vimはターミナルで実行されますが、マウスではなくキーボードで駆動しますが、ビジュアルインターフェイスです。）

実際の問題は、設計が不十分なインターフェイスです。適切に設計されたインターフェイスは作成するのが難しいため、どちらの陣営でも頻繁に発生することはありません。しかし、今日ではCLIよりも多くの非UXウィザードがGUIを設計しているため、....

（私の他の大きな欲求は膨らんでいます。200MBプログラムと同じタスクを達成するのに19MBプログラムが必要な場合、何かがおかしいです。XTreeGold for DOSは、現代のファイルマネージャーよりも生産性を向上させました。 Turbo Cは素晴らしいIDEでした。NookがMacクラシックよりも遅いように見えるのはなぜですか？カーネルだけでシステム全体が使用するよりも多くのディスクスペースを占有するようになったのはなぜですか？）

グラフィカルユーザーインターフェイスを使用すると、同じ操作を繰り返し実行するために、プログラムと繰り返し対話する必要があります。シェルを使用すると、物事をより簡単に自動化でき、パイピングを通じてプログラムを連携させることができます。たとえば、一連のファイルまたはネットワークパケットの正規表現に一致するものを出力するために使用できます。前述のように、多くの操作で高速です。

ターミナルでのプログラミングは、SSHを使用しない限り、おそらくグラフィカルエディターでのプログラミングほど優れていません。

私は個人的に、UNIXシェルは典型的なWindowsコマンドラインよりもはるかに親しみやすいと感じ、タイルウィンドウマネージャーと多くの端末を備えたLinuxシステムに非常に没頭しています。

すべての例は、ほぼ1ステップのプロセスです。ほとんどのGUI環境で、現在のアプリケーションとは関係のないファイルを移動したい場合は、アプリケーションを終了せずにファイルメニューから行うことができます。コマンドプロンプトに移動しても意味がありません。ファイルをコピーして別の名前を付けたい場合は、コマンドラインで一度にすべてを実行できます。これをバッチファイルに入れるには、少なくともこれを行う方法を知る必要がありますが、必要に応じてGUIからバッチファイルを実行できます。

キーボードコマンドとマウスについても同様の議論がありました。

私の仕事のやり方は、はるかにGUIを好んでいます。

典型的な使用法：

• 3つの異なるプラットフォーム用の3つのIDE。一部のスクリプト用のNotepad ++ウィンドウもあります。これらのすべてのビルドシステムのコマンドを記憶する方法はありません。CLIの問題は、ビルドを機能させるためだけに多くの詳細を知る必要があることです。最近のIDESには通常、デフォルトで適切なオプションがいくつかあります。時間が来たら、いつでもよく見ることができます。
• SVNまたはGitが統合されました。プログラミングを補助するプログラムには非常に多くのオプションがあり、ほとんどの場合、コミットまたは更新のみを行っています。
• ネットワーク関連：幸運なことに、私もオフィスですべてのネットワーク設定を行うことができます。ほとんどのネットワークボードはCLIコマンドを大量に提供しますが、状態の概要が必要なことが1つあるとすれば、それはファイアウォールとルーティングです。ルーティングについては、コマンドラインでほぼライブで実行できますが、ファイアウォールは複雑になり、GUIが優れている点が1つあると、多くの情報が表示されます。
• 一般的に、あるものから別のものへの移動がたくさんあります。コンテキスト切り替えは、視覚的なコンテキストでより簡単です。

CLIの主な利点であるスクリプティングに関しては、私はほとんどそれを行いません。私たちが繰り返しているタスクは、c＃で一緒に投げたcronジョブアプリであり、頻繁に変更されることはありません。Linuxで実行する方法はありますが、主に移植（ブースト）されているため、ファイルをいじることなどは最小限に抑えられます。そして物事が困難になった場合、Linux用の優れたIDEもあります。