自分は LLM ではうまくコードが書けない

GitHub Codepilot のような LLM にコード生成させてコード書くのを効率化している人がいるらしい。
自分は、うまいこと指示できないし、間違っているかもしれないコードを書いてくれて、人間が間違い探しするくらいなら、自分で最初から書いた方が良さそうに思ってしまう。
みんなは、めっちゃ未熟な人に動かないゴミのようなコードを提出されて煮湯を飲まされた（自分で直す or 何度も指摘して直してもらう）ことなかったんだろうか？

考えてみたら、自分は インテリセンスのような補完機能も使ってないもんな。

どんなに Chat GPT が進化していっても、インターネット上に学習元となる良いコードはそんなにはなさそうなので、これ以上大幅に良いコードは書いてくれないだろうと予想している。

LLM によるコード生成は、一過性のブームになると今のところは想像している。10年後に、このことを書いたことを思い出したら、振り返ってみることにする。

プログラマーになることをお勧めしない

30年前の職業プログラマーといえば、労働集約的で誰でもできて、それでいて若いうちしかできないものだった。
あの頃に比べれば、待遇もよくなり、子供の人気職業になり、なにより長く続けることができるようになった。
学歴による差別も性別による差別も、他の仕事よりは少ないと思う。
会社に依存せずに、転職しやすいというメリットもある。
転職はしなくてもいいが、一つの会社にしがみつかないと生きていけない、というのはつらいものだ。

しかし、若者に職業プログラマーをお勧めしづらい。
せめて、仕事を始める前に適性があるかどうかわかればいいんだけど、なかなか事前にはわからない。
自分の子供のことは、性格も能力も比較的わかっているはずだが、職業プログラマーとしてやっていけるのか自信がないのでお勧めできない。
僕よりは、数学も英語もできるとは思うのだが。

コンピューターやスマートフォンのスペックに詳しくて興味あるんだろうなぁという人が、単なるガジェットおたくのままだったりする。
新人研修で
「全くわからん」
と言ってそのまま１年経過せずに辞めていく人がいる。
そういう人は、本人も僕も、どこがどうわからないかがわからないまま、会社を恨んで去っていく。

一方で、何も知らない状態で就職して研修期間中にプログラミングに触れて開花する人もいる。
「日本文学を学びました。崩し文字読めます」
という人が、ハローワーク経由の技能講習でプログラマーになった人もいる。

話は簡単ではなく、大学時代に興味があってプログラミングの会社にバイトに行ったが、２〜３年は、理屈はわかるがプログラミングはわからないかったのに、
ある日突然ひらめいてプログラミングがわかるようになったんです、という人もいる。
（ということは、一年経過せずに会社を辞めた子は、３年くらい我慢したたら「エウレカ！」となる時が来たんだろうか？）

大学の情報系の学科は、プログラミング演習の時に、
「俺はプログラマーは無理そう」
と、早めに挫折するメリットはあるのかも。

梅宮アンナさんが標準治療をしている

以前からいろんなところで言っていたと思うが、週刊文春で、乳房がんで、民間療法に頼らず標準治療をしているということを答えたいた。
よかった。

昨今、多くの芸能人、漫画家なのが民間療法に頼って死んでいったような話を聞く。
標準治療をしながら、別のところでこっそりビタミンCを摂取するとかならまだいいのだが、最近、そういう人たちは、標準治療をやめて民間療法で早死にしているらしい。
せめて、亡くなる時に、民間療法を選択したことを後悔せずに死ぬんだったらいいけど・・・と思うけど、川島なお美さんは、後悔していたようだ。
Wikipedia によると、（アメリカに標準治療はないけれど）スティーブン・ジョブズも相当後悔していたそうだ。
お金持ち故に民間療法が選択できて、そのために死ななくてすんだのに死んだとしたら、実に悲しいことで、何のためにお金持ちになったんだろうって思っちゃう。

梅宮さんのインタビューでは直接は書かれてないけど、癌だってことが報道で知らされると、民間療法のインチキ医者が群がってくるようだ。
梅宮さんのインタビューで標準治療が最高レベルの治療で、民間療法はインチキ（臨床試験で有効性が示されていない）ということがもっと広まれば良いと思う。

プログラミングには単純作業がない

プログラムの関数名を変えるとか、処理を分割するとか、まとめるとか、同期関数を非同期関数にするとかを
「単純作業だから・・・」
と言ったりする。
しかし、キーワードを置換して済むような場合はコマンドで一括置換できる。

人間がやる必要がある単純作業は、どこかに人間が判断する必要がある箇所があるわけで、そうすると、未経験の初心者には難しかったりする。
そして、単純作業と言っているものほど、慣れている人がやった方が圧倒的に速くて未経験の初心者にやってもらうメリットがない。

「Webサイト上の画像を入れ替えて」
という場合に、コピーする場所がわかっている場合なら指示する人がやっちゃえば終わりだし、HTMLのソースをみて、ソースコードをみてどこに置かれているか調べて置き換える、場合によっては HTML に書かれているファイル名、パス名を変更しなきゃいけないとなると、何もわからない人にとっては、これって結構難しいよなぁ。

僕こそが、プログラミング言語の文法はわかるけど、プログラミングをしたことがないという状態で就職したので、そういう人たちが一人前になって生活できるようになっていって欲しいと思うが、あの頃自分がどんなだったか覚えていない。
おそらく、僕が新人の頃のプログラミングが、もっと素朴で簡単でスケジュール的な余裕もあったんだと思う。

SSLでECDHEをサポートしない暗号が使われなくなっていく？

Go 1.22 では、デフォルトで RSA暗号が使えなくなっている
https://zenn.dev/shopan/articles/a0cacca7aa258d
と聞いて、ちょっと驚いた。

RSA暗号は、鍵長が短いと解かれちゃうので、十分長い鍵長にしないといけない。
ECDHE は、鍵長が短くて済むけど運用期間が(RSAより）短いので、誰も発見してない脆弱性があるかも

という認識だったけど、RSA 暗号はもう使っちゃダメなのかな？
これ以上鍵長を長くしていくと処理時間がかかりすぎちゃうっていう事情もあるのかな？

世の中では、ようやく TLS1.1 を廃止(Azure で 10/31 に終了) というところで、これだけでも、おじいちゃんの自分は
「え？TLS1.1 使えなくなっちゃうの？古いサーバーとか大丈夫かな？」
と思っちゃう。

TLS1.2以降でも、なんとなく安心だから、サーバー証明書には RSA 暗号を使っているってところ多いんじゃないかな。
Go 1.22 で、デフォルトで RSA暗号使えなくなっているのは大胆な決断だなと思った。今後のバージョンで RSA暗号が復活するのか、それとも世の中の TLS のライブラリが RSA暗号のサポートをドロップしていくのか？

（追記）
あ、違うか ECDHE-RSA-AES128-GCM-SHA256 なんていう暗号スイートがあって、 RSA=ダメってわけじゃなくて、 ECDHE を使ってないことが問題なのか。