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

我之前的背景主要是 js 和 ClojureScript, 對(duì)類(lèi)型了解很有限,到 Nim 算是才開(kāi)始長(zhǎng)時(shí)間使用靜態(tài)類(lèi)型語(yǔ)言吧. TypeScript 那只當(dāng) type checker.

Nim 的明顯問(wèn)題

JavaScript 到底是 Google 砸錢(qián)了的, 調(diào)試的體驗(yàn)真的是好.

至于 Nim, 大部分的報(bào)錯(cuò)靠著類(lèi)型信息倒是也能定位出來(lái),不過(guò)沒(méi)有趁手的斷點(diǎn)調(diào)試工具, 經(jīng)常要靠大量的 log, 我也挖得不夠深.

Profiler 我也用過(guò), 導(dǎo)出的是文本的調(diào)用棧和開(kāi)銷(xiāo)占比, 當(dāng)然沒(méi) Chrome DevTools 清晰.

VS Code 使用體驗(yàn)自然也遠(yuǎn)遠(yuǎn)不能跟 TypeScript 比, 我直接 Sublime 了.

Nim 的 echo 首先就很讓我頭疼, 沒(méi)有自動(dòng)加空格, 挺煩的.

Nim 沒(méi)有內(nèi)置的 string interpolation, fmt 不確定是函數(shù)還是 macro.

通常 fmt"balbla " 這樣的語(yǔ)法可以插值, 但是效果完全不如語(yǔ)言級(jí)別的插值方便,這個(gè)寫(xiě)法中如果有 { 或者 } 還需要手動(dòng)處理, 我在使用的時(shí)候就感覺(jué)比較糟心.

要在語(yǔ)言里邊實(shí)現(xiàn) interpolation, JavaScript 或者 CoffeeScript 都不會(huì)這么麻煩.

Nim 類(lèi)型和運(yùn)行時(shí)的一致性

TypeScript 雖然有很風(fēng)騷的類(lèi)型系統(tǒng), 但我也沒(méi)用著 strict, 也不是所有依賴(lài)都 ts.

然后偶爾會(huì)遇到寫(xiě)了類(lèi)型但是底下完全不是那么回事, 就很莫名.

Nim 的類(lèi)型跟數(shù)據(jù)是直接對(duì)應(yīng)的, 使用當(dāng)中除了一些 edge case, 都能對(duì)應(yīng)上,意味著類(lèi)型檢查報(bào)錯(cuò)的地方修復(fù), 代碼對(duì)應(yīng)的報(bào)錯(cuò)也就解決了,這讓我感覺(jué)到類(lèi)型才是可靠的. 當(dāng)然, 很多靜態(tài)語(yǔ)言應(yīng)該就是這樣子.

Method call syntax

Nim 不是面向?qū)ο笳Z(yǔ)言, 里邊的 object 大致對(duì)應(yīng) C 的 struct, 而不是對(duì)象.

object 里邊就是數(shù)據(jù), 這個(gè)還是比較習(xí)慣的.

不過(guò)代碼觀感上, Nim 還是有點(diǎn)貼近 js 這樣支持 OOP 的寫(xiě)法的,我是說(shuō)大量的 a.b(c) 這樣方法調(diào)用的語(yǔ)法, Nim 里邊叫做 Method call syntax.

也剛知道這在 D 里邊已經(jīng)有了, Wiki 上都明確說(shuō)了:

https://en.wikipedia.org/wiki...

這個(gè)特性對(duì)應(yīng)的 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)

最初我使用的時(shí)候沒(méi)有在意, 但是隨著遷移一些代碼到 ts, 才感受到靈活.

在 JavaScript 當(dāng)中, 繼承, 多態(tài), 依賴(lài) class 結(jié)構(gòu)才能實(shí)現(xiàn),這也意味著我要定義 class, 然后 new instance, 然后才能用上.

但定義了 class 也就意味著這份數(shù)據(jù)不是 JSON 那樣直白的數(shù)據(jù)了.

我對(duì) OOP 使用不多, 但是思來(lái)想去大致也理解, 動(dòng)態(tài)類(lèi)型能做到 JavaScript 這樣已經(jīng)很強(qiáng)了.

Nim 的多態(tài)是通過(guò)編譯器判斷類(lèi)型來(lái)實(shí)現(xiàn)的, 比如前面的 add 可以有很多個(gè) add,

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

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

