世间一切苦

小远刚出生的时候,朋友问我,当爸爸开心吗?我说,在没有经过他同意的情况下就把他带到这个充满苦难的世界上,我只希望他能够原谅我。

朋友说我是个一个悲观的人,但我有时总觉得这并不能完全怪我。

我自认为自己一直在努力对得起身边所有的人。至少,如果有人问我:“你有想有意识地去伤害过谁吗?”我自认为自己可以坦然地回答:“没有。” “即便这个人伤害过你?” “没有。” 然而,我还是会无意中伤害到别人。然而,我还是会觉得所有人都对我不满意,所有人都觉得我还做得不够好。仿佛我亏欠他们一样。

那么我问你们,如果我从这个世界上永远地消失呢?你们的日子因此会变得好一点吗?如果会的话,那或许就让我消失好了。

其实,那些对我不满意的人,往往是那些对我好或者曾经对我好过的人。只不过,人,有了付出,总觉得需要得到回报,有了回报,总希望得到公平的回报。而曾经的付出,使他们觉得得到公平的回报是件理所应当的事情。

而这个世界其实并不见得有什么公平。

爱往往就这样埋下了恨的种子。这恐怕是世间一切苦的因缘。

佛家有这么个故事。

山里住着一个和尚。有一天有个姑娘带着一个婴儿来到山上,说这是这个和尚的孩子,要和尚对孩子负责。这个和尚什么都没说,就把孩子收下了。

十年之后,和尚把孩子辛苦养大,当年的姑娘已经成了妇人。她到山上来找到和尚,说孩子其实不是和尚的,说要把孩子带走。和尚依然什么都没说,就让姑娘把孩子带走了。

旁人问和尚:这明明不是你的孩子,你还白白花了十年时间把孩子养这么大,最后还送了回去,自己什么都没得到。和尚笑笑说,我得到了十年的修行。

呵呵,这话若是让那孩子听到了,那孩子说不定还会伤心地骂和尚:原来你养我只是为了你自己的修行……

然后这个世界上就没有人会再记得,一个和尚无私地替一个不幸的姑娘把一个可怜的孩子辛苦地养了十年。

或许只要爱的无私就注定会被误会吧。

这个世界可能其实就是这个样子。勇敢去爱的人其实常常都是没有人理解的人,但他们勇敢,所以他们仍然会继续爱下去。

小远,爱是一种幸福,也是一种苦难。但愿你长大之后不会恨我。但愿你在自己去爱别人的路上多一点开心快乐,少一点苦楚委屈。

民族感情

民族其实是一个挺有意思的东西。人在国内的时候不觉得,因为反正所有人都是中国人,同仇敌忾,媒体告诉你一个靶子,送给你一个目标,说美国又怎样怎样了,然后大家就可以一起冲上去,还挺带劲的。觉得自己特爱国。是民族的才是世界的嘛。让世界知道我们都是中国人嘛。

然而,等到了国外,就发现原来这世界上其实有很多很多民族。会看到课上一个韩国人上在台上特别骄傲地讲自己国家的历史故事,会听到印度人特别骄傲地穿上他们的民族服饰去逛百货商店,会看到罗马尼亚人特别骄傲地说他们怎么和欧盟对着干,怎么觉得罗马尼亚姑娘都应该嫁给罗马尼亚小伙儿才是对的,会看到美国人在Dota2的赛场上齐声喊USA。

这种事情见多了,有时会觉得很恍惚。不知道为什么,当别人特别自豪地说他们的民族或者国家怎么怎么好的时候,我并不因此而如何钦佩他,反而常常会觉得气氛会有些尴尬。因为这种自豪在夸赞自己国家的同时,潜台词也在说:你的国家不如我的好,因为我的国家是最好的。

这就好像幼儿小朋友之间互相之间攀比谁的书包好看,或者谁的爸爸官儿更大。

可是咱已经长大了,这东西似乎就没什么劲了。

其实我们生下来是什么民族的,并不是我们自己的决定。老天爷也并没有规定过民族传统文化必须要一代一代去传承。就像人都会死掉一样,人类也终究会灭绝,文化也终究会消亡。理性来看,当数字化已经成为了我们新的不朽方式,我们可能其实并不需要为我们自己的基因之延续付出那么大的努力,不管是生物上的还是文化上的。当我们的生活都永久性地存储在云端上的时候,文化基因的保存讲不成为什么实质性的问题。这时候,每个人如果以每个人自己开心的,觉得有意义的方式活下去,而不拘泥于自己属于什么民族,什么文化系统,可能反而为人类文化基因库提供更丰富的多样性。

