10

この質問を見た後、盲目のプログラマーが直面するさまざまな課題と、それらのいくつかが目の見えるプログラマーにもどのように適用できるかについて考えるようになりました. 特に、ソースコードを声に出して読む問題は、私を一時停止させます。私はこれまでの人生のほとんどをプログラミングに費やしてきました。また、仲間の学生にプログラミングの指導を頻繁に行っています。ほとんどの場合、C++ または Java を使用しています。

C++ 式の本質的な構文を口頭で伝えようとすることは、非常に腹立たしいことです。話し手は、英語への慣用的な翻訳、または「開き括弧」、「ビットごとの and」などの明示的で遅い用語を使用して、口頭でコードの完全な仕様を提供する必要があります。これらのソリューションはどちらも最適ではありません。

一方では、慣用的な翻訳は、関連するプログラミング コードに逆翻訳できるプログラマーにとってのみ有用です。これは通常、学生を指導する場合には当てはまりません。次に、教育 (または単に誰かをプロジェクトに慣れさせること) は、ソースが読み上げられる最も一般的な状況であり、エラーの余地はほとんどありません。

一方、リテラル仕様は非常に遅くなります。「シャープ、インクルード、左山括弧、iostream、右山括弧、改行」と言うのは、単に入力するよりもはるかに時間がかかります#include <iostream>。実際、ほとんどの経験豊富な C++ プログラマーは、これを単に「iostream を含める」と読むでしょうが、経験の浅いプログラマーは多く、文字通りの仕様が必要な場合もあります。

そこで、この問題の潜在的な解決策について考えました。

C++ には、有限のキーワード( 63) と演算子(54) のセットがあり、名前付き演算子を無視し、複合代入演算子と前置対後置の自動インクリメントとデクリメントを別個のものとして扱います。数種類のリテラル、同様の数のグループ化記号、およびセミコロンがあります。私が完全に間違っていない限り、それはそれについてです。

それでは、簡潔でユニークな発音をこれらの異なる概念 (必要な場合は空白の発音を含む) のそれぞれに単純に帰し、そこから進むことは実行可能ではないでしょうか? プログラミング言語は自然言語よりもはるかに規則的であるため、発音を標準化することができます。どの言語の話者でもC++ コードを口頭で伝えることができ、言語の規則性と固定性により、音声テキスト変換ソフトウェアを最適化して C++ 音声を高い精度で受け入れることができます。

したがって、私の質問は 2 つあります。まず、私の解決策は実行可能ですか。第二に、他の誰かが他の潜在的な解決策を持っていますか? ここから提案を受け取り、それらを使用して、私のソリューションの実装例を含む正式な論文を作成するつもりです。

4

3 に答える 3

4

盲目の開発者として、私は13歳のときからプログラミングをしていて、この質問は本当に興味深いものでした。まず第一に、他の人々が述べているように、コードを理解できるように新しい言語を学ぶことは、実際のプログラミング言語を学ぶよりも話された発話を学ぶのにおそらく時間がかかるので、実用的な解決策ではありません。

質問/回答を読んで、さらに2つのポイントが私に起こりました。

  • 第一に、あなたは「考える時間」がいかに重要であるかに驚くでしょう。以前はC/C ++ / Javaでプログラミングしていましたが、現在はC＃を第一言語として使用しており、非常に競争力があると考えています。しかし、Pythonでいくつかのプロジェクトを行ったとき、句読点の減少によって「思考時間」が奪われたことがわかりました。無意識のうちに、句読点を使用して、聞いたばかりの内容を消化していました。魅力的です...しかし、状況は識別子に関しては、リスナーにはあまり知られていないため、少し異なります-頭字語変数（RGXRatio、RGVRatio）を使用したコードを聞くのは、それが何を意味するのかを理解する時間がないため、個人的には難しいと思います。反対に、
  • 考慮すべきもう1つのことは、オーディオストリームの長さは最終結果であり、根本的な原因ではないということです。音声が非常に長い理由は、音声が1次元の媒体であるのに対し、テキストを読むことは2次元の媒体であり、関連性のない/なじみのあるテキストを飛び越えてスキップする機能を備えているためです。対面式の講義では機能しませんが、スピーチを制御するためのキーボードコマンドがある場合はどうでしょうか。テキストドキュメントでは、スクリーンリーダーで次の行にジャンプできますが、これがプログラミング言語のセマンティクスに適合している場合はどうなりますか。GoogleのTVラマンによるものなどのいくつかの研究には、構文の強調表示にさまざまな音声を使用したり、大文字のようなメタデータをマークするための音声キューを使用したりすることが含まれます。

