ClojureがLLVMとC++と融合！？新言語jankが切り開く未来とは

Hey folks. I’m the creator of jank. I didn’t expect to be on HN today, but I appreciate the interest.In short, jank is Clojure, but it’s on LLVM and has seamless C++ interop. You still get full nREPL capabilities, can redefine anything on the fly, and we can actually JIT compile C++ code alongside your Clojure. The seamless C++ interop is first of its kind, for a lisp, and is done by JIT compiling C++ alongside the LLVM IR we generate for jank and then stitching them together into one IR module.Note, jank isn’t released yet. I’m targeting the end of this year for the first alpha release. I put out monthly development updates on the jank blog, with the next one coming out this week.

beautiful work. clojure is very nice. one of the most impactful talks I have ever seen was from Rich Hickey - simple made easy.however my only gripe with clojure while it’s easy to write and comprehend at first - it’s difficult to read. & yet most our time we read code not write it. but then again it might be my lack of brain power.

I agree with you, but perhaps in my own way. Jumping into an arbitrary Clojure program can be tough, since the data shapes may not be defined anywhere. Hopefully the program uses spec or malli, but even then, unless they annotate every function with the shape it expects, you may be left needing to REPL in and poke around. However, REPLing in to check just a function or two may not be easy if the program requires some setup and doesn’t use integrant or similar.Once Clojure parity is achieved, I’m interested in static typing, pattern matching, value-based errors, and some other opt-in improvements that I think will greatly improve both readability and toolability (i.e. how well tooling can work with the code, based on what it knows of the code). Stay tuned. :)

What’s your take on Hickey’s talk titled “Maybe Not” which fundamentally criticizes static types? Is there a middle ground where some form of static typing makes sense in a Clojure-esque world?https://youtu.be/YR5WdGrpoug?si=4mI8doBX6jj6PJkk

My comment to code ratio is magnitudes higher in Clojure than in other languages, which helps a lot with this.Also writing Clojure can be incredibly terse, resulting in quite high-effort when reading. Conversely, a lot of time I can condense hundreds of lines of equivalent python into 5 or 6 lines of Clojure. Having all of this functionality condensed into something you can fit in a tweet really helps for grokking larger parts of the dataflow or even larger system. So there are tradeoffsPlus structural editing and the repl really help with the “reading” experience (reading in quotes because it’s much more interactive than reading)

＞ Conversely, a lot of time I can condense hundreds of lines of equivalent python into 5 or 6 lines of Clojure.I’m curious if you have any example of this? Even if it’s an hyperbole, I don’t really see how.

Maybe hyperbole on the frequency, but not the condensation. I meant more along the lines of “most of the complicated code I write in Clojure is an order of magnitude more dense.” Most of the code I write would be 1:1 or 1:2 with other languages, it I don’t think it’s the type of code OP was referring to.The 1:20+ is definitely not hyperbole though. Using transducers to stream lazy reductions of nested sequences; using case, cond-＞ and condp-＞; anywhere where you can lean on the clojure.core library. I don’t know how to give specific examples without giving a whole blog post of context, but 4 or 5 examples from the past year spring to mind.It’s also often the case that optimizing my clojure code results in a significant reduction of lines of code, whereas optimizing Python code always resulted in an explosion of LoCPersonally I find Python particularly egregious. No map/filter/reduce, black formatting, no safe nested property access. File length was genuinely one of the reasons I stopped using it. The ratio would not be so high with some languages, ie JavaScriptEven with Elixir though, many solutions require 5-10 times the amount of lines for the same thing thing in Clojure. I just converted two functions yesterday that were 6 & 12 lines respectively in Clojure, and they are both 2 pages in Elixir (and would have been much longer in Python)

I find 95% Clojure has the right tools to write very terse code. But in some cases the functional transducer/piped paradigm can’t be contorted to the problem.Usually these are problems where you need to run along a list and check neighboring elements. You can use amap or map-indexed but it’s just not ergonomic or Clojure-y (vs for instance the imperative C++ iterator model)The best short example I can think of is Fibbonaccihttps://4clojure.oxal.org/#/problem/26/solutionsI find all the solutions hard to read. They’re all ugly. Their performance characteristics are hard to know at a glance