对于各种爱国青年们,可以试试给自己三分钟时间,只三分钟,一百八十秒,忘掉自己是什么民族,什么国家,尝试以一个完全中立的视角看看这个世界,想象自己忽然死去,灵魂漂泊在这个世界的上空,感受一下你的国家是否因为你的忽然离开而伤心了很多,想象一下自己下辈子投胎可以自己随便选一个国家,思考一下自己除了国与家的荣辱之外还有什么其他的可以追求的好下辈子来做。如果你没有答案,那么是不是可以想想呢?如果你有个答案,为什么这辈子不去做呢?

AlphaGo之后

我这个人有时很有喜欢预测事情。有时候对有时候错。

比如预测老罗做手机能成事,因为我相信理想主义旗帜的正确性在长期上会大于局部的执行。结果虽然锤子科技还没死掉,但是似乎离成事儿还很远。所以事实证明局部执行还是很重要的,尤其在创业这种事情上。幸好这是在我要亲自创业之前,很好的一课。

另一个预测是我一直认为人类的所谓智慧其实并没有本质的超越性。相信自由意志中的自由其实只是一个带有信息隐藏的随机性,相信智商高是算法优势而不是算力优势,而算法上的差别从来不是硬伤,因为算法是软件,是可以习得的。相信借助简单易得的计算工具每个人都可以在智力上平等,而只是在自我表达上存在差异。

借助简单易得的计算工具每个人都可以在智力上平等,这也是E8VM的价值观——让理解所有已有的算法变得没有门槛。

这之所以是猜测是因为很多人类直觉上有优势的事情目前还没有很好的解释。

比如审美,比如围棋。

这些问题上电脑似乎一直还离超越人类很远,因此显得似乎人类的智慧对图灵计算还在某些方面有超越性。但如果从计算理论上去分析,实在是找不到任何理论支撑和事实依据能具体说清楚人类智力的超越性在什么地方,找不到在某个明确的子问题上人类是oracle而计算机一定不是。

而屁股决定脑袋的bias会让很多人倾向于相信人类是有超越性的,不然怎么显得智力生物的优越呢?

但如果用科学一点的态度去分析,至少应该假设观察不到的就是不存在的。

AlphaGo比赛结果的重大意义就在于打破了人类智力的这种优越性。

就像当年的日心说打破了人类信仰的优越性一样。

如果智慧是可以通过机械训练得到的,那么智慧其实也只是平凡的。我们不是宇宙的中心,从来都不是,从哪个方面说都不是。

我们甚至可能离程序做ACM竞赛题能轻松干掉楼教主已经不远了。到时候回头想想今天的人们各种忙着刷算法题,可能会觉得挺可笑的。

所以人工智能普及之后什么最重要呢?

我认为将是自我表达,如何准确地合适地最优地表达自我的内部随机性。如何认识自己,知道自己想要什么,了解或者决定自己的人生在下的到底是什么棋。

了解和决定我们人类到底是在下什么棋,想要的是什么样的共同幸福。

智力终究也只是一种工具,而当智力上的竞争也变得没有意义时,everyone is unique才不会是一句空话。

江湖终结之后,也许才是真正的和平。

民科

其实,如果真的发现了逆天的黑科技,而世界上又无人承认,直接创业赚钱就好了。

严肃的学术是否需要做功?是。但做功了就一定是严肃的学术吗?只有在学校里多虚度了几年,有了正经学术素养,才有资格谈学术吗?这其实是毫无道理的。

真理的探讨只看是不是在摆事实,是不是在讲道理。不应该看是谁在说话。

不因人废言,这是最基本的学术素养。

学术讨论需要事先要费力做那么多功课才能进行,这其实恰恰是科学家们需要更加努力的地方,要努力让做这些功课变得更容易一点,需要的年头更少一点。学术讨论前需要先学习大量知识,而学习大量知识需要耗费很多精力,这其实是一件很值得我们去努力一起改善的事情。

而不应该是在过去付出了很多精力去学习的人所要维护和依赖的荣誉光环。

人类社会在很大程度上是个荣誉和信用的社会。

