Malt開發實錄（一）不斷改變的設計

我開了個新系列（沒錯以前的系列爛尾了，心情好再寫）

看名字就知道，講的是Malt的開發過程

但事實上正式的Malt第一版還沒有發布

這涉及到以下幾點原因

• 設計目標及方向幾經改動
• 之前的代碼寫得太糟糕了，重構之
• 換實現語言
• 以及最重要的原因——Lazy

所以這就是Malt跳票了半年多的原因

當然我說這麼多並不是為了給我找借口（廢話，你看我這不來發文章了嘛），換言之，寫文章的目的就是督促自己勤快點，早日寫完malt，然後開新坑/逃

開個玩笑，Malt我肯定要長期維護的

咳咳，好了，廢話說這麼多，現在開始咱們的正題

Malt的設計變遷

最初的設計

剛開始的時候，Malt在我的設想中應該是個完美的語言

應該是什麼樣子的呢：

• 支持函數式，過程式，面向對象編程範式（當然到後來又變成了純函數式）
• Mark-Delete辣雞回收
• 動態語言（類Lisp、Python），但支持類型約束
• 一切皆為函數（哪怕是個Number都是個返回self的函數，沒錯我當時就有這麼極端）
• 一切皆為對象
• 語法像commonlisp那樣「完美」

<!-- 不存在的 -->

後來（應該說是現在，中間省略）

因為某些事情，我改變了想法

我認為：簡潔為主，實用為基本，健壯性至上

我不需要寫個拳打java，腳踢Python的語言出來

我只需要實現一個我自認為能用，好用的東西出來就行了

不管是對於運行時實現者還是Maltlang用戶，只要寫起來舒服就好

對象模型：

不再是『一切皆為對象』

我將Maltlang的內置類型分為了兩類：

一類是簡單數據類型

什麼意思呢？這是指一個變數能表示下的類型

另一類則是複雜數據類型

這是指無法由一個變數所表示出的類型

換言之：像Bool，Number，Char之類的類型我們直接設計為值類型

而像String, Tuple, Lisp, Map這一類的複雜數據類型我們設計為引用類型

這樣有一個好處，就是降低複雜度，同時避免大量小對象創建所造成的開銷

【這是代碼，因為知乎的代碼編輯器和渲染器太辣雞了，所以我待會傳圖上來，RNM】

同時，Malt取消了原本設計中的用戶Class，因為用不著，這種設計已經夠用了，大不了用map模擬Class和Object

因為如果追求完美保證一致性的話所有內置對象都要套一層Class對象

垃圾回收：

由原本的Mark-Delete變為了Reference count

咱這可不是在抽風

首先，Reference count在無數次實踐中證明了是一種非常有效的方案

例如com技術（聽說過），Python的GC演算法之一，Rust對象所有權管理策略，C++智能指針等

另外咱們後來的目標為簡潔為主，盡量輕量級，所以我們不必採用可能會導致Stop on world的Mark-Delete演算法，畢竟從Root Object Set一個個遍歷不管怎麼優化還是很消時間的啊，從整體來講，RC的即時回收無非是把挨個遍歷的時間給鋪平了而已

當然，我說這麼多，無非是這個原因——我懶，我不想做，反正現在這麼多用RC的玩意都工作的好好的，只要不亂搞應該沒事

當然，就算我巧舌如簧也不能改變一個事實——循環引用

a = []b = [a]a.append(b)# 不用看了，沒有高亮的，我寫的時候就沒有，知乎的CodeEdit就是這麼辣雞

這段代碼在Python的某個版本之前（我忘了）會造成內存泄漏，Python為了解決這個問題才引入了mark-delete

至於Malt。。。你看我這麼懶像是會解決這種問題的人嘛/逃

這個時候就體現出了Malt設計簡單的原因了，因為足夠簡單，所以很容易能察覺出對象循環引用的問題（就算察覺不出我也有靜態分析器和動態分析器（別捉急，會有的）），所以這個問題應該是很好規避的啦

好了，咱這個系列的第一章就寫到這裡，有空我看如果漏了點什麼我再加上，現在先碎覺去了，好睏