AI時代が到来したということで、LLMを活用できそうな技術を調べていたところ、HazelというElm/MLライクなライブプログラミング環境を見つけた。最近、プログラミング学習の一貫として試しています。
試してみたいと思った動機
動くソフトウェア（近年ではプロトタイプ等）が強めに要求されるAI時代において、実装を穴埋めするコードを書くのに時間がかかってしまう。その中で、ソフトウェア開発の再現性が味わいにくくなっている地域でのみ局所的に発生している現象の可能性がある。LLM活用で埋まれた負債をどのように解消するかプランがなさそうな状態をどう生き残るか。そして、大量のソースコードをメンテナンスするには？それもAIに直してもらうことでいいのだろうか。エンジニアの皆様であれば、なにか考えをお持ちかと思います。
Hazel言語は、Elm、OCaml、および MLファミリーの他の言語に似ていています。Hazelに限ったことではありませんが、現代のLLMは、HazelコードのLLMデータセットでトレーニングされていません。そうなると、現代のLLMはHazelの構文と意味論に従わず、OCamlやElmから構文形式やライブラリ関数を借用することが多くなると思います。しかし、LLMコンテキスト学習が可能というポイントは興味深いです。
Hazelのホール・スケッチという特徴を試してみます。
ホール
式・パターン・型が失われている箇所は空の hole として扱われる。
let empty_hole = in
3種のホール
参照： https://prg.is.titech.ac.jp/papers/pdf/ppl2025-zhiqi.pdf
スケッチ
(*アクションに基づいてEmojiPaintアプリのモデルを 更新します*)
let update : ( Model , Action ) -> Model = ?? in
たとえば、
let fizzbuzz : Int -> String =
??
というスケットを書いて、LLMに「スケッチを完成させて」というと ?? のだけ埋めてくれる
ここで、let fizzbuzz : Int -> Int のように明らかに間違った型だと勝手に直してくれる。是非はともかく。そして、わりと、その推論の元として test 関数を使ってくれる。
そして、LSPとして下記のChatLSP APIメソッドが提供されています。
- ChatLSP APIメソッド
- 文脈に期待する文字列を返す
- 文脈に応じるためトークン使用が節約できる
- どの関数を使うべきか言語サーバーで関連ヘッダー抽出を実装できる
これは、かなりトークン使用量を節約できるのでは？と思いました。
感想
LLMから出てきたものをそのまま出すという実情もある中、一方ではElm-UI を使ってフリーハンドなビューを構成したいという流儀もある。Elm-UI はCSSやNative windowの直コーディングではなくWPFなどの独自レンダリング戦略を採った系統であり、Elmだからフリーハンドなビューになるというわけではない。もちろんWeb技術というセマンティクスの範囲でしか表現できないのだが、原点回帰するのであれば、なぜGopherプロトコルやWebAPIではだめだったのかという問いに戻ってしまう。もちろんElmライブラリをそのままポートできるわけではないため、なにか方法を探りたい。
巷では、時代に即した初速のある技術がバズっている中、Hole-punch という分野には、めっちゃ期待しています。技術的な話から一歩離れて観察してみると、仮想敵を内部におく戦略では課金額バトルになりがちで、節約や摂生、コスパ、スループット、資本力ではなく「累計課金額」で勝負するというルールは往々にしてある…。とはいってもサンクコストに引きづられちゃうのはあるある。不確実性には平等に報われるという安心感が必要であり、万が一負けても格好がつくという保険的立場があるのかもしれない。