我们会说一个人会做好一个事情,是因为他以前做好过类似的事情。

然后我们就会说最好的笛子应该给这个世界上吹笛子最好的人。

但其实这个并没有确定的道理。尤其在一个大家要不断创新的世界,以前做过A,未来就一定能做好A’吗?这其实只是一种maximum likelihood的估计。

而且,如果可能的话,为什么不把最好的笛子给世界上每个想吹笛子的人一人做一份?多么好的创业机会!

那些觉得星空不是随便什么阿猫阿狗都能仰望的人:菩提本无树,明镜亦非台。几个小民科的沉浮和你所仰望的星空又丫的有什么关系呢?

我为什么要写e8vm

我读phd的时候写程序搭系统常常自己从头手搭。有些人因此经常觉得我傻,觉得我做得不对。但我其实心里有个很简单的原因:我更愿意在我自己了解的软件上工作,而自己从头写能保证我对我用的软件了如指掌。

我也不是没试过用别人的软件。我也见证过身边的人用别人的软件。用其他人的软件,弄个东西跑起来往往很容易,但是要做深度调整和优化就往往很难了。结果往往没有自由,也就没有创新,只是一层抽象上面再叠加另一层抽象。

然而,从头写软件其实也并不解决本质问题。往往其实只有写的那个人是唯一懂的人,其他人都是外人。当这个软件作者换了个工作,或者仅仅是对一个项目不再有兴趣的时候,项目实际上往往就死掉了。代码可能折腾一下还是能编译能跑的,但是要做深度调整和优化就往往很难了,即便是有其他人有愿意来做这个事情。我自己写的软件对于他人来说也会变成别人的软件。轮回往复。

我想止住这轮回。

代码本质是一段可执行逻辑的形式描述。它其实是可以有自己独立的生命而存在于世的,就像文学作品一样。人们应该通过阅读一段代码就能了解它是在做什么。

代码可读性甚至比代码性能更重要,因为时间往往能打败一切。《射雕》里黄裳为报家仇避世练《九阴真经》,几十年练成之后出山发现仇人已经都死光了。岁月是最牛逼的杀猪刀,这在代码界也是一样的。而只有可读的代码才是不朽。不朽才能笑到最后。

然而,今天的代码往往极为难读。随便上github或者coding.net上找一个有几千行的项目,你能准确估计出要彻底了解这个项目的代码需要多少时间吗?“彻底了解”可能是个不太好定义的概念,那我们换个问法:你能准确估计出把这个项目徒手翻译成另一种语言需要多少时间吗?

我曾经尝试把v86翻译成Go语言,但简直不知从哪儿开始下手。逐个文件逐行翻译恐怕是行不通的,因为总不能连写几千行的代码但甚至编译都没编译过一次。一个可能更可行的办法是对照着git日志从头用Go语言重复一遍开发历史,但这就相当于要把原来走过的弯路也都重新走一遍,似乎并不比自己从头开发好到哪儿去。

如果有文档呢?有文档和注释的代码更可读吗?

有可能,但写代码的人都不喜欢写文档,并且他们有十分充足的理由。首先,他们自己写的时候不需要文档,因为代码的设计都在他们自己脑袋里,不用写出来。文档在当下是没有用的,只是可能在以后才有用。其次,代码总在变,刚写过的文档经常没多久就过时了。所以问题来了:大概注定要被删掉重写的文档,又怎么能说是在以后会有用呢?最后,好的代码往往是自解释而不一定需要文档的。模块名、文件名和符号名都是可读的文字,关键字也都是可读的文字,为什么要把代码所表达的逻辑再以另一种方式用可读的文字重新写一遍呢?而且还没有代码本身精准?

这事儿应该有更好的办法。

所以我常常琢磨,为什么代码本身常常不那么可读呢?

对于这个问题,很多人给过很多解释,也做过很多改进的尝试。但大部分都是技术性的,比如设计一种新的语言,一种新的编程模式,一种新的可读性测量标准……

这些当然都很好。但我觉得其实有个更本质的问题:代码不可读是因为代码写出来就基本上不是去给人读的。就没人去读。

我们读书,读文章,读博客,读微博,解读绘画作品,甚至读剧本读食谱,但是我们几乎从来不读代码。甚至即便是IT界的职业程序员,也常常对读大项目的代码心存畏惧,能不读就不读。就更别说各种初学者和业余爱好者了。

