BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

语言约束和责任感,我们应该信赖谁?

| 作者 Abel Avram 关注 7 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2009年7月31日. 估计阅读时间: 7 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

语言应该完全灵活、允许开发人员随心所欲地进行调整、并相信他们会对自己的工作负责呢,还是应该从设计阶段就在语言中设置明确的约束集,以避免出现生成糟糕代码、难以维护或阅读的错误?

Bruce Eckel认为有些功能非常复杂,大多功能最终并没被使用过:

C++里一直没有运行时模型(所有内容都编译为原始代码,这是C兼容性的另一个遗留问题),之前出现了模板元编程。由于模板元编程确实很难用,它非常复杂,几乎没人知道该如何去做。

Java有运行时模型,甚至还有动态修改代码的方法,但语言的静态类型检查非常麻烦,以致原始元编程跟C++里一样很难做到。

很显然,需求依旧层出不穷,我们首先看到了面向方面编程(AOP),而事实证明对大多数程序员来说AOP又有点儿过于复杂。

跟Smalltalk一样,Ruby中的所有内容都是可替代的(对习惯于静态语言的人来说,这确实让动态语言引起了惊声尖叫)。

Michael Feathers觉得Eckel是在建议对语言进行约束

语言设计者总是坚持这类理由——有些东西不应该被允许。如果你想看这种理由的例子,就去看看Bruce Eckel本篇博客的元编程一节吧。

Feathers提倡信任开发人员,而不是建立安全网,这能促进道德责任,他认为这在Ruby社区是存在的:

某些语言里,你会觉得语言设计者在告诉你有些东西非常危险,我们应该防止这些东西,而且应该有可用的工具来防止滥用这些功能。结果整个社区在规范意见和可行方案上花费了大量时间。如果语言不能用人们习惯的方式提供锁定所有这些内容的特性,人们就会非常生气。

在Ruby文化里我还没有发现这一点。

你可以在Ruby里为所欲为。你能改变库里的任意类,织入方面的(Aspecty)行为,完全用元编程做疯狂的事情。也就是说,一切全在于你。你需要负责任。如果出现问题你只能怪自己。你不能责怪语言设计者没有添加功能,因为你自己可以去做,你也不能因为他没有按你的方式去做而责备他。

那为什么很多人并没有输得很惨呢?我想有一个很好的理由。在你能做任何事情的时候,你必须变得更加负责。你掌握着你自己的命运。而且我认为这能提升责任感。

Coda Hale并不认为Ruby社区有更好的责任感,相反,这是一种放任:

我非常想去相信Ruby有责任感文化,但我并不觉得是这样。我已经调试了Ruby应用中的大量问题,它们都是由擅自采用他人代码的第三方库造成的——把NilClass变成一个黑洞,或者使用alias_method_chain,却没有很好地复写基本的方法签名。对那些引起问题的库,每次都要尽力说服其作者去修复问题,但每次我都不得不在库更新之前自己给代码打热补丁。这并不是积极意义上的责任感;它的责任感只是“如果你不修复,就没人修复”。

我认为Ruby文化里放纵多于责任。任何事情几乎都是可以接受的,而不会抗议另一个库的不良行为,由于库自身的不良行为,你要编写自己的版本。

Niclas Nilsson同意Feathers的观点,让开发人员不受约束,让他们觉得有责任:

由于某些原因,我总会在各种不同的情形下跟别人结束这个讨论。“这不危险么?”我的答案往往是“是,危险。不过汽车、刀具、药物也是如此。”几乎所有可用的东西都会被滥用,但我们很少这么做,如果这么做了我们很快就会认识到,在软件里,我们具备各种无与伦比的撤销功能。

只要为(虚假)保护付出的代价非常小,尤其是它们可以规避,我就不愿意为它们付出代价。你不能在Java运行时改变一个类,所以为了解决这个问题, 人们转向了字节码编织。壁垒打破了,但却是高成本和高复杂性。我还是相信责任,我设置好的习惯和安全网,以保护自己不犯逻辑错误。

自由和责任是并行不悖的。

Keith Braithwaite举了Lisp社区的例子,该社区不庇护它的用户,用户也学会了如何避免错误:

从Lisp社区的历史中能汲取哪些经验教训呢?Lisp(还有Smalltalk和汇编)是不庇护自己用户的。我似乎还能想起来读过Dick Gabriel的一些文章,里面说明了Lisp程序员如何停止自我检查,认为某些模板的灵巧是不得体的——他们小心翼翼以不让那些灵巧性困扰他人。他们几乎可以做任何事情(还有编写代码本身),但他们选择不去做某些事情。

Glenn Vanderburg认为,语言约束并不会避免开发人员犯错

差的开发人员会“竭尽所能”地去犯错。你不能通过锁定利器而规避他们造成的破坏。他们会更费劲地挥动钝器去犯错。

如果你希望你的团队有很多产出,并对他们的决定负责的话,就给他们强大的工具。

Aslam Khan认则认为,新手觉得保护机制有必要,但随着他们越来越有经验,这些保护机制就可以移除了:

很多语言设计者假设人们需要被“控制”。事实上,新手们更喜欢基于规则/方法/准则学习文化和语言,这迫使各种有关“危险”事情的“安全网”很好地为小组服务。当新手不再是新手,这种情况才会结束,然后约束就会变得不合理。

Ward Bell注意到,人们并不是很负责任:

好的情况下……谁会反对责任和学习呢?但阅读实际已有代码的多年经验告诉我,别人不负责,我们自己往往也会松懈。Ruby是怎样改变了我们的天性呢?

早在七十年代和八十年代,我用APL编写商业应用。非常动态。改变别人写的代码非常容易。你可以编写新的APL作为字符串,也可以用烦人的操作符执行它们。几乎没有捕获或警告的解释程序支持(那时还没有编译)。

我们创造了非常好的东西。我们修复的速度几乎和编写的速度一样快,这非常酷。但你必须要非常擅长阅读任何人的代码(包括你自己的)。

T. Powell认为,不管使用什么语言,开发人员都能吸收,因此问题之所在并不是语言,而是态度:

不论用什么语言,你都能要么举步维艰,要么很优秀……当然,语言有所影响,你也会经常看到设计者或社区适当的作用,但你会成为用Java、Ruby、Fortran等语言的白痴……

你对此有何看法呢?我们应该要无约束的语言、信任开发人员呢,还是应该有适当的安全网?

查看英文原文:Should We Rely on Language Constraints or Responsibility?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

asm膜拜者应该选a吧 by Wei Fisher

比如鼓捣os kernel,device driver的达人们?

我需要静态检查 by Jeffrey Zhao

但足够自由

Re: 我需要静态检查 by * nolearning

Haskell是个不错的选择。

Re: 我需要静态检查 by Jeffrey Zhao

haskell的话……pure functional了,也会碍手碍脚。
我相比我喜欢C#,F#和Scala。

Re: 我需要静态检查 by Lee Albert

Haskell 有 IO Monad 来进行IO 操作。 他并不妨碍你进行IO,而是将其限制在一定范围内,将纯与不纯的代码隔离开,强制你进行合理的设计。

Re: 我需要静态检查 by Jeffrey Zhao

你说的没错,但这就是“语言约束”了啊。

我需要静态检查,但是要足够自由,呵呵。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

6 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT