会話で使える気がする「プログラミング文法」(気がするだけ)

コレは何？

我々が普段行っているコーディングでは一定のルールを定めてそれに沿ってコーディングすることが一般的である。

もし、そんなもの私の知ったことではない！という人がいるのであれば、ぜひBrainf*ckでもWhitespaceでも好きな難読言語を書いてほしい。

本記事はそのコーディングルールの大切さがわかるように一般の会話で使うことを想定して考えてみよう。

また、本記事に登場するコードはあくまで自然言語をプログラミング言語的に解釈したものなので、記載されているコードは全て動作しないことを保証する。

Case1 何が言いたいのかわからない

皆さんはこんな話をすること、もしくはされることはないだろうか？

「昨日、仕事から帰ってきたら、急に雨が降り始めて、コンビニに行こうと思っていたのに、傘が見つからなくて、友達と話している間に、電車も遅れて、夕食の準備ができなかった。」

これはChatGPTに作ってもらった例だが、文章にわかりにくさが伝わってくると思う。

これらは常に時系列順に事実を列挙しているだけであり、聞き取り手にとっては何を伝えたいのかがわかりにくく「一体何を伝えようとしているのだ？」となってしまうでしょう。

コードで書くとこんな感じ

昨日(() => {
    仕事から帰宅((自分) => {
        急に雨が降り始める((雨) => {
            自分.思う(自分.行く(コンビニ), () => {
                傘がない(() => {
                    自分.友達と話す((友達) => {
                        電車遅れる(() => {
                            自分.伝える(夕飯の準備ができなかった)
                        })
                    })
                })
            })
        })
    })
})

おそらくこのような構文になる。

この時点でプログラミング言語のメリットをあげるのであれば

• インデントがあるおかげで、処理のまとまりが見えやすい
• 最終的に何をしているのか？が一目瞭然
• どこを改善すればいいかがわかりやすい

という点があげられるであろう。

この時点で最終的に伝えたい要素が「なんやかんやあって、夕飯の準備ができなかった」という事がわかる。

リファクタリング

この時点で主語がどこにあるかがはっきりしたので、以下のようなコードに変換できるだろう。

自分.伝える(
    夕飯の準備ができなかった,
    理由=昨日の出来事([
        帰宅遅延(理由=[
            コンビニにいけなかった(
                理由=雨が降っていたが傘がない
            ),
            友達と話していた,
            電車遅延,
        ]),
    ])
)

まずは伝えるべき内容が1番目に来るのが重要だ。
伝えられた側は「なぜ？」と思う事で聞く準備が整うだろう。

また、前者では物事の過程を表していただけの情報が「なぜ？」と思うことにより理由として立項されるようになるだろう。
理由に関して言えばそれぞれのつながりに意味がなければ、それぞれ同じスコープで扱ったほうがわかりやすいので、List的な扱いをすることにした。

これにより前者より圧倒的にネストが減り、前提条件を覚えるコストがだいぶ減るだろう。

会話に戻してみる

つまりコレを会話文に置き換えるなら

「ごめん、夕飯の準備ができなかった。言い訳なんだけど、昨日帰るのが遅れちゃったからなの。急な雨でコンビニに行けなかったし、友達と話すのも長くなっちゃって、それで電車も遅れちゃって。」

という感じになる。

これならおそらくあなたのパートナーが渋々ウーバーイーツを注文する決断も早まるだろう。

Case2 赤い頭の魚を食べる猫

「赤い頭の魚を食べる猫」という言葉がある。
これは解釈が5通りほどできてしまうというものだ。

これをコードにすると属性として表現できるため間違いがないだろう。

コードで表現

let 猫 = {
    頭: {
        色:赤
    },
    行動: (魚) => {
        食べる(魚)
    }
}

「頭が赤い猫。その猫は魚を食べている。」
それぞれの特徴が分類ごとにわけられているのであれば、間違いは起こらない。

let 魚 = {
    頭: {
        色: 赤
    }
}
let 猫 = {
    行動: (魚) => {
        食べる(魚)
    }
}

「赤い頭の魚、その魚を食べる猫。」
これもそれぞれ分離されているので属性として捉えられる。

let 魚 = {
    色: 赤
}
let 猫 = {
    頭: {
        行動: (魚) => {
            食べる(頭)
        }
    }
}

ありえないシチュエーションでもコードであれば聞き返さずに受け取れそうだ。
「赤い魚を猫は頭で食べる。」となりそうだが、自然言語に戻すとこれは違和感のほうが勝っている気がする。

let 魚 = {
    色: 赤
}

let なにか = {
    頭: {
        形状: 猫
    },
    行動: (魚) => {
        食べる(魚)
    }
}

「頭が猫のなにかが赤い魚を食べる。」
元の文章からでは生物か無生物か言及されていないので「なにか」とした。

let なにか = {
    頭: {
        形状: 猫,
        色: 赤
    },
    行動: (魚) => {
        食べる(魚)
    }
}

「頭が赤い猫の形をしたなにかが魚を食べる。」
こちらも「なにか」である。

構造化の恩恵

プログラミング言語は構造化をすることにより、どのスコープであるか？を明示することが容易だ。
これにより、比較的容易にこれらの状態を判別できる。

とりあえずコレ以上思いつかない

通勤中、唐突に思いついたネタだが、思った以上に例文を探すのが難しかった。

ここから学びを得るとすれば、「プログラム言語は人が読みやすく設計された言語」ということであろう。
おそらく、ここで登場したコード（と呼べるのだろうか？）はプログラマであればノリで読めるのではないだろうか？

つまり何が言いたいかというと、EXCELに設計書と言う名のプログラムは可読性が最悪で誰も幸せにならないから今すぐやめろてくれ。 プログラミングって楽しいよねーって話でした。