王垠（人物）

王垠在自己的 BLOG 《编辑器与IDE》里很推崇 JetBrain 的产品，他写 java 代码用的是 Intellij IDEA，王垠很认同「结构化编辑器」的理念，JetBrain 的产品也都符合这个理念。王垠一篇 2013年的 BLOG 《What makes Python static analysis hard and interest… 显示全部

发布于 2015-11-01

关注问题 8 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 4

如何评价《王垠：C 编译器优化过程中的 Bug》？

20

Wish Night 一|颗|赛|艇

20 人赞同

这次纯技术讨论，觉得说的很对啊。编译器测试很重要的，PLDI，OOPSLA，ICSE近几年都有论文。因为优化开一多，不同的优化相互影响会带来大坑。看那些bug都是非常莫名其妙的，单跑一个pass都没问题，组合起来就崩了。Zhendong Su 老师做过一系列研究，找了gcc… 显示全部

发布于 2016-10-13

关注问题 6 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 5

如何评价王垠的文章《我为什么不在乎人工智能》？

280

陈然机器学习、数据挖掘话题优秀回答者 Tubi 旧金山北京…

收录于编辑推荐 •280 人赞同

机器学习对世界的改变之大，是不能忽视的。但人们却容易低估已经被创造出来的东西的智能程度。要是十年前说自动驾驶，一定觉得那是人类智慧集大成才能发明的东西，说电脑围棋打败人类，一定是机器的掌握了一种极为先进的学习方法。突然间这些我们都做到了，但是突然间大家都觉得这些成就是 Trivial 的了。自动驾驶仅仅是图像识别的进步，AlphaGo 也仅仅是暴力搜索的升级，任何智能的进步一旦被创造出来，就不再智能了。人工智能的进步变得毫无惊喜，未来依然遥不可及。真是这样吗？当然不是，我们的世界已经被算法改变的太多。我们的阅读大部分来自 Facebook（今日头条） 的机器学习算法推荐，听的音乐来自 Spotify（网易音乐） 的机器学习算法推荐，购买的东西来自 Amazon（淘宝京东） 的机器学习算法推荐。我们已经生活在了一个几乎完全由算法来决定的世界，机器学习已经完全改变了我们的生活。对于人工智能的发展特别容易走两个极端，过于狂热或者过于悲观。但这都有一点迷思往往是共通的：人们对于人工智能的期待总是喜欢对标人类的智能，认为只有像人类那样归纳和演绎才是智能的表现。然而这种期待是错误的，机器智能不会是一种像人类智能成长方式来成长的。正如我在<a href="https://www.zhihu.com/question/29350212/answer/148274613" class="internal">这一波人工智能泡沫将会怎么破灭？ - 知乎</a> 中提到的：机器智能的发展，是渐进的，是被广泛应用的，是永远不会后退的，并且是普通人难以察觉的。话说回来，倘若你也经历过机器学习的模型上线，取代人类的经验系统，带来 KPI 翻5倍，或者营收翻翻，这样的巨大震撼体验的话，或许你也会像我一样，由衷地认为机器学习的应用前景广阔，激动不已。倘若当初王垠能够坚持学习人工智能，早日投入工业界做应用，恐怕早已功成名就，扬名立万，成为人工智能第一吹了。----<a class="member_mention" href="//www.zhihu.com/people/e0b5a47e889233397702282b0cc705bf" data-hash="e0b5a47e889233397702282b0cc705bf" data-hovercard="p$b$e0b5a47e889233397702282b0cc705bf">@陈然</a>

机器学习对世界的改变之大，是不能忽视的。但人们却容易低估已经被创造出来的东西的智能程度。要是十年前说自动驾驶，一定觉得那是人类智慧集大成才能发明的东西，说电脑围棋打败人类，一定是机器的掌握了一种极为先进的学习方法。突然间这些我们都做到了，… 显示全部

编辑于 2017-04-28

关注问题 54 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 6

怎么评价 Yin 语言设计者王垠公开征女性粉丝的行为？

