入力で受け取ったByteStringを32bitの数値で扱いたい。

いろいろ方法がありそうだけど、自前で作成してみた。Cならばunionで4バイト領域にへunsigned charとunsigned longとしてアクセス可能で便利であるが、型が厳密なHaskellではそうはゆかないようです。

ByteStringをWord8のリストで扱うことは容易なので、ByteString -> Word8を4つ切り取って、Word32へ変更という作戦です。

もうずいぶん前から、１０年近くはなるんじゃないだろうか。いまに至るまでもずうっと考えていて、文章にはしていなかったこと。「関数プログラミング実践入門」という本にそのまま書いてあった。

…ここでの「分かっている」は「言語機能として処理系の基準で判断できる」ということ…

開発プロセスのノウハウや明らかになった理論をソースコードとの関連を持ったまま作業できる環境とすること。これにより次のことを可能にできる。

…プログラマ自身が人間として限界のある記憶力でいつまで覚えているか、また、手を入れる他のプログラマも同様に分かっているか、は一切保証していません。…プログラマが言語の制約を破ることがそもそもできなければ、誰が処理に手を加えても性質は保証されるのです。

事業継続のために情報が落ちずに引き継がれ、品質が確保しながら作業性を向上する。

…多くの場合、プログラムはメンテナンスなりアップデートしてユーザーに提供しなけれなりません。仕様として正しい動作を定め直し、現実的なコストと時間内で、できればプログラマに過度の負担がかからない範囲で、プログラムに手を入れ続ける…

プロダクトを提供し続けながら、実務者の負担を押さえていくことが可能ということだ。

そう、これがずっと欲しいと思っていたことだ。

問題は明瞭で、ソフトウェアのライフサイクルはある技術者が担当する期間よりも遥かに長く、派生するソフトウェアまで含めてしまえば現役期間よりも長くなる場合が想定されるということ。そのため情報の漏れない伝承と教育が必要。この作業は個人には後ろ向きに捉えられやすく、後回しになりやすいということ。結果、ソフトウェアの品質は徐々に下がっていくということ。

課題は単純で、ソフトウェアが満たすべき性質(仕様)をソフトウェアの本体であるソースコードと一体で扱える環境がないこと。仕様の検証やテストが人力であり、振り返り、現状調査、情報の整合確認が必要となり、綿密な作業計画までも必要とされる場合さえあること。

これをいち早く解決できた事業はソフトウェア開発において大きなアドバンテーを得ることができるはずである。しかし、この分野はあまり注目をされない。バラダイムシフト以上のインパクトがあるし、技術者判断で適用困難な状況があるかもしれない。開発プロセスと密接に関連することであり、現状維持に傾きやすいのかもしれない。

この本が述べている関数プログラミングもパラダイムシフトである。現場への負担は小さくない。けれども課題の解消を実現できることを説明している。関数プログラミングを採用できなくても、なにがウィークポイントなのか、どのようにプロダクト開発へ適用できるのかのヒントにもなるだろう。考えるだけの価値は十分あると思う。

参照:

• 関数プログラミング実践入門
• [増補改訂]関数プログラミング実践入門