这是一个创建于 4807 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
2
Los OP 悲剧了，还以为嵌入代码也可以如 https://gist.github.com/1209128 这里一样直接显textile的格式呢。
|
 |
3
kaktos 2011-09-11 12:02:27 +08:00
ruby的做法是想创造出一种灵活的DSL类语言，不过这灵活性也是双刃剑啊。不过抛开语言来讲，我还是觉得rails是地球上最fashion的MVC框架，至于效率是不是最高，我就不引起争论了：），用过的人都知道。。。一些理念，包括activerecord，restful风格，都是rails率先将理论引入实践的，加上最近3.1搞的什么assets pipline,coffeescript之类的东西，如果你是个干时髦的年轻人，不管平时是搞java或者php或者python，我觉得你都至少可以从rails里面学到不少东西，开阔不少视野呢~~
|
 |
4
chloerei 2011-09-11 13:52:04 +08:00
总的来说就是偏见，自己的领域玩得越熟，踏进别的领域就越被思维定势困住。如果是有心跨领域探索的，要放开心态，遇到问题可以问一问，不要自顾自用用老办法。
我想到这样一个场景，一个人去KFC点餐 “我要单点一个汉堡，一份大薯条，一杯大可乐” “不如你试试我们的套餐，可以有节省3元” “套餐的可乐是中可乐不是大可乐啊！” “可以换大可乐，还是比原价节省2元” “我要大薯条不要中薯条！” “换大薯条也是比原价节省2元” “汉堡是XX堡么？” “是一样的” “你们套餐的汉堡肯定偷工减料的……我就是要单点” “先生……” “怎么这么罗嗦，隔壁M记从来不干预我单点的，我回他们那了” |
 |