270

匿名用户

270 人赞同

函数式编程是没有对象的 ~~~ 显示全部

发布于 2014-09-04

关注问题 12 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 7

如何评价王垠的《Swift 语言的设计错误》？

15

知乎用户装逼与打击装逼者是我上知乎的乐趣

15 人赞同

放在C++里，就是要实现const 引用不能调用非const成员函数。 也就是禁止const Class &amp;b = a;b.set(X);这样的语句。 但是Swift里面let的语义是这样：Class&amp; const b = a;//我故意把&amp;跟Class写一起了，因为Swift里面没有显性的引用，或者说都是引用 这就尴尬了，因为被禁止的只是b=c这种语句，而b.set还是随便调用。这跟我预想不一样啊，怎么办呢？ 于是苹果大神想了一种方法，对于某些类，它们比较常用，也经常用于存常量，就让他们作为值来传递，比如数组，把上面的Class&amp;整个替换成Array，写下Array b = a;的时候b整个就是一个常量，不能调用任何非const方法（[]=可以看作set(index, value)方法），当然b=c也是不允许的。 目的达到论了，似乎挺和谐。 但是这么做引来一些问题。 一是王神所说，数组这么大，靠值传递会引发严重的效率问题。这个Swift采取的解决方案是copy-on-write，简称cow（母牛）。线程安全与多核并行问题暂且不论，在C++里面，cow是非常蛋疼的，因为[]无法区分左右（可以参考下map里面的[]操作，不管是get还是set都会给你insert），导致c = str[5]这样的表达式也能触发cow。事实上string的复制效率非常高，一般都会用memcpy实现，并且如果我不想复制直接用const string &amp;就行了，需要复制的时候早晚也要复制，还能自己觉得早还是晚，cow完全是自作多情的做法。然而某些C++编译器似乎一意孤行的使用这项在VS2003时代就放弃了的“技术”，果然C++是装逼乐园。 TMD扯远了，一黑就收不住。总之cow是蛋疼的东西，没有任何效率优化，却增加了程序员的思考负担。王神在博客中用的一个词非常好——削足适履。 第二个问题是把Array当值传递使得语义不那么统一。类型分为两类：不可变类型，包括C中的int, double, Java/Python中的字符串，他们除了用赋值之外没有任何改变自身值的方法；可以改变的类型，包括各种自定义类，数组，它们可以通过某种操作改变自身，比如set方法，比如[]=的操作。如果前者按值传递，后者按引用传递，那么这种传递方式可以看成所有对象都是引用传递（赋值可以看成改变引用，参见<a href="//link.zhihu.com/?target=http%3A//www.yinwang.org/blog-cn/2016/06/08/java-value-type" class=" wrap external" target="_blank" rel="nofollow noreferrer">Java 有值类型吗？</a>）。无端的让数组值传递，破坏了上述统一性，也使得数组从“可改变对象”中割裂，为什么偏偏是数组，其他类对象怎么不这么搞？ PS：C的传递方式非常统一，都是值传递；C++的分为引用和值两种，不过都是显式声明的，也无可厚非；C#就不那么统一了，既有值又有引用，光看var b = a不知道是怎么传的。 问题之三还是王所说，value type并没有带来多少效率的提升，却大大增加麻烦。在这里不得不黑一波Rust，这货号称比C++安全……个屁！用了各种关键字，各种符号，各种库，就是为了实现C++里面的各类智能指针，同时各种指针本身的问题一个也没避免，租借move之后只能有一个在用（unique)，RC不能循环引用(shared)，非线程安全，再加上unsafe(raw pointer)，根本就是比C++没有一丁点长进，完全是一厢情愿，倒也有mozilla的作风。 回到问题。有人可能会问，既然你说这么做不好，那应该怎么做？我的看法，一是引入新关键字，如C++的const，C#的readonly，禁止一切改变类成员的行为（数组元素可以看成数组类的成员）；二是像Java/Python/C(89)那样，放着不管，不提供保护措施，你爱改就改出了问题自己负责。两种方法都能保证语义的统一性，前者稍微复杂，能满足强迫症需求；后者更加简洁，代价是几乎为0的出错几率。 iOS9变卡不是没有原因的。

