組み込みやファームウェアの仕事では、Gitの変更を確認し、要件を読み直し、コードをビルドしてボードに書き込む作業を繰り返す。
今では隣の画面にAIも開いている。レジスタの値や古い関数を見せれば、考えられる原因をすぐに整理してくれる。ただし、その答えが正しいかどうかは、結局ボードとログで確かめなければならない。
ファームウェアでは、ビルド成功が仕事の終わりではなく、テストの始まりであることが多い。装置は一時間動いた後、特定の温度や通信順序で止まることがある。コードが正しく見えても、一つのタイミング前提が製品を壊すことがある。
そこでCを学んだ人の質問が変わる。データはどこにあり、誰が作り、いつまで有効なのか。誰が変更でき、使い終わったメモリは誰が返すのか。
Cは、直接制御できること、小さな実行環境、確認しやすいコストによって現場に残っている。ST、NXP、Nordic、Texas Instruments、Infineonの開発環境を開けば、今でもCのドライバ、サンプル、スタートアップコードが並んでいる。
だからといって、C自体が安全な言語というわけではない。安全性を重視するチームは、MISRA C、静的解析、コードレビュー、広範なテストによって既知の失敗を管理する。
Pythonはツールや自動化を素早く作るのに向いている。測定で確認された重い処理やハードウェアに近い層だけをCやC++に任せればよい。良い設計とは、すべての層に一つの言語を押し込むことではない。
すべてをCで作る必要はない。それでも、ボードが止まり、ツールが遅くなり、抽象化の下を調べる必要が生まれたとき、Cは今でも仕組みを理解するための明快な方法の一つだ。
コメントを読み込んでいます。