《ruby元编程》有奖试读中！（获奖名单已公布）

zhlong8

元编程谁也比不上 Lisp 吧，但是毕竟元编程在程序中只占很小比例。Easy things should be easy and hard things should be possible Perl 中这名格言我想很适合这里。日常应用方面 Lisp 相当的悲剧，想要用个模块找不到，处理字符串感觉像在写汇编，数学计算方面前置语法看的人想死……

Ruby 在提供常用功能的情况下让元编程同自己的语言模型比较好的结合起来，这些就够了，作者也没狂妄到要超越 Lisp 吧。

可以省掉调用的括号很有用啊毕竟函数当参数在 Ruby 中更少用，它用 BLOCK 语法省掉了不少高阶函数。另外千万别喷我啊，我也是 Lisp 党

琳琳的小狗

回复 30# OwnWaterloo

其实绕到最后，兄台挖了个坑自己跳下去了。还记得最初的讨论焦点么？导火索来自于《Ruby元编程》中作者有利用Ruby语法优势贬低其他语言（如C++、以及Lisp）的嫌疑。现在回头看看，不正是以FP语言之长来对比Ruby的短板么？

Ruby社区以Pragmatic为宗旨，属于实战派，相比Lisp这种学院派的风格来说，的确是不太一样（当然，你也可以说是因为FP另类）。面向对象语言之所以获得大多数人的关注，其中最大的一个原因就是他尽力去模拟现实生活中的事物，比较符合人类的心智模型，要不然FP这么优雅高级，怎么就流行不起来呢？lua还好点，恕在下孤陋寡闻，还真没在多少场合下见到Lisp的大规模应用。俗话说“工欲善其事，必先利其器”，就那我最熟悉的Web应用开发，以及自动化测试来讲，使用Ruby这类动态语言才是最佳选择。

感觉OO实在是被妖魔化了，如果真如某些人所言，那怎么有这么多语言都以此为卖点？比如javascript，还有风头正旺的Objective C，为何不搞成纯FP呢？个人认为，FP太过于抽象的思维是其受阻的最大原因，另一个原因就是源代码的可读性，Lisp那括号语法，以及前缀表达式，都给初学者带来了不小的障碍。还记得SICP第一章的导言么？作者是这么说的：“程序是写给人看的，机器顺便执行”。同样的道理，映射到Ruby中来，方法调用可省略括号、各种操作符比如加号的语法糖，无一不是为了实现整洁、易读的代码而设计的，《Ruby元编程》一书中指代的“程序员友好”就在这里。

至于我的回帖中引入Ruby实现的Lisp解释器，仅仅只是想说明，如果你愿意，使用这种带有一定约束条件的内部DSL，也是完全可以实现FP那些特性的。但是，可以归可以，为什么没人去这么干呢？这是个问题。Rubyist一般都会采取最简单的办法来实现手头的任务，如果开发过程中，真要我去实现一个map，那我顶多这么做：

1. def map(operate, *args)
   
2.   args.shift.zip(*args).map {|pair| pair.reduce operate}
   
3. end
   
4. 
   
5. p (map :+, [1, 2, 3], [4, 5, 6], [7, 8, 9]) #输出[12, 15, 18]
   
6. p (map :push, [[1, 2],[3,4]], [5,6], [7, 8]) #输出[[1, 2, 5, 7], [3, 4, 6, 8]]

复制代码

的确，正如你说，利用了zip和reduce，但是就API的使用者而言，真的有区别么？拿BDD的理论来比拟，客户是关注你软件的内部实现细节，还是更关注于产品的功能和行为？

大乘佛藏经虽然牛逼，可以普度众生，还不是需要唐僧师徒一行远涉万里西天取经么？同理，如果没有人推广传授，FP可能永远都是实验室那些科学怪人们的小蜜，仅此而已。所以我倒是觉得，其他语言能借鉴其中好的思想，并将其应用到实战总来，这绝对是有百益而无一害的好事情。他山之石可以攻玉，在Ruby社区这样一个满怀包容性、以及上进心的生态环境中，作为其中的一员，我很欣慰。还是那句老话，切莫跑题，先抛弃成见，就这本书的内容进行展开讨论吧：）

2gua

狂热的PK，能让人热血沸腾，但转过身之后，还需要大家冷静、理性地选择合适的技术，总之，我喜欢Ruby！

wenxin588