我五年半的博士读下来可能还不是总能写出极好的论文——写作还是很难的——但我至少懂得了如何提高自己的写作能力,那就是必须不断写东西给别人看,听取别人的反馈意见,让其他读者告诉你文章哪部分他们没读懂,读哪部分的时候开始犯迷糊了。听取别人的阅读反馈是提高写作的唯一办法。

代码也是一样。

所以,我想建一个网站,让人们可以在上面发表自己的代码,订阅别人的代码,互相读代码,就像互相读微博读博客读对方生活中的故事一样。

有人可能会说:不是已经有Github了吗?

说的好。但我以为,Github是分享平台,而不是阅读平台,而只要没有阅读,就不会有可读性的进步。在我看来,一个代码阅读平台要鼓励大家阅读必须满足以下这些特征:

  • 所有的代码都是用一种可读性很好的语言来写的。
  • 它要能自动把一个大项目拆分成小块,让读者可以从小读起,开卷有益,而不是要把所有代码都读完才能知道这段代码到底在说什么。
  • 它要能自动为一个大项目生成一个提纲挈领的目录,使得读者可以对项目的结构一目了然。
  • 代码必须在网页里直接一个点击就能编译运行。代码不仅仅是文本,它不是死物,而是活物。

这是我想建的网站,一个代码阅读的网站。而E8VM是这个网站的核心基础技术。E8VM为可读代码而构筑,同时自己也要构筑成可读的代码——至少这是我的愿望。它到底是否可读,只有在网站上线人们真的读过之后才可知道。

这将是一个历史被创造的时刻。这个时刻起,代码将以可读逻辑的形式,独立于它的造物者存在并获得永生。

你愿意和我一起创造这历史吗?

Why I am building e8vm

When I was in graduate school working on my Phd, I often prefer writing systems from scratch. Some people often think I am crazy, or at least doing it in the wrong way. But from my personal perspective, I have a simple reason: when doing work, I prefer using software that I can understand, and writing one by myself often guarantees that I understand every detail of it.

I also tried using other people’s software. I also have seen others using other people’s software. It is often easy to get something running, but hard to make fundamental enhancements later. Freedom is lost. Innovation stops. What left is endless layering.

However, building from scratch does not solve the problem. Often times, the builder is the only one that really understands the code; others are still foreigners. The project effectively dies when my life moved on and I had no interests on further maintaining it. The code might still compile and run, but it becomes hard to make fundamental enhancements for other people that have interests to take it on. I see the cycle that me becomes the others.

I want to stop this cycle.

Code is the formal representation of a piece of executable logic. It should live independent of a maintainer, like literature. A piece of code should be understandable just by reading it.

Code understandability is even more important than its performance, because time beats everything. In a Chinese Kungfu novel, there was a man that seeks to revenge his enemies for his family. He hid in a cave for decades and eventually trained himself to be the best Kungfu master in the world, but when he came out of the cave several decades later, all his enemies are dead already. Time will is toughest killer, and it is the same for code. Human understandable code is immortal, and immortal code will win everything eventually.

However, I find code today is often extremely hard to read. Randomly pick a Github repo, say some that has at least several thousand lines of code, could you even precisely estimate how long time would it take to fully understand it? The state of “fully understood” might be a vague heuristic, so let me ask more specifically: could you estimate how long time would it take for you to rewrite it in another programming language by hand?

I once wanted to translate v86 to Go language, but I didn’t even know where to start. Blindly translating the code line by line, file by file does not really work. It would be like writing thousands of lines of code but without a single successful compile. A probably more feasible way is to track the git commit logs and reproduce the development history but in another language. However, that means I have to go through all the failed trails and attempts in the history as well, which would be not so much better than building from scratch by myself.

How about documentation then? Does code documentation make code more understandable?

It probably does, but developers do not like writing documentation, and there are perfectly good reasons for it. First, the working developers do not need documentation. When they are writing the code, the design is mostly in their brains already. Second, things keep changing, and documentation easily gets out of date. The argument that one would need the docs in the future is hence not true for a general piece of doc, because they are either out-of-date and useless, or replaced by another piece that is more up-to-date. So why write words down if you are mostly likely to delete them later? Third, good written code pieces often document themselves. Packages, files and symbols all have readable names in English. Language keywords are also readable English words. So why restate what the code does in plain English again, and often in a less precise way?

There should be a better way.

