作者: fixopen

不妨反过来想想，在编译期，究竟有多少东西是可以静态确定的？

Fortran似乎静态确定的东西很多，但是递归就不能支持了。

对于并行，本质上是一种运行模式，编译期静态可得的信息究竟有多少？其实只有那些同步框而已。我们没有办法预测那个活动比另一个活动早一步到达目的地，只能给出一个信息就是在某点两人汇合或者某点A停止B开始等这些同步信息。

我们把模板和实现推广以下，可以认为编程是制造模板，运行程序是使用模板制造产品。制造模板的时候，我们考虑了产品的特征，也唯有如此，我们才能造出来这个模板。可是，用模板制造产品的时候，总会有很多很多我们制造模板的时候不需要考虑或者没有考虑的事情，原料不够【CPU运算性能低，文件不存在……】怎么办？原料不符合设想的要求怎么办？一系列问题。模板是一个静态可确定的东西，而制造出来的产品只有在制造后才确定出来。

当然，我并不是反对静态的收集程序特征信息，甚至运行时的特征都可以有所反应。实际上，类型系统就有这个作用，可以帮助程序更高效和安全的运行，但是，类型系统是有其极限的，最经典的例子是现在的类型系统都没有办法处理我在一排动物窝里面奇数号窝放乌龟，偶数号窝放螃蟹的这个事实。它们都没有办法描述这个模式。类型是静态确定的，对象却是动态确定的。而生命期的问题在顺序执行环境下也是可以确定的，但是在并行执行环境下却不可静态确定。

我不排除经过深入的思考，拼命的努力，可以把本应该静态能确定的东西确定下来，Fortran编译器就是一个实例，但是问题是是否值得？确定下来的好处是性能高，可是灵活性也相应的降低，这种取舍是否划算？并且，你不觉得有些东西是没有办法静态确定的吗？你或许会想到C++的TMP也是图灵完整的，似乎就意味着我们可以静态确定所有的事情了。但是实际上你别忘了，C++的TMP根本不能处理IO，甚至所有实施了Immutable的FP语言实现IO都显得很绕并且性能确实成问题。更别说所有的都静态确定了。