Ruby ruby 和 "脚本语言"

fsword · 2013年04月23日 · 最后由 bhuztez 回复于 2013年04月23日 · 6401 次阅读

之前没注意这篇 blog,感谢 @hpyhackinghttp://ruby-china.org/topics/10381 写了这么一段让我注意到

所以我认为脚本语言是一个祸害,它几乎永远是错误的决定。
我们应该尽一切可能避免使用脚本语言。在没有办法的情况下(比如老板要求),也应该在脚本里面尽可能的使用通常的程序设计原则。
摘自 http://www.yinwang.org/blog-cn/2013/03/29/scripting-language/

我基本上赞同王垠博客里的观点,事实上这也是我一直以来比较注意的一个事情,除了 rails/sinatra 这样 “手把手” 的框架外,很多人(包括我)写的 ruby 代码基本上就是脚本堆砌,我见过公司的另外一个同事写的运维脚本,除了使用 ruby 语言,我找不到和(新手写的)bash shell 有什么不同——同样无结构、缺设计,而这是难以维护和不能长久的。

举个例子吧,类似的现象常出现在对 AR 的使用上,我们知道,在 M.F.的企业应用架构模式中,与领域模型做对比,还有一个业务脚本(也翻译成事务脚本)模式,后者的困难在于难以迎接业务的演化,所以结合 ORM 技术,我们 rails 中使用了充血模型,但是 AR 本身并不能保证你不写出 “业务脚本”,比如:

Product.where("created_at > ?", Time.now).where(:owner => user).order(:id).limit(5)

这句话并不比

select * from products where created_at > now() and owner_id = #user.id order by id limit 5

更加结构化和易复用

当然,有经验的人都知道,正确的做法是使用 relation 技术复用各种 scope。但是,如果没有 AR 或者 Rails,有多少人能够意识到什么才是正确的做法呢?而王垠这篇博客的观点其实正好提醒我们——虽然 ruby 号称是脚本语言,但是作为一个程序员,你必须知道在必要的时候用严谨的方式使用通常的程序设计原则,避免 “脚本面条”

BTW:之前很多同学都在讨论面试时怎样体现 “深入”,我想,能充分理解这些做法的来龙去脉,利用工具而不是受到工具的支配算是一个方向吧。

SQL is better ...

不同意王垠这个观点 他根本没有开发大型项目的经验 根本看不到脚本语言在开发速度上的优势。 我不否认运维脚本存在代码堆砌的现象,这只是因为这个脚本通常完成一些很简单的任务或是只运行一次,用完即删。因此心理上没有足够的重视,如果换一种更严谨的语言也未必解决这个问题。如果是标准的项目,肯定会基于一套已有的框架或是自行设计,因为心理上已经足够的重视并且可以预见到这个项目未来的规模,肯定会足够谨慎,不会再出现堆砌代码的现象了。

#2 楼 @iBachue 回贴不看贴......

#3 楼 @fsword 你后面那部分观点我同意啊...

#4 楼 @iBachue 其实那就是王垠的观点,只是他的表述比较理想化而已,比如,他知道脚本语言的开发优势,但是从理论上这些优势全都可以模仿(背后偷偷编译就行了),这是他这种 researcher 和我们这些工程师的思维区别,不涉及根本分歧

#5 楼 @fsword 脚本语言的优势不仅仅是不需要编译啊。。。而且编译问题也不是偷偷编译能够轻易解决的。。

用 shell 或 ruby 这类语言的脚本只要用 vi 或 nano 改一下就能立刻跑起来。用静态语言,比如 Java。我会先打开 eclipse,然后改,编译,打包 jar,上传....

运维脚本其实用粗粒度的模块划分也能搞定的吧 = = 反正除了迫不得已或这服务器就是跑 rails,否则一般不会上 ruby 的

都读完了 没看懂楼主在说什么。 举的例子、标题、还有结论......没看出来有什么逻辑上的联系。

#7 楼 @saiga 这都不是不可克服的困难,当然是从理论上。但是从另一方面,因为我们可以用 ruby立刻就能跑起来,所以往往忽略了设计,不然你抛弃现有的 framework,只用各种工具库,看看是不是很容易就写成面条了?