5
keakon 2011-09-11 14:06:01 +08:00
@Los 那篇文章如果你读完的话，就知道我并非只是抨击RoR。我真正想说的是各种东西都有其适应的群体，开发者应该拿有限的时间去找适应他的技术，而不是逼自己去适应技术。
拿其中一个观点来说：Pythoner极力维护语言的纯洁性，简洁易懂是他们的哲理；Rubyer很喜欢新奇，巴不得每行代码都能用6种语法来写。 以你上面的为例：“Ruby允许一个函数可以有多个别名，比如得到 Array 的长度，有size，length甚至count”。 那么Python为什么不这么做？因为它需要简洁，这种简洁也带来了一致性和通用性，可以减少人们的疑惑和学习负担。 试想一下字符数组，它在C语言里可以当成字符串。前者或许可以有size，length甚至count，但是后者有count合理么？而在Python中，不论是内置的list、set、str、unicode、dict，还是开发者自定义的类型，一律都用__len__(self)这个接口获取长度，而且这个命名也让你趋向于选择更短的内置函数len()。 为什么要用函数而不是对象的方法？ 我不知道Guido设计的初衷是怎样的，但是如果一个函数只想接收定义了__len__(self)方法的对象时，len()可以让不支持的对象抛出异常。而如果换成size(self)、length(self)和count(self)方法的话，你在定义自己的类时，为了不与标准的接口相冲突，这3个方法你都不能定义。于是你不能有square.size、rope.length和money.count，除非你保证其他人不会把这些对象当成Array。 我承认你的例子里用count确实更符合语境，但在Pythoner看来，作为一门语言的基本类型，它应该保持简洁；而在开发者需要他的语境时，才去自行定义别名。 而在Rubyer看来，他们只知道__len__很丑，len不面向对象，而且没有alias语法，这太过死板和沉闷了。 关于那个“:attachable_id=>topic_id”，我只想说人类的语言不会带:和=>。不管你学过多少门语言，只要没学过Ruby的人都看不懂这些符号。 而Python极力避免使用符号，宁愿使用关键字来取代符号。 还有我之前所提到的，那个.save让人疑惑究竟是一个属性访问，还是一个方法调用。一个get方法模拟成属性说得过去，可是这种带有强烈副作用的方法，为什么要伪装成人畜无害的样子？ 假如这个对象还有个saved属性，然后你在获取它时碰巧少写了个d，而这个save方法最后会返回saved属性，会出现什么现象呢？你也许会说我有写单元测试啊，可假如你的测试代码是save == saved，或者这个错正好就发生在单元测试里呢？ 我想这3点差异的本质就是：Python追求简洁，不让人疑惑；而Ruby追求自由，让自己惬意。 这也是我说“真正的Python程序员和Ruby程序员肯定是2个极端，绝对是水火不容的存在”的原因。他们的观念和care的方面完全不一样。 更多原因可以看这篇文章，有些观点现在看来存在错误，但大方向上和我现在的看法仍然相符： http://www.keakon.net/2009/03/17/%E4%B8%BA%E4%BB%80%E4%B9%88%E6%88%91%E9%80%89%E6%8B%A9Python%EF%BC%8C%E8%80%8C%E9%9D%9ERuby 其实回头想想，这有点像iOS和Android的差异。很多人想把iOS当成Android用，然后觉得很不灵活。可问题是2者本来就是风格迥异的，不适应就换一个，何苦折腾自己？ 关于你的PS.2，这并不能解决根本原因，如果想用mootools呢？ |
|
6
keakon 2011-09-11 14:19:21 +08:00
@chloerei 我想说的是我在接触Python后没多久，就喜欢上Ruby了，详情可以看 http://www.keakon.net/article/888
但随着了解的深入，就越来越觉得不爽了。 我可以轻易为JS和Python抛弃学了4年的C++，但却忍受不了Ruby，这实在很难以偏见来说服我自己。 |
|
7
chloerei 2011-09-11 14:20:26 +08:00
我最反对的就是这句：
“Python追求简洁，不让人疑惑；而Ruby追求自由，让自己惬意。” 说得好像Ruby不追求简洁，让人迷惑似的。你提出的语法问题在实际开发中未曾成为问题，不一一反驳了。 |
|
8
chloerei 2011-09-11 14:42:15 +08:00
还是挑几点说好了
1. 方法名和属性名 实例变量（对象的属性）都是以 @ 开头的，比如 @name，默认情况下只能在对象内部可见，要在外部访问，必须设置相应的方法。所以熟悉 Ruby 的人，肯定知道 foo.bar 这个 bar 是个方法，如果它有对应的属性，那么可能会命名为 @bar。 你举例的 (@)saved 属性，从命名上看是布尔值，按照惯例，访问方法应该命名为 saved? 2. 方法的别名是开发者对语言和框架作者的适应。 也就是 Matz 和 DHH 为某方法设置了别名，那么想用就用好了。如果团队里面有人乱搞别名，要不人留下代码不留，要不人和代码都不留。 3. 人类语言本来就没有 hash。ruby 1.9 引进了 json 式的 hash，比如 { foo: "bar" } 跟2一样，不想用可以不用。 4. mootools 想用就用啊，该怎么用怎么用。最简单粗暴的拷进 public 目录用 <script src=..> 引进去。Railsful 一点的打包成 gem，用 assets pipline 跟其他js代码一起打包，减少 http 连接数。 奥，已经有人做了 https://github.com/neonlex/mootools-rails |
 |