后邊遇到 o.add(j, k) 根據(jù)類(lèi)型在編譯時(shí)候就能實(shí)現(xiàn)多態(tài)了.

當(dāng)然這在 JavaScript 靠 class 是能夠?qū)崿F(xiàn)的, 但那就一定要把數(shù)據(jù)操作綁在一起了.

長(zhǎng)期使用受 Scheme 影響的語(yǔ)言, 對(duì) class 這個(gè)臃腫的做法就很難適應(yīng).

有類(lèi)型的情況下, 在這套方案當(dāng)中 overloading 很自然的,比如 Nim 當(dāng)中對(duì)類(lèi)型 A 定義 equality 判斷的寫(xiě)法這這樣的,

type A = object
  x: number

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

沒(méi)有耦合在一起, 意味著我引用 A 類(lèi)型在另一個(gè)項(xiàng)目也能自行擴(kuò)展,而且這基于類(lèi)型的, 不會(huì)修改到原始的模塊當(dāng)中, 不影響到其他引用 A 的代碼.

這一點(diǎn), 我的代碼從 Nim 轉(zhuǎn)譯到 TypeScript 就比較頭疼,因?yàn)槲叶x數(shù)據(jù)結(jié)構(gòu)的訪(fǎng)問(wèn)和判斷需要 overload 這些個(gè) array accessing 和 equality,我一時(shí)半會(huì)也想不出來(lái) TypeScript 當(dāng)中能怎么做, 只能用 mutable data 在運(yùn)行時(shí)強(qiáng)行模擬.

Nim 里邊就很簡(jiǎn)單, 我對(duì) [] 進(jìn)行重載, 后邊就能 ys[index] 直接用了:

proc `[]`[T](xs: MyList[T], idx: number): T =
  discard

這個(gè)對(duì)于 iterator 的場(chǎng)景也是類(lèi)似, 定義了 iterator 就能直接寫(xiě) for..in 了.

iterator 這在 JavaScript 當(dāng)中也行, 只是說(shuō) Nim 當(dāng)中很多運(yùn)算符都能自己重載.

然后好處也是比較明顯的, 比如我重構(gòu)了操作內(nèi)部實(shí)現(xiàn), 但使用的地方基本不需要調(diào)整.

而在 JavaScript 里邊, 長(zhǎng)久我就習(xí)慣性直接面對(duì) Array 跟 Object 了.

沒(méi)有碰過(guò) Java 跟 C#, 碰過(guò)語(yǔ)言當(dāng)中這套玩法跟 Haskell 倒是挺像的,Haskell 從 class 產(chǎn)生 instance 的時(shí)候可以定義一些函數(shù), 就很靈活.

(具體 Haskell type class 高階玩法真是還玩不起來(lái).)

不過(guò) Nim 相比來(lái)說(shuō), 簡(jiǎn)化是簡(jiǎn)化了, 但這個(gè)語(yǔ)法糖在編碼當(dāng)中就是很方便.

也因?yàn)槿笔н@個(gè)功能, 導(dǎo)致我對(duì) Clojure 跟 TypeScript 這都有點(diǎn)不適應(yīng)了.

動(dòng)態(tài)數(shù)據(jù)的類(lèi)型

轉(zhuǎn)譯代碼還發(fā)現(xiàn)的問(wèn)題是由于 JSON 跟 EDN 極為便利,引起我在大量代碼當(dāng)中直接使用 Array 和 Map 直接表示數(shù)據(jù),這個(gè)不能算錯(cuò), 但數(shù)據(jù)在 Nim 當(dāng)中這些都是明確用類(lèi)型表示的,也意味著在 Nim 當(dāng)中有明確的結(jié)構(gòu)進(jìn)行判斷, explicitly...

反觀我的 TypeScript 代碼, 大量的 Array.isArray,然后還有那個(gè)不知道怎么說(shuō)的 typeof x === 'object' 的尷尬,在類(lèi)型系統(tǒng)當(dāng)中使用習(xí)慣之后, 回過(guò)頭感覺(jué)特別不踏實(shí),然后我自動(dòng)跑去折騰 instanceof 的玩法來(lái)做對(duì)應(yīng)功能了.

