第二の脳としてのLogseq / 対話駆動開発とシンプルさを実用するために
あけましておめでとうございます。
普段はですます調で記事を書くことはほぼないのですが、挨拶文から冒頭始まるということで、今回はですます調で統一してみます。
また、このブログにガジェットやキーボード以外の技術記事を書くこともあまりなかったのですが、今回は少し抽象的で思考整理が多分に含まれているので、QiitaやZennではなく、あえてこのブログに書くことにします。
第二の脳としてのLogseq
昨年はSNSなどを大きく整理した年で、発信したり見たりをしないままのアカウントをどうするか迷い、このブログ自体も非公開にしたり公開に戻したりを繰り返していますが、折り合いがつくまではしばらくその状態が続くかなと思っています。
ちなみに発信していない情報やコンテンツについては、以前はNotionやObsidianに記録していましたが、Logseqで落ち着きつつあります。
Logseqの素晴らしいところは、日誌形式で適当に書きなぐったものが、いつの間にか綺麗に整理されていくところにあります。さらに普通のWikiと違うところは、いわゆる内部リンクを貼っていない記事についても自動で「Unlinked References（非リンク参照）」としてまとまったり、強力なクエリ言語により、クエリ結果自体を記事に貼り付けれるところにあります。
元々、Logseqを使う前はObsidianやNotionを使っており、ObsidianとLogseqの似ている点としては、プラグインシステムが充実している点や、アウトラインエディタ的に使えるという点が類似しています。自分は、よりアウトラインエディタ的にDynalistやWorkflowyなどに原点回帰しようとしたのがきっかけでLogseqを知りました。Workflowyとは、ドラッグやズームなどの機能面でもよく似ています。 *1
NotionとLogseqの似ている点と違う点は、Notionはデータベース (DB、テーブル) と文章を分けているのに対して、Logseqは分けずに基盤となっているグラフデータベースシステムから直接クエリによりテーブルを生成できる点が異なります。はじめ自分はこの点をよく理解していなくて、Notion DBの代替機能としての Dataviewプラグイン などを検討していました。
実際、それでもLogseqと似たことはできるはずですが、Logseqの場合はページ単位だけでなくブロック単位でクエリが可能であることと、前述の非リンク参照があること、ページは自動で作成されること、タスク管理機能を内在していること、そしてテーブルを直接書かずにクエリで好きな観点でデータを収集・分析・表示でき、雑多な思考をいつの間にか整理できることを決め手にLogseqを使い始めました。
元々Obsidianでも、自分は毎日その日の日付が入ったファイル名で日誌・日記を付けるスタイルをとっていたので、日誌形式をメインにしているLogseqへの移行はスムーズで、かえって日付を一つのページとして参照でき、かつバックリンクが自動で貼られるので、リマインダやTODOを非常に忘れにくくなったと感じています。 *2
ObsidianやNotionは今後もきっと使っていくと思いますし、Obsidianはきちんと文章を書きたいとき、Notionはチームで連携したいとき、あえてリレーショナルDB (テーブル) を使いたいときなど、自分のなかで使い方を棲み分けていくと思います。そういう意味では、NotionがリレーショナルDB + 構造化文書だとすれば、LogseqはグラフDB + 構造化文書と、わかりやすく対比できるかもしれません。
ClojureとREPL駆動開発とシンプルさ
さて、次の話題に直接的には無関係なのですが、運命的だなと思ったのが、LogseqがClojureで開発されていることです。
自分自身の座右の書になっている、『7つの言語 7つの世界』でClojureに触れて以来、度々、自分はClojureのようなスタイルの開発をしたいとずっと考えてきました。
ClojureやLispに特徴的なのは、REPL駆動開発というもので、PythonやRubyなどにあるような補助的なREPLではなく、REPLを中心に対話的に開発をするスタイルがとられています。
また、Clojureでは特に「シンプル」を言語設計のキーワードとしており、様々な観点でそのシンプルさが際立ちます *3 。
この両方の観点で、Clojureを超える言語はなかなかないのではないかと個人的に考えているのですが、当時JVM (Java仮想マシン) 上で動く言語であることなどがネックとなり、自分が仕事でClojureを使うことはありませんでした。
Clojure界隈でも例えばAndroid開発にJVM版のClojureを使うと起動時間がネックになることなどから、現在のClojureのメインストリームはClojureScript、つまりJavaScript版に移っているようで、例えばAndroid開発もClojureScript + React Nativeで行うのが主流とのこと。
きっと、サーバ周りだけでなく、Logseqのような身近なツールがClojureで動くようになったのも、こうしたことのおかげだと思います。
時代は変わってきたなと思うと共に、変わらないものを愛する人もいるのだなと嬉しくなります。
対話駆動開発とシンプルさを実用するために
自分もこの流れで、いつかClojureScriptを仕事で使いたいと思う一方で、やはりコンパイラ基盤がJVMであることはネックになってきます。今はGraalVMなどで起動時間が短くなったりインストールが簡単になったり (例えば nbb や babashka など ) しているので、近い未来にそのまま活用できると思うのですが、自分自身はリアルタイムよりでC/C++に近いレイヤーでの仕事が多い傾向にあるため、何か代替策はないかと調べてきました。
そして最近有力視しているのが、Janet言語 と Cakelisp です。JanetはC/C++と連携できるClojure-like言語として最有力に感じており、まるでPythonのようなBattery Includedな雰囲気も個人的に好きです。
Cakelispについては、REPL駆動開発という意味では脱線するものの、C/C++とのバインディングを書くことなく、そのままC/C++に綺麗にトランスパイルされる点 *4 で優れていると感じています。Cakelispの作者自身が他の言語との比較記事を出していますが、Zig言語に対するLiz言語のような位置づけでありつつ、Zig言語自体のようにビルドシステムを内包している点が興味深い点です。 *5 。
Cakelispはさしあたり使えるシンタックスハイライター ( VSCode用 / Vim用 ) を書いたりする過程でだいたいの機能は理解したのですが、Janetとはまた違う意味で非常に魅力的で、C/C++のバインディングが不要だというのは強みであり、面白い使い方ができそう。
Janetでも実際に対話しながらリアルタイムにコードを書き換えるデモを書いてみて、対話駆動開発とClojure/Lispルーツのシンプルさの強力さを実感しています。Conjureという対話開発支援ツールがとても便利そうで、次はJanetのnetreplとVSCodeが連携できるツールを探すか開発したいところ。
まとめ: 考え方は伝播していく
今年は、こうした自分自身が本当はやりたかったことを仕事でも活用していきたいと思っていて、こうした技術が直接的に利用できるかはさておき、こうした地道な活動が、自分自身の原点を思い出させてくれたり、別の形で理念を応用するきっかけをつくると信じています。
Logseqは直接活用できるとして、Clojureについては、ひょっとしたら例えばNode.jsにいろんなC/C++バインディングを書いてClojureScriptやJavaScript (あるいはTypeScript)で対話開発を始めるかもしれないし、あるいは Fennel やLuaなどで折り合いを付けるかもしれないし、Pythonなどのスクリプト言語やJupyter Notebookなどの対話開発のルーツはLispにあるともいわれているように、これらの道具を直接的に利用できなくても、良い考えは他の分野に浸透していっていて、既に仕事で使っている技術も多いと感じています。
そうした原点を時々思い出しながら、新しい考え方も少しずつ取り入れつつ、実際に自分がそれをどんな形でどこに見出していくかは、今年の楽しみにしたいと思っています。
*1:ちなみにObsidianはDynalistの開発チームが作ったものとのことで、よく棲み分けされていると思います。
*2:管理にGitなどを使ったり等、ローカルで好きにできるのもObsidianとLogseqは似ている面が多くあります。LogseqもObsidianみたいにモバイル側でもプラグインが使えたらなお良いなと思ったり。
*3:Clojureで掲げられている「シンプル」についての参考記事: https://logmi.jp/tech/articles/321965
*4: こちらの記事のLisp分類でいうところのType-Aにあたる。
*5:CakelispはまるでNimのように、ホットリローディングができる機能 (参考記事) があるとのことだったのですが、自分はまだホットリローディングを動かすことには成功していません…。Nimでその強力さと機構は実感しているので、期待したいところ。