9
args 2011-09-11 14:44:20 +08:00
我觉得ruby只有两个地方比python更让我满意：
1) 块结构， 给函数传入一个块的思想真的很强大。 2) 丰富的内建自省机制，提供强大的原编程基础。 其他的地方我觉得都比python烂。例如ruby强调面向对象，但method原生不是对象；def和class会定义一个封闭的作用域，不能方便的访问外部变量。以及各种奇怪的语法。 ruby从perl继承了一些好东西，例如if和else定语还有正则表达式字面量等等，但也继承了太多无用的东西。 |
|
10
Los OP @keakon 其实rails你里面的东西很多都可以换的，早两年前我就用jquery了。
---- 而rails采取了「MVC制」的web开发框架，「约定胜于配置」的本质意义在于「规划部门」，将「部门」确定下来并将「各个部门该负责干什么确立下来」，但这里它会「预先安排好一支精干的工作人员队伍」，免得你这个「头」对着这个空壳机构无处下手，无事可做。 |
|
12
keakon 2011-09-11 14:52:54 +08:00
@chloerei 我很不乐于和Rubyer讨论语言，原因前面也提到过了。
所以只简单回答下，我希望你有反对意见的话，先站在对方的观点想想为什么会存在这个问题，而不是把别人当成无理取闹的异类。 我就经常很疑惑，我自己就是证人，哪怕全世界只有我一个人疑惑，也是“让人疑惑”。同理，你也只能证明你自己不疑惑，不能证明它不“让人疑惑”，这在海猫中属于恶魔的证明。 要我说的话，我不认同“在实际开发中未曾成为问题”。我看到那条语句就得猜测是不是函数调用，这么大的问题都不是问题的话，那我把save改成一个属性，你在阅读代码时是否还按照“约定”认为它是函数调用？ 关于“不追求简洁”，如果你注意到我的用词了的话，我对那么有好感的Ruby的第一印象不是简洁，而是简约。这2个词在Rubyer眼里也许看不出区别，这更让我觉得当初用这个词用对了。 @Livid 载入github的内容严重拖慢页面加载速度，能改善下吗？ |
|
13
Los OP 感觉语言之类的喜好还是归于自己的观感，你心目中它是什么样子，往往决定你能不能喜欢它。
萝卜青菜各有所爱，也不非得大家都喜欢同一门语言。 记得N年前还是在win下进行桌面开发，我就非得用SDK自己一字一字自己敲桌面程序（好吧，还有更底层的），MFC之类明明用起来很快但内心处极度不喜欢，这一种感觉 |
|
14
args 2011-09-11 14:56:14 +08:00
不过框架的话，rails真的是我见过里最完整好用的。当然我以前大框架只用过django（php的话简单接触过zend），接触的其他python框架则类似与wsgi的封装，算不上full stack。
不过rails是不是真的很慢啊，我目前自己写了个小论坛程序玩，看到控制台输出居然用了400多毫秒（大部分都花费在active view上），而我对比其他的大规模的php论坛，也就几十毫秒。 |
 |
16
bhuztez 2011-09-11 14:57:37 +08:00
@keakon 在method的调用上，Ruby是类smalltalk语法，你熟悉的是类C语法，其实没啥区别，习惯了就好。各有各的好处，类smalltalk语法，可以让 Ruby 有block，可是类C语法，可以让你更方便地把 method 当参数。
|
|
17
chloerei 2011-09-11 15:01:30 +08:00
@keakon 前面有跟帖了。save肯定是方法，方法有问题，找方法的编写者。
简洁简约用来描述语言有啥语境区别我只能请指教了。 你对 js 库的理解倒让我觉得还未做到理解 web 开发的本质啊。 我也不太喜欢面向非 Ruby 人群讨论 Ruby，因为发现有些偏见根深蒂固很难改变。 |
|
18
Los OP |
|
19
keakon 2011-09-11 15:03:54 +08:00
@chloerei 我明确说出来吧，省得你还搞不懂我们观念上的根本差异：你希望的自由，是不想用可以不用；但我希望的是不想用的，我要求全世界所有人都不能用。
我承认这样很霸道，所以才会提起iOS。观念和乔布斯相符的，会满意iOS，不符的可以去选择Android。2者本来就都没有错，只在于你是否选择和你观念相符的。 |
|
20
Los OP @keakon 「但我希望的是不想用的，我要求全世界所有人都不能用。」汗，你这句话让我想起了广州这边前段时间闹得纷纷扬扬封杀粤语事件，普通话进来了，连本地电视台也要求只能用普通话进行播放，非一家语言独用为好。:)
|
 |
21
ikbear 2011-09-11 15:29:55 +08:00
观念不一样的人在一起，有什么可争的。这样的情况，看过几百遍了。不是偏见，就不需要去拿来说服别人了。因为如果不是偏见，那就是事实，而事实是摆在那里不需要一遍又一遍的说的。
|
 |
