下次自动登录
现在的位置:
& 综合 & 正文
正确实现 IDisposable 接口
正确实现 IDisposable
.NET中用于释放对象资源的接口是IDisposable，但是这个接口的实现还是比较有讲究的，此外还有Finalize和Close两个函数。
MSDN建议按照下面的模式实现IDisposable接口：
1 public class Foo: IDisposable 2 { 3
public void Dispose() 4
Dispose(true); 6
GC.SuppressFinalize(this); 7
protected virtual void Dispose(bool disposing)<span style="COLOR: #
{<span style="COLOR: #
if (!m_disposed)<span style="COLOR: #
{<span style="COLOR: #
if (disposing)<span style="COLOR: #
{<span style="COLOR: #
// Release managed resources<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
// Release unmanaged resources<span style="COLOR: #
<span style="COLOR: #
m_disposed = true;<span style="COLOR: #
}<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
~Foo()<span style="COLOR: #
{<span style="COLOR: #
Dispose(false);<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
private bool m_<span style="COLOR: # }<span style="COLOR: #
<span style="COLOR: #
在.NET的对象中实际上有两个用于释放资源的函数：Dispose和Finalize。Finalize的目的是用于释放非托管的资源，而Dispose是用于释放所有资源，包括托管的和非托管的。
在这个模式中，void Dispose(bool disposing)函数通过一个disposing参数来区别当前是否是被Dispose()调用。如果是被Dispose()调用，那么需要同时释放托管和非托管的资源。如果是被~Foo()（也就是C#的Finalize()）调用了，那么只需要释放非托管的资源即可。
这是因为，Dispose()函数是被其它显式调用并要求释放资源的，而Finalize是被GC调用的。在GC调用的时候Foo所引用的其它托管对象可能还不需要被销毁，并且即使要销毁，也会由GC来调用。因此在Finalize中只需要释放非托管资源即可。另外一方面，由于在Dispose()中已经释放了托管和非托管的资源，因此在对象被GC回收时再次调用Finalize是没有必要的，所以在Dispose()中调用GC.SuppressFinalize(this)避免重复调用Finalize。
然而，即使重复调用Finalize和Dispose也是不存在问题的，因为有变量m_disposed的存在，资源只会被释放一次，多余的调用会被忽略过去。
因此，上面的模式保证了：
1、Finalize只释放非托管资源；
2、Dispose释放托管和非托管资源；
3、重复调用Finalize和Dispose是没有问题的；
4、Finalize和Dispose共享相同的资源释放策略，因此他们之间也是没有冲突的。
在C#中，这个模式需要显式地实现，其中C#的~Foo()函数代表了Finalize()。而在C++/CLI中，这个模式是自动实现的，C++的类析构函数则是不一样的。
按照C++语义，析构函数在超出作用域，或者delete的时候被调用。在Managed C++（即.NET 1.1中的托管C++）中，析构函数相当于CLR中的Finalize()方法，在垃圾收集的时候由GC调用，因此，调用的时机是不明确的。在.NET 2.0的C++/CLI中，析构函数的语义被修改为等价与Dispose()方法，这就隐含了两件事情：
1、所有的C++/CLI中的CLR类都实现了接口IDisposable，因此在C#中可以用using关键字来访问这个类的实例。
2、析构函数不再等价于Finalize()了。
对于第一点，这是一件好事，我认为在语义上Dispose()更加接近于C++析构函数。对于第二点，Microsoft进行了一次扩展，做法是引入了“！”函数，如下所示：
<span style="COLOR: # public ref class Foo<span style="COLOR: # {<span style="COLOR: # public:<span style="COLOR: #
Foo();<span style="COLOR: #
// destructor<span style="COLOR: #
// finalizer<span style="COLOR: # };<span style="COLOR: #
“！”函数（我实在不知道应该怎么称呼它）取代原来Managed C++中的Finalize()被GC调用。MSDN建议，为了减少代码的重复，可以写这样的代码：
1 ~Foo() 2 { 3
//释放托管的资源 4
this-&!Foo(); 5 } 6
7 !Foo() 8 { 9
//释放非托管的资源<span style="COLOR: # }<span style="COLOR: #
对于上面这个类，实际上C++/CLI生成对应的C#代码是这样的：
1 public class Foo 2 { 3
private void !Foo() 4
// 释放非托管的资源 6
private void ~Foo() 9
{<span style="COLOR: #
// 释放托管的资源<span style="COLOR: #
!Foo();<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
public Foo() <span style="COLOR: #
{<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
public void Dispose()<span style="COLOR: #
{<span style="COLOR: #
Dispose(true);<span style="COLOR: #
GC.SuppressFinalize(this);<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
protected virtual void Dispose(bool disposing)<span style="COLOR: #
{<span style="COLOR: #
if (disposing)<span style="COLOR: #
{<span style="COLOR: #
~Foo();<span style="COLOR: #
}<span style="COLOR: #
else<span style="COLOR: #
{<span style="COLOR: #
try<span style="COLOR: #
{<span style="COLOR: #
!Foo();<span style="COLOR: #
}<span style="COLOR: #
finally<span style="COLOR: #
{<span style="COLOR: #
base.Finalize();<span style="COLOR: #
}<span style="COLOR: #
}<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
protected void Finalize()<span style="COLOR: #
{<span style="COLOR: #
Dispose(false);<span style="COLOR: #
}<span style="COLOR: # }<span style="COLOR: #
由于~Foo()和!Foo()不会被重复调用（至少MS这样认为），因此在这段代码中没有和前面m_disposed相同的变量，但是基本的结构是一样的。
并且，可以看到实际上并不是~Foo()和!Foo()就是Dispose和Finalize，而是C++/CLI编译器生成了两个Dispose和Finalize函数，并在合适的时候调用它们。C++/CLI其实已经做了很多工作，但是唯一的一个问题就是依赖于用户在~Foo()中调用!Foo()。
关于资源释放，最后一点需要提的是Close函数。在语义上它和Dispose很类似，按照MSDN的说法，提供这个函数是为了让用户感觉舒服一点，因为对于某些对象，例如文件，用户更加习惯调用Close()。
然而，毕竟这两个函数做的是同一件事情，因此MSDN建议的代码就是：
<span style="COLOR: # public void Close()<span style="COLOR: # {<span style="COLOR: #
Dispose(();<span style="COLOR: # }<span style="COLOR: # <span style="COLOR: #
这里直接调用不带参数的Dispose函数以获得和Dispose相同的语义。这样似乎就圆满了，但是从另外一方面说，如果同时提供了Dispose和Close，会给用户带来一些困惑。没有看到代码细节的前提下，很难知道这两个函数到底有什么区别。因此在.NET的代码设计规范中说，这两个函数实际上只能让用户用一个。因此建议的模式是：
1 public class Foo: IDisposable 2 { 3
public void Close() 4
Dispose(); 6
void IDisposable.Dispose() 9
{<span style="COLOR: #
Dispose(true);<span style="COLOR: #
GC.SuppressFinalize(this);<span style="COLOR: #
}<span style="COLOR: #
<span style="COLOR: #
protected virtual void Dispose(bool disposing)<span style="COLOR: #
{<span style="COLOR: #
// 同前<span style="COLOR: #
}<span style="COLOR: # }<span style="COLOR: #
这里使用了一个所谓的接口显式实现：void IDisposable.Dispose()。这个显式实现只能通过接口来访问，但是不能通过实现类来访问。因此：
<span style="COLOR: # Foo foo = new Foo();<span style="COLOR: # <span style="COLOR: # foo.Dispose(); // 错误<span style="COLOR: # (foo as IDisposable).Dispose(); // 正确<span style="COLOR: #
这样做到了兼顾两者。对于喜欢使用Close的人，可以直接用 foo.Close()，并且他看不到 Dispose()。对于喜欢Dispose的，他可以把类型转换为 IDisposable 来调用，或者使用using语句。两者皆大欢喜！
&&&&推荐文章:
【上篇】【下篇】温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(5717)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_082',
blogTitle:'C# IDisposable',
blogAbstract:'&&& C#中昂贵资源的释放是通过手工调用'
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}王垠谈编辑器与 IDE · Ruby China
还记得很久之前
写过一篇吐槽编辑器的文很好看...
上次大家在咖啡馆那次ruby tuesday，
说了一点编辑器的设想，不过好像和王垠角度不同，你看是否有借鉴意义？
至于“直接编辑程序的 AST 结构”，似乎IntelliJ系的IDE就是这么做的，我不知道王垠提的MPS系统是否和这个有关。
王垠粉还挺多的哈~
仿佛记得那个帖子里好像是围绕现有的一些编辑器实现总结了一下 ，从vim到emacs到textmate谈了谈一些实现间杂一些吐槽，很好玩..
不负责任的理解结构化编辑器就是把编译的中间结果暴露出来，多一个维度，显得更立体..从中间切进去来弥补一些不足..
哈哈 其实我是luikore粉
我没记错的话 《编程语言实现模式》里提过，ide的智能感知就是利用AST实现的
vim.很好用，就是debug和插件语言狠不爽。
另外不能多线程
我还是认为IDE速度太慢，说真的，我不希望IDE理解我写的代码，它理解就意味着运行速度会变慢，它理解的越是清楚运行速度就变得更慢，慢到让人难以忍受。
编辑器智能点没啥不好，不要慢到影响心情就行，其实理智的看，你看代码的时间更长，所以智能的编辑器如果能够自动标示出一些错误，总体还是节省时间的。
当然，能保证一蹴而就写出来代码就是对的，并且打字飞快的，vim还是最佳选择吧……
可以考虑升级下配置，这基本上都不是问题
代码应该在自己的脑子里，纯编辑器就很好，我是支持 VIM
目前rubymine 5.4 除去启动 使用上非常流畅
用编辑器要做加法，配置各种插件
用ide要做减法，去掉工作中不用的功能，我看做减法比做加法要容易
心情影响非常严重啊 有时候就是想做个小实验或是写段小脚本，VIM直接打开就能写代码了，IDE首先要等老半天打开，然后还要创建项目什么的，等到能开始写了，我用VIM写的脚本早就可以开始跑了。。。
已经是MacBook Pro，8GB的那种，如果这样的配置还满足不了IDE，那我只能说就和他没缘分了，白富美实在泡不起。。
哈哈， 你说的是rubymine吧？xcode在公司配的老爷机上跑得比较欢快的，或许应该说这只是暂时的问题~
嗯 被猜对了
不过以前在Linux上用Eclipse写Java也是非常慢的
《系统批量吐槽一下各种编辑器》 已经找不到了。
可不可以恢复一下？
唯独这次我完全同意王垠的观点。
文件较多时编程用IDE，服务器远程和小段程序或单文件一般用vim就够了。作为编程本身，IDE中很多功能确实不是vi/emacs这些能比的。我喜爱vim但从不迷信这个东西。结构化编辑器，intellij idea的mps和eclipse的xtext都在做。
我觉得, 王垠真的是很牛和牛!
牛的一塌糊涂...
不过, 有一点, 不知道出于什么原因, 我似乎没看到过他提起过有关 Ruby 的只言片语...
难道他没有用过 Ruby ? 如果是事实, 这应该是他最遗憾的事情了. (至少我替他遗憾...)
其实我用xcode的时候都用
把它搞成vim模式
感觉还挺爽的
如果xcode能够不那么容易crash掉
而且自动注释能够完善点的话就更完美了
一个读了十年书什么都没搞出来的人，可能是因为缺乏实际编程经验，所以对编辑器/IDE的看法接近我本科毕业的水平。
一句话说完：什么方便就用什么。
突然发现大一大二时候最早老师教我们用MinGW写C++，后来自己转到VS2008和VS2010，写PHP的时候也是用IDE的，至少那时我对IDE在速度上是没有任何抱怨的，但是自从进了Linux，在Eclipse上写Java之后，对IDE的速度问题越来越感到不满，之后一写Ruby立即扔掉IDE只用VIM了。工作后接触了RubyMine，试用了五分钟就扔掉了，跑得比Eclipse还慢啊。
所以说我后来接触的语言都是那种IDE比较慢的那种，这大概也是我现在只用VIM的重要原因吧。
话说王垠有github吗？只读过他很多文章却从未见识过他的代码，求拜读。
Jetbrains的IDE真是好用的没法说啊。
pycharm开发django，只要写好了url规则，按alt+enter自动创建view，在view里面按alt+enter自动创建模板，虽然django没提供rails这么强大的generate，但是pycharm可以弥补过来。
rubymine开发rails的各种贴心功能，各种自动创建。不过rails本身的自动创建命令已经够强大了，rubymine的贴心功能跟rails的贴心功能部分重复了。
刚刚看了个intellij idea开发struts2的视频，配置好struts.xml以后，package、action、model、class、method、jsp统统自动创建，什么mkdir、mkfile的全省了。
IDE不仅仅是写代码而已。她能做的事情很多，对熟手她是贴心的顾问，对新手她是循循善诱的老师
在IDE里面，写代码感觉已经不是在编辑文字，而是在操作一个构造精密的机械装置。
这有个他的github项目
(基于语义的diff)，还有就是给jython社区贡献的那个语法分析器
这里面是一个python的静态语法分析器。
他从事的研究领域是PLT，主要就是研究设计编译器和设计编程语言这些的，所以经常可以看到他挑各种语言的刺儿，呵呵。
盖茨他爹....
工具的代码生成确实挺容易吸引人的,可以提高效率, 有时候觉得不考虑可读性用zencoding写html和slim舒爽度差别也不大..
感觉编辑器和IDE哪个好就像sinatra和rails之争一样，有些喜欢简洁自己搭起来，有些可以忍受rails is omakase...
反正永远不会有统一的讨论结果...
应该是因为我孤陋寡闻，主要觉得这篇提出的解决方案挺有意思的，每一次对工具(编辑器，编程语言)灵活度的提升，应该都会是对创造力的一次推进...
好吧 可以理解
他提过ruby的
真的是只言片语哦
我也是刘核心的粉
是 吕 不是 刘 ；）
我在初学者或一些windows平台，常看到用Notepad++，我是没用过，但就单Notepad++作者是台独言论，就鄙视Notepad++。
Notepad++ 也不错，至少比 Win 自带的 Notepad 好太多了，编辑小文件啥的也很方便。
王垠有不少项目经验，如果我没记错，他在Google用scheme写过python的解释器和代码生成器。
你去翻一翻他的文章，再重新考虑一下你的看法吧。我觉得这是你最没有水平的一次发言，no offense。
人家还为你遗憾呢
这篇文章说得挺有道理的哈哈 我们的代码里有太多部分就是为了解决各种属性奇怪的nil之类的问题 初次以外 很多Rails代码也就是处理它方法所可以接受的各种options的形式，因为这些方法所能接受的参数实在太多种多样了，王垠说的这个问题的的确确是存在的。
我的看法是ruby和python没有一个类似接口机制约束输入，过于灵活不一定是好事
好在ruby 2.0加了命名参数，options可以去掉了
peg是什么？
看了一部分代码，没看懂，弱弱的问，Lisp/Scheme 会火么？
函数式语言一直不温不火，但是总体趋势是各种范式语言都在吸取函数式思想
我有认识一个做金融行业分析的lisper，据他的说法，sbcl的实现性能已经和c++差不太多了
命名参数是不是意味着要用一个参数还得在上面声明下，而且必须要赋一个默认值，即使那个是nil？
我也觉得要约束下，初次以外，也有必要进行适当的方法重载，让Ruby帮我们解决一部分参数处理的难题。
怎么可能火。。这么学术的语言，用户体验一塌糊涂的。
呵呵，有些人就是吃王垠这一套。
我很好奇，过去十年是不是只有他读博中退，是不是只有他研究编译器，是不是只有他喷这喷那。
这么迷信天才吗？这么迷信反权威吗？这么迷信颠覆几十年的成果？
别看他说了什么，看他做了什么：1、清华读博，中退了，他觉得自己做的事很没意义 2、出国到 Cornell 读博，又中退了 3、到 Google 实习，跟所有人搞得不开心，走了。4、写文章喷这喷那
我看到了什么，看到的就是失败。我不是看不起失败，而是他经历10年的失败还是那个调调：我太牛了，环境配不起我。10年都想不通这个问题，还持续的犯错，他还真牛呢。
哦，他终于开了个 github 帐号，让我们一窥他的：
(cps '(lambda (x) (if (if x (zero? a) b) c d)))
看到这段代码有没有发现什么？a b c d 是什么东西？哪个真实项目写这样的代码早被踢出去了。看得懂的不屑于看，看不懂的不明所以，哇好厉害啊。
他喷的东西毫无新意，每年有多少读书人和实习生在喷。建造一个有瑕疵但运行良好的系统比找出一个系统的瑕疵要难一万倍，苍蝇总是最会找腐烂的地方，但是苍蝇始终是苍蝇。
要粉他的，我不拦着。
道不同不相为谋
keyword arguments in Ruby 2.0
def foo(x, str: "foo", num: 424242)
[x, str, num]
foo(13) #=& [13, 'foo', 424242]
foo(13, str: 'bar') #=& [13, 'bar', 424242]
就是解决options的问题的...方法重载Ruby应该实现不了了，options本身也在解决一部分重载的问题
插一句：这玩意也是c# 4.0的特性，c#也是门很不错而且进取的语言
不能同意更多了！
嗯 我说的就是如果参数有几十种，量很大，那我在这里声明的时候是不是就要把他们全部声明一遍，还必须加上个默认值呢？
还有，方法重载为啥实现不了？只要参数可以约束，就可以了嘛。
当然，二义性的问题是存在的，这个可能要通过运行时报错来解决。
那样你应该考虑的是重新抽象你的类和方法。
为例，光文档里出现的render方法支持的参数就不下十种了，假如你现在用Ruby keyword arguments来实现这个方法(可能其中只有template和layout是有默认值的)，你如何抽象呢？
我还没开始研究2.0，但预感默认值不是必须的
参数几十种的情况我的感觉是函数的责任过重了，或许可以通过其他设计改善，但即使这样，也比options的方式把参数放到方法内部处理要强上很多
我同时粉你和王垠，希望你不要介意。哈哈哈哈
别捧杀我啊 @
其实不一定是函数责任过重啊，这个函数唯一的责任就是处理好各种options然后调用下一层的方法吧，这个不算重吧，Rails源码里很多方法都是为了做这件事情而存在的，核心内容其实很少啦。
Rails是所以好用其实也是因为API设计的很易用，而用户易用的代价就是很多代码要用来分析用户的参数，而且这些代码通常很丑陋很莫名其妙，但是如果没有这些代码，Rails也就肯定没有现在这么简单易用了，那样的话可能Rails就不会出名了。。
好像我们严重偏题了的说。。
(cps '(lambda (x) (if (if x (zero? a) b) c d))) 我连a b c d的声明都没找到。。。难道是全局？？
我觉得这是Rails设计的最糟糕的一部分。可能会带有一些历史遗留问题。
但是如果我来设计，我会把这些render分开：
render_partial
render_action
render_string
render_json
less magic, more clearly.
Rails的这个设计我倒觉得挺UNIX文化的 这一经典案例就是UNIX的read write系统调用了
算了 这个也不是很重要，我现在也看不出到底是Rails的抽象方法好还是你的抽象方法好。关键是Ruby作为动态语言，即使真有需要也可以用send解决，C就没有这种优势了。
这种代码应该比较偏数学推导吧 变量长短应该不是关键
额 可是我没找到这个变量的声明啊。。
不是很懂scheme 但是这一句是个测试 。cps是他实现的函数，后面的加了一个'表示quote，相当于用cps这个函数解析后面的字符串
应该是这样...
好吧 了解了
首先我没粉他。
且不说到他这个水平做普通的APP已经对提高技术水平没有什么实际效果，但的确在Google做出了一些好项目。
其一，作为一个做学术为主的人和一个做工程为主的人，对待代码价值的认同方式是不一样的。看某些工程成果的角度也不一样。做学术的习惯就是这么吹毛求疵，要去比较和研究那些常年没有答案的争论，以他的角色不能“什么方便就用什么。”这种答案，具体到个体工程师，某个项目，可以说什么方便用什么，这没错。但是谈论到普遍的事物时，想要得出更有价值的答案，他就不能这么说。
其二，说王垠粉，或者是他的文字，看不懂的时候调侃一下“垠神”，很多时候只是在开玩笑，并没有谁真当他是神，去迷信他。如果要反驳，也是有人写过深入的博文去反对他的看法，这种方式比较高级。
中文圈成「神」门槛低，写中文的占很大便宜。
'有人写过深入的博文去反对他的看法'——批评王垠的人多了，学术上有理有据反驳的我还真没见过，求传送门
发现大神大部分都在是讲一般人接触不到的东西~
zencoding写html和slim舒爽度差别也许不大，但是最舒服还是用zencoding 写slim……
唉，这个还是比较形而下的，王垠的学术热情并不在这里，我以为你说的是有人challenge 他写的代码（从学术上）呢
如果有兴趣，可以先从刘未鹏的几篇博文入手去科普
我是“粉”王垠，但是它表达的是对其能力的倾佩，如果我自己的水平也高到那样的地步，我也会“粉”自己的。:-)
每个人对失败的定义都是不一样的，你所列举的事实都是事实，它们在你眼里是失败，但在我眼里是一种理想情怀和完美主义，不是每个人都有勇气一而再，再而三地否定这些世俗所定义的成就的。（不代表别人的看法）
另外他的博客的文风也确实透着一股“我太牛了，环境配不起我”的调调，对此我都是捏着鼻子看的，但这对我来说只是情商略低的表现，虽有反感，但不至于成为讨厌其为人的根源。
最后给的代码，我看不懂。但这既然是一个解释器的代码，我想如果水平达到这种地步的话，区区几个变量也不至于把人难倒吧。
但我看得懂的其他文章，大部分都可以做到言之有物，有理有据，虽然里面洋溢着上面所提的文风，但还是有许多干货，每次阅读都可以给我很多启发和共鸣。为了自己更好更快地提高，所以我还是要继续粉他（你想拦也拦不住 :-D）
ruby-china的好处是，喷起来也比较文艺；我还是看看热闹，不发表言论了~
基本上赞同
王垠虽然语气很像国内的民科，但是人家是有真材实料的。
就算读不懂王垠的代码就喷他也是可以，因为
是另一个方向的牛人
你列出那行(cps '(lambda (x) (if (if x (zero? a) b) c d)))是测试用例，不拿这个说事，他牛的是指上面那40行。
正解。从第7行开始到第49行结束，牛的是这40行。好像是一个自解释的scheme解释器。
嗯。。。咱们的问题不上代码讨论不出啥结果来
不开放评论更无耻
说的对，每个人对成功和失败的定义不一样，如果从国人普遍认为的没有拿到文凭退学就算失败~~~那。。。。。。。
王垠粉.... - -! 关于新的想法, 说的人少, 做的人更少,, 所以我佩服王垠,
当然更希望他能做出可以把玩的软件出来印证他博客说的东西是真的
期待他的操作系统吧。hoho~~
v2ex、python-cn、ruby-china 等等他的每一篇blog都不会错过....难怪google要抛弃greader,人肉转播比rss厉害多了...
关闭评论的好，立马体现出来了
我都是把他的吹牛当作“来骂我啊来骂我啊,反正你也评论不了”解读的...
真的吗? 那我真是有幸了! 哈哈
因为前面 quote 了，a b c d 都不会展开
keso的博客上有，不要跟我谈客观，他的博客叫，当然我是在扯淡，所以，人家自己的地盘，爱怎么怎么着，您看了有什么判定是您老的事。
对于那四十多行代码的解释，看知乎的解释：
更多王垠的信息
他是个潜心做研究的理想主义者，兼且输出价值观。现今社会都以成败论英雄，像他这样的不多了。 喷的内容我不敢苟同，不明觉厉自然不好，无知无畏恐怕也不见得牛逼。
Doing is better than saying !!
不要认为搞底层就很牛，因为他们更擅长那些，也不要因为一些言论就 粉 谁，都没意义。
刚简单的翻了一下最近的博文，发现了这么一段
所以我认为脚本语言是一个祸害，它几乎永远是错误的决定。
我们应该尽一切可能避免使用脚本语言。在没有办法的情况下（比如老板要求），也应该在脚本里面尽可能的使用通常的程序设计原则。
不想过多的评论什么，对这样的言论也没什么评论的必要。
我比较同意
的观点， 调调 确实存在，问题随处都有，阮一峰的博文可以做为鲜明的对比。
还是那句老话
Doing is better than saying !!
唉，不看人家文章具体内容有没有值得借鉴的东西，老喜欢评论这个人怎么样，发现我们国家上至朝廷，下至普通百姓都喜欢诛心，这可不是好习惯哦。另外，知乎上面有人说过，王垠的人品还不错，周围的人员很好，不劳烦我们费心了，要驳就对着他文章的内容使劲的开炮吧。
+1，说的很对
搬家没网错过了 party 啊...
IDE 的做法是折中的: 内存中既保存文本又有 AST, IDE 追踪文本的修改然后尝试把 AST 的变化最小化. 但 parse 就是个世纪难题, 增量 parse 依然有很高的复杂度也很难并行化. 而且 CPU 的单核速度已经发展到极限, 没法再快了. 所以人们开发出二相着色和 flymake 等各种技术(自然会被科学家鄙视, 但是科学一直没发展, 怪谁呢)...
结构化编辑器的载体就完全是树, 保存的时候才生成文本或者干脆就不要文本了. smalltalk 时代结构化编辑器就辉煌了, smalltalk 就不谈文件, 谈 image... 现在所谓的 refactor 命令都是结构化编辑器上的基本编辑动作...
另外结构化版本控制工具没跟上的话, 结构化编辑器都还不够实用 -- 难道是变相给 ydiff 做广告?? (其实之前
提的 xib 版本控制问题, 如果 git 支持 ydiff 就直接解决了...)
其实我最喜欢经典编辑器... 就是在平面上搞文本. 高亮是通过词法为主, 语法辅助的方式做, 着色都是 "99% works and nobody complains"... 什么都能做还可以 out-of-box 的思考: 例如把 end 这个关键字编辑改成 endo 这个方法, 或者把整段代码用引号包起来, 或者为了对齐某个符号鼓捣一些奇怪的缩进和空格...
只是现在, IDE, 文本编辑器, 结构化编辑器已经没有明显的分界线了... 多多少少什么都有掺杂...
王垠学东西学得太多了，把自己都绕进去了，还不如当初没文化时候的观点鲜明，现在都没观点了，让人不禁想到王垠在国外的大学里是不是受到了某种惊吓
现在我在IntelliJ IDEA里面写Java，IDEA号称是比Eclipse还慢，不过在我8G，配备了SSD的MBP上运行起来一点障碍都没有，感觉完全和编辑器一样快啊。
额 你神马时候写回Java去了。。
那我只能表示RubyMine比IntelliJ和Eclipse都慢吧。。。
不要叫它ydiff，叫它tree diff
最早以前喜欢使用IDE是因为微软，开始放弃IDE而选择简单的编辑器的时候是因为Rails。
现在因为开发iOS又必须选择Xcode。
所以 我们没有机会选择。
别说这么难听好不，写回Java。其实以前没写过，现在做作业用。
你也在用IntelliJ啊。。。
哈 我们当年也做过这样的事情 不是还在SHLUG发帖找人培训嘛
花100刀買個好用的IDE，還是花幾小時設置一個好用的emacs或者vim.
我顯然花錢買時間。
然后再花几小时发现这个 IDE 干不了好多 vim 能干的事情...
我很少遇到vim能干同时Jetbrain系干不了而又很重要的功能
那我幹嘛買他？
買他肯定是因爲我要的功能都用了才買啊。哪有人買衣服是連標籤都不看的。
编辑器的争论为什么又开始了……
看了几篇，说实话有点失望……都是一开始给人眼前一亮的感觉，因为观点跟大众不同，行文风格自由。但每次我想继续往下看“为什么作者这样想”的时候……就没有然后了……
难道没有看广告觉得很强大, 买下来觉得也就那样的时候...
只要还存在编辑器这玩意，争论就不会停……
项目最开始的时候用vim写，代码多了以后就切换到了JetBrains的IDE。虽然输入上有很多不爽的地方，但各种贴心的提示还是能够节省不少时间的。有时候还得学会忽视一些比较严格或不者不够智能提示，还有封装比较多层的代码，IDE的语义提醒也完全失去作用了。
我第一次知道这个人，看了看他的最新一篇博文 关于go语言 ，对于“为什么作者这样想”，他在思维导图中解释得很清楚，他列出的关于go语言那些坏的、丑的、可怕的地方都一目了然的，还有是然后的。
可能他的思维导图随时在更新，过了就看不到他当时的想法了。
go的那篇文章我看过了，思维导图我就点进去瞄了下。因为对go没什么了解，就不说了。
倒是原先他写的那篇关于python等动态语言的文章我看过
那篇文章举了些在我看来比较怪异的比喻，其实本质上说的是语言太过灵活导致不好掌控。相比起来他更倾向Java那种更严格的语言。我觉得动态语言有相应的优势，比如可以省去为了不出错而做的各种接口定义，比如ActiveRecord那样可以做到定义一个空的class自动映射数据表字段，更多的就不举例了。
我很遗憾他没有看到这些语言特性在实际生活中带来的好处。照他的逻辑，Rails就是这个世界上最大的怪物之一……但Rails确实曾经改变了世界。
其实表达不同的观点也没问题，这个世界毕竟是多元化的，但我不喜欢的原因不在于此。
下面我简单分析下一个不懂 Python, Ruby, JavaScript的人看到这篇文章前后的想法：
网上都说Python好，这篇恰恰相反，观点新颖，从反方向看也许会有些收获。
虽然不懂Python，不过这个比喻还挺好懂的，三只手的人确实太怪异了。
原来Java这样严格定义数据结构的做法还有这个好处，以后还是用Java算了。
在我看来，这是一个经典的套路：先用新奇的观点吸引人，再用比喻模糊概念，最后得出“铁证如山”的结果。
你觉得这篇文章对一个想了解Python的初学者有帮助吗？
他并没有拿甚至一个Python代码片段来举例，讲下语言特性会在什么场景下造成什么样的影响。在对比下Java在同等场景下有什么优势。就是一个似是而非的比喻（还是特意丑化过Python）的。新手看完后根本就不知道Python的语言特性是什么，灵活在哪里。就无意识的接受了作者的理念 -- Python很危险，会造成“无穷无尽的烦恼和时间精力的浪费”。
我不反对主观。但我反对把主观的想法，经过一些似是而非的例子包装，最后生成一个看起来很客观的结果。
所以，如果我想学一些我不了解的技术，我不敢去参考他的博客。
我們是在討論如何看廣告么？
我就是python 初學者，我個人認爲那篇關於Python的很有幫助。如果學一門語言的時候只知道優點卻不知道缺點，我更不敢學。而且他的舉例我自己代碼工程中也遇到過。
所以我要學一些我不瞭解的技術的話，我更希望看了類似的介紹再決定。
我并不反对说一门语言不好，实际上很多黑Ruby的文章我也都看的津津有味。我更喜欢拿实际例子讨论语言的文章，而不是扯些虚的。也许我不大理解大神的抽象思维……
对比下老赵的这两篇，我更喜欢这种风格的干货：
其中第二篇还是个系列黑，但有理有据
搞学术的思维出发点不一样，我们做工程的，看看即可，不可当真，你让一个铸剑大师看一把明月弯刀他还可能勉强接受，但要他接受一对倒钩就太难了，这什么玩意儿？能刺吗？能劈吗？为什么不直？为什么没锋？…… 至于说瑞士军刀，就更是丑得不成样子了。
此人肯定不是铸剑大师，但也不是百晓生，如果你自己用倒钩用得正爽，何必在意别人嘲笑你的兵器丑呢？至于说初学者，挑选兵器时不舞那样几下，光听别人说，又有什么用呢。
你说的也有道理，领域不同看待事情的观点也不同。
@ darkbaby123 你觉得老赵有干货，那是因为你是码农他也是，并且他给出了代码；你觉的王没有干货是因为你觉得他没有提供具体的代码。是的，有点鸡同鸭讲的感觉。因为王是从事学术研究的，在PLT(主要研究的就是编译器和编程语言的设计)研究方面他很牛，说的东西还是值得一看的。我们是工程领域的攻城师，在学术领域内并非都是"shut up. just show me your code"准则,有时候很多问题用具体的代码根本说不清。
就从他批评python的这个问题具体来讲：他给python做了一些静态语法分析工具(例如pysonar)，他觉得之所以这么难做是python设计时一些人为的原因造成的，仅此而已。但这些问题不会丝毫影响到我们这些搞工程的码农，因为很多学术上理论上有缺陷的东西在实际中并非是什么大问题。
但王垠为什么还要说？因为他就是搞这方面研究的。
那为什么一些码农还要看？因为工程师除了完成工作，挣钱，也应该在思想上时不时的更新一下，不断提高自身。
至于老赵的第二篇Why Java sucks and C# rocks，看来看去都是语法上的问题，跳不出这个框框。他的这种文章之前很多老外也写过，但没有什么新意，至少带不来在思想上的新的东西。你觉得这种文章写上10000篇能发一个paper么？王在05年上学的时候就有很多paper了。算了，说这些都没意义。
总之：不要老纠着一个人不放，而忽视了真正要谈的问题的本身。
老赵那个系列反复强调Java != JVM，他喷的是不思进取的Java，不说语法说什么？
王垠发的是什么样的paper你知道么？05年的时候他还没搞编程语言设计。像王垠博客里这种文章写上10000篇能发一个paper么？有哪些思想上的新东西么？他的文章里充斥着观点，你找得到支撑论点的论据么？
王垠最近一篇对Go的评价“Go 语言里面有很多新的和好的东西。可惜新的东西都不是好的，好的东西都不是新的”这个句式简直听到烂，既可以什么都不说又好像说了很多，反正等于没说。看思维导图也没什么新东西，都是之前别人喷过的。
最后说一次，我从来都没说这个人怎么样，我只是表示不喜欢他的文章。因为正
所说，他的文章给我的感觉就是这样……所以我觉得对自己没什么帮助。不是没用，是对我而言没啥用。我们这些关注高层抽象的人尚且知道语言细节的重要，难道一个搞底层语言的专家反而要不在意？
肯定有其他人会觉得写的很好很精彩，这很正常。就像我先前回复另一位的，领域不同看待问题的观点也不同。其实这个话题的争论就像vim和emacs多年不变的宗教战争，永远不会有结果的……但我不理解的是为什么总有人抱着说服对方的想法去讨论……那讨论就变质了。
从来没有学了可包治百病的知识，只有对自己有用的知识。正确分析自己需要什么，有用则学，无用则抛，仅此而已。
他对Go语言吐槽的地方，其实在Go的官方文档和各种演讲里已经解释的很清楚了，Go设计出来的主要目的就是为了填补语言性能和程序员生产率之间的鸿沟，自然会借鉴大量其他不同类型语言的做法，所以没有程序设计思想的创新很正常，人家本来就不是冲着这来的。可看他的口气似乎觉得语言设计者太dumb所以没有新点子出来，对此实在不能认同。这也只能说明搞学术研究和搞工程实践考虑问题的出发点过于殊途， 不能同归也不能说明谁对谁错。做工程实践的人要牢记自己的视角，以防再遇到这样主观性极强，煽动性极强的来自学术大牛的文章时，偏听偏信乱了分寸。
我觉得我不应该写那么一堆，应该只写这一句：不要老纠着人不放，而忽视了真正要谈的问题的本身。这楼已经歪的不像样了。
主观性极强是的，煽动性极强倒不至于，至于学术大牛什么的就有点开玩笑了
谈论这种问题就像大多数刚毕业时会讨论学习哪种语言好一样，最终都不会有答案。
123楼 已删除
后方可回复, 如果你还没有账号请点击这里 。
共收到 122 条回复