放在C++里，就是要实现const 引用不能调用非const成员函数。也就是禁止const Class &b = a;b.set(X);这样的语句。但是Swift里面let的语义是这样：Class& const b = a;//我故意把&跟Class写一起了，因为Swift里面没有显性的引用，或者说都是引用这就尴尬… 显示全部

编辑于 2017-03-24

关注问题 14 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 8

如何看待王垠的《微软感受》？

81

徐汉彬程序员，技术博客：http://hansionxu.blog.163.com/

81 人赞同

我在学生时代，曾经度读过王垠的博客，直观感觉，才华横溢，锋芒毕露。 现在时间过去好多年，我也毕业工作了好多年，回头一看，王垠的才华和性情一如当年。他是非常优秀的天才型技术高手，但是，多年的工作经历让我明白一个道理，大公司里很多大型的项目不仅仅只需要技术，虽然，技术是非常重要而核心的一环。 在大公司里： 1. 技术项目通常服务于业务场景，通过技术手段解决业务问题，才是技术的价值体现。 2. 大型项目是一个庞大的分布式系统，数以百计的服务和存储以某种架构模式组合在一起，里面的代码量和工作量不是一个人可以完成的，它是以一个开发团队的模式来维护和迭代开发的。因此，团队合作和沟通技巧是一项基本技能。 3. 不同系统之间的通信和交互，又会产生很多跨中心、跨部门、跨公司等联调和接口通信，这里又会涉及更为复杂的人员沟通和项目协调，合理和低成本的技术对接方案，良好的沟通和协调能力，都是比较重要的。另外，通过人格魅力、技术水平或者其他方式，来影响和带动团队其他成员，获得他人的认可和支持，是非常重要的。能够有效获取他人的帮助，也是一种能力。 4. 系统和系统之间，技术人员和技术人员之间，会存在大量的协作。这种协作越复杂，沟通和系统之间的对接成本越高，通过合理的架构设计、人员分工和研发流程规范，尽可能减轻这类型的协作成本。例如，系统之间合理划分以某种通信规范降低接入成本（SOA、微服务），在研发流程中引入发布评审（评审新发布项目对原系统、用户和进度的影响，更好地规避和把控发布风险）。 ... ... 仅仅只有个人的技术，我们是无法完成全部工作，也无法解决所有问题。 <blockquote>有人常说，在大公司里，每个人都是一颗螺丝钉。</blockquote>我们以此为例子来看，不同阶段需要怎样的能力去解决不同的问题： 第一阶段，做一颗好的螺丝钉。（主要依赖个人良好的技术水平） 第二阶段，搞明白这颗螺丝钉和其他螺丝钉的协作方式，并且尝试优化它，让它更高效。（依赖个人技术水平、团队沟通、多人协作能力） 第三阶段，向其他螺丝钉发出沟通和协调，尝试优化这一批螺丝钉的协作方式。（团队协调和架构设计） 第四阶段，将这些螺丝钉组合为一个有机的零部件整体，高效为其他零部件提供有效服务，并且，改进零部件和零部件之间的协作效率。（业务和技术的架构设计，外部协作、协调和推进能力） ... ... 诚然，我们在实际的工作中也没有这么清晰分明的所谓“阶段”，有一些非常资深的技术高手，在某一个细分的具体领域深入研究，并不需要复杂的多人协作，个人将某个细分的公共基础服务做得非常好，然后，被大量的业务和系统广泛使用，这个也能产生非常大的价值。 在大公司里，个人的技术水平无法解决所有问题，“人的协作”（情商）是个重要的因素，不能被忽略。 腾讯公司内部的资深专家们，通常都是以整体业务架构和公共研发体系建设的维度来解决问题，支持业务和技术的发展。 王垠是个天才型的技术高手，他有他所擅长的领域，祝福他能找到自己擅长并且喜欢的东西。 祝愿他前程似锦，事业顺利。