22
adamsxu 2011-09-11 15:32:04 +08:00
Rails这种可以歇了。
|
|
23
keakon 2011-09-11 15:50:04 +08:00
@Los 哈哈，其实这件事我很支持政府的（如果我没有理解错的话）。我待在上海，就觉得上海话很难听和拗口。我自己是可以不学，也可以不说；我也很认可上海人相互之间用上海话交流；但重要的是别TMD的对我说上海话，或者是一群人交流时，一小部分人不时说些上海话。
对我来说，避免痛苦远比获得快乐重要。一开始我就说了，Ruby有“很多”我喜欢的东西，但是为此而忍受“一些”我不喜欢的东西，这点我做不到。 而对“很多人”来说，这些我认为的痛苦是不存在的，所以他们会喜欢Ruby，对此我觉得可喜可贺。 但是强迫别人认可自己的痛苦或快乐，这是我不可接受的。所以我选择只和与我价值观相同的人交流，因为这部分人已经认可了什么是我们共同“不想用的”，也就不需要承受道德上的自责了。 |
|
25
Los OP @keakon 这个实在不敢苟同，我们都很容易以自己的立场来希望外部环境更加顺应自己。如果你是说普通话的，但有政策下来强制你当地只能说广州话（估计你没有注意到我上面的「本地电视台」字眼，广州对于不会说广州话的人员还是很友好的以普通话交流的），地方特色一般都与当地语言有所关联，这样的政策估计你也很难接受的。
哈，不在这方面继续讨论下去了，越跑越偏了，而且，这方面的讨论很容易引起激战。 我们还是转回技术方面的讨论算了，轻松自在一些讨论技术多爽，而关于rails的「约定」这个定义，好像太多人对它认知偏差了。 |
|
26
keakon 2011-09-11 17:51:07 +08:00
@Los 我会很爽快地离开，重点是有很多地方使用普通话，且我和这些人都认可普通话。
我不知道政府的禁令具体内容是什么，但如果只是在公开场合、电视台、广播电台中避免使用粤语，同时允许一部分台只为听得懂粤语的观众服务，我觉得是非常合理的，甚至是法律中早有规定的。 我记得我小时候去广州时，除了CCTV以外，所有电视台都是我听不懂的话，害得我实在没事可干。 关于约定，你所得过于抽象，而在Google里搜索“rails 约定”都是些命名规范之类的东西，而带来的好处并未提及。 @Livid，为什么Chrome下每敲一个字符，输入框就会增高一点？查了下源码可能是这个引起的： <textarea class="mll" name="content" id="reply_content" onkeyup="c();" onpropertychange="this.style.height=this.scrollHeight+'px';" oninput="this.style.height=this.scrollHeight+'px';"></textarea> scrollHeight要比style.height多6px，因为存在3px的padding。 |
 |
28
ssword 2011-09-11 19:38:09 +08:00
关于约定，你所得过于抽象，而在Google里搜索“rails 约定”都是些命名规范之类的东西，而带来的好处并未提及。
--- 没“命名规范”这么简单。请屈尊多了解一些再下结论，不然讨论不在一个层次，交流会很困难。 |
|
29
Los OP @keakon Google里搜索“rails 约定”之类的比较难得到真正的结果，正如你有说过的，很多人觉得rails好但却说不出它好在哪
|
 |
