型でドメインを構築できてるかが一番大事
@mizchi: なんか今後はAIがコードを推論するから型不要を主張するRubyist ちょくちょく見るけど自分が copilot使い込んだ感想は全く逆で、入力と出力の構造を規定するほど精度もプロンプトを挟んでの生成のバリエーションも格段に上がるので静的な情報は本当にあればあるだけ良い @mizchi: 関数名、型シグネチャ、その関数へのテストコードで外堀を埋めると大体一発で高品質なコードを出力するし、それでも足りない時はプロンプトとしてコメントを書いていく。型でドメインを構築できてるかが一番大事。 ただ、現状のcopilot はテストコードをプロンプトとして拾う力が弱い気がしてる
@mizchi: 自分が書きたいコードが一般的にどのようなメタファーやデザインパターンで過去に実装されてきたかの想像力が大事で、選ぶ抽象を間違えなければcopilot の学習結果のホットスポットを踏むことができて格段に精度が上がる ~中略 ~
@mizchi: 型の表現力とドメイン記述を中心に考えるなら、scala か typescript がホットスポット踏みやすそうな気がしてる @naoya_ito: 静的型付けの型をどういうメンタルモデルで捉えるかの違いかなあ。かくいう私もかつては、型は関数の入力と出力のデータ形式を指定するだけのものであって、めんどくせえなとしか思っていなかった @naoya_ito: 一方で関数が、何かを何かに写す関係を示しているものと考えると型はその「何か」と「何か」を表現するものになる。「何か」を集合とみなし、その集合がどこからどこまでなのかを型が表現する。 BDD とかで「テストを見れば仕様がわかるよね」と喜んだりするのと、同じだと思う。 @naoya_ito: この時、型システムの表現力が多様であれば、値の取りうる範囲をより構造的に宣言することができるので、関数の仕様をより正確に型で表現することができる。 ジェネリクス、ユニオン型や ADT、モナド、型クラスはそういう型の表現力を向上させてくれる @naoya_ito: 関数の型を先に宣言して、その型が通るように関数を書いていくというのは TDD と考え方としてはほぼ同じで、わざわざユニットテストを回さなくったって、今時ならエディタ上でリアルタイムに型チェックをしてくれるし、その型にあったコードだけに補完対象を絞り込んでくれたりするわけで @naoya_ito: ということを考えると、型注釈があれば AI がより正確に、コードを推論できるのはさもありなん、ということになるかなーと @naoya_ito: 未来に AI の性能が閾値を超えたところで体験がどう変わるかはわからないけど、少なくとも現時点の AI の性能ではこの辺が着地点かと思われます @naoya_ito: ユニットテストも当初はプログラムを守るディフェンシブなものとみんな捉えていたのが TDD なんかで積極的にテストを先に書くことで「思考を助けるもの」と捉えるようになったと思うんだけど、私は昨今は型もそういう類のものだと捉えています @akfm_sato: TSとかが提案してくるいわゆる「補完」に間違いはないけど、Copilotの「提案」は存在しない関数とか出てくることあるからそこの違いは気をつけないと使いこなせないな。