Similarity、言語開発の苦悩

はじめに

Similarityは、C/C++代替を目指して開発しているシステムプログラミング言語です。

しかし、言語開発というものは、単純にコードを書けば完成するものではありません。

むしろ大変なのは、その前段階。

「どんな言語にするのか」
「何を正しい設計とするのか」

を決めることでした。

今回は、Similarity開発で経験した苦悩について書きます。

---

その1：独自性が強いため、参考にできるものが少ない

Similarityは、既存言語の単純な派生ではありません。

そのため、設計時に参考にできるものが少ないという問題がありました。

もちろん、

• C/C++の性能
• Rustの安全性
• Lispの構造的な美しさ

など、参考にしたものはあります。

しかし、Similarityの中心となる、

カテゴリ[操作{引数}]

という構造は、自分で意味を定義していく必要がありました。

「この設計で本当に良いのか？」

という判断を、何度も自分自身で行う必要があります。

正解が書かれた本があるわけではありません。

そこが言語設計の難しさであり、面白さでもあります。

---

その2：修正するのが本当に大変

言語設計では、小さな変更が大きな修正になります。

例えば、普通のプログラムなら変数名を変更する程度で済むことでも、言語では、

• 文法
• パーサ
• AST
• コンパイラ
• ドキュメント
• サンプルコード

など、多くの場所に影響します。

「少し変えたい」

が、

「全部確認し直し」

になります。

言語設計、怖い。

---

その3：設計だけで4ヶ月以上

Similarityでは、実装より前の設計段階に4ヶ月以上費やしました。

「早くコードを書けばいいのでは？」

と思うかもしれません。

しかし、言語は後から簡単に変更できません。

最初に決めた文法や思想が、その後のすべての基礎になります。

だからこそ、

「書ける言語」

ではなく、

「長く使える言語」

を目指して、時間をかけて設計しました。

---

その4：美しさと実用性のバランス

言語設計では、綺麗な設計だけを追求すればいいわけではありません。

美しい構造でも、使いにくければ意味がありません。

逆に、便利な機能を追加しすぎれば、曖昧さが増えてしまいます。

Similarityでは、

• 明確さ
• 安全性
• 性能
• 書きやすさ

のバランスを探しています。

そして、この調整が非常に難しいです。

「もっと美しくできるのでは？」

「でも実用性は？」

という悩みが常にあります。

---

その5：判断力が鈍っているとマジで死ぬ

これは本当に言いたい。

言語設計中の判断力低下、危険です。

なぜなら、その時にした小さな判断が、数ヶ月後の自分を苦しめるからです。

「まあ、これでいいか」

その一瞬の妥協。

それが後々、

「なんで当時の自分はこれでOK出したんだ……」

になります。

例えば、

True[]

。

当時の自分：

「Trueも子要素持つし、[]でいいか！」

現在の自分：

「いや待て……Trueってカテゴリなのか？
処理ブロックなら{}の方が自然では？」

結果：

修正。

また、

+{sum:i}

。

当時の自分：

「名前と値の関係っぽいし、:でいいかな」

現在の自分：

「いや、これ引数だよな？
,の方が明示的では？」

結果：

修正。

そうです。

言語設計は過去の自分との戦いです。

しかも厄介なのが、当時の判断も完全な間違いではないことです。

その時点では、その設計にも理由がありました。

しかし、設計が進むほど新しい問題が見えてきます。

そして気付く。

「これ、直すの大変じゃん……」

と。

まあ、何敗もしています。

※n敗目

---

おわりに

Similarityはまだ開発途中です。

しかし、言語開発で一番難しいのは、コードを書くことではなく、

「何を正しい設計とするか決めること」

だと感じています。

これからも試行錯誤しながら、Similarityを進化させていきます。