30
lepture 2011-09-12 11:59:20 +08:00
其实 @keakon 那篇文章，我觉得他要表达的是你要了解事情的本质，然后选择适合的工具，而不是用一个万金油的东西。
@keakon 不知道我理解的对不对？ 我也遇到过你所说的问题，公司用Java，我用Python，没找到合适的Python的工作。现在做前端。当我跟Java同事去交流时，（比如ajax），他就要问我这个关连到servlet什么的。我给他讲这个原理是怎么样的，它其实就是一个http请求，本质上来说和你用浏览器所访问的这个链接没什么区别，不过加上了xmlhttp的头信息。结果绕了一下，他又绕到了java的controller之类的概念里去了。这很让人郁闷，难道一个做后端的做互联网的人都重来不看rfc2612的么？ 小可也曾尝试过ruby，也没能学进去。不过平时向人推荐的时候python和ruby都会向人推荐。我也同意 @keakon 所说的python和ruby有点水火不容，pythoner真的很难接受ruby，除非你只是用了下python而不是pythoner。 这并不是说ruby不好。所以我会向别人两者都推荐，他自己选择适合自己的。 目前来说，我对 java 和 php 有点偏见。主要是遇到的这两类程序员喜欢绕在语言里，而忽略了本质。正如 @keakon 所说的： “举例来说，我在浏览器上访问了一个URL，服务器要怎么处理呢？PHP程序员会说根据它路径里的php文件名，在磁盘上找到对应的php文件，然后执行里面的代码；Java程序员会说根据它的路径，在XML配置里找到对应的servlet，再执行里面的代码；Rails程序员会说根据它的路径，分离出application、controller和action，然后执行这个action的代码。” 如果一个程序员脱离了这一层，我都可以接受。因为遇到的java和php程序员大多没脱离这一层，不免怀疑是不是这个语言本身就会造成这样的现象，让人不容易去了解事物的本质。所以不免就有了偏见。 |
|
31
keakon 2011-09-12 14:37:43 +08:00
@lepture 就是这样。我讨厌的语言不多，Ruby并不属于其中之一，所以我不会去刻意攻击它。
但是Ruby本身的争议很多，大家对其的误解也多，所以Rubyer大都很敏感，一看到非议就会很冲动地捍卫自己所用的语言。 我不是说Pythoner就不会这么做，但是他们会清楚地解释原因；至少不会以一种盛气凌人的姿态，告诉你要么就花大把时间去领悟它的好，要么就别指手划脚。 突然想到战色女，我的问题不是问题，一切都是男人的错。 @chloerei 以我的理解，简洁是以大家都懂的方式让其简单，简约则是为了简化，而限制了一些隐含的约束条件（例如赋予符号特殊的意义）。 顺便附字典中的解释，确实没什么区别： 简洁：简明扼要，没有多余的内容。 简约：是力求语辞简洁扼要的文体风格。其特点是简洁洗练，单纯明快，辞少意多。简约不是简单摹写，也不是简陋肤浅，而是经过提炼形成的精约简省，富有言外之意。其弊在容易流于郁而不明的晦涩。 关于JS框架，如果Rails只是单纯地引入，而不会自动生成JS代码，那就当我没说。 关于.save，让我们先抛开属性和方法的区别。假设有个函数名叫save，我把它赋值给一个变量：x = save，这会让我疑惑save是变量还是函数返回值。 你可以说动词一般用于函数名，但如果一个词既可做动词，又可做名词呢，例如answer？ 你也许会换个没有歧义的名字，但这已经是在解决问题了，而不是你所说的不存在问题。 即使对你来说不存在问题，那么是否又能和我之前所说的一样，先思考为什么别人会有问题，再做定论？ @Los 以我浅薄的理解，Rails约定了一些前提，你在遵守这个前提时，除了直接体现出来的无需配置以外，其他地方也因为用到了这些隐喻，而省去了编码工作——这都建立在你必须保持一致性的前提下。 而项目的需求总是有不一样的，你可能要做移植工作，处理原来不符合Rails约定的URL、表名等，说不定还有knowlegde这种不可数名词的存在。在约定被破坏时，我不知道维持配置，以及为修复它而补充那些省去的代码需要怎样的effort。 Google搜索“约定胜于配置”，第2篇的内容囧到我了。 看上去还是到stackoverflow搜索比较好： http://stackoverflow.com/questions/1166539/do-you-find-convention-over-configuration-good-or-bad |
 |