还可以吧，没什么特别的感觉，技术类的图书都差不多。。

OwnWaterloo

回复 31# zhlong8

>> 但是毕竟元编程在程序中只占很小比例
no。 是因为元编程在其他语言里不容易，所以才占很小比例。


>> 日常应用方面 Lisp 相当的悲剧
目前我也觉得是这样。

讨论语言时，一部分人是将语言、语言实现、语言所在环境一起在讨论。
而一部分人，比如我在这个帖子里，是仅仅讨论语言本身。

因为这几者本来就是分开的概念。
例如，Java语言（实现只有一个）很烂，但JVM环境还不错，至少很丰富，移植性很好，安装程度也很普遍。
于是clojure（实现也只有一个）出现了，lisp+JVM……  等haskell学完了（学得会么我……）下一个可能就是它了……
又或者haskell遇到瓶颈了（已经遇到了……） 与clojure同步学……

类似的，Lua是一个好语言，也是一个好的实现。但环境就匮乏了。
于是虽然我没事就挑Python/emacs lisp毛病，但日常应用方面还是得用它或者emacs lisp……


>> 数学计算方面前置语法看的人想死
可以自己写个宏，将表达式从中缀解析为后缀。
如果数学计算的比例很多的话。


>> 作者也没狂妄到要超越 Lisp 吧。
我想作者应该没有。 但用户呢？

有Python程序员，甚至是个知名人士，宣称Python是lisp —— 《关于Lisp最迷人的故事》。
JS也想参合，说JS=C+Lisp，（文章名我忘了，因为内容太狗血了…… 。
说是因为JS学了C的语法…… C的语法毫无亮点，中缀声明是被诟病的存在好吗……
而从Lisp里学了什么我真没看出来……  因为JS的设计者是个scheme程序员？
或者是gc？ dynamic typing？ first class function？ closure？ 我都不好意思说if-else与recursion了……  但是， who doesn't ？

而Ruby，貌似有篇文章名字叫做： ruby is an acceptable lisp。
观点有2：
1. ruby语法比lisp好
2. lisp元编程功能的80%在ruby中都可以实现

我是学了lisp之后才明白为什么这些语言都想与lisp扯上关系：真像给自己脸上帖金了一样。
但没有一个学到了lisp的精髓。 syntax friendly从来就不是lisp的精髓， 而且会影响AST的直观性。
所以ruby那篇第1个观点就站不住脚。 第2个观点我很怀疑80%这个数据。
也许能完成80%的功能， 但不是以lisp的元编程的方式。
直到现在我都不能肯定ruby里能够code transformation。 而且即使能， 多样的语法也许也会造成转换时的障碍。


>> 可以省掉调用的括号很有用啊毕竟函数当参数在 Ruby 中更少用，它用 BLOCK 语法省掉了不少高阶函数。
我没说它没用……
block语法，不是1st class value，需要Proc.new/lambda后才是。 这也许是松本一开始的设计失误。
省略调用的括号更是让函数也降级了， f 也不是 1st class value， 需要 method 后才是。 这是"友好"语法产生的代价。
一个影响函数传出，一个影响函数传入…… 这还怎么算是函数式语言？

注意……  我前面也强调了， 不是说Ruby就一定要有lisp那样元编程， 就一定要支持FP。
它不支持是它的选择。 如果能用其他方式，比如OO，表达思想依然没什么可挑剔的。
但是：
1. 许多表达不是OO专属的，仅仅只是Ruby这么选择了
2. 如果Ruby不支持lisp那样的元编程， 就不要说它支持
3. 如果Ruby对FP的支持是这种样子…… 至少没法说服我Ruby是个函数式语言……

与上面的X语言是否是Lisp一样。 许多语言也称自己是函数式…… 就像java说自己支持generic……
其实FP并不是个很精确的定义， 但它常使用的那些构造就有比较精确的定义。
在这些定义下这些号称FP的语言各有各的问题，而Ruby的问题是很严重的。 前面已经说了这里就不重复了。



>> 另外千万别喷我啊，我也是 Lisp 党
我像在喷人么……  我一般只会喷Java、OO、设计模式等等…… 现在也有点懒得喷了……

OwnWaterloo

回复 32# 琳琳的小狗

>> 其实绕到最后，兄台挖了个坑自己跳下去了。还记得最初的讨论焦点么？导火索来自于《Ruby元编程》中作者有利用Ruby语法优势贬低其他语言（如C++、以及Lisp）的嫌疑。现在回头看看，不正是以FP语言之长来对比Ruby的短板么？