我在学生时代，曾经度读过王垠的博客，直观感觉，才华横溢，锋芒毕露。现在时间过去好多年，我也毕业工作了好多年，回头一看，王垠的才华和性情一如当年。他是非常优秀的天才型技术高手，但是，多年的工作经历让我明白一个道理，大公司里很多大型的项目不… 显示全部

编辑于 2016-10-30

关注问题 8 条评论感谢收藏 • 没有帮助 • 举报 • 申请转载

Question 9

如何评价王垠最新博文《美国公司管理层常用心理技巧》？

9

硅谷老实人 2017年死于徐白左江

9 人赞同

你这么打广告，我也就不客气了。关于王垠的讨论可以移步boism org。绝不删帖显示全部

发布于 2017-04-18

关注问题 14 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 10

如何评价王垠的新文章，《给Java说句公道话》？

74

Belleve编程话题优秀回答者微软字体设计师；新中文字体主催

74 人赞同

黑 java 的（比如 @赵劼）都是黑 java 使用繁琐、Type Erasure 导致不一致、Checked Exception、没有运算符重载之类，几人天天扯「java 不是动态类型」了？显示全部

编辑于 2016-01-20

关注问题 26 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

Question 11

如何评价王垠新博文《我看自动驾驶技术》？

19

薛迟汽车话题优秀回答者奥迪自动驾驶研发工程师

19 人赞同

谢谢邀请！ 提到自动驾驶，在中国道路上测试包括媒体展示已经有一段时间了。谈谈自己看法，真理不辨不明。欢迎参与讨论与交流: ) 首先又是定义，国际上有分类标准，但有些关键问题比如责任划分仍然不清晰。国内对自动驾驶，无人驾驶的定义和分类标准的起草也在刚刚起步阶段。 比如叫做“自动驾驶”（Autopilot）功能的特斯拉算不算真正意义的自动驾驶，这一点上我同意作者观点。具体解释可以参考: <a href="https://www.zhihu.com/question/36884389" class="internal">辅助驾驶功能与自动驾驶有什么区别？特斯拉的 7.0 是否可以算作「自动驾驶」？ - 特斯拉汽车 (Tesla Motors)</a> 整体看这篇文章比较保守，因为自动驾驶这东西还没出来，谁也不好说到时候出不出的来。 但是随着驾驶员辅助系统的日趋成熟，稳定性可靠性有了质的飞跃，由智能汽车产业带动的新型传感器（摄像头，激光）发展迅猛。作为研发工程师，我更加相信，真正意义上的自动驾驶并不远。 自动驾驶一定会经过一步步的演进过程，从最基本的驾驶员辅助系统（自适应巡航控制、车道保持）到高级的驾驶员辅助系统（拥堵驾驶辅助）再到真正意义上的有条件的自动驾驶，最终发展到全自动驾驶（无人驾驶）。 每一代产品也都实现了从功能到性能再到智能的发展。 一代一代的传感器、控制算法改进并流传下来，变的更可靠，价格更低。 当然IT企业可以挂个几十万的Velodyne 360度激光扫描传感器去做实验，那量产的时候呢？不得不说，整车OEM和供应商在传感器研发上做出了巨大贡献，当然也不否认谷歌在程序算法上的领跑位置。 关于A.I.，最近看到非常多的讨论，大概是因为AlphaGo。按照文中的逻辑确实几百年也出不来自动驾驶。 但是，仔细想过么，实现自动驾驶真的需要人工智能吗？ 自动化==人工智能？ 显然不是，现在实现的自动驾驶，甚至无人驾驶基本不包含人工智能，或者很少。 因为自动控制系统需要的是一套算法，应对不同工况和环境。给定输入就会有确定输出。比如什么时候加速减速，加速度是多少；什么时候转向，转多少。都是设定好的。当所有的工况都被变成代码和参数，当所有的逻辑都经过调试优化后，这就是一套完善的自动驾驶系统。 各家跑的路试数据还是需要人来分析，找到问题，用于修改代码优化参数。这里并没有A.I.什么事。或者说这些数据并不是用来做机器学习的。 那A.I.可以干什么？在自动驾驶上，最先应用人工智能的恐怕是传感器的环境感知，比如图像识别，自学习过程会让识别变的精确可靠。但如果把人工智能引入控制就会困难很多，因为你要让机器帮你决策了。很多时候你给了确定的输入，输出是不一样的，或者你其实也不确定它一定会输出什么。就像一个人学开车，新司机和老司机肯定不一样。人工智能发展还在起步阶段，我相信将来，人工智能会带领自动驾驶一起飞，但显然没有人工智能，自动驾驶照样能飞起来。 最后，新事物要来的时候谁也挡不住，还不如好好迎接~

