cut-sea

書かせてもらったもの（含進行中）

過去

cut-sea:log(2003/5/29-2004/12/31)
cut-sea:log2(2005/01/01-2005/12/31)
cut-sea:log3(2006/01/01-2006/06/30)
cut-sea:log4(2006/07/01-2006/12/31)
cut-sea:log5(2007/01/01-2007/12/31)
cut-sea:log6(2008/01/01-2008/12/31)
cut-sea:log7(2009/01/01-2009/12/31)
cut-sea:log8(2010/01/01-2010/12/31)
cut-sea:log9(2011/01/01-2024/12/31)

和田先生の「計算機科学の終焉」を読んだ

https://note.com/ipsj/n/n5452212e0dbf

本筋関係ないけど地味に 0 から列挙しているのが好き。

codex を使ってる

会社で使えるようにしてくれているので自分は少し遅かったけど7月位から使ってる。で、相当のコミットを積んでまだまだ十分ではないけど今思っていること。

この手の AI が登場した当初「あと1年もしたら仕事無くなる」という人が湧いたけど、まぁまだねーなという感想。別にAIがダメだと思ってなくて、AIの進化も疑ってないんだけどそこじゃないなという認識。

まず開発においてこれが作りたいとかここを改修したいという動機を持つのは今のところ人間だというのを前提に置く。(これは後で議論)

この場合 AI にやらせたいことを伝えることが必要なんだけど、やってみて思うのはこれがやっぱり難しい。

難しいポイントは2つあると思ってて、一つ目はコミュニケーションの難しさ。これは AI だから難しいというわけではなく人同士でも認識に齟齬があったり食い違いがあるのと同じでコミュニケーションにおいてインピーダンスミスマッチがあるということ。 AI は別にテレパシーが使えるわけでもこちらの脳とつながってもないので仕方ない。これは AI が優秀になることとはあまり関係ない。

二つ目のポイントは我々指示する側の成果物に対する解像度の問題で、規模によっては成果物の解像度が低い場合がある。書きながらでないとはっきり分からないことがあったり、仕様通りに書けばすべてうまくいくような指示を、実装前に決定できないことがあったり、問題に気づけないこともある。これも別に AI じゃなくて人に依頼して作ってもらうときにもあったこと。

新しい AI が出てくるとまず「テトリス作らせたら一発で動いた」的な話が出てきて続いて「プログラマ終了」みたいな煽りが出るけど、「テトリス」だけで仕様がカンペキに伝わるんだからむしろこれは簡単な課題なのよね。

動機を持っている自分の頭の中だけにある成果物のイメージを伝えつつ、しかもその成果物は実は解像度を高めると欠陥や矛盾を抱えているようなものなんだが、それを完成まで持って行くのはやっぱり難しい。これって AI が登場する前からそうだったし解決されてない認識。

でも AI のいいところは確実にあって、とことんリテイク出しても良くて全然機嫌を損なわないし、なんなら破棄しても不平を言わない。技術的には苦手分野が無い。自分だったら畑違いだとお手上げだが、 AI にはほぼそれが無さそうに見える。少なくとも自分より圧倒的に広範囲をカバーできてる。すごいコードを紡ぐわけではないけどそこそこのコードをこれだけ広範囲にカバーする人はあまりいないだろうと思う。なのでペアプロには上に書いたような問題はあるけど頼りになるドライバではあるし、コーディング能力自体は今後もどんどん向上されるはず。期待できる。

というわけで、結局 AI があればソフトウェアエンジニア要らないとかはそうすぐには来ないかなという風に思ってる。今のところ難しいけどそれでも最もうまく使えるのはプログラマだろうから。

つまり私の現時点での気持ちとしては危機感ではなく、良いツールが手に入った。昔から人同士であっても存在してた課題は相変わらず残ってて、それを解決してくれるものではなかったが考えてみれば当然のこと仕方ない。という感じです。

ただし、これは開発動機を持つのが我々人間だという前提を置いた場合の話。 AI が動機を持つようになるのであれば我々が不要になる可能性はあるかもしれないと思う。社内 Slack にアクセスし、会議内容をすべて共有し、顧客とのミーティングにも参加、エゴサーチをして自社のプロダクトの評価や課題を知り、 AI 自身がどういう対策が必要か、どういう改修をするのかの動機を持つようになるならコミュニケーションの問題は解消しそうだ。この場合の障壁はやっぱり人間で、会社が今人間で構成されている開発部門にプロダクトのすべてを委譲しているとして、それを AI に委譲しちゃうぜって決定(決断)できるかどうか。

で、昔の保守的な会社とかは難しいと思うけど、わりと今の世の中だと新しい会社なんかはやっちゃえやっちゃえで始まるかもしれない。チームメンバに AI が加わり、そのうち比率が逆転して、どこかで会社が決定する。 AI だけでも任せられる。インシデント対応だって 24x365 で休みなく対応するだろう。最終的に AI だけのチームに...というのはあるかもなーと思ったりはする。