承认FP是Ruby的短板了？  那我部分目的也达到了。

我一直记得讨论是怎么展开的：
1. 我认为那些技术不是OO的专利，只是Ruby选择了OO来实现这些功能
2. 你质疑我对OO的质疑
3. 因为我听许多人（不仅仅是你）说Ruby是FP语言， 而我知道这两种风格结合在一起很容易出问题

于是将那些容易出问题的地方向你请教， 结果发现Ruby为了省略调用括号连1st class function都不支持……

而且我一直在强调…… 这很重要，我再重复一次……
不是说Ruby必须支持FP，它支持OO也没什么可挑剔的。
而是说1) Ruby的那些功能不是OO的专利 2) 就不要再说Ruby对FP的支持很好了好吗……

OwnWaterloo

回复 32# 琳琳的小狗

关于OO的流行，与FP以及Lisp的不流行。  记得前面你说的"不流行不代表不好"吗？

说OO符合人类的心智模型，其实是在说OO扯低了程序员的整体水平。
3.times ...  a.push(x) 才符合人类心智？ 而times(3, ...) push(a,x) 就不行？ 这抽象思维水平是得有多低？
而且前者是后者的特殊化， 这种特殊化会另语言变得很复杂。 前面js与python的反例我举了， lua的正例我举了。
ruby的oo方面我接触到的那一块 —— 整个ruby中的一小部分 —— 已经比lisp整体复杂了 ……

OwnWaterloo

回复 32# 琳琳的小狗

关于你那行代码 map :push, [[1, 2],[3,4]], [5,6], [7, 8]
我似乎看到了ruby的希望， 只是不知道ruby是如何解释这一行为的。

关于这里的语法问题，以及省略调用括号，加法操作符等等等等……
语法简单不等于语意简单。 有一个语法使得看代码看上去好看， 写起来舒服， 但代码是否真如看上去那样的运作？
于是无论语法如何简炼， 系统的学习一门语言终归是要学习它的语意。

lisp的语意 —— 此处特指emacs lisp，因为cl/scheme是标准化的，由一两个实现去解释标准不合适……
我可以在10句话、200字以内说解释完。
其余的都是由语言自己实现的， 可以通过上面的核心语意去看这些机制的准确定义。

而lisp的语法更是没什么好说的了…… 它的目的就是为了代码写成什么样子， 就读(read procedure)做什么样子……

ruby能做到吗？

OwnWaterloo

回复 32# 琳琳的小狗

>> 所以我倒是觉得，其他语言能借鉴其中好的思想，并将其应用到实战总来，这绝对是有百益而无一害的好事情。

也许ruby借鉴了smalltalk，但smalltalk我不了解……
但我了解smalltalk有一个特性， 叫image-based execution。 如果有兴趣也许会去了解， 不过这东西在cl里面也有， 也许不会有那个空闲。

lisp我了解，ruby从lisp里借鉴的 —— 排开其他许多语言都已经借鉴过的 —— 是expression only。 这是值得肯定的。
但仅仅为了调用省略括号就抛弃1st class function…… 我觉得代价太大……
C我了解，我没看出ruby从C里借鉴了什么…… 难道只是因为C、Lisp招牌响亮就要说自己是它们的后继？


>> 他山之石可以攻玉，在Ruby社区这样一个满怀包容性、以及上进心的生态环境中，作为其中的一员，我很欣慰。
no, Ruby是排外的， 前面已经说了它排斥FP与编译。


>> 还是那句老话，切莫跑题，先抛弃成见，就这本书的内容进行展开讨论吧：）

我有成见吗？ 我指出的那些问题难道不是事实？ 只是我对ruby的误解？
关于跑题…… 这帖人气高啊…… 要另外去开一帖： ruby不是函数式语言， 就没人来了啊……  我就学不到东西了啊…… 码这么多字还干嘛呢……

lcqtdwj

回复 39# OwnWaterloo


    Lisp是很强大，但是复杂度太高了。语言的目的是交流，不运用就没有价值。所以Lisp与其说是语言不如说是理论。就像大部分科学家潜在的内心都对数学家有所嫉妒，有所自卑。诸多语言都羡慕Lsip的强大，并且从中吸取养分。所以两者没有什么可比性。