Dev | ntea.log

プログラミング 2026年7月27日

実装者と利用者——境界の向こうに他人がいるとき

一人で書いているとコードに境界は生まれません——実装者と利用者が分かれた瞬間に何が変わり、ライブラリやフレームワークがなぜあの形になるのかを整理します。

プログラミング 2026年7月27日

インターフェースは型と並ぶ概念ではなく型の一種です——では何が特殊なのかを、契約・判定方法・所有者の3点から整理します。

エンジニア 2026年7月26日

一応動くのに、全体としては劣化していく——AI が量産するコードの症状を4つの軸に整理し、その根っこにある「削除の証明ができない」という制約と、コストを誰が払っているかを実証データから読み解きます。

プログラミング言語の世代交代 2026年7月26日

記述量を減らすためではなく、表現できてしまう状態を減らすために構文は変わってきた——言語をまたぐ変化の共通ベクトルを読み解きます。

プログラミング 2026年7月26日

型設計の目的はエラーを早く見つけることではなく——不正な状態をそもそも表現できなくして、確認そのものを不要にすることです。

プログラミング 2026年7月25日

try/catch を書く技術ではなく、どこで捕まえてどこまで運ぶかの設計——例外処理の良し悪しはその一点で決まります。

プログラミング言語の世代交代 2026年7月25日

match と書ければ同じではありません——分岐の網羅漏れをコンパイラが教えてくれるかどうかで、機能としての価値が変わります。

プログラミング 2026年7月24日

null 安全は言語機能で自動的に手に入るものではなく——生成・伝播・消費の各段階で「不在」をどう設計するかの問題です。

プログラミング言語の世代交代 2026年7月23日

不変性には「束縛の不変」と「値の不変」、そして浅いか深いかの軸がある——同じ readonly でも守る範囲が違います。

プログラミング言語の世代交代 2026年7月21日

例外と Result 型の違いは好みではなく、失敗を型に載せるかどうかの設計判断——処理漏れを誰が検出するかが変わります。

プログラミング言語の世代交代 2026年7月19日

null 許容・nullable 型・Option 型——同じ「null 安全対応」に見えて、実際に違うのは値の欠如が検査されるタイミングです。

プログラミング言語の世代交代 2026年7月17日

動的型言語のまま、型注釈・パターンマッチ・遅延評価が拡張されてきた——3.9 世代のコードが古く見える理由を構文の差分で整理します。