プログラミングと「表現力」

yamayuski
·
公開:2024/7/11

良いコード、悪いコード、良い設計、悪い設計、様々な面からプログラミングに対して評価がなされているが、最近感じるのはプログラミングにおける「表現力」の重要性の高さだ。

`var a = 0;` と `var index = 0;` のどちらが表現力が高いと言えるかといえば、もちろん後者。これは簡単。色んな教材で「命名の重要性」が触れられている。変数や関数に適切な命名を行うことが良いとされている。

`user = ['id' => 1, 'name' => 'ああああ'];` と `user = new User(1, 'ああああ');` のどちらが表現力が高いと言えるかといえば、これも後者。型による制約が付き、より正確に変数を表現することが出来ている。カプセル化も可能だ。

`user = new User(1, 'ああああ');` と `user = new User(new Id<User>(1), new UserText('ああああ'));` のどちらが表現力が高いと言えるかといえば、意見が割れることもあるが自分は後者だと思う。型は絞り込むほど正確性が上がり、厳密なコードになるので、エラーを詳細化出来る。

このように、「良い」とされるコードは「表現力が高い」ことが多い。逆に言えば、いかに表現力を高めるかがコーディングでは重要なのである。

これはユーザー定義の型に限らず、プログラミング言語自体や利用するライブラリにも同じことが言える。

私はこのライブラリを見て「なんて表現力のある素晴らしいライブラリなんだろう」と感嘆した。

ユニットテストで assert(これはこうなるはず、そうでなければバグである、という表明) を助けるライブラリだが、このライブラリを使うとその assert の表現力が一気に高まる。

通常、 `assert(some === 1);` とだけ書いて、それが失敗した場合、 `Failed to assert some === 1` というようなテスト失敗文字列が出力される。それだけだと何故 `some` が `1` じゃないのか、 `some` には実際何が入っているのかわからないため、別途ログを仕込んだりする必要があり手間だ。

このライブラリを使うと、テスト失敗文字列に `some` の中身の値も表示してくれるようになるので、何故失敗したか一目でわかるようになる。これが「表現力の向上」だ。

こんなことを言ったが、イテレーションの向上には「エラー時の表現力の高さ」が欠かせない要素だ。先ほどのライブラリを使えば、イテレーションを高速化することが可能なのは理解しやすいと思う。

もちろんライブラリだけでなく、コンパイルエラーもイテレーションを加速する手段だ。ユニットテストのように実行して初めてエラーに気づくより、コードを書いている瞬間に構文エラーや型のエラーが表示された方が早く修正出来る。また、表示されるエラーがより詳細で理解しやすい方が修正もしやすい。 Rust を触ったことがある人は、コンパイルエラーの詳細さに助けられたことがあるはずだ。

ここで、日本人特有の課題があることに気づく。それが「エラーが英語であること」だ。現在の日本人は英語は必修ではあるが、毛嫌いしている人も多く存在する。元々プログラミングに精通していない人が、苦手な英語の文章を目の当たりにすると、「よくわからないけどなんかエラーが出て動かないよー」と落ち込んでしまう。

これは「(特定の日本人に対して)表現力が不足している」と表すことが出来る。エラーが日本語であったり、そもそも書く変数名や関数名が日本語であれば躓かなかったかもしれない。

コードにおいて表現力が重要であるという前提だと、わざわざ国語ではない外国語に一度翻訳することは、表現力を損なうもったいない行為だと私は考える。

だからといって `if` や `for` も全部日本語にすればいいというわけではないのだが、英語の命名に対して苦手意識を持っている日本人のエンジニアは少なくないのではないだろうか?

ということで、私のやってみたい一つの物事として「命名もエラー文もローカライズ(最低限日本語)が可能なプログラミング言語」を作るのはどうか、というのがある。

プログラミング言語の作成は様々な考慮が必要なためかなり高度な技術を要求され、実装コストも非常に高いのが現状なので実現する可能性はかなり低いのだが、日本人エンジニアの生産性を向上させる一つの手段としては良さそうだな、と考えている。

言語を作るのはさすがにしんどいので、せめてライブラリとして表現力の向上を助けるようなものを今後作成していけたらな、とは思う。