クリーンルームに対する認識が少し間違っているようですが……ソースベースで書き直したからといってクリーンルームになるわけではありません……クリーンルームというのは、片方で既存コードをもとに spec を作成し、別の主体がそれをもとに実装してこそ成り立つものではないでしょうか……

 

oh my zsh はもう何年も必須で入れていて、
oh my opencode も Anthropic に止められるまでは本当に便利に使っていましたし、コミュニティでたまに話題になったときも「自分もあの頃はそうだったな」と思っていたのですが、
今では oh my XXX を見るだけで「また―あのグループ―か?」という気持ちが先に来ますね。

煽りもほどほどにしてこそ好意的に見られるものです。今回はちょっと一線を越えましたね。

 

こんなことをしてスターをたくさんもらったからといって、リスペクトされる名の知れた開発者になれるわけではないでしょう、、、

 

元カノの名前を入れちゃった自分みたいな人間のことですよ……。NAVERもこの機能を導入するって言ったら、すぐ株を買いに行きます

 

中国製モデルの性能がさらに向上しそうですね

 

基本的なところは、もう少ししっかりしてほしい……

 

メモリ安全性のために機能を追加するのではなく、ダングリングポインタや可変参照だけでも禁止すればメモリ安全性は高まるのに、むしろ機能追加でコードの複雑さだけを増やしていますね

 

韓国でも早く対応してほしいですね。

でもこれ、NAVERが対応してくれたらものすごく称賛されそうです。
NAVERのIDは適当に作ってしまって後悔している人が多いですし

 

経験上、会社にはこういうスタイルが思ったより多くありました。どの世代でもこうしたやり方は初期にはうまくいくことが多いようですが、長く続くケースはまれでした。それでも中の上くらいにはうまくやりながら生きています。

 

最近は、良いものを共有するというより、注目を集めることに必死な自称スター開発者が多すぎます。Threadsに行くだけでもそういう人ばかりです。サイバーれっかーは、もはや一部のYouTuberだけの専売特許ではなくなりました。そうであればあるほど、逆の現象も起きると思います。プレミアムコンテンツの方向へ、というように

 

これがいわゆるホンデ病ってやつなんですかね

 

クリーンではないコードをもとに作ったものが、クリーンルームになり得るのでしょうか?

 

流出版のソースコードに含まれていた /buddy 機能が正式に公開されました。

buddy 開始(ふ化させる)

/buddy

バディをなでなでしてあげる

/buddy pet

バディを寝かせる

/buddy off

 

苦労してRustに移行したのに、C++26の標準案に待ち望んでいた機能のかなり多くが反映されたのは心強いですね。でも、再びC++に戻ることはないと思います……(笑)

 

これがいちばん大きな心配ではあります。
10年後、20年後、30年後にシニアと呼ばれる開発者が何人残っているのか……

 

わあ、ゲーム画面から感じられる昔の時代の空気がすごい;;

 

クリーンルーム(流出コードベース)...?????