交替使用 TypeScript 和 Nim 的一些感想

我以前的背景主要是 js 和 ClojureScript, 對類型瞭解頗有限,
到 Nim 算是纔開始長時間使用靜態類型語言吧. TypeScript 那隻當 type checker.

Nim 的明顯問題

JavaScript 究竟是 Google 砸錢了的, 調試的體驗真的是好.
至於 Nim, 大部分的報錯靠着類型信息卻是也能定位出來,
不過沒有趁手的斷點調試工具, 常常要靠大量的 log, 我也挖得不夠深.

VS Code 使用體驗天然也遠遠不能跟 TypeScript 比, 我直接 Sublime 了.

Nim 的 echo 首先就很讓我頭疼, 沒有自動加空格, 挺煩的.

Nim 類型和運行時的一致性

TypeScript 雖然有很風騷的類型系統, 但我也沒用着 strict, 也不是全部依賴都 ts.
而後偶爾會遇到寫了類型可是底下徹底不是那麼回事, 就很莫名.

Nim 的類型跟數據是直接對應的, 使用當中除了一些 edge case, 都能對應上,
意味着類型檢查報錯的地方修復, 代碼對應的報錯也就解決了,
這讓我感受到類型纔是可靠的. 固然, 不少靜態語言應該就是這樣子.

Method call syntax

Nim 不是面嚮對象語言, 裏邊的 object 大體對應 C 的 struct, 而不是對象.
object 裏邊就是數據, 這個仍是比較習慣的.
不過代碼觀感上, Nim 仍是有點貼近 js 這樣支持 OOP 的寫法的,
我是說大量的 a.b(c) 這樣方法調用的語法, Nim 裏邊叫作 Method call syntax.
也剛知道這在 D 裏邊已經有了, Wiki 上都明確說了:
https://en.wikipedia.org/wiki...

這個特性對應的 Nim 代碼是這樣子的:

type Vector = tuple[x, y: int]
 
proc add(a, b: Vector): Vector =
  (a.x + b.x, a.y + b.y)
 
let
  v1 = (x: -1, y: 4)
  v2 = (x: 5, y: -2)
 
  v3 = add(v1, v2)
  v4 = v1.add(v2)
  v5 = v1.add(v2).add(v1)

最初我使用的時候沒有在乎, 可是隨着遷移一些代碼到 ts, 才感覺到靈活.

在 JavaScript 當中, 繼承, 多態, 依賴 class 結構才能實現,
這也意味着我要定義 class, 而後 new instance, 而後才能用上.
但定義了 class 也就意味着這份數據不是 JSON 那樣直白的數據了.

我對 OOP 使用很少, 可是思來想去大體也理解, 動態類型能作到 JavaScript 這樣已經很強了.
Nim 的多態是經過編譯器判斷類型來實現的, 好比前面的 add 能夠有不少個 add,

proc add(x: Y, y: Y): Z =
  discard

proc add(x: P, y: R): Q =
  discard

後邊遇到 o.add(j, k) 根據類型在編譯時候就能實現多態了.
固然這在 JavaScript 靠 class 是可以實現的, 但那就必定要把數據操做綁在一塊兒了.
長期使用受 Scheme 影響的語言, 對 class 這個臃腫的作法就很難適應.

有類型的狀況下, 在這套方案當中 overloading 很天然的,
好比 Nim 當中對類型 A 定義 equality 判斷的寫法這這樣的,

type A = object
  x: number

proc `==`(x, y: A): bool =
  discard

沒有耦合在一塊兒, 意味着我引用 A 類型在另外一個項目也能自行擴展,
並且這基於類型的, 不會修改到原始的模塊當中, 不影響到其餘引用 A 的代碼.
這一點, 個人代碼從 Nim 轉譯到 TypeScript 就比較頭疼,
由於我定義數據結構的訪問和判斷須要 overload 這些個 array accessing 和 equality,
我一時半會也想不出來 TypeScript 當中能怎麼作, 只能用 mutable data 在運行時強行模擬.

沒有碰過 Java 跟 C#, 碰過語言當中這套玩法跟 Haskell 卻是挺像的,
Haskell 從 class 產生 instance 的時候能夠定義一些函數, 就很靈活.
(具體 Haskell type class 高階玩法真是還玩不起來.)
不過 Nim 相比來講, 簡化是簡化了, 但這個語法糖在編碼當中就是很方便.
也由於缺失這個功能, 致使我對 Clojure 跟 TypeScript 這都有點不是應該了.

動態數據的類型

轉譯代碼還發現的問題是因爲 JSON 跟 EDN 極爲便利,
引發我在大量代碼當中直接使用 Array 和 Map 直接表示數據,
這個不能算錯, 但數據在 Nim 當中這些都是明確用類型表示的,
也意味着在 Nim 當中有明確的結構進行判斷, explicitly...

反觀個人 TypeScript 代碼, 大量的 Array.isArray,
而後還有那個不知道怎麼說的 typeof any === 'object' 的尷尬,
在類型系統當中使用習慣以後, 回過頭感受特別不踏實,
而後我自動跑去折騰 instanceof 的玩法來作對應功能了.

固然, JSON 或者 EDN 通用地表示各類數據, 確實在通用型來講很是好,
我跨項目調用數據, 這些動態類型就是直接通用的結構,
在 Nim 當中, 通常傳遞數據是會涉及到一些類型轉換, 寫寫是有點麻煩的.
我不是很能衡量那種方案是更好, 可是對於底層類庫, 我是但願有明確類型的.

其餘

TODO