「コンパイル」「実行」というステップを分離する

[saki7]

C++でプログラムを書くときは、

1. コードを書く
2. コンパイラを叩く（コマンドを打つ）
3. 出力された実行バイナリを実行する（コマンドを打つ）

こういうステップになる。

今のcpprefjpの実行機能では、 (2) と (3) の出力が同じ場所にそのまま連結して出力される。間に区切りなどが無い。

これはUXとしては問題がある。プログラマの思考として (2) と (3) は明確に分離されているものなので、出力は何かしらの形で2つに分けるか、バイナリを仮想的に叩くようなターミナルコマンド行を勝手に追記した方が良いと思う。

これを直さないと、プログラミングの初心者の混乱を招く。自分も初心者の時は「コンパイル」と「実行」という概念がまず理解できなかったので、ここはしっかり直したい。

[saki7]

ただ、コード実行機能はIDEではないので、今の右三角形のボタンを2つに分離すると面倒くさいことになるのでそれは避けたい（個人の感想です）

[saki7]

#19 でまったく同じIssueを自分で立ててた。完全に記憶飛んでた

[melpon]

一応、bash を使えばこういう風に見せることはできます。
https://wandbox.org/permlink/vMlP4LrHBa1DKYyd

[saki7]

これは素晴らしいですね。

一つ懸念としては、 #13 を実装したときに、コードが単一のスニペットとして表示されてほしいです。Wandboxの複数ファイル機能を使って bash で別のファイルを叩けるなら、たぶんその方が良いです。ただ、bashスクリプトが毎回余分なファイルとして添付されることになると思うので、なかなかうまい解決法が思いつきません。

もう一つの懸念としては、いまは以下のコードでWandboxのANSIエスケープシーケンスをパースして色を付けてるので、bash経由にするとここが消えそうというのがあります。

kunai/js/kunai/yata.js

Lines 314 to 316 in 4ea3bbe

	return $('<p>').addClass('yata-console-line').html(AN.ansiToHtml(l, {
	use_classes: true
	}))

[saki7]

僕の提案にあるようにウソのコマンド行を追記するよりは @melpon の提案のように再現性のある形で出す方が二万倍くらい美しいので、なにか良い方法ないですかね……

[yohhoy]

本issueはcpprefjpコード実行機能のUXとして「コンパイル／実行フェーズ分離を行う」というニュアンスでしょうか？この解釈を前提に、一つの意見として、懐疑的なスタンスを表明しておきます。

プログラマの思考として (2) と (3) は明確に分離されているものなので、出力は何かしらの形で2つに分けるか、バイナリを仮想的に叩くようなターミナルコマンド行を勝手に追記した方が良いと思う。
これを直さないと、プログラミングの初心者の混乱を招く。自分も初心者の時は「コンパイル」と「実行」という概念がまず理解できなかったので、ここはしっかり直したい。

この内容それ自体には同意します。その上で、cpprefjpの目的は「言語機能やライブラリのリファレンス」であり、プログラミング学習者をターゲットとした教育的側面は二の次と考えています。

前者の目的を持ったユーザにとっては、コンパイルと実行のフェーズ分離は裏方の実現手段にすぎず、今調べているライブラリ関数の実行結果はどうなるかが興味対象と考えます。このユーザに対するUXとしては、ワンアクションで実行結果が得られる現状仕様が好ましいと思います。

[saki7]

@yohhoy 同じように思います。なので、僕もボタンごと分離するとかはあまりやりたくないです。しかし、出力を結合してしまっている今の仕様には流石に無理があると思うので、見た目は分離したいと思います。

@melpon の提案のように再現性があるスクリプトを同梱すると別の意味で付加価値が出るので、これはこれでやりたいです。教育的側面が二の次という点はその通りですが、一方で、C++の初心者がcpprefjpの記事に特有の親切な解説で助かっているという声は非常に多く聞くので、ここを助けるのはcpprefjpでやってもスコープを逸脱するほどではないと思います。

CONTRIBUTING の一番最初の項目にサンプルコードでユーザサポートをするということが書かれているくらいなので、受け取り方次第ですが自分はサンプルコード周りはもう少しくらいなら強化しても良いかなと思っています。

[yohhoy]

出力を結合してしまっている今の仕様

上記の問題定義・解釈が、人によって（私だけかも）少し違うのかもと思いなおしました。wandboxが返す結果データが分離されていれば、あとはサイト上での画面表示の問題ということでしょうか。
言い換えると、ユーザによる"アクション"UXは現行維持でもよいが、ユーザへの"フィードバック"UXを改善したいという解釈ですね。

[saki7]

そうです。最速で解決するなら <hr> を一個出せば良いと思います。

WandboxのAPIが返すデータ自体は標準出力、標準エラー、プログラム出力では分離されていたはずです（たぶん、記憶が正しければ）。

[saki7]

見た目の区切り方としては、CircleCIのrunのような表示までリッチにするのが案2。これは、ステップ自体をデザインから根本的に分離することで、「人間の行為」と「機械的出力」を分けるという思想です。感覚としてはCIよりJupyter Notebookの方が近いかも。

案1は横棒一本追加するやつです。

案3は、ターミナルを実際に叩くときのコマンド以外の装飾は一切入れないやつてす。これは最も現実世界原理主義ですが、悪くはないと思います

[usagi]

わたしは案3がいいな。 cpprefjp ユーザーが必要とするわかりやすさを私なりに考えるとこれが最良と思います。

[saki7]

@melpon Wandboxでコンパイルに使われた完全なコマンド全体を取得する方法ってありますか？

[melpon]

@saki7 ディスプレイ用のコマンド（g++ prog.cc -std=gnu++1z みたいなの）は取得できますが、内部で実際に使われた完全なコマンド（※）は取得できないです。

※ /opt/wandbox/gcc-head/bin/g++ -oprog.exe -Wl,-rpath,/opt/wandbox/gcc-head/lib64 -lpthread -I/opt/wandbox/boost-sml/include -I/opt/wandbox/boost-di/include -I/opt/wandbox/range-v3/include -I/opt/wandbox/nlohmann-json/src -I/opt/wandbox/cmcstl2/include -std=gnu++1z prog.cc