谢谢邀请！提到自动驾驶，在中国道路上测试包括媒体展示已经有一段时间了。谈谈自己看法，真理不辨不明。欢迎参与讨论与交流: ) 首先又是定义，国际上有分类标准，但有些关键问题比如责任划分仍然不清晰。国内对自动驾驶，无人驾驶的定义和分类标准的起草… 显示全部

发布于 2016-04-02

关注问题 7 条评论感谢收藏 • 没有帮助 • 举报 • 申请转载

Question 12

如何看待王垠的《关于测试的道理》？

44

胡大狗 Server-side Kotlin 汪汪汪

44 人赞同

同意一部分条目。文末提供的案例非常精彩！ 你们还是要多学习一下。 然后我对这篇文章来条分缕析一下： 测试的道理： <blockquote>1. 不要以为你处处显示出“重视代码质量”的态度，就能提高代码质量。</blockquote>+1！有态度无能力 =&gt; 教条主义。 <blockquote>2. 真正的编程高手不会被测试捆住手脚。</blockquote>持保留意见。人非圣贤，高手也有糊涂的时候。 <blockquote>3. 在程序和算法定型之前，不要写测试。</blockquote>+1！如果你在写一个要反复推倒重来的程序，先写测试就是浪费。不要拘泥于教条。 <blockquote>4. 不要为了写测试而改变本来清晰的编程方式。 结果你就发现这程序里每个类都有一个配套的 interface，还需要写另外一个 mock 类，去实现这个 interface。</blockquote>+1！反对每个类都配一个interface，铺张浪费。 <blockquote>5. 不要测试“实现细节”，因为那等同于把代码写两遍。 测试应该只描述程序需要满足的“基本性质”（比如 sqrt(4) 应该等于 2），而不是去描述“实现细节”（比如具体的开平方算法的步骤）。有些人的测试过于详细，甚至把代码的每个实现步骤都兢兢业业的进行测试：第一步必须做A，第二步必须做B，第三步必须做C…… 还有些人喜欢给 UI 写测试，他们的测试里经常这样写：如果你浏览到这个页面，那么你应该在标题栏看见这行字……</blockquote>+0.5！90%正确，10% depends。 <blockquote>6. 并不是每修复一个 bug 都需要写测试。</blockquote>+1！不要在技术界搞『两个凡是』。 <blockquote>7. 避免使用 mock，特别是多层的 mock。</blockquote>+1！过多的mock即使在TDD中也属于反模式。 <blockquote>8. 不要过分重视“测试自动化”，人工测试也是测试。</blockquote>持保留意见。自测无所谓，上规模的测试还是要自动化的吧，自动化是大趋势啊。 <blockquote>9. 避免写太长，太耗时的测试。</blockquote>+0.5！若实在无法避免，建议耗时的测试不要频繁运行。 <blockquote>10. 一个测试只测试一个方面，避免重复测试。</blockquote>+1！是这样的。重复的后果是又多了一笔legacy code in test。 <blockquote>11. 避免通过比较字符串来进行测试。 </blockquote>持保留意见。比较字符串方便啊，看实际效果决定吧，可不能往反方向搞教条哦。 案例： case Google <blockquote>如果我当时按照 Google 队友的要求，采用已有的开源代码，或者过早的写了测试，别说无法在三个月的实习时间之内完成这个东西，就算折腾好几年也没有可能。</blockquote>能否实现都不知道，就惦记着写测试，岂不是本末倒置。而且我搞过类似东西，确实很难写测试。 case Shape Security <blockquote>队友们听说我花一下午重写了一个换名器，非常紧张，咋呼地跟我说：“你知道我们的换名器是花了多少个月的时间做出来的吗？你知道我们写了多少测试来保证它的正确性吗？你现在一下午做出来一个新的，你如何能保证它的正确！”</blockquote> 即兴给这种场景起个名字——“人月教条”。 <blockquote>在这个项目中，由于代码的改动幅度很大，在同事和部门领导的理解，信任和支持下，我们决定直接抛弃已有的测试，完全靠严格而及时的 code review，逻辑推理，推敲讨论，手工试验来保证代码的正确。</blockquote>《代码大全》告诉我们，大多数缺陷发现于code review阶段。这个案例符合软件工程实践。 case Coverity <blockquote>本来很明显的一个图论算法问题，加一个“&amp;”就修好了，手工试验也发现问题消失了。然而 Coverity 的测试教条主义者们（包括写出这 bug 的那人自己），吵着闹着，严肃命令我必须写出测试，构造出可以造成这种后果的数据结构，确保这个 bug 不会再重新出现。为一个我根本不会犯的错误写测试，而且它不可能再次发生，这不是很搞笑吗？就算你写了测试，也不能保证同样的事情不再发生。如果你不小心漏掉“&amp;”，下次同样的问题还会发生，并且发生在另外的地方，而你却没有给那块代码写测试，所以给这个 bug 写测试，并不能防止同样的问题再次发生。这就像一个技术不过关的赛车手，他在别人不大可能撞车的地方撞了车，然后就要求赛场在那个地方撞上轮胎护栏。可是下一次，这个车手又会在另一个其他人都不会撞车地方撞车……</blockquote>一针见血，这种情况的正确测试方法应为静态检查，一家生产静态检查工具的公司竟然不懂这个道理，呵呵。 大量的测试只是从0到N，可谁能完成从0到1的测试呢？ 最后，我的理解浓缩成一句话：用心对待你的工作。 答案备份在『轻境界』： <a href="//link.zhihu.com/?target=http%3A//www.qingjingjie.com/blogs/21" class=" wrap external" target="_blank" rel="nofollow noreferrer">评论《测试的道理》</a>

