共计 2085 个字符，预计需要花费 6 分钟才能阅读完成。
我之前的背景次要是 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