So I ask myself, why code is often not readable in its plain form?

For this question, people have many different answers and even proposed many solutions. Most of the solutions are technical ones, like design a new language, or a new programming paradigm, or a new heuristic for readability or complexity.

But I think there is a more fundamental reason: because people do not read code in its plain form.

We read books, we read articles, we read blogs, we read tweets, we read paintings, we read film scripts, we read recipes. We do not read code. Even professional programmers in the software industry are mostly feared or at least reluctant to read code from a large project, not saying learners, beginners, or non-programmers.

I might have not learned how to write good articles during my 5.5 years of Phd study — writing is hard — but I did learn how to improve one’s writing skills: you must ask others to read your written words for feedbacks. Let the readers tell you which part they do not understand, at which part they start to get lost. It is the only way to improve.

I think code is no different.

I want to build a website where people can publish, subscribe and read code, like reading a tweet, a blog post, or a story.

“How about github?” One might ask.

That’s a good question. My opinions: Github is for sharing, not reading. Without reading, readability won’t improve. In my opinions, a code reading website needs to satisfy these requirements to enable and encourage reading:

  • It only uses programming languages that are designed to be easily readable.
  • It automatically breaks big projects into small pieces, so that a reader does not need to dive deep and read everything before he can understand something.
  • It automatically provides a reading order of the project like a table of contents.
  • It compiles and runs the code inside the browser with just one click. Code is after all living animals.

This code reading website is what I want to build, and E8VM is the core foundation of this website. It is written in readable code for readable code — at least I wish it is readable. Its readability will be tested when the website launches and people start reading it.

This is how history will be made. Immortal code will start here.

Do you want to be a part of it?

e8vm

e8vm终于写得初具雏形了。纯业余时间写了17000多行代码,心里却开始有点担心起来。和人吹牛皮的时候有一个很美好的愿景:小说一样可读的代码将颠覆整个软件产业。可是真执行起来却其实有各种各样的困难。从根本上革命的东西,往往初期边际收益很少。而天下众生大部分人还远不到参透生死万念俱空的境界。其实最怕的不是不被人看好接受,怕的是自己能力有限而终究做不成这个事情。要写SSA优化,要写同步文件系统和版本系统,要做网站,要设计UI,要把后端port到X86和arm,要做运营。我很需要一个团队,却还看不见这个团队的影子。甚至有时会恨自己快30岁的年龄和这张不讨好的亚洲男的脸。

其实最近也找了很多人聊,但是大部分人也只是点头称赞一下有意思,但不会愿意一起做。可能也是自己起步的角度有些太纯粹了,就像你看到网上其他人自己发明的一个语言的时候,你首先看到的是他们过于庞大的自我,而常常看不到背后的意图。可是这也是没有办法的事情。我增加程序可读性的办法不过三点:简化语言、控制依赖结构、浏览器内直接编译运行。现有的语言和编译器不是不能重用,只是要做这样的深度定制可能还不如自己重写一个。也可能是因为大部分人写程序也更多的是为了生计或者一些其他的兴趣,而不是因为对程序逻辑本身的热爱。

其实多说也没什么用,除了更加虔诚地去做这个项目,目前来看也并没有什么其他的路。但不管怎么说,这是需要一个团队去做的事情,所以我阶段性的目标应该是做出一个原型,然后拿这个原型去尝试组建一个团队。团队的人注定会很难找;这需要缘分,不要拖沓,也不用着急。琐碎的工作自己可以慢慢做,SSA自己可以慢慢学;其实可能也并没有想象的那么难。17000多行的编译器都写下来了,也不过用了8个多月的时间(虽然前面还有好几次失败的尝试),或许应该乐观一点。

优化当然是一个跳不过去的坎,但在优化之前应该先把网站粗糙地做起来。所以,把import和简单的const做好之后,语言就先可以基本feature freeze了。编译器上只需要重构代码和修bug。并可以把重点放在网站上,要做一个简单的用户系统,一个简单的和云端同步的带版本历史的文件系统,要在这个系统上演示写那个简单的os,以及各种OJ的题目。有了编译器,最难的工作其实已经过去了。一个小网站而已,或许不会比难矣斋复杂很多。

但愿我的团队到时候会来……我是不是应该去烧烧香啥的?

加油吧。

为什么不去学术圈

毕业了会离开学术圈,去工业界,先去Google,山景城。

