王垠：我和Google的故事

shang2010

有影响力impact{:3_203:}

folklore

回复 8# KanonInD


    因为他要写的是类编译器的东西，
无类型是对用户而言的，编译器需要知道类型,就算这个类型是可以动态变化的，和C++的Virtual一样

4000行一个Parsor，的确是个牛人了。
随便写个玩具都上这个规模的泪奔。。。

感觉不像在米国，
像是中国Google的样子（国内的服从文化）

captivated

回复 8# KanonInD


    鸭子类型... "如果一个东西走路像鸭子, 叫声像鸭子, xxx像鸭子, 那么它就是一只鸭子"的说法么.
    可惜... python的用户是"鸭子类型"的用户, 而此文的作者是要实现鸭子类型这种类型模型本身的类型推导. 人家是在实现语言类型模型本身的反解析...

狗蛋

KanonInD 发表于 2012-08-14 11:57
(python的)鸭子类型有什么不好, 为何需要类型推导?

python的duck type本身没什么不好，不过它必须要在运行时环境里、运行到的那一刻才能知道被调用的方法存不存在、来自何处。

对编辑器及其用户（程序员）来说，他们看不到动态的东西，只能看到静态的代码。那么，具体到一个方法究竟由谁提供，哪怕是程序作者自己恐怕都无法立刻回答。

一般的编辑器实现类似正则表达式模式匹配：你调用了to_str()，它就找所有提供了to_str()的类；这样大多数情况下能工作，而且不需要多少代码就能实现。
但恰恰对to_str()，这个办法失效了。因为这个方法每个类都有，全列等于没有列；而对method proxy这类应用，它提供的很多方法根本不可能从代码上看到。这就相当于在静态分析时丢掉了一个关键环节。


为解决以上问题，字符串匹配法同样有可能解决；但这样就要穷举匹配各种可能，相当于人工分析代码、并通过前后对比以找到线索，去回答“哪些to_str和当前代码行无关”和“这个proxy究竟提供了哪些方法”问题。

这种做法可行，但非常笨拙，好像杀牛用了水果刀，代码量自然飕飕就上去了，bug也肯定是一出一大坨。


此文作者相当于实现了一个能静态推导运行时类型的预处理器；这个实现提供的能力类似运行时，但无须真正执行程序（那样代价就太大了）。
大概思路就是写一个编译器去检查类型如何“传染”出去。这样，当你查询某个对象的to_str()方法时，他就可以根据“传染逻辑”反推，告诉你这个方法只可能来自哪些类；类似的，对一个method proxy类，他也能回答“根据目前的程序逻辑，这个类能提供哪些方法、这些方法都来自何处”。

这样一来，动态类型的语言一样可以像静态强类型语言一样，在程序编写的同时就得到丰富的方法/类型/参数提示。这种功能，显然是基于模式匹配的手段绝对无法达到的。

这个“静态代码分析”的做法比起字符串模式匹配，起始代码量大，类似杀鸡用牛刀；但遇到棘手的to_str/method proxy之类情况时，反而非常轻松，因为用对了工具。

flw

牛人就不要打工，打工就意味着受气。

xcodeman

回复 15# 狗蛋


    太专业了

windoze

还真没想通怎么对这样的代码做类型推导：

1. s=eval(sys.readline())

复制代码

Python这种动态类型语言，静态分析基本上就是白费工夫

王同学显然非常看不上Google的Staff Engineer，作为一个Fortune 500的前Staff Engineer，偶的鸭梨山大啊……

folklore

回复 18# windoze


    王同学不用管这个表达式吧

chinesedragon

是清华退学的那个王同学吗？
看他写得自己这么牛，那现在在做什么呢，好像没有他的消息了吧。
牛人怎么可能没有动静呢

aychxm

回LS，其实人家还是有动静的
http://blog.sina.com.cn/s/blog_5d90e82f01018byh.html
这篇博文不错！