orange @[email protected]

後で自分でも読みたくなるかもだからログ共有＞＜
https://g.co/gemini/share/e369d0929c12

議論の本題かもしれない部分は、 "では、実際にその点について考察してみるとどうでしょうか？＞＜" 以降かも＞＜
最初の方は、Geminiが矛盾を見つけられるかをテストしたくてやってた部分だからあんまりおもしろくないかも＞＜

動的型付けって不要ではって話で、Geminiは「究極の安全性要件」("宇宙船の制御システムや医療機器など、絶対に失敗が許されないシステムにおいて")は、実行時にもバリデーションするじゃん」って話をしてきたけど、「実行時のバリデーションは動的型付けと関係ないだろ＞＜　むしろバリデーションの必要な範囲を実行前に検出するのも静的型検査だろ＞＜」って説明するのにAda/SPARKを使った＞＜

Geminiさんのまとめ＞＜

簡単に言うと、人間がかかわらずとも完璧にプログラミングできるAIなるものが出来たとして、
完璧に動作するプログラムは、実行前に型がすべて決定されている（とりうる範囲が全て想定されている）物の事を言う（実行時にしかわからないものに関してバリデーションコードの漏れも無い状態）であるので、
未来の完璧なAIがコーディングした完璧なコードなるものは、完成の時点で既に型が決定しているので、
つまりそれは、定義上、静的型付けである＞＜
みたいな感じで合意が得られたかも＞＜

なんか、Geminiに最初普通に感想を聞く形でさっきの記事について聞いたら、全然矛盾を見つけられなくてオレンジの指摘でやっと見つけられるという残念なことになったので、「この点とこの点とこの点について、このような矛盾がないか検証してほしい」みたいに注目させるプロンプトで聞いたら、
矛盾は相変わらず見つけられなかったけどなんかものすごい議論モードでの返答になって、そこからバチバチの議論になって超おもしろい＞＜＞＜

まつもとゆきひろさん「Programming Language for AI age」～RubyKaigi 2025 3日目キーノート | gihyo.jp
https://gihyo.jp/article/2025/05/rubykaigi-2025-keynote-report-day3

なんで、コミュニケーションでのエラーの話を、統合された認識（知識）内でのエラーの話に挿げ替えてるの？＞＜

"...AIが出力したコードを読んで人間が修正したり、人間が書いたコードをAIが手直ししたりなど、AIと人間が相互にやり取りする場合、一般的には静的型付け言語が使いやすいと言われています。..."
"...ただ、未来のことを考えた場合、本当に静的型付けは必要だろうか、とまつもとさんは問いました。人間はうっかり型を間違えることがありますが、賢い人間は型エラーを起こさないので、十分に賢いAIは静的型付けなどなくても型エラーを起こさない、と言います。"

プログラミングみたいな比較的決定論寄りの話だけでなくて、もっとふわっとした創作がらみでも、間に確率的なレイヤーが挟まると刃のキレが悪くなる的な感覚があってなあ…

AI（というかLLM）がコンパイラみたいなレイヤーになる、って主張にある程度は賛同するんだけど、動作が確率的なことを思うと、その下を隠しちゃうレイヤーになってほしくはない

あとコンパイラみたいなレイヤーだとすると資源食いすぎるのではないかとも思う

「お、お前まさかAIを使わずに手でコードを書けるのか…？まだそんなやつが生き残っていたとは…」

LLMは面倒そうだしそのうち料金も高くなりそうだし電気も無駄遣いしてそうな気がするので触りません #老害

いまLLM利用のソフトウェア開発、面白いフェイズだなー

おおまかに3種類のひとがいる

* 仕様を与えつつコード自体もバリバリかかせる
* コードは書かせない、補助にとどめる。補完、レビュー、テストなど
* こんな危ういもの絶対使わん/使えん

グラデーションもあるしバリエーションもある。テストだけ書かせてコードは人間、テストは人間が書いてコードかかせる、って正反対のひともいる

みんなそれぞれに説得力のある論拠をもってて面白い。よくみると前提条件がそもそも違うから違って当たり前だったりもする。新規コードと歴史あるコードじゃぜんぜん違うし（新規の方がLLM得意）、コードの規模によっても違うし

たのしく眺めながら私自身もいろいろ遊ぶつもり。お仕事への導入は補助的なほうでやってる。補完とか

カリフォルニアっぽい展示車

ソノマ・レースウェイだ！

レース見にきた