三体杂评

  三体是年来看过最好的科幻小说系列.
  没有之一.
  因为这确实是许多年以后,才又第一次看起来科幻.

  从在某年某月某日把倪匡的除木兰花系列的所有科幻都看完之后,就再没碰过科幻小说.

  当然,这不是说倪匡的作品已经前无古人,后无来者了.
  只是说,那时候,知道的东西渐渐多了起来.
  于是,没有了童年,也自然没有了科幻.

  所谓科幻,如词所表达的.
  即是科学,又是幻想.

  它的魅力在于可有可无之间.

  当年着迷的倪匡便是如此.

  许多年过去之后,就没有碰过国内的小说.
  一部分原因是如四姑娘的阴影.
  
  当看到幻城末尾最有深度的人物刻画来自于古龙小说之后,便对国内小说水平从此绝望.

  当然,这里也不是要谈幻城,也不是要谈郭总.
  
  从三体3上市开始,twitter和reader里便不乏相关的消息.
  timeline上剧透和反剧透的在互相较量.
  
  此时的三体于我来说,毕竟不过是一本比较热门的书.
  即便,在一些比较"高端"/"成熟"/"理性"的圈子里,也有不少对刘慈欣的赞誉.
  但,也仅限于此.
  
  甚至于当同事看完三体3兴奋地向周围推荐的时候,植根深入的对国内小说的悲观感让我回了句:
  "都几岁了,还看科幻".

  在这本书被传阅几个人之后,终于也还是有了点兴趣.
  
  一句题外话,这便是social network的魅力/营销.
  所谓的口碑营销和virus便是如此.
  从一个节点外延扩散,然后形成爆炸趋势.

  找回了三体前两部来看.
  感觉与其说是科幻小说,不如说是科普小说.

  三体一谈论的是混沌.
  借用三体有些的发展来描述科学探索方法的演变.
  从纯经验,到纯理论,到理论结合试验.
  
  当到达现代物理的时候,混沌的出现以及不可观测性造成数学上的不和谐之后.
  刘慈欣把"智子"引入了进来.

  这是一个很有意思的想法.
  用这个来解释混沌和理论物理的各种不完美.
  犹如书中提到的靶子的例子.

  某种程度上说,这是一个有神论上帝式的科幻观点.
  规律还是存在,只不过在于一个观察不到的"维度"上.

  虽然这个科幻观点深入下去有些索然无味.

  三体一另外一个有趣的地方在于对文革的描写.
  对于纯幻想小说来说,很少会纠结到现实.
  
  而刘慈欣对"现实"的执着使我在翻开前几页的时候因为这是一本描写文革时期/知青的书.
  当然,也许这也是三体让人有"代入"感到理由.
  利用现实拉深科幻的层次.

  相对于三体一着眼于方法论,黑暗森林则更偏向于哲学/世界观层面.
  有一点博弈的感觉,但更多的是对于世界观的设置.

  从内容深度上说,三体二没有第一部那么"科幻".
  因为它已经超越的纯粹科幻的场面,而致力于营造一种世界框架.
  即所谓的黑暗森林体系.

  所有有点"科幻"味道的描写都在于补充强化"生存",这个第一法则.

  三体三则是对前两部的一个补充和扩展.
  从维度上进行的扩展.
  只是,想表达的东西有些模糊.

  似乎主要只是把黑暗森林法则进行扩展.

  于是,从这个程度上说,三体其实只有后两部在理念上是合一的.
  第三部跟第一部的联系也许只在于对一些前沿理论的科普式宣传和描绘.
  尽管,有些看起来比较玄.

  比如关于维度展开和跨越,智子的制造方式,四维宇宙的描述和维度坍塌.

  当然,对于量子/前沿理论物理我所知的并不多.
  对于维度的理解也只是限于它数学上的纯粹维度.
 
  比如描述宇宙需要11个基本变量,便是11维度.
  于是,对于"维度坍塌",能想象到的也就是"投影".
  "坍塌的维度"也即是被限制了的那个投影维度.

  所以,对于坍塌的景象,也许只是一个观测上的不同而已.

  回到主题.
 
  对于三体系列,从某些方面来说确实承担得了那些赞誉.
  毕竟,对于目前以"毫无根据的胡扯"居多的中文小说来说,算是一缕曙光.

  借用某人的一句评价就是:
  "还可以,就是有些地方太罗嗦."

  其实,作为科幻小说,能提供给人一些有理有据的白日梦就已经是成功.    
  只是,像三体这样没有明显硬伤的小说似乎已经越来越少了.    

Java Class.cast的问题

  以前没觉得java的类型系统有什么问题.
  不过就两条机制在,box/unbox的问题而已.

  当然,接触java的时间不算久,所以没有经历过那段没有autobox的日子.

  不过,从一些例子看来,autobox也未必是好事情.
  比如这段代码

  int n = 0;
  int another = int.class.cast(n);


  从表面上看来,这应该是一段很符合表面语义的代码.
  一个类型转换,而且应该是没什么问题的.

  只是,由于cast的函数声明参数是一个Object.
  而在java里,primitive和object是两套类型系统.
  
  在java引入autobox之前,这段代码应该是会编译错误的.
  但是,有了autobox之后,没有编译错误,但是肯定会有运行错误.

  在调用的时候,java隐式地将int box成java.lang.Integer.
  
  想想,既然有autobox,那么应该也问题不大.
  最多返回Integer之后,再unbox隐式转换回int.

  但问题是,cast做了一些类型兼容的检测.
  从jvm的角度来说,int和Integer是两个不兼容的类型.
  于是,在调用cast的时候,会抛一个ClassCastException.

  也就是说,在java两套类型系统存在的前提下,
  primitive.class.cast()的行为就变得有些古怪了.
  
  一些语义上看上去无误的代码,也许运行时就必然要抛异常.
  
  当然,对于这类可以显式调用的也许可以避免.
  但程序复杂了就难免会有这样那样的trick/trap.

  比如:

  void  Type method(Class type){
       ....
      return type.class.cast(value);
  }
  
  这段代码.

  初看上去似乎还行.实现了某种程度的模板/复用.
  但是,注意那个cast.
  
  所以,很难保证在实际情况下不会出现这种box/unbox带来的cast的问题.

  于是,解决方案就是尽量避免使用cast做转型,或者时刻记住box/unbox的问题.
  
  问题是,如果不用cast转型就要自己写个检测null的东西了.
  这当然不是什么大问题.

  最好的方法估计还是统一一下类型系统吧.
  做接口的时候也许最好是使用非primitive的类型吧.
  这样或许能够避免一些问题.
  
  虽然在诸如做序列化的时候,非primitive类型会有一些额外开销.
  不过,真要做序列化的话,这些开销也是可以避免的.

  比如,最直接的一堆if,else做对应的类型映射.
  
  总而言之,java的两个类型系统是个头疼的存在.
  不仅存在陷阱,还使得在做reflect的时候经常让人崩溃.

  在这方面,后来者C#做得貌似就好得多了.

  比较,Java老了.

  语言这东西,也许不是说年代越久越成熟.

  毕竟,需要解决的总是新问题.