-----------------------------
review comment 1
-----------------------------
■ 総合点
3
■ 確信度
3
■ 査読コメント
API情報への人間のアクセスという観点から興味深いシステムを構築しているのですが，「プログラミング手法の提案」という観点からは，不明なところが多くあり，積極的に採択するということはできません。
まず，提案の手法が有効とおもわれる状況設定が明確でないとおもいます。「はじめに」でかかれている「(1)->(3)->(2)」の順序のほうがユーザの思考に沿う」という記述，評価実験のなかで，「プログラミングの経験によらないユーザの試行に即した支援」という表現から，提案の方法が有効である範囲が未検討であることが推測され，状況設定が曖昧であるので，査読者に提案方法が有効であるかを判断することを困難としています。
つぎに，「コメント」として指し示している範囲が，通常のプログラムにおけるコメントのごく一部であり，特に，明晰なコードを記載した場合には不要であるようなコメント（実行コードのほうが正確で明瞭性が高いケース）となっていると考えられます。
ソフトウェアの作成で，外部仕様書（解くべき問題の記述），内部仕様書（解法の記述）を記述してから，コーディングに入るケースも多いとおもいますが，そのようなときに，「コメント書くために，自然言語での思考を思い出す」という問題があるということには違和感を覚えます。
さいごに，仮にご提案の方法がAPIについての知識の十分でない状況（実験で確認した状況）を前提にしていると好意的に解釈したとしても，「四角」という単語をどのように選ぶかについて，説明が不十分で，実際に有用なシステムを構築するときに問題になりそうかと推察します。
ご提案の方法は，APIレファレンスの新しい形態と利用法という観点で整理すれば，理解がしやすいと考えられます。参考文献[11]は，コマンドのヘルプですが，コマンドのヘルプとAPIレファレンス参照との差を論じ，識別子でなくて，べつの単語をトリガとしてユーザとインタラクションするものであれば，差が明らかになろうとおもいますし，APIレフェレンスという観点からまとめるならば，差を明らかにすることは必須となるとおもわれます。本質的なところは，プログラムで実行される識別子を検索のクエリとするか，別のもの（ご提案のシステムでは「ある特別な日本語」とするところがメカニズムとしてちがうと考えられます。この整理をするのであれば，「APIにおける関数名」ではいけないかという説明を伺いたいと考えます。
■ レビューサマリー
提案の手法が有効とおもわれる状況設定が明確でないので，明確にしてください。想定しているプログラミング対象の範囲，利用者のレベルの記述は必要です。現状は，「どのような条件でも」という記載になっていますが，再考をお願いしたいです。
-----------------------------
review comment 2
-----------------------------
■ 総合点
4
■ 確信度
3
■ 査読コメント
コメントを書くとソースコードが補完される新しいプログラミング手法の提案である。通常のコード補完のように「命令」を推薦するのではなく、コメントからキーワードを拾って「穴の空いた自然文」を提示するため、意味を知らない命令を使うことができる。
現状、正規表現でマッチングしている実装では、日本語プログラミングの好意的解釈や構造化エディタとの差分が見えにくい。そのまま日本語でコードを書かせればいい、そのまま構造化エディタで穴埋めプログラミングさせればいい、と思えてしまう。
また、使い方を知らない命令を使う手法としてBrandtらのExample-Centric Programmingがある。これはキーワードをもとにWeb上のサンプルコードを検索し、変数名をコンテキストにあったものにして挿入してくれるもので、著者らのゴールに非常に近いものに見える。
http://joelbrandt.org/publications/brandt_chi2010_example_centric_programming.pdf
コード補完時に穴の開いた自然文を提示する部分は面白く、新規性があるように思うが、OmarらのActive Code Completionを参照するべきだと思う。自然文と入力ボックス、だけではなく、柔軟な入力インタフェースを表示することもできるはずである。
https://www.cs.cmu.edu/~comar/graphite-icse12.pdf
なお、自然分の穴埋めでスクリプトをカスタマイズするという発想は、目的がコードを書くことではないという差異はあるが、Microsoft on{X}で既出である。
https://www.onx.ms/
著者らの主張として、(最終的なソースコードの書き方はユーザに委ねられるので、)ユーザの自由度を制限しない、という議論がある。しかし、主たるターゲットユーザとされている初心者は、そのようなスタイルを身につける前の人たちなのでは？と感じた。
本研究の真のポイントは、よく知らないけれども使いたいプログラミング言語を学習するために、(現在は著者らが用意している)穴開き自然文を読めるところであり、その点の議論を深めることを薦める。
例えば、上記Example-Centric Programmingはサンプルコードを検索するインタフェースであり、けっきょくそのコードを読んで理解できないといけない。一方、本研究は提示内容を読めば何ができるか分かる。
プログラミング手法という漠然とした捉え方よりも、プログラミング言語の学習支援インタフェースとして見れば、新規性・有用性を主張しやすい研究だと思う。
その他:
p.5 「未知の命令に対し，サンプルプログラム、リファレンスを見つけることと同様によりその命令を実際に適用したプログラムを書くことも困難である．」の文意が読み取れなかった。
---
プログラム委員会後の追加コメント:
他の査読者のコメントにもあるように、概要と本文の狙いがずれているように読めるなど、発想は面白いのに日本語で損をしています。この研究で何を目指しているのか、なぜその手法を用いたのか、評価結果から読み取れることは何か、精密な議論展開を心がけてください。一つの研究論文でカバーできる範囲を超えているところは未来ビジョンに記載してください。
例えば、ユーザスタディでは「実行画面を作成する」という例を出したのがそもそもミスリーディングだったのだと思います。このようなboilerplateコードは言語の特徴として覚える他なく、今回の提案手法で補完する対象ではない気がします。（観察した内容によりますが、リミテーションとして議論できるところです。）
また、議論の焦点を絞るためにも、上に挙げた参考文献を読んでみてください。現在引用されている[4][12]などと比べると、こちらのほうが関連があるように思います。
-----------------------------
review comment 3
-----------------------------
■ 総合点
3
■ 確信度
3
■ 査読コメント
自然言語で書かれた処理内容について、曖昧検索したコードテンプレートとその穴埋めによってコードの完成に導く機能を提案しています。面白いとは思いますが、初心者受けはしても、それ以上の発展に結び付く工夫は提案されていません。また、コードテンプレートの構成にあたって新たに用意する必要があるため、この方式はスケールしない印象を持ちました。
ちょっと面白いアイデアだと思いました。さわってみたいとも思います。しかしながら、たとえ初心者であっても数週間にわたって、このシステムを使ってくれるかといえば、大いに疑問が残ります。Scratch を始めとする他のシステムとの比較が望まれます。
ちょっとしたスクリプトを除くと、プログラミング作業とは抽象化です。低レベルなデータ構造や命令などを組み合わせてスクリプトを抽象化して、関数や手続きなどのモジュールを構築し、それらを組み合わせることでさらに抽象度の高いモジュールを構築することで、徐々にシステムを完成させる作業です。たとえ初心者相手とはいっても、抽象化機構のないプログラミング言語に実用上の価値は認めにくいです。
このシステムの推薦機能は JSON で記述されたデータ構造に依拠しています。この設計はシステムのスケーラビリティを著しく限定していると思います。すでに世の中にある API について、新たにこのデータ構造を追加しなければならないとしたら気が遠くなります。既存の API のドキュメントとコメントとの文書合致率などの工夫はできないのでしょうか。
実験の内容について、細かいことになりますが疑問に思える点がいくつかあります。
p. 4 のコード断片には function 宣言がなされています。プログラミング未経験者は "function" という概念で戸惑わなかったのでしょうか。
p. 4 のコード断片で、「実行描画を作成する」というコメントにたいして setup と draw 関数が生成されます。「実行描画を作成する」というのは未経験者が自然に記述するコメントとは思えません。そもそも、「画面を作成」しなくてはいけないという理解は普通なのでしょうか？この魔法のフレーズを思い出せなくて困った人はいなかったのでしょうか。
"7時19分になったら" というコメントを draw 関数内部に記述するのも初心者にとっては困難な気がします。setup の内部や "実行画面を作成する" の直後などに書いて困った人はいなかったのでしょうか。
"7時19分になったらページを開く"と一気に書いた場合にはなにがおきるのでしょうか。アプリケーションの仕様を一文で書いてしまった人はいなかったのでしょうか。