Personally, I would normally reach for loop to check neighboring elements very ergonomically. (loop [[a b c & more] coll] (recur (apply list b c more)))

There’s also partition if you’re working with transducers/threads/list comprehension (partition 3 1 coll)

Or if you need to apply more complicated transformations to the neighbors/cycle the neighbors (-＞＞ coll cycle rest (map xform) (map f coll))

Using map-indexed to look up related indices is something I don’t think I do anywhere in my codebase. Agreed that it’s not ergonomicEDIT: those Fibonacci functions are insane, even I don’t understand most of them. They’re far from the Clojure I would advocate for, most likely written for funsies with a very specific technical constraint in mind

Heh. Hickey once debated with me at length about visual neuroscience, a subject I have a master’s degree in and he doesn’t. At no point did this stop him from confidently asserting things.I have to wonder if “Maybe Not” is similar, since he’s not actually an expert in types, either afaik.Alexis King wrote a partial rebuttal to Maybe Not: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ…

正直、partitionって危なっかしいツールだと思うんだよな。例えば、数字のシーケンスがあって5点移動平均を計算したいとするだろ？
(partition 5 1 coll)ってやって、結果の各要素を平均化すれば、理解はすごく簡単だ。でもパフォーマンスは最悪だろうな？レイジーリストだし、5要素のセットにアクセスするたびに、コレクションをなぞってサブセットを作り直してるんじゃないか？配列タイプから始めればいいのかもしれないけど、いつもシーケンスに強制変換されるし、難しいわ。
最初の5要素を取って、先頭要素を削除したリストで再帰する方が多分いいけど、コードが読みにくいと感じるんだ。慣れの問題かな…。

なんでjankって呼ぶんだ？ほとんどの文脈でネガティブな言葉じゃん。だから気になってるんだよ。

個人的には型付けするかしないかはスタイル選択だと思うけど、ここでの君の批判はHickeyが視覚神経科学の修士号を持ってないって言ってるみたいで、ちょっと的外れに見えるな。
君の主張が「俺は専門家だけどHickeyは違う」ってことなら、彼の言語設計スキルを批判するのは論理的な間違いじゃないか？彼は今の時代の第一線の言語設計者の一人だぜ。「Maybe Not」は、専門家が自分の専門分野で話しているスピーチだ。
もし彼の自信に根拠がないって主張するなら、これもまた、彼はその分野の専門家だ。彼がその分野で自信満々な態度を取るのは妥当だし、他の専門外の分野で根拠のない自信を持っていたとしてもな。多くの専門家がそうしてるし、賢い人のよくあるステレオタイプだぜ。
彼は型を実装する専門家である必要はないんだ。それが良い言語機能かどうかを判断するためにね。

うん、俺が言ったように、まずloopを使うね。もしもっと複雑なものだったら（ここではコメントはかなり単純だけど）コメント付きだとこんな感じになるぜ：
(loop [coll [1 2 3 4 5 6 7 8 9] memo []]
(if (＜ (count coll) 5) memo ;; アイテムが5個未満になったら停止
(--＞ (take 5 coll) ;; 最初の5日間を取る
(reduce +) ;; 合計する
(* 0.20) ;; 5で割る
(conj memo) ;; memoの末尾に追加する
(recur (rest coll)) ;; 残りの要素で再帰する
,,,))))
現実的にパフォーマンスを考慮するなら、多分こうするな：
(loop [[a b c d e :as coll] [1 2 3 4 5 6 7 8 9] memo []]
(if-not e memo
(recur (rest coll) (conj memo (/ (+ a b c d e) 5)))))
ネストされたループを避けることで、約15倍速くなるはずだぜ。最小サイズを変更したい場合でも、かなりクリーンだ：
(loop [[a b c d e :as coll] [1 2 3 4 5 6 7 8 9] memo []]
(if-not c memo
(recur (rest coll) (conj memo (/ (+ a b c d e)
(cond e 5 d 4 c 3))))))))

