世界を動かす技術を、日本語で。

エンタープライズにおけるClojureプログラミングの導入 (2021)

概要

  • 製造業向けの新しいリファレンスデータシステム設計体験の共有
  • Clojure導入の経緯とJava等の従来言語との比較
  • ClojureのLisp的特徴やREPL、Java連携のメリット
  • Clojure活用で得られた学びと今後の展望
  • チームへの導入・学習曲線への配慮

製造業向け新リファレンスデータシステム設計とClojure導入

  • 製造業の新リファレンスデータシステム設計プロジェクトで Clojure 導入を検討
  • 当初は標準開発スタックからの逸脱に 懐疑的 だったが、徐々にClojureの多様な機会に 価値 を見出す
  • 本記事ではClojureを選択した 理由 と従来言語(Javaなど)との 比較ポイント を整理

Clojureとは何か

  • ClojureJVM上で動作 する動的関数型プログラミング言語
  • Lispファミリー に属し、 コード=データ という独自のセマンティクスを持つ
  • 不変データ構造強力なデータ操作ライブラリ を標準装備
  • 2007年誕生、近年は エンタープライズ用途 での利用が増加傾向
  • ThoughtWorks Radar でも2014年以降「採用推奨」技術に認定

Clojure選定の背景

  • 製品が大量の データ構造 と頻繁に変化する ビジネスルール を必要とする
  • DSL(ドメイン固有言語) でビジネスロジックを柔軟に表現する必要性
  • オブジェクト指向言語 では柔軟性不足、Clojureは mallispecter 等のライブラリで対応可能
  • 初期段階の検証プロトタイピング において、Clojureの ボイラープレート不要 な記述が効果的

コード=データの利点

  • Clojureは EDN(Extensible Notation Format) を活用し、可読性の高い構造で コード宣言 が可能
  • DSL構築ルールエンジン実装 に最適
  • 非開発者でも 簡単に編集・DB保存 できるデータ構造設計
  • マクロシステム による高度なDSL構築も将来的に視野

REPL(Read Eval Print Loop)の強み

  • REPL環境 で実行中プログラムへ 対話的にアクセス・修正 が可能
  • 反復的な開発・テスト が容易、ワークショップ等での 即時フィードバック で効率向上
  • CursiveCalva 等IDEプラグインで インタラクティブ性 がさらに向上
  • REPL駆動開発 はClojureコミュニティで特に重視される文化

Javaとの相互運用性

  • JVM上動作 のため、 Javaライブラリやフレームワーク の利用が可能
  • Java/SpringBoot とのシームレスな統合
  • 導入初期は プロトタイピング に限定し、徐々に 本番コードへ統合
  • チームの スキルマトリクス技術習得 を考慮し、段階的な適用を推進

その他の注目機能

  • マクロシステム :ユーザーコードでコンパイラ拡張、DSLエンジン設計に最適
  • ClojureScript :JavaScriptターゲットのClojureコンパイラ、 フロントエンド/バックエンド の技術的境界を縮小
  • データ指向ライブラリClojureSpecSchemaMalli 等が利用可能

学習曲線と導入戦略

  • 関数型・データ指向 の考え方は 従来のOOP 経験者には 学習コスト が高い
  • Clojure経験者 は市場に少なく、 段階的な導入・習得 が推奨
  • 小さな成功体験 を積み重ね、プロジェクト初期から 効果的に活用
  • チームの 継続的な技術力向上 ・ナレッジ蓄積を重視

まとめ

  • データ変換・操作に強い関数型言語
  • DSL構築に適したLispファミリー
  • 短サイクル開発・テストを可能にするREPL
  • 強力なデータ検証ライブラリ群
  • Javaとの高い互換性 でエンタープライズ導入も容易
  • データ駆動型開発新規プロジェクト において、Clojureは一考の価値あり

参考リンク

  • https://clojure.org/
  • http://clojure-doc.org/articles/tutorials/growing_a_dsl_with_clojure.html
  • https://www.braveclojure.com/writing-macros/

Hackerたちの意見

最初のチャートのy軸は何ですか?データソースはどこですか?

彼らは公式ウェブサイトで年次調査を公開してるよ。このグラフは「State of Clojure 2020」からのものみたいだね。リンクはここだよ: https://clojure.org/news/2020/02/20/state-of-clojure-2020 最新のレポートはここ: https://clojure.org/news/2026/02/18/state-of-clojure-2025

Clojureがどんどん注目されてるって聞いて嬉しい!俺は仕事でClojure書いてるけど、他の言語に変えたくないな。コミュニティは小さいけど、すごく助けてくれるし、連絡も取りやすい。学習曲線は確かに急だけど、それだけの価値はあるよ!

Clojureには結構大きな欠点があるよね。 - シンタックスが読みづらいから、慣れるまで時間がかかる - 短い変数名の規約がさらに難しくしてる - 関数の定義順序も難しさを増してる - 大多数の人にはダイナミックすぎる - 型安全性がない - 退屈とは真逆 - 他の言語に対して明確に勝ってる使い道がない - 小さなコミュニティと求人市場のニッチ - JVM これらの理由から、ほとんどの人には売りにくいと思う。