为什么不去学术圈?这是一个PhD毕业的时候经常被问到的问题。

这个问题被提出,背后有两种可能的逻辑。

第一种逻辑是说,博士原本就是为学术圈提供人才的。但就业选择本身其实是每个人的个人自由,而且事实上是学术圈的需求很小,而博士毕业生供给很大。大部分博士肯定不会进学术圈。

第二种逻辑是说,博士读很久,如果不去学术圈而去了工业界,大部分博士期间所获得的科研训练就都成了没有价值的投资。

我选择读博士是因为自己喜欢科研,当初喜欢,现在也喜欢。对接受的科研训练,我一点也不后悔。我读博士前曾经立志要成为一流学者,做一流的科研。现在也仍然是这么想的。

我离开学术圈,是因为自己不喜欢学术圈的生态。

事实上,学术圈里的人,尤其和工业圈相比,其实是相对更好的。统计上来讲,更理性,更和善,也更理想主义。工业圈经常是功利至上的。获得财富有两种方法:可以生产创造,也可以巧取豪夺。两种方法在市场经济下常常是不作区分的。工业圈的人也因此显得更险恶一点。

学术圈不靠获取财富吃饭,而靠获取认可,通行的货币是idea,是想法。获得认可靠同行评议,但生存保障来自第三方的政府或者企业。看家本事是创造和推广新想法。

学术圈和娱乐圈、艺术圈有点像(娱乐圈是商业化的艺术圈)。名声是饭碗。实际上,在中国,文人和学者之间经常傻傻分不清楚,因为他们虽然看家的本事其实很不一样,但是活着的姿态是相似的,甚至可能混的是同一片江湖。

所以,和娱乐圈一样,立志于学术圈的人往往是热爱功名的人,人生目标是名垂千古或者至少受到尊重。当然,也有不少例外,但是大体上是这样的。这本身没什么错。希望自己站在台上,希望名字被人记住,追寻属于自己的光荣与梦想,pride and honor,这可以是一件很好的事情。

不过,光荣与梦想并不是科研。而我喜欢科研,但对荣誉不那么感兴趣。

爱功名,但更爱真理。

理想状态的学术圈中,荣誉与科研,功名与真理,应该是等价的。科研好的人荣誉高,发现真理的人拥有功名。但现实是,这只在科研想法容易被检验的时候才有效。

学术圈的检验机制是同行评议。理想中的同行评议,应该是拿到一个论文,看到一个想法,自己至少要把这个想法按照论文上提供的方法论试一遍,事实论据应该核实一遍,实验应该重复一遍,推导计算应该验证一遍。这是科研最起码的态度,是科学之所以为科学的根本方法论:靠事实和逻辑说话,而不是靠个人喜好。然而,现实是,由于科学研究已经变得很复杂,验证事实和逻辑往往成为只有工业界才有实力做的事情,也就慢慢成了工业界在科研活动中的一项事实分工。

验证都外包给了工业圈,那学术圈呢?

只提供想法就好了。

那么问题来了,没有了事实和逻辑的验证,同行评议如何评价一个想法是否是好想法呢?

基本靠个人感觉。

这就非常不靠谱了。即便评审的人都是专家。

没有了有效的事实和逻辑的验证,学术圈和娱乐圈的本质区别在渐渐消失。生存的要义在于讨好观众。

当然,讨好观众也是一项很了不起的本事。解密人性的通感和解密事实中的逻辑结构同样是很难也很有价值的事情。一个是艺术,一个是科学,一个是美的事业,一个是真的事业。都是伟大的事业。都名正言顺。

何况任何言论,只要是生存在人们的传播之中,总要首先寄托于不让观众太讨厌的言辞。

但伪装成科学的艺术,就有点扭曲了。

把美说成是真,这是不对的。

这是我对学术圈这几年来最失望的地方。

老板经常教导我要乐观一点:在很黑暗冰冷的地方更容易耀眼夺目地发光发热嘛。这话让愤世嫉俗怨天尤人的人无话可说。

他自己也是以身作则这么做的,很令人敬佩。

但他毕竟已经过了做选择的阶段。而我还有选择的机会,并且我看到另一种更好的路径。

IT产业在经济危机之后的迅猛发展,计算机行业钱很多。

