Acadia：Elmライクな型安全性をSQLデータベースにもたらす
Rethinking Database Programming
Acadiaは、SQLデータベースにElm言語の利点をもたらす新しいプログラミング言語です。より精密な型、検証されたマイグレーション、親切なエラーメッセージ、エンドツーエンドの型共有を実現します。テーブル定義はElm風の構文で行い、クエリはmapやfilterなどの関数型プログラミングで記述します。コンパイラがSQLを生成し、最適化も行います。現在はElmとHaskellの統合をサポートし、公開アルファ版がリリースされています。
「私は、SQLのマイグレーションを実行するとき、とても怖いと感じます。本番データベースに入るとき、体が警戒態勢に入ります。」
HNでの議論
149- mike_hearn
非SQLプログラミング言語でスキーマを定義する問題は、常に基盤となるデータベースの機能に遅れを取ることです。確かに、ORMのようなフレームワークは主キーや一意性制約などの基本を定義できますが、パーティション分割スキーム、圧縮方法、より高度な制約を定義できるでしょうか？
ここでサポートされているすべての機能を見てください：
https://www.postgresql.org/docs/current/sql-createtable.html
そして、他のデータベースにはさらに多くの機能があることを考慮してください。コードでスキーマを管理すると、それらすべてへのアクセスを失い、結局SQLを書く必要が出てきます。
クエリに関しては、特に優れたコンパイラがあれば、それほど問題ではありません。しかし、私は最近SQLラッパー/抽象化への信頼を失いました。通常の正当化は、多くの開発者がSQLをよく知らないというものでしたが、LLMはSQLが得意です。LLMにとっては、あまり馴染みのないDSLよりもSQLを書く方が簡単です。そしてSQLは比較的理解しやすいように書かれています。特にCTEやビューを正しく使用すれば、複雑なクエリでも理解可能にするためにロジックを分割することが可能なはずです。
Acadiaのようなフレームワークにとっての疑問は本当にこれです：私がSQLに堪能で、データベースのすべての機能を知っていると仮定した場合、そのフレームワークは私に何をもたらすのでしょうか？なぜなら、LLMはその視点でそれに取り組むからです。
- CopyOnWrite
私はもうSQLを置き換えようとする試みを数えるのをやめました。
SQLに対する正当な批判は多く、いくつかのことが異なる設計だったらと非常に嬉しく思います。
一方で、リレーショナルデータベースの背後にあるアーキテクチャと数学はシンプルで、合成可能で、ソフトウェア開発における他のほとんどの設計、方法論、アプローチよりも時の試練に耐えてきました。
SQLは改善できるかもしれませんが、平均的なSQLスキルでも、データベースから情報を取得するのに苦労したことはありません。ウィンドウ関数のような派手な機能は、標準SQLさえもチューリング完全にすると私の理解ではなります。
SQLにはネイティブなデータベースサポートがあり、ほとんどの企業にとって、データとデータベースは特定のアプリケーションや、プログラミング言語/プラットフォームのエコシステム全体（Visual Basic、Visual FoxPro、Python 2など）よりも長生きします。
さらに、素晴らしい書籍、知識、ORM、クエリビルダー、そしてSQLとSQLデータベースのためのツールの巨大なエコシステムがあります。
Acadiaは技術的な観点からは素晴らしいかもしれませんが、それは重要ではありません。なぜなら、SQLと比較して十分に大きな改善には見えず、それに投資する価値があるとは思えないからです。私はむしろ標準SQLの知識や特定のリレーショナルデータベースの知識を向上させたいと思います。
最後に、Acadiaは他のORM/クエリビルダーと比較して本当にハードルを上げているようには見えません。関数型プログラミングの観点から、map/filterがSELECT ... WHEREよりも優れているのは理解できますが、私が参加したプロジェクトでは、ある時点で直接SQLとやり取りすることになるでしょう。
- dwohnitmok
私はデータベースを所有しようとする言語には警戒しています。特に、「SQLと共存する」という主張は、例えば合計型がカスタムバイナリエンコーディングを持っているため、他の言語との相互運用が難しい可能性が高いことを考えると、疑わしいものです。これにより、主張されている他の言語との相互運用は、本当に長期的な均衡ではなく、Acadia完全採用への一時的な通過点になります。合計型の使用を避けない限りは。（また、合計型をネイティブにサポートしようとすると、ORMのインピーダンスミスマッチのような関数型プログラミング版につながる可能性があると疑っています。リレーショナルロジックでデータをモデル化する方法は、代数的データ型でデータをモデル化する方法とはかなり異なることがあり、後者を前者に無理やり当てはめようとすると、オブジェクトをリレーショナルロジックに無理やり当てはめるのと同じ問題が生じるのではないかと思います。）
これにより、データベースはAcadiaがその上に載っているものではなく、Acadiaがコンパイルする対象に近くなります。私自身の開発者経験からすると、これは違和感があります。なぜなら、私は一般的にデータ層が王様であり、アプリケーションコードはそれを中心に回るべきであり、データ表現がコードで作成され、データベースがそこから作成されるべきではないと期待しているからです（これが私がORMのようなものを嫌う理由でもあります）。
一般的に、データベースはアプリケーションコードよりも寿命が長いと考えています。特に時間の経過とともにデータが蓄積されるにつれて。本番アプリケーションでは、データベースはしばしばアプリケーションの複数回の書き直しよりも長生きします。
私は疑っていますが...
- gbjcantab
これはかなり興味深いように見えますし、Evanはデザインについて非常に思慮深いです。彼がこれに多大な努力を注いだことを知っています。
個人的には、アプリケーションの一部として、このような制限的なライセンスを持つクローズドソースソフトウェアを採用することには非常に慎重になるでしょう。特にElmの軌跡を考えると。Elmが破壊的な変更や退行を経験したとき、または何年も公開で開発されなかったとき、ユーザーはソースコードにアクセスでき、それを変更する権利がありました。Acadiaのライセンスでは、あなたは取り残されるでしょう。
- jeremyjh
ここに特別なものは何も見当たりません。Haskellには10年以上前からこのようなものがあります。SeldaがおそらくAcadiaに最も近いでしょう：https://valderman.github.io/selda/
彼らの主張にもかかわらず、これは多くの言語のORMプラットフォームと本質的に違いはありません。
- let_rec
これはいくつかのことのように思えます：
1. .dbファイルに存在するElmライクなプログラミング言語
2. この言語からターゲットバックエンド言語の強く型付けされたデータベースプロシージャへのコンパイラ
これはORMよりもセマンティックレイヤーに近いものです。
得られるのは、テーブル定義（たとえばSQLマイグレーションフォルダ）とAPI言語（しばしば手書きのSQL）を接続する共有言語です。これは型チェックされ、最適化される可能性があります。
しかし、私にとって大きな疑問は、どのような機能を失うのかということです。PostgreSQLができるすべてのことを表現できますか？
- bbkane
私は実際、新しい資金調達モデルに最も興奮しています：https://acadia.engineering/license/faq
仕事ではAcadiaを使うことはできませんし、個人プロジェクトで使うリスク許容度もありませんが、このモデルがどのように/もし支払いを賄うのかを見るのを楽しみにしています。より寛容なライセンスのコードと競争できるでしょうか？
- honungsburk
Elmの作者であるEvan Czaplickiによる、PostgreSQLとSQLiteのための新しい関数型クエリ言語