Clojureがますます注目されているのを読むのはいいね。この文を「Hackernewsでの最高の偶然のフリースタイルラップ」にノミネートするよ。

https://archive.ph/5RJ2V

俺はClojureを約5年間書いてた。仕事を変えたときに辞めたけど、辞めたくて辞めたわけじゃない。使った中で本当に生産的な言語の一つで、REPL駆動のワークフローが恋しいよ。作ったものの一つはこれ: defun https://github.com/killme2008/defun -- パターンマッチングを使ってClojure関数を定義するマクロなんだ。オープンソースにした中で、今でもこれが一番好きかも。

いいね!本当に素敵なAPIだ。似たようなものをマルチメソッド用に書こうと思ったことがあったけど、結局考えをまとめる時間がなかった。defmultiとdefmethodの動きは、データ構造に対してスレッドセーフな操作を行って、関数を呼び出すときに正しいメソッドに振り分けるんだ。core matchを使えば似たようなことができるんじゃないかって思ってる。ただ、それがいいアイデアなのか悪いアイデアなのかは分からないけど。パターンマッチングをやってるなら、ライブラリみたいに一つの場所で全部見たいよね。

Clojureは書くのがめっちゃ楽しい言語だよ。最初から素晴らしい並行処理ツールがあって、Javaエコシステム全体にアクセスできるから、ライブラリに困ることはない。Clojureじゃないほとんどの言語でClojureスタイルのマルチメソッドが恋しくなる。マルチメソッドが私にとってしっくりきたとき、それがモジュールプログラミングの「正しい」やり方だって明らかに思えたから、サポートしてない言語にはちょっとイラッとする。core.asyncは本当に素晴らしい。CSPスタイルのセマンティクスを提供する素晴らしい並行処理ライブラリがたくさんあるけど(例えばRustのTokio)、core.asyncほど自然に感じたものはない。最近はClojureに本格的に触れる機会がなかったけど、ClaudeにVert.xのための良いバインディングを生成させて、Javaでやってる個人プロジェクトを移植できるか試してみたいなと思ってる。

2012年から2013年にかけてClojureに出会ったことを後悔してる。すごく知識のある人たちと一緒に大きなClojureプロジェクトを学んだり働いたりするチャンスがあったのに、目の前で「いや、結構です!」って自信満々に言っちゃったんだよね。それから数年、Javascriptと格闘して、選択肢を尽くして、Typescript、Coffeescript、Livescript、Gorillascript、IcedCoffeeScript、Fay、Haste、GHCJS、Elmを試して、ようやくClojurescriptにたどり着いた。あの時はフロントエンドを扱ってたけど、もう結構経験があったし、他のスタックもいろいろやってた:.Net - C#、F#、VB;Python;Haskell;Objective-C;ActionScript;Delphi;あとはあまり知られてないものも。最初は混乱してたけど、突然「これだ!」って感じになった。すごく現実的で、説明できないくらい実用的で合理的で、もっと学びたいと思わせてくれた。実際には何も作らなかったけど、関連するGoogle検索結果を見てたら「Clojure/Remote Conf」の発表を見つけた。これは参加するしかないと思って、1日休みを取って家のパソコンから参加した。すぐにファンになっちゃった。そこで見たクレイジーで素晴らしいもの、チャットで出会った人たち、メモした記事や本の量、全部がワクワクさせてくれた。カンファレンスの後、椅子に座って空白の画面を40分くらい見つめてた。考えたり、瞑想したり、これが中年の危機なのか何なのか考えてた。月曜日にはまた同じ苦労に戻らなきゃいけないって思うと、過去2年間の同じ問題、同じ混乱が頭をよぎって、すごく落ち込んでた。月曜日に仕事に戻って、「見たものは忘れられないから辞めます」って言った。Clojureをそこに持ち込むことは絶対無理だってわかってたから。だから辞めたんだ。給料も良かったし、家から15分の場所だったのに。Clojureに出会ったことで、コンピュータの概念が根本から変わった。プログラミングの新しい方法を見つけただけじゃなくて、すごく啓発されたし、コミュニティで出会った人たちのおかげで、特に感謝してる。Clojuriansは本当に特別で、優しくて、知識が豊富で、寛容で、誠実なプロフェッショナルたちだ。質問をしたとき、どんなにバカみたいなことでも、挑発的でも、混乱させるものであっても、一度も無視されたり、拒否されたりしたことはなかった。彼らはどんなことでも喜んで話してくれた。言語やツール、技術、アイデアに関係なく、答えを見つけたり解決に近づく手助けをしてくれる。Clojureのおかげで、僕はより良いプログラマーになった。もっと大事なのは、より良い人間になれたこと。そう、Clojureに出会ったことを後悔してる。準備ができていないときに見なければよかった。無駄にした時間が悲しい。もっと早く学ぶように説得してくれる人がいればよかったな。

REPL駆動の環境以外で非Clojureのコードを書くたびに、石を叩き合わせてる原始人になった気分になる。IDEの賢さやエージェントのトリックじゃ、思考プロセスと開発プロセスが同期してる感覚には勝てないよ。

REPL駆動の開発とLLMをうまく組み合わせられないかなって思った。

Hacker Newsで議論の続きを見る