但其实能做的事儿并不多。这也是IT产业为什么往往会出现很多类似的产品。瓶颈其实正是在科学技术,大规模高效地把人类生活的方方面面数字化是一个很难的事情。这也是为什么机器学习最近很火的原因之一。

钱多事儿少的结果,是很多一流的程序员和工程师在工业界没有足够多的一流的事情可以做。毕竟科研想新想法不是工业界擅长的事情;大部分人没有受过专业训练,这也不是工业界的追求和定位。

而对于受过训练的人,正好,有闲可以玩科研。

以兴趣来科研,关键在于建立严格的自我激励。(否则有闲就都玩游戏去了。)所以,也要有观众,也要讨好观众。互联网其实给了一个这样的平台。

更重要的是要接受事实和逻辑上的检验。

这就首先要让互联网上的观众有能力检验科研结果中的事实和逻辑。

这本身也是一项科学技术,一项本质上甚至属于哲学领域的科学技术。

这技术就将是我这几年挣钱养家之外要做的最重要的事情。

其实这本是学术圈里的人应该做的事情。但学术圈的游戏规则已经形成,而在游戏规则之中挑战游戏规则本身,是个很难的事情,要花很长的时间先按照游戏规则爬到一个比较安稳的位置,要处心积虑忍辱负重地过6年,实在是太累了。搅局的事情,还是从外面来进攻更容易一点。

嗯,文章写在这儿了,算是自己对这个世界的一个承诺。试试看吧。咱走着瞧。

Coding Dreams

I somehow ran into this page of Bret Victor‘s again.

I love it and hate it.

I love it because it shows a very beautiful vision.

I hate it because what is shows has really nothing similar to the programming I do everyday.

Bret is a guy that works more on the design side. I appreciate that he pointed out pretty accurately the pain points of programming.

However, it is like one of those very deceitful sales talks, that tells you that just two thing: first, your life is shit; and second, now imagine that what would be like if it is wonderful. And they tell you: yes, you can!

It is like dreaming. It makes you feel good, but it does not give out a god damn solution. Just never.

The page gives some examples illustrating the principles.

And here is my question: how to apply these principles to a real system project of 10000 lines of code, say a lab OS project like OS/161 or xv6? How would you visualize the code for an interrupt handler?

Or, how to apply these principles to all the algorithms in The Art of Computer Programming? How would you automatically illustrate an algorithm, draw the trees for trees (like B-tree), the graphs for the graphs (like Dijkstra), and the state machines for the state machines (like KMP)?

It is very hard.

Coding is not just drawing lines and rectangular. The underlying objects are often interacting in a non-linear fashion, even when the code has no goto’s.

Bret renders the problem as if programmers do not really recognize the principles. That is probably not the truth. Programmers might had never illustrated them as clearly as he did, but they recognize them implicitly by going through all the painful engineering, sometimes more lively than anyone else. The real missing part is the technology that can make all kinds of computer programs human comprehensible.

I appreciate Bret’s vision, and the presentations are also very well crafted. It makes more people pay more attention to the problem. However, the presentation also often gives people the illusion that the basic technology is already there, ready for use, and his vision is the critical missing point. That’s probably not the truth; the technology is still missing (though we are moving there slowly). I wish Bret could be just more clear and honest on this issue. As an example, he clearly spent a lot of efforts behind the scene on designing his demo so that they work beautifully, but he never talked about his efforts to build his presentation and it makes people feel like it is effortless. It is just so illusive, almost dishonest.

And he is asking people to invent new data structures that can be easily visualized. What if 2-D visualization at scale for programming logic of good utility is fundamentally an NP-hard problem? He says that programming has to be changed fundamentally. If so, Bret, could you please design, or at least give a presentation on how to design, something real, fundamental and has some moderate complexity, like a simple operating system and a simple compiler that can host themselves, yet every structure/data in the OS and compiler can be visualized under your principle?

Bret, what makes you believe that your vision is even possible? Where is the path? Where should the engineers start? Anything concrete?

I feel like I am such a hater now…

I don’t hate dreams. I just hate people talking about dreams but not clear about how real it is in its presence. I hate advertising dreams as if it could be reality already. These people harvest respects and attentions, steal all the credits (because their dreams seem so beautiful), yet provide no logical solutions on realization. They emphasize on what things should be, but talk too little about if it can be. It is unfair to the ones who will go deep into the problem and try to do the actual hard work but eventually might fail miserably (like Light Table and all people that funded it); they should have been better warned.