當(dāng)然, JSON 或者 EDN 通用地表示各種數(shù)據(jù), 確實(shí)在通用型來(lái)說(shuō)非常好,我跨項(xiàng)目調(diào)用數(shù)據(jù), 這些動(dòng)態(tài)類(lèi)型就是直接通用的結(jié)構(gòu),在 Nim 當(dāng)中, 一般傳遞數(shù)據(jù)是會(huì)涉及到一些類(lèi)型轉(zhuǎn)換, 寫(xiě)寫(xiě)是有點(diǎn)麻煩的.

我不是很能衡量那種方案是更好, 但是對(duì)于底層類(lèi)庫(kù), 我是希望有明確類(lèi)型的.

內(nèi)存相關(guān)問(wèn)題

因?yàn)橐幾g到 C 運(yùn)行, Nim 當(dāng)中的數(shù)據(jù)結(jié)構(gòu)多少還是要涉及到一點(diǎn)內(nèi)存的部分.

不過(guò)好在 Nim 當(dāng)中指針絕大部分已經(jīng)封裝成 ref 了, 也很少要去操心.

主要是感覺(jué)就是不同數(shù)據(jù)結(jié)構(gòu)之間性能的區(qū)別比較容易體現(xiàn)出來(lái)了.

這個(gè)在 JavaScript 這邊, JIT 老是偷偷幫忙優(yōu)化, 自己寫(xiě)出問(wèn)題沒(méi)那么容易察覺(jué).

我感覺(jué)到如果我早使用 Nim 的話(huà), 對(duì)算法和性能的朦朧感就會(huì)輕很多.

而能觸碰到內(nèi)存, 也就意味著內(nèi)存管理會(huì)遇到一些問(wèn)題,我之前遇到, 似乎是用 macro 的時(shí)候, 遇到語(yǔ)言?xún)?nèi)部的代碼出錯(cuò)了,然后 illegal memory access, 這就變得很無(wú)助了,論壇上給我的幫助讓我編譯 Nim 編譯器本身然后打 log 來(lái)獲取細(xì)節(jié),這個(gè)體驗(yàn)還是蠻新奇的, 反正 V8 我是沒(méi)有自己帶參數(shù)編譯過(guò)...

至少我目前用到的還不需要很清晰了解內(nèi)存布局細(xì)節(jié), 以后再看吧...

一些語(yǔ)法細(xì)節(jié)

Nim 當(dāng)中的語(yǔ)法糖還是挺多的, 有很多使用 CoffeeScript 時(shí)候那種輕快的感覺(jué),比如說(shuō) JavaScript 現(xiàn)在不好加語(yǔ)言級(jí)別的 range,這在 Nim 當(dāng)中直接用 .. 或者 ..< 就能生成 range 了:

for i in 0...<n:
  echo i

然后 if 在 Nim 當(dāng)中雖然比起 CoffeeScript 有那么點(diǎn)不順手, 但也還是表達(dá)式:

let a = if b:
  c
elif d:
  e

這樣的代碼轉(zhuǎn)到 TypeScript 馬上就變得挺長(zhǎng)了, 我更不能用三元表達(dá)式去犧牲可讀性.

當(dāng)然還是跟 CoffeeScript 去比的話(huà), Nim 畢竟還要考慮類(lèi)型, 沒(méi)的那么靈活.

對(duì)于代碼格式化, Nim 有個(gè)內(nèi)置的 nimpretty 命令.

我沒(méi)怎么用, 只是試了一下, 快當(dāng)然是很快的.

不過(guò)我用縮進(jìn)寫(xiě)代碼本來(lái)就已經(jīng)精確管理空格了, 再弄一個(gè)好像沒(méi)必要, 也沒(méi)手寫(xiě)靈活.

其他

TypeScript 的強(qiáng)大是我不得你承認(rèn)的. 為此我對(duì) AssemblyScript 還挺期待的.

但是隨著 Nim 帶來(lái)的這些感受, 我也起了一些疑惑.

比如說(shuō)基于 WebAssembly 我們將來(lái)有個(gè)更好的瀏覽器語(yǔ)言了, 怎樣才更好?

一方面要兼顧 Web 應(yīng)用大量的界面處理的場(chǎng)景, 一方面高性能和靈活,單純 AssemblyScript 這樣, 總感覺(jué)還是不夠的吧

以上就是TypeScript Nim交替使用細(xì)節(jié)分析的詳細(xì)內(nèi)容，更多關(guān)于TypeScript Nim使用的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論