同意一部分条目。文末提供的案例非常精彩！你们还是要多学习一下。然后我对这篇文章来条分缕析一下：测试的道理： 1. 不要以为你处处显示出“重视代码质量”的态度，就能提高代码质量。+1！有态度无能力 => 教条主义。 2. 真正的编程高手不会被测试捆住… 显示全部

编辑于 2016-09-16

关注问题 7 条评论感谢收藏 • 没有帮助 • 举报 • 作者保留权利

王垠（人物）

王垠为什么不研究区块链技术？

如何评价《天才是不存在的》？

王垠的水平和 JetBrains 比如何？

如何评价《王垠：C 编译器优化过程中的 Bug》？

如何评价王垠的文章《我为什么不在乎人工智能》？

怎么评价 Yin 语言设计者王垠公开征女性粉丝的行为？

如何评价王垠的《Swift 语言的设计错误》？

如何看待王垠的《微软感受》？

如何评价王垠最新博文《美国公司管理层常用心理技巧》？

如何评价王垠的新文章，《给Java说句公道话》？

如何评价王垠新博文《我看自动驾驶技术》？

如何看待王垠的《关于测试的道理》？

加入知乎

与世界分享你的知识、经验和见解

描述

父话题

王垠（人物）

加入知乎

与世界分享你的知识、经验和见解

登录知乎

与世界分享你的知识、经验和见解

描述

父话题