詳細な返信ありがとう！本当に考えさせられるわ。こんなコードを書くなんて思いつかないよ。命令的なインデックスベースの解決策より解析しにくい気がするけど、どうなんだろうな。すぐに理解できる？慣れの問題なんだろうな、きっと。
最初の解決策で避けたネストしたループって、reduceのこと？それともcount？
conjってすごくLispyな感じがする（ClojureじゃなくてLispの方ね）…アイテムを追加するたびにリストを辿ることになるんじゃないの？
俺の残ってる懸念は、リスト／ベクターへの絶え間ない型強制だな。結果のサイズは実質的に分かってるのに、実行時やコンパイラはそれが分からないだろ。だからmemoを事前割り当てしてないし…なんか間違ってる気がする（笑）
純粋に君の意見を聞きたいだけさ。
全てをこれほどきれいに抽象化して構成可能に保つのは多分無理だろうけど、配列をランダムアクセスで扱えるともっとスムーズだったらいいのにって思うよ。Clojureで配列を扱う現状の方法はいつもちょっと扱いにくいんだ。そして全てがリストに強制変換される。ベクターをmapvやfiltervなどで使うのは便利だけど、ランダムアクセスがないから、いつも欲しい解決策ってわけじゃないんだよな。

俺の言いたいこと、分かってないな。Hickeyが講演する時の自信は、彼が何を話しているか知っていることと混同すべきじゃないってことさ。
＞「Maybe Not」は専門家が自分の専門分野で話しているスピーチだ。
動的型付け言語を書いているからといって、彼が型のエキスパートってわけじゃないだろ。
ハハ！最高だね。
アシモフ：「アメリカには無知の崇拝があり、常に存在してきた。反知性主義の傾向は、私たちの政治的、文化的暮らしを貫く絶え間ない糸となっており、『私の無知はあなたの知識と同じくらい価値がある』という誤った考えによって育まれてきた。」

Richは静的型を批判してたってより、思ってるほどメリットがないし、時間の経過とともにプログラムの進化を複雑にするって言いたかったんだと思うよ。

これをClojureの代替バックエンドやC++構文拡張じゃなくて、別の言語として実装することを選んだのはなんでか、ちょっと気になるな。
Windowsサポートを最優先にする予定はある？LLVMベースの言語に注目してる多くの人は、ゲーム向けC++の代替を探してると思うんだ。

＞動的型付け言語を書いているからといって、彼が型のエキスパートってわけじゃない。
それはここで妥当な批判じゃないね。極端に言えば、ホメオパシーを無視することにしたからといって、その人がホメオパシーのエキスパートでなければならないとは誰も認めないだろ。自分の分野の価値を積極的に示すのは専門家の役目だ。彼は言語設計のエキスパートで、型システムを形式化する人々が、新しい言語設計のためにそれが一般的に強力であることを証明できていないと彼は考えているんだ。
彼は型のエキスパートだと主張しているわけじゃない。「Maybe Not」では、プログラミング言語において型は問題を解決しようとする試みだけど、もっと強力なアプローチを探すべきだと具体的に主張しているんだ。そして、そのアプローチとはオープンなスキーマだとね。

