Open abbshr opened 8 years ago
所以说大概需要一个宇宙级 IDE 在写代码时标识出来推导结果呐 ww
@lingmm 如果要是准备放低门槛对入门选手普及开来, 那么给现有 editor 写插件也未尝不可, 毕竟类型系统理论源于数学, 有足够的信息应该可以推导出来. 但对于通读 reference 的人或者熟手来说, 估计自己可以演算出来, 没必要靠 ide 帮忙了, 如果一门语言要靠 ide 协助那我觉得太讽刺了... (没有黑 Java, lisp及其远亲的意思)
@lingmm 要在类型灵活性和严格静态类型之间权衡, 我总觉得还是 rust 做的可以, 到 crystal 时有些过分彰显自己类型的灵活性了, 你想要把代码写成 Ruby 那样的, 然后又要时刻堤防那些不可以做自动类型推导的. 可能是接触的不深的原因吧, 就是写起来总是很怀疑...有种为了看起来简单而刻意那么做感觉
@abbshr 前面只是开玩笑,我记得之前看 crystal
标准库的代码,里面好像基本都标注出了类型。感觉如果不是天天用,特别熟悉。相对于直接写出类型都会多一些心智负担。想写少又怕出现其他问题 hhh
rust 刚刚用时特别懵逼一件事,closure 不能写出来类型,let a: ? = |b| { ... }
,感觉这些东西还是需要专门记忆,挺麻烦的。
@lingmm 嗯, 看出来了...
我记得闭包是 Fn(T) -> T
, 在函数里是这么标记的
@abbshr 可以通过 Fn
接收一个 closure,但是不能在定义时用ORZ
C的类型体系终究还是有他的好处,在学习了两天Crystal后很迷茫…,静态语言使用type inference真的有那么好么(当然不是指智能推断方面,因为这是它的杀手级特性),看起来兼容了Ruby语法允许多数情况下以动态语言的表达方式写静态语言,然而每次写都要考虑这段代码编译器能不能足够smart去推导其中变量的类型?后面无意间reassigned或复杂的条件赋值,对于写代码的人来说是不是无形增加了心智负担。
学习Rust时候是首次接触类型推导,但毕竟Rust中不声明类型就写逻辑的情况实在少见,因此基本上无需担心这里要不要手动标注,而到了Crystal中就凸显出自动类型推导的强大,是union type还是编译错误?先分析一下整个代码看看编译器能不能知道吧…这种感觉怎么说呢?好比是一个菜鸟接了一个大牛的烂摊子,目前运转良好,然而对于是否会出问题,哪里可能出问题,以及出问题怎么解决之类的毫无头绪无从下手。
或许是我经验不足考虑简单吧,总之是否适合作为系统/底层编程语言还有待考证。
学习小结 2016.08