GUI対 CLI-最後の戦い

実際のプログラマーは、コマンドラインインターフェイスよりも優れたものを発明したことはないと信じています。 当然、私は議論したいです。



お互いをよりよく理解するために、抽象的なオレンジについて話しましょう。 聞いたことがあるか試してみたAutoCADを想像してください。 プログラミングからは程遠いIllustratorまたはCorelDroから、抽象的で公然と推論することができます。 コンソールで動作しないのはなぜですか？





図 1.真空中の抽象的なインターフェース。



最初に、何が起きているのかを全体的に把握する必要があります。 コマンド(get-lines)



を作成し、正直なリスト(((0 12) (5 12)) ...)



を取得することは、人にとって(((0 12) (5 12)) ...)



不便です。 コマンドの助けを借りて現在の状況を理解しようとすることは、風がどのように匂い、音楽が表現力の面でどのように聞こえるか、そして正確に書かれた声明によってのみ証明書が発行されたときにメソッドを使用して官僚制のように聞こえる方法についてメモを交換することです、あなたはあなたの間違いについてのみ見つけるでしょう出願後、将来的にはアプリケーションを何度も作成する必要があります。 そして、はい、どんな種類のリクエストを送信できるのかを知るには、別のリクエストをする必要があります。



全体像を見ると、人のすべてをすぐに明確にすることができますが、要求について考える必要があり、結果を解釈する必要があります（それぞれの答えは、それ自体が情報の投影であり、メンタルモデルの作成や習慣の発達には寄与しません）。 十分に容量のあるスキームでは、さまざまな人が自分のそれぞれを見ることができます-これは現在興味深いです。 要するに、一度見たほうがいいです。



2番目：直接的な対話。 グラフィカルインターフェイスでは、人はコンソールでオブジェクト自体を移動できます。「どの変数とどのように変更するかによって、ソリューションが私が望むように変わる」という方程式を解く必要があります。 彼は1つのスペースで作業し、タスクは別のスペースにあり、翻訳ルールは一方向に形式化され（コマンド→タスク）、逆問題を解決する必要があります。 HTMLでサイトのレイアウトをすぐにプロトタイプ化する方法のように感じます。 バナナに戻って、セグメントの最後を取得し、別のセグメントの最後にドラッグします（結合）。 私は何をする必要があるかを理解し、まさにそれをやっています。



逆に、リクエスト/レスポンススタイルのインターフェイスは人にとってより自然であるように思えるかもしれません。結局、これが私たちが人生の人々との対話を構築する方法です。 アクションの数を数えて比較します。 架空のコンソールで、私は：

1. どのセグメントを移動するか、つまり 一意の属性によってセグメントの検索リクエストを作成および確認します。 サインも発明されなければなりません。
2. 同様に、2番目のセグメントの終わりを見つけます。
3. コマンドを与え、前のコマンドの結果をそれに渡します。
4. どういうわけか、何が必要か、そして何が必要かを確認してください。
5. これが私が望んでいたものであることを確認してください。

私が書いたことは、例がなければ理解できないものではないに違いない。 コマンドラインインターフェイスの不適切な使用の最も顕著な例の1つとしてgitを取り上げましょう。ただし、そのために、外見上愚かな人の多くは、槍を破る準備ができてまったく無駄になっています。 それで私は午前中に仕事に来て、リポジトリのあるフォルダに入りました。 何が起こっているの？ どこで止めたの？ 私はどのブランチにいますか？ 昨日すべてをコミットしましたか？ わかった？ 何か引っ張っているように見えましたか？ プル後、私のコミットはどちら側にしがみつきましたか？ リポジトリの構造は何ですか？ コンソールでは、これらはすべて個別のコマンドです。 私が仕事に参加するためには、ダイアルし、打ち上げて、7つのスペルについて結果をまとめて頭の中で収集する必要があります。 これは明確さと全体像のためです。 唯一のことは、gitがリポジトリ構造をグラフィカルに表示することです（まあ、擬似的に-しかし、これはもはやコンソールではなく、悲惨な男です）。





図 2. git log --graph --pretty=oneline --abbrev-commit



。 メモリから再生しますか？



直接的な相互作用についても興味深いです。 gitkでツリーを見ると、複雑なマージやその他の巧妙な変換の途中であっても、現在何が起こっているかを把握することは大きな問題ではありません。 しかし、これをチームに変換することはすでに困難です。 たとえば、このコミットから始めて、すべてのチップセットを別のブランチに転送する必要があることを理解しています。 しかし、どのチームですか？ 現時点では、それらはそれぞれ独自の特性を持つ5つあり、それらは私がどこにいて、どこに行きたいかによって異なり、通常は必要なことを行います。つまり、組み合わせる必要があります。 この謎を解くことはほとんどありません（恥ずかしくて、年齢で暗記できたかもしれません）、私は自分の無力さからひどく怒ります（すべてを理解していますが、それを言うことはできません）。



しかし、コマンドをもっと簡単にしたとしても、まだ問題があります。あるウィンドウでリポジトリツリーを確認し、リビジョンハッシュを別のウィンドウにゆっくり書き直さなければなりません。 つまり、再び、ボーナスが何であるかは明確ではありません。



そして今、善のために。 柔軟性。 パワー。 Du子。 私は愚かではないし、bash + unix utilsが強力な束であると主張するつもりもありません。 ここでの唯一の熱意は、通常、bashがファイルシステムのスクリプト言語のREPLであり、そのインターフェースが正常に補完するという事実に関連付けられています（たとえば、mcまたはFarに組み込まれている方法を参照してください、はい、これらはコマンドラインインターフェースではありません）。 プログラムにREPLを使用したスクリプト言語があると便利です。これにより、インターフェイスはより複雑なタスクに適したものになります。 （博識な読者は、AutoCADにもLispコンソールがあり、そこにリストされているすべての恐ろしいことを実行できることを知っています-オブジェクトの検索、行の移動）。 しかし、上記の理由により、これは柔軟性と使いやすさの交換であることに注意してください。これが、cliで最も単純なユーティリティ関数のみが可能な理由です。 そして、これはまさにグラフィカルインターフェースの本質と天才です。





図 3.チームモードAutoCAD。