＞インデックスベースの解決策より解析しにくい気がするけど、どうなんだろうな。すぐに理解できる？
これらの例は驚くほど分かりやすいぜ。インデックスベースの解決策を理解するのに、俺ははるかに時間がかかるんだ。特にnilの処理、インデックスの欠落、境界チェック…Clojureでは心配する必要のない、当たり前の問題にすぐに埋もれてしまうからな。
もしもっと複雑なら、最初の例みたいにコメントを使う。もっと複雑なループを理解するときは、確かに文字単位で見ると読む速度は遅くなるけど、他の場所でも言ったように、機能の理解が遅くなることはないと思うな。
＞最初の解決策で避けたネストしたループって、reduceのこと？それともcount？
正解、reduceはループだぜ。
＞conjってすごくLispyな感じがする（ClojureじゃなくてLispの方ね）…アイテムを追加するたびにリストを辿ることになるんじゃないの？
いや、ベクターはリストよりハッシュマップに近いんだ。Clojureには主にリストとベクターの2つのシーケンシャルコレクションがある。リストは追加がO(n)だけど、ベクターはO(1)だぜ。リストは先頭追加がO(1)だけど、ベクターの先頭追加のパフォーマンス特性は実はよく知らないんだ。
＞俺の残ってる懸念は、リスト／ベクターへの絶え間ない型強制だな。
コード中でベクターからリストへの型強制は1回だけだ（入力が元々ベクターだった場合に、restが最初に呼ばれる時だな）。入力がリストである可能性の方が高いし。それに、コンピューターサイエンス的な意味での型強制ですらないかもしれないんだ。
＞結果のサイズは実質的に分かってるのに、実行時やコンパイラはそれが分からないだろ。だからmemoを事前割り当てしてないし…なんか間違ってる気がする（笑）
これはJavaScriptでは問題にならないし（JavaScriptはいつもすべてのベクターに大量のメモリを事前割り当てしてるはずだ）、Javaでの意味合いは分からないけど、Clojureでみんなが出してるパフォーマンスを考えると、問題ないはずだぜ ;-)
＞Clojureで配列を扱う現状の方法はいつもちょっと扱いにくいんだ。そして全てがリストに強制変換される。ベクターをmapvやfiltervなどで使うのは便利だけど、ランダムアクセスがないから、いつも欲しい解決策ってわけじゃないんだよな。
俺のプロジェクトでnthを使った回数は片手で数えられるくらいしかないぜ。ランダムアクセスに基づいてソリューションを構築するなんてクレイジーだなって思うんだXD
とはいえ、ベクターのランダムアクセスはO(1)だぜ。filtervやmapvが返すものも含めてな（厳密にはO(log32n)だけど）。

ベクトルがハッシュマップみたいに振る舞うって話、忘れてたわ。リストで動いてるってことは、O()保証が必要な場面ではちょっと「ヤバい」かもね。reduceのオーバーヘッドとデストラクチャリングの性能差は意外だった。nthはあまり使わないけど、配列の連続メモリアクセスとキャッシュ局所性はホットループで性能差がすごく出るよね。

ホメオパシーは基礎物理で否定できるけど、型システムは複雑すぎて専門知識が必要だって話。「モナドは自己関手の圏のモノイドに過ぎない、何が問題？」っていう有名なジョークがそれを物語ってるよね。

jankはClojureだけど、商標の問題と、静的型付けやパターンマッチングみたいな新機能を追加したいから、別の言語名にしたんだって。Windowsサポートは今限定的だけど、まずはClojure開発者向けに集中して、その後C++開発者向けにWindowsサポートを強化していく計画らしいよ。

「jank」みたいにネガティブな名前の技術は使わないって話。テック系の面接で不利になったり、何か問題があった時に「jankのせい」って言われたりするリスクがあるからだって。皮肉たっぷりで、プロジェクト名がもたらす印象の怖さを語ってるよ。

リストで反復してるのは、リストを返す関数で再帰してるからだよ。ベクトルを使う必要がないケースもあるし、Clojureのコア関数のほとんどがリストを返すのには理由があるんだ。ほとんどのプログラミングでリストで十分だってね。dotimesやvolatile、nthを使えばパフォーマンスも確保できるし、エルゴノミクス的な解決策は常にあるから大丈夫だよ。

そうだね。僕もloopやpartition+map/reduceを使うよ。map-indexedはほとんど使わないし、インデックスを使うことも稀なんだ。大抵はmapやreduceで十分。map-indexedは、関数型アルゴリズムじゃなくて命令型アルゴリズムに走ってる感があって、ちょっとコードの「匂い」がするなって思う。

ElixirとClojureの例をいくつか見せてくれるかな？

「jank」って名前、やっぱり目立つよね。GitとかRustもネガティブな響きだし。これって新しいトレンドなのかな？もう良い名前が残ってないのか、それとも単に名付けが怠惰なだけなのかな。

「Maybe Not」って記事のアイデアが面白かったな。静的型付けは情報のシェイプと存在・要件を混同してるって指摘が重要だった。つまり、型定義はシェイプに、null許容性みたいな要件はコンテキストに属すべきだって。このnull許容性マスキングはSpecの機能として意図されてたらしいけど、実装されてる感じはしないね。

Clojure大好きだったから、jankもすごく良い感じ。今C++プロジェクトやってるんだけど、jank入れて自動化できるか試してみるつもり。CarmackのTrinityとコンパイル戦略が似てるってのも最高だね！応援してるぞ！