32
makestory 2011-09-12 15:40:08 +08:00
作为自学 python 又因工作转移到 ruby 的一枚，表示转换过来并不难，也没觉得痛苦，可能离 pythonic 的境界差的远吧？ 如果过程是反过来，我想也是类似的。
觉得同是动态语言的python和ruby肯定是众多语言里相当接近的一对。 虽说好好看过的书只有《learning python》《the ruby programming language》，但也感到了两个语言的设计风格是差别蛮大的（python简洁严谨，ruby人性化）。一个语言或多或少都有点自己不太喜欢的地方，但对我这种不是纯粹的程序员(也关心产品和运营)来讲，能够适应就能感到快乐(我好容易有满足感)。 所以我的看法是几位能对这个争论起来，还是因为对编程的热爱度超高啊！ 喜欢python的缩近，所以所有ruby代码也一直这么缩着。 |
 |
33
Kymair 2011-09-12 15:46:24 +08:00 via Android
其实在某种程度上，@keakon所说的那种“霸道”是必要的。
这让我想到了很多大牛对C++的抱怨，Coders at work里非常多。最著名的应该是Linus，也可以搜搜云风的几篇评论。 太多的特性和范式会给程序员带来额外的心智负担，而且往往会促使人们为了去利用某个范式或特性而刻意构造精巧，埋没了本来的目的。 |
|
34
chloerei 2011-09-12 16:02:11 +08:00
@keakon
Rails 3 没有生成 js 代码 x = save，x 得到的是 save 的值，不论他是方法还是局部变量。或者你觉得 foo.bar 和 foo.bar() 得到不同的结果更符合预期？ 命名一直是高级语言一个非技术的纠结点，我不认为 Ruby 是特殊的。 其实你的偏见已经越来越越暴露出来，你为了证明 Ruby 有那么多问题，去想一些不切实际的问题，要不没人会这样做，要不不是 Ruby 特有的。 有什么语言能阻止程序员写出 def save(record) ....delete(record) 这样的代码？这样问题我都不知道点在哪里，哪个程序员写代码是为了跟自己过不去。 路由：完全不遵循 RESTful url，用 match 规则写路由没什么问题；表名不规则，那么设置一下表名；单复数支持很好，rails 维护了一个非规则的单复数名词表，你也可以自己定义特殊词表，也可以无视单复数。破坏约定时，代码量还是比自己实现一套规则要小。 回顾一下#4的套餐恐惧症。 不知道我盛气凌人了没有，我对着你提的问题一个个敲回应，结果就这样的。一方面想感谢你理解 Ruby 受了很多误解，一方面又很无奈你也是误解群体的一员。如果在你产生误解之前，能找到个人问那结果可能就不同了。 |
|
36
chloerei 2011-09-12 16:32:06 +08:00
说说这贴没点出来的 ruby/rails 误解
1. Rails 传说中很敏捷，所以学起来是最快的 错误，学习 Rails 花的时间可能比别的框架都多。因为它一方面大包大揽，一方面默认你已经对各个层面的理论有了基本了解，选择 Rails 是因为你已经厌倦了重复制造轮子。但是，学习 Rails 比学习其他语言 + 框架 + 理论 + 最佳实践 + 时髦技术的总代价少，因为它已经为你选择了最受好评的那部分，节省了筛选时间。 2. Ruby/Rails 工作机会少 见仁见智。http://chinaonrails.com 现在招聘帖子很多，但我觉得他们挺难招到人的。有人觉得满大街的招人是安全感，有人觉得适合自己发挥的酷工作才有意义。 3. Ruby 程序员生产力高、一个顶十/玩世不恭、不负责任 Ruby 程序员也是程序员，有靠谱的有不靠谱的，好的程序员总是珍稀资源。 |
|
37
Los OP 1. rails不完美，rails一直在进化，快速的进化，它进化是在开创。而现阶段rails远远抛开了其竞争对手好几条街
2. 如果你真的对rails熟悉，你会发觉rails的一些「约定」可以相当容易打破，但过后你会发觉你自己捣鼓出来的那一堆东西还远远不如遵从rails的「约定」来得好 3. 如果你站在门外，你永远无法想象ruby/rails的社区活跃度是多么的变态，并且这个活跃度并非昙花一现的景象，它已维持了好几年，一个活跃的社区能带来什么你应该会知道 4. 很多人对rails潜意识的抵触是因为误解了其「约定」的本质，以为「约定」就是绝对的「约束」 5. 大部分对rails长篇大论的人没有用rails真正完成过一个项目，有些甚至连真正的使用方法都还没有摸清 |
 |
