Javaでのデータ指向プログラミングの話を聞いた。これを聞いて(1日経って)思いついたことを取り留めもなく書く。
昨日時点だと、Record・Sealed Class・パターンマッチングの登場は、これまでオブジェクト指向プログラミングの考え方(クラス・継承等)で対処していたある特定の事柄に対して、より手間なく明確に処理をかけるソリューションが新しくできたということだと認識した。
新しい道具が増えると全部それで解きたくなるという話を聞いたことがあるが、プログラミング言語の新機能について既存の解決策の問題点を認識した上で、ほらこんなによくなったというのを見ると、そのような思い違いをすることもなさそうと感じた。
そして、プログラミング言語の新しい仕様によって解決できるその問題点を抽象化していくと、その仕様の登場以前の実装効率と表現方法(実装方法)であると認識できた。(厳密にはそれぞれの要素がお互いの一部分を内包している気もするが)
今回は前者の話はせず、後者の表現方法の話となる。
新しい語彙が辞書に加わることがあると思うが、それに近いことがプログラミング言語で起こっており、それを使うとコミュニケーションが早くなるということ。うまく話せるようになるということ。意図を伝えられるということ。
表現を的確に行うには、それを表す事柄についての理解が必要でそれをしていかないといけないということに(今更)気が付いた。
そして、プログラミング言語における習得度合いは、既存の問題に対してその言語の仕様を使ってより適切に実装できる度合いのことだと自分なりには腹落ちした。
特定技術を「オワコンだ、死んだ」と話をする人は既存の問題に対する解決策を提供してくれない技術と結論付けており、大抵そこに議論が起こるのは既存の問題に対する認識が各人で噛み合っていないか、解決策への理解の差があるということなのだろう。(本当に既存の問題を解決できない言語も存在するかもしれないけど、それを断言できるほどそれぞれ詳しくなれるのだろうか。)
これまでの話とは別に、今(更)リーダブルコードを読んでいて、この本にあるのは他者に本来実現したい処理の意図を遮らないため、理解をする上での不要な副作用を発生させない一般的な方法が書いてあるように思えてきた。
ある特定言語でのリーダブルコードを実現するには、そのような言語を問わない一般的な話に加えて、その言語特有の部分である問題とそれに対する適切な解決策の組み合わせを使って意図を伝えるということだと、言語化できた。
コードの読みやすさの話もプログラミング言語の新機能追加の効果の一部も結局のところ、コミュニケーションの話に繋がるのだなと新たに気づいたので本稿書いてみました。