回顾 Forth
第一件事就是没有钩子。不要留一个接口，想着未来的什么时候当问题变化时插入一些代码，因为问题会以你不能预见的方式变化。反正这个成本肯定是浪费了。不要预测，只解决你眼前的问题。by Charles Moore (Forth 之父)
今天也是机缘巧合，莫名其妙的翻出老资料温习 Forth 了。我想是个心结吧。19 年前，我痴迷于 Forth ，只看到了皮毛；13 年前，我进入大学的第一年，在校图书馆借出的第一本书，就是《Forth 语言》，读书笔记写了 20 多页。
只到今天，我才有机会，有能力，去仔细探究 Forth 的深层思想。当然，由于时间有限，几个小时的阅读，也只算是初窥门径。原本是想研究下 Forth 的系统实现，对同事正在设计的 3d 粒子系统，提供一些建议的。
碰巧又读到 Charles Moore 在 99 年的访谈稿 1x Forth ，颇多感慨。题头那段话，我在一周前刚好苦口婆心的对一同事说过，只差几个字而已。
最近很忙，既然晚上不能睡的再晚了，只好早上早点起。现在改为 10:20 起床了，比过往的 12:20 足足提早了 2 小时。感觉每天可用的时间的确长了许多。
晚上回家的时候，小巷子里总有两条狗。见我走过来便会汪汪狂吠，然后冲过来。头几次我心里还有点点害怕。次数多了也就习惯了。通常它们会冲到我跟前一米左右缓下来，跟着我一直走到家门口。跟它们打招呼也不大搭理，也就是用眼神盯着。
我想起同事养的一只贵宾。我每天都煮好两鸡蛋带到公司，饿的时候吃掉。上次体检 B 超的时候医生说我胆固醇太高，我便尽量不吃蛋黄了。若是那条狗在公司，我只要一敲鸡蛋，它就飞奔到我的座位前坐下，摇尾乞怜。已经不只听一个养狗的人说，鸡蛋黄对狗有莫大的吸引力了。
这两天，我吃完鸡蛋，都把蛋黄带着。夜路上再碰见那两条狗儿，就抛给它们。
这个时候，我居然会想起奥贝斯坦。
Comments
哈哈，真的蛮像奥贝斯坦的
Posted by: geekyu | (18) May 17, 2009 11:34 AM
搜forth,搜到你.大家同好forth.有空多交流阿
Posted by: Fox | (17) May 16, 2009 06:52 PM
在可以预见的范围内还是预见的好,问题也不并是总以所有人预见不到的形式出现
Posted by: windmeup | (16) May 10, 2009 08:52 PM
哈哈，原来云风钻研过Forth。
想当年，买来个Mac，按进固件一看，这是啥？一个诡异的白屏，写着Open Firmware。从此我就知道了Forth……
Posted by: Zhe![[TypeKey Profile Page]](https://blog.codingnow.com/nav-commenters.gif)
| (15)
May 8, 2009 07:22 PM
根据我有限的经历，是否“为了不确定的需求做设计”不仅仅是个技术问题，也是个“政治”问题——它更多的由部门官员根据部门地位来进行指定。
因为如果真的不为不确定的需求做设计，那么当需求改变而需要对程序做较大调整的时候，特别是看起来初始设计要为此付出某种代价的时候，似乎总得有个人承担责任，而当发生过度设计时其实也是类似。到底是需求定义不清？还是需求分析不明？呵呵……
Posted by: sjinny | (14) May 7, 2009 11:05 PM
深表赞同，最好的设计就是把程序做死，绝对不要为以后的需求而搞得很灵活。
Posted by: limantian | (13) May 7, 2009 09:56 PM
呵呵 为了证明我是人类
留言下
为什么不在白天工作呢？要做夜猫？
Posted by: *** | (12) May 7, 2009 08:40 PM
所谓"不为看不见的需求做设计"这种言论只是一种偷懒的借口而已
=========================
这种理解太狭隘。你与云风论述的对象是不同的。一个资深的程序员，会为多写几行代码少写几行代码而偷懒吗？
Posted by: 红色警戒 | (11) May 7, 2009 02:25 PM
头发为什么那么长？没时间剪？
Posted by: sylvia | (10) May 7, 2009 12:51 PM
不知道云风对d语言有什么评价？
Posted by: black | (9) May 7, 2009 12:23 PM
有一道题，这几天把我折磨坏了，想看看大家的意见：
http://acm.buaa.edu.cn/oj/problem_show.php?p=1002
如果你的速度在50ms以内，请给我邮件：
chinainvent.zyk@gmail.com
期待你们的优秀的方法。
Posted by: chinainvent | (8) May 7, 2009 11:46 AM
Oberstein是我最喜歡的人物
Posted by: Anonymous | (7) May 7, 2009 11:31 AM
编程的事，没有绝对的原则，确定自己想要的是什么，尽量用准确的抽象去符合问题本质模型，这样所采取的方法才会自然，不会那么容易偏离正确的方向。
Posted by: 啃饼 | (6) May 7, 2009 09:01 AM
所谓"不为看不见的需求做设计"这种言论只是一种偷懒的借口而已,设计时当然要充分了解需求,如果你还没有确认它,就应该确认它.你当然可以在出现新的需求时重构你的代码,不过有时候因为项目进度的压力未必来得及,作冗余设计是必要的,但有时候也会走向极端,要准确把握这点需要程序员对所面对的问题领域有足够的了解,也就是所谓的经验.
Posted by: ix | (5) May 7, 2009 08:26 AM
除非问题变化和原来预计的方式完全一致，否则多出的那一点设计是一点用都没有的；一不小心，后面就有依赖心理，老想用以前留出来的“钩子”，然后就是Abstraction Leak了。
问题变化了，设计也要跟着变(a design that can grow.)。设计能否跟得上，跟得好，就是设计师的本事了。
Posted by: al_lea | (4) May 7, 2009 07:21 AM
>不要留一个接口，想着未来的什么时候当问题变化时插入一些代码，因为问题会以你不能预见的方式变化。反正这个成本肯定是浪费了。不要预测，只解决你眼前的问题。
这一点我完全认同，我也喜欢直面问题，而不喜欢添加各种无谓的抽象层把简单的问题包的像只洋葱。这个问题在OGRE里非常的突出，可以作为典型的反面教材。
不过这不能成为不用C++的理由，没有人规定用C++就非得过度设计，喜欢C++是因为它带来的便利性，由语言特性所提供的抽象机制在大多数情况下总是更有效的，说白了就是可以节省一定的代码量，降低对使用者的要求，不必关心抽象的实现机制。而各种语法糖带来的便利性同样也不应该抹杀。
始终觉得云风放弃C++而转用C是矫枉过正了，虽然说语言特性带来的便利性可能会被滥用，导致不必要的复杂性，但是需要我们用自废武功这样方式来避免吗？
Posted by: analyst | (3) May 7, 2009 12:34 AM
军务尚书泪流满面...
Posted by: adaptee | (2) May 6, 2009 09:52 PM
这两天，我吃完鸡蛋，都把蛋黄带着。夜路上再碰见那两条狗儿，就抛给它们——好感动！做你老婆肯定幸福死了。。。现在这样的男人不多了，MM们，生扑吧，！！
Posted by: 风风 | (1) May 6, 2009 08:59 PM