あー、その時は仕事なくなる... けど AI が動機を持つからといって我々が動機を持たなくなるわけではないので相変わらず自分はプログラムを組むんだろうと2025年の9月時点では思ってる。

さて今後どうなるのでしょうか。と言いつつまたプロンプトを打ち込んでコーヒーを入れに行く。 2025/09/22 03:45:12 UTC

Rust を使うことが多くなっているけれど...

先日の Imprementing Functional Language(以下 ifl) 読書会で最近は Rust が割と好きで大抵 Rust で書いてるという話をした。 ifl の実装は Haskell で書いているけど、すっかり Scheme 書かなくなっている。

なんだけど、実は言語の設計の考え方というか思想というか大袈裟に言えば哲学の部分はやっぱり Scheme が好きなんだよなという話をした。 Scheme の仕様って他にもあったと思うけどほぼ RnRS なのかなと思うことにして、先頭に書いてある以下の文章が良いのだというのを語った。ミニマルってこと？と聞かれたんだけど、まぁ結果的にミニマルになっているのかもしれないけど、そういうことではなくてこういうこととふんわり話したんだが R7RS にも当然継承されてたので INTRODUCTION の最初の一文を引用。

Programming languages should be designed not by piling
feature on top of feature, but by removing the weaknesses
and restrictions that make additional features appear necessary

Haskell もそういう感じだと思うという人が居たんだけど、だいぶ違うんだよね。 GHC なんかも新しいバージョンが出たら、このプラグマが使えるようになって云々と嬉々として語るとかあるじゃん。

あと他の言語のフィーチャーを指して、Haskell にもあれは欲しいとかそういう話が出るんだとしたらやっぱり違うんだよね。例えば async/await とかいろんな言語で採用されつつある構文だけど、これを欲しいと思うプログラマが自分の好きな言語に導入してもらうには言語実装者にプロポーザルを書くか口頭で伝えるかして説得して実装してもらうことになるんだけど、それは SPJ だったり Guido だったり Matz だったりするのかもしれないが Scheme だとこんな感じで Scheme プログラマが作っちゃう。

で、逆にわからなくなったんだけど、 Scheme の場合バージョンが上がることでなんかうれしいことってあるっけ？みたいな事もその時ちょっと言ったりした。 2025/09/22 02:37:38 UTC

Haskell と Rust の型に対する考え方(?)の違いについて思ったこと

長いこと趣味で書くコードは Haskell ばかりになってて、ここ2-3年だと Rust を使うようになってる。簡単な Toy プログラムでしかも綺麗に感じるものはいまだに Haskell で書くことが多いけど、ちょっとプラクティカルなものは Rust で書いている。

ともに Scheme と違っていわゆる静的型付言語というやつだけど、しばらく前にペアプロに召喚されて、プログラマの脳に影響を与えているなと思った違いに気づいたので記録しておく。

Haskell はこんな感じでコードが書かれている。(ここでは a が型シグネチャ)

f :: a
f = ...

一方 Rust だとこんな感じ。(型なしで済ませることが多いけど敢えて書く場合で、ここでは T が型シグネチャ)

let f : T = ...

些細な違いだけど、 Haskell は型と実装はあくまで別のコードとして書いてて、よく 型だけ 先に書く、といったことをやる。実際には実装なしだとエラーになるので f = undefined という風に実装も書くっちゃ書くけど、そういう意味ではなく実装はノーアイディアでも型だけを考えるというのが割と自然に推進されている気がする。やはり基本的には Haskell は型推論ではなくて型検査を建前としているということだと思ったりする。

一方で Rust など最近のモダンな静的型付言語は基本的には型は推論されてほしいものであって、実装に対して補助的にアノテーションするということなのか(どうなのかは知らないけど)型は実装に練り込むような形になっている。逆に言えば、まずは実装ありきであって、型だけ先に考えることはできなくはないけどプログラマにそれを促すような作りではないように思う。(だって型だけ独立して書けず、実装にアノテートしているわけだし)

というのもヘルプで呼ばれたときドライバはどういう実装になるのかがあまり見えてなかったようで、いろいろコードを書いては型を確認してあぁでもないこうでもないと苦しんでいた。この時実は私も実装については解像度が高くなかったが、ひとまず実装は考えずに型を書いてこんな型があれば良さそうだよね？という風に進めると分解された型の実装はほとんど一意に定まってしまってなんてことなく実装できてしまったのだ。

もちろん Rust でも todo!() 使って実装を undefined 相当にしつつ型だけ書く流儀を適用することはできる場合もあるけど、トレイトを返すような関数だと通らなかったりするし、仮にそこをサポートしたとしても根本的には言語の構文としてそれを自然に推進するような言語ではないんだなと思った。2025/09/22 01:59:09 UTC