#10 楼 @fsword 这个只能看人了= =静态语言也能堆,一个方法堆几百个 if 的大有人在....

#11 楼 @saiga 你说的没错,我只是觉得,很多人用了 ruby 以后就觉得自己写代码变漂亮了,用了 rails 就觉得自己懂得 web 了,其实很可能自己的能力并没有提高。 一般来说,一个人不会仅因为自己手里的工具而变强大的,ruby/rails 是个很强大的工具,所以它更容易给人错觉。

[Build Awesome Command-Line Applications in Ruby] 推荐这本书,一步一步把脚本变的 awesome

说说我个人的感觉吧,其实很多时候,我自己都会陷入一个泥潭,就是如果我用 RUBY 开发,如果有个人指出了 RUBY 的某些问题的时候,有一瞬间,我是很难接受的,我觉得要反驳他,不然有种被冒犯的感觉,但是自己想想,我觉得任何事情都要分开看,楼主所说的完全正确,当我们写脚本的时候,确实容易写出很多所谓的脚本面条,所以下次写的时候,如果这脚本不是一次性的话,注意抽象和设计,让它维护起来简单,我觉得这并不代表 RUBY 不如 Java 或者说脚本语言不如所谓的正规语言,每种语言都有自己擅长处理的事情,没有一门可以搞定所有事情,所以我觉得还是要辩证的看问题,在用脚本语言的时候,让我自己写的代码更具维护性,在用所谓的正规语言的时候,尽量让自己的架构部要太臃肿,不管使用什么语言,警惕它可能引入的问题,最终让自己写出的代码结构清晰,易于维护。

rails 确实是强大的工具,很多人对自己也没那么高的要求,如果只是用来写一些简单站点的话,rails 还是很不错的。 如果说想提高的话,ruby/rails 中也有很多不错的思想。 如果说写脚本害怕面条的话,写的时候注意就好了,一切都要看使用的人,脚本所拥有的开发速度是很多静态预言所不能达到的。rails 有些人看着笨重,有些人看着敏捷,就是因为他们从不同的角度观察的,使用起来自然也有所不同的。 而且语言和使用习惯也是因人而异的,事务都是存在既合理的,更不用提语言了。

还有例子里说那个 ORM 模型,我是能看到笨重和效率损失的,但是我同样看到了可移植性和结构化,这两个语句是无法比的,一个也许是可以注入的,另一个则不能。

钱是万恶之源,所有犯罪都是因为钱

不设计和过份设计,这个还是只能看程序员自己。gnu grep 的源码里 main 函数也有 400 行,都是 if else,switch case,一样在用。

如果只是简单的脚本,我倾向于最简单的设计,甚至于没啥设计。 如果是个工具包,gem,web app,那适当做设计。

lz 举得的例子不太能看出效果,抛开 rails,orm 还是解决很多问题的,比如 escape,sql 注入等。 而且如果例子里的 where 和 order 没有被复用,这样的代码不觉得有太大问题。如果真的被用到很多次,再改成 scope 也没啥问题。

赞同@fsword 说的,ruby/rails 是很强大的工具,但代码的重点并不在于他们。特别像我这种新手,的确会有用了 ruby 就和其他人不同的错觉。关注各种奇淫巧计,殊不知程序设计思想才是最重要的。我们总会无意识的写出脚本面条式代码,很难写出拿得出手的东西。我们需要抛开工具,深入学习,或者至少可以了解工具的来龙去脉。这个过程肯定会有点枯燥,没有永远好远有趣的东西,除非你要当一辈子新手,我不要啦。。

20 楼 已删除

如果把脚本语言理解为一种特殊的 dsl,那就没有什么好纠结的。 有些时候,能 run 才是最重要的。

根据原文第二段的定义,他所说的 “脚本语言” 是指 shell, awk, sed, 滥用的 perl 这些,ruby 不属于他所定义的 “脚本语言”

#1 楼 @bhuztez SQL 错就错在 where clause 不是一等公民...

#23 楼 @luikore 所以要用 Datalog...

需要 登录 后方可回复, 如果你还没有账号请 注册新账号