38
stranbird 2011-09-12 19:28:32 +08:00
rails程序员过来围观一下。
有哪位同学可以解释一下这种语言（编辑器、框架）之间的辩论最后是希望达成什么样的目的？ |
 |
39
huangz 2011-09-12 19:56:22 +08:00
没有目的，也没有结果。就大家掐掐架，打发时间，缓解工作压力，促进生活和谐，等大家的压力排解了帖子就沉下去了，然后一周过去，又来了个人，问了一句“写xxx是用Ruby语言好还是Python语言好”，于是，新的一轮战役再次爆发，Ruby党和Python党之间脆弱的协议再次荡然无存。
关于到底是A语言好还是B语言好的战争必将持续到诺亚方舟扬帆起航那天，必将持续到Perl6发布那天，必将持续到中国房价回归理性那天，必将持续到世界终结那天，必将。。。 |
|
40
keakon 2011-09-12 20:14:28 +08:00
@chloerei
1. 有的东西我不想点明，因为我感觉你是装不知道。 就好像我说这家中国餐馆经常拿臭鸡蛋做菜，有人就会说美国的鸡蛋也是从鸡屁股里出来的一样。 你的回答甚至让我怀疑Ruby的magic就是你猜啊，猜对了就说明它是对的，猜错了说明你的想法是不切实际的。 这句话不是搞笑，我在学习Ruby时确实存在不少困惑，不是因为不懂它的语法，而是不懂为什么要这样设计。随着对它了解的深入，这些质疑让我渐渐摸到了一些规律，似乎接触到了设计者的理念，然后确信这不是我理想中的语言，仅此而已。我也知道肯定有你这种和他观念一致的人，也只有这种人才能学好Ruby。 我想你我都知道对方要表达的意思，既然不愿点破，我也不想就此问题再做回复了。 2. “盛气凌人”指的是教育我“要么就花大把时间去领悟它的好，要么就别指手划脚”的人，并不是对你说的。 我在V2EX遇到过一些这样的Rubyer，认为自己捡了块宝，所有认为Ruby不好的都是SB，能力肯定不如自己，所以没有自己这种超凡脱俗的见解。当然原话没有挑明，但字里行间透露出的语气不是来交流，而是来鄙视的。 很不巧我太过有自知之明了，我相信你也有。 3. 正如前面所说，我对Rubyer的偏见很早就有了。有个形容词我觉得很贴切，不过我觉得他人之言很难入耳，还是自省的好。 我也不掩饰对他们的好感：思维敏捷和开阔，热衷于新技术。但是他们真的不善于表达，就像Ruby一样让我困惑。好在我不是在追妹子，不需要勉强自己与其交流。 对Ruby的偏见倒是自认为没有。我考虑的是“是否适合自己”，而在“语言好不好”这方面我和你的看法是相同的。 所以我也很看不起那些没有思考过什么是自己真正想要的，就盲目去寻找一门“公认”的好语言的人，因为他们把自己看得比语言更低贱。 |
|
42
stranbird 2011-09-12 20:41:13 +08:00
其实我觉得rails和python都只不过现在比较热门⋯⋯ 过后世界应该还是js的
|
 |
44
yuest 2011-09-13 16:53:36 +08:00
@chloerei
@keakon x = save，x 得到的是 save 的值，不论他是方法还是局部变量。或者你觉得 foo.bar 和 foo.bar() 得到不同的结果更符合预期？ 我能理解这样设计是为了一致性。 但是，难道不能得到方法的 reference 吗？ 还有若 save 是方法，比如 obj.save，那么 obj.save.xxx 和 obj.save().xxx 是一样的吗？ |
|
46
yuest 2011-09-13 16:55:45 +08:00
|
Select Language