クラスでの講義に特に関連する元の質問は知っていますが、私のようにソースコードのファイル全体を聞く必要がある場合は、コードの構造も大きな違いを生むことがわかります。私は個人的に物語のようにコードを読みます-左から右、上から下。そのため、ボトムアップで記述された場合、なじみのないコードを追跡することは非常に困難です。

于 2010-04-17T21:28:11.387 に答える
4

それらを説明するための新しい「単語」を作成する代わりに、「include」などの場合、声に出して言うときに単に「キーワード」を前に付けることができます。一般的に知られている単語/フレーズを使用して、他の部分も言うことができます。新しいプログラマーと同様に、文字通りすべてを説明する必要があるため、特に注意する必要はないと思います。新しい単語を作るのは難しい方法だと思います...

たとえば、次のようになります。

#include <iostream>;

int main()
{
   if (1 < 2)
     return 1;
   else
     return 0;
}

次のように読むことができます。

(キーワード) include iostream new-line (キーワード) int main no params start block if number 1 (operator) number 2未満 new-line (keyword) return number 1 new-line (keyword) else new-line (keyword) returnナンバー0エンドブロック

() 内の単語は、より複雑なコードで使用される可能性が最も高い、オプションの説明的な単語として扱います。実際に説明的な単語を書いてもらいたい場合は、「リテラル」という単語を使用できます。例えば

(キーワード) if リテラル番号 (演算子) リテラル キーワードより小さい場合

になる

if (number < keyword)

現在開いている括弧を閉じずに次の行に続けたい場合の「分割行」など、他の単語にも定義された意味を与えることができます。

個人的には、この方法は非常に使いやすく、教えやすいと思います。いつものYMMVです。

もちろん、これで国際化の問題が解決するわけではありませんが、最悪の場合、英語以外の言語で「新しい単語」が使用されることになります。これは、提案されたソリューションよりも悪くありません。

于 2010-01-28T08:09:58.240 に答える
3

それでは、簡潔でユニークな発音をこれらの異なる概念 (必要な場合は空白の発音を含む) のそれぞれに単純に帰し、そこから進むことは実行可能ではないでしょうか? プログラミング言語は自然言語よりもはるかに規則的であるため、発音は標準化される可能性があります

おそらくですが、あなたは目標を見失っています。前提は、聞いている人がまだその言語を知らないということでした。もしそうなら、単に「iostream を含める」と言うことができ#include <iostream>ますstd::vector<int>。

あなたの前提は、聞いている人は、あなたが声に出して読んだことを正確に読まない限り、その言語に精通していないということでした.

さて、ソース コードで発生するプリミティブを記述するためだけにまったく新しい言語を発明しても、問題は解決しません。代わりに、すべての構文トークンを読み上げる必要があります (より単純で、より「標準化された」発音を使用しますが、それでも大声で読み上げる必要があります) 。 "include iostream" を理解できるほど C++ を理解していなければ、標準化された発音も理解できません。そして、自分の発音を教えるつもりなら、代わりに C++ 構文を直接理解するように教えることができたのに、なぜわざわざする必要があるのでしょうか?

C++ コードが多くの構文トークンで構成される傾向があるという根本的な問題もあります。次のように単純な行を取ります。

std::vector<int> v;

私は9トークンを数えます。それらの 1 つを省略することはできません。聞いている人がコードと構文を十分に理解していない場合、「v という名前の int のベクトルを宣言する」などの高レベルの説明を理解できない場合は、何らかの形で 9 つのトークンすべてを読み上げる必要があります。「名前空間解決演算子」や「小なり記号」よりも単純な名前を思いついたとしても、9 つのトークン名をリストする必要があります。これは大変な作業です。

要するに、いいえ、うまくいかないと思います。第一に、それはまだあまりにも面倒であり、第二に、聞いている人が高レベルの説明を理解することを可能にする予備知識のない学生であったという動機であった場合、聞いている人の一部に事前知識があることを前提としています。コードの。

于 2010-01-28T08:54:16.193 に答える