w***g 发帖数: 5958 | 1 C的macro基本上就是过街老鼠人人喊打。
C++11以后基本上就完全不需要用macro了。
为啥lisp的reputation就没被macro影响呢?
我觉得是lisp用的人太少。版上的lisp用户怎么看? |
c******n 发帖数: 16666 | 2 C的没用过
但这玩意绝对是我对C++最深恶痛绝的东西了 |
g****t 发帖数: 31659 | 3 只用10年以上没变过的广为流传的macro作为语言的补充。 |
h*i 发帖数: 3446 | 4 别的Lisp不熟。Clojure社区里面,不鼓励用macro. Macro一般只用于作为library的用
户界面,提供DSL。应用程序一般不用macro。
因为macro不如函数composable, 比如a, b, c, d是macro的话,你不能((comp a b c
d) input), 而如果他们是函数,就可以随便往上垒高阶函数。
当然,要论composability, 函数还不如数据。所以在Clojure里面,优先级是Data >
Function > Macro
【在 w***g 的大作中提到】 : C的macro基本上就是过街老鼠人人喊打。 : C++11以后基本上就完全不需要用macro了。 : 为啥lisp的reputation就没被macro影响呢? : 我觉得是lisp用的人太少。版上的lisp用户怎么看?
|
e*******o 发帖数: 4654 | 5 现在还用lisp的都是死忠,因为macro才不换.
如果lisp去掉macro,就是perl, js, python. |
O***b 发帖数: 104 | 6 不过我看 Clojure 玩的早的那帮人做出来的轮子,都没少用 macro. 我个人比较懒,
遇到 macro 的代码一律跳过不读,默认里面黑魔法云集,就当写代码的人已经炼丹炉
炼过了。
应该是写 DSL 或者解释器的时候少不了用宏,是这个情况吧
c
【在 h*i 的大作中提到】 : 别的Lisp不熟。Clojure社区里面,不鼓励用macro. Macro一般只用于作为library的用 : 户界面,提供DSL。应用程序一般不用macro。 : 因为macro不如函数composable, 比如a, b, c, d是macro的话,你不能((comp a b c : d) input), 而如果他们是函数,就可以随便往上垒高阶函数。 : 当然,要论composability, 函数还不如数据。所以在Clojure里面,优先级是Data > : Function > Macro
|
h*i 发帖数: 3446 | 7 就是这样,macro是给做轮子的人用的,应用程序员不应该用。
而且,早期的Clojure人士都在瞎蒙,并不知道Clojure的优势在什么地方。早期的轮子
,比如storm之类的设计,现在看起来就并不适合Clojure。
现在比较清楚了,Clojure的优势是data oriented programming. 所以现在Clojure的
发展方向也是在强化这块,花了很大功夫搞spec啥的。
就算搞DSL,现在也不太用宏了,而是直接上数据结构。比如新的轮子,onyx这些,DSL
就是Clojure数据结构,不用宏。我公司搞的DSL也是这样的。总之以数据为中心的体系
机构很灵活,逻辑不依赖于实现,很容易进化,适应性强。
往大里说,这有点生物的DNA的味道了。我觉得这是发展方向。
【在 O***b 的大作中提到】 : 不过我看 Clojure 玩的早的那帮人做出来的轮子,都没少用 macro. 我个人比较懒, : 遇到 macro 的代码一律跳过不读,默认里面黑魔法云集,就当写代码的人已经炼丹炉 : 炼过了。 : 应该是写 DSL 或者解释器的时候少不了用宏,是这个情况吧 : : c
|
h*i 发帖数: 3446 | 8 这个不太对。
Clojure的绝大部分用户都是从Java, ruby, python这些转过来的。很少有从其他Lisp
转到Clojure的。大部分Clolurians对macro没有什么感情,用Clojure不是因为macro,
而是因为functional programming。
而FP, 要么就是haskell这派的,要么就是Clojure这派的。这是两种不同的人,前者
觉得人是不可靠的,需要工具帮忙;后者觉得,若为自由故,一切皆可抛。
这两种人,即使一开始结婚了,最后还是会分手。比如Facebook买的wit.ai, 一直是个
Clojure店,最近宣布要用Haskell重写。
【在 e*******o 的大作中提到】 : 现在还用lisp的都是死忠,因为macro才不换. : 如果lisp去掉macro,就是perl, js, python.
|
a*****g 发帖数: 19398 | 9 好好写,注意些细节,是没问题的。
【在 w***g 的大作中提到】 : C的macro基本上就是过街老鼠人人喊打。 : C++11以后基本上就完全不需要用macro了。 : 为啥lisp的reputation就没被macro影响呢? : 我觉得是lisp用的人太少。版上的lisp用户怎么看?
|
a*****e 发帖数: 1700 | 10 现代的 Lisp(比如 Racket 或者 scheme)基本上都是 sanitized macro,主要用途也
是 meta programming,方便实现 DSL,所以大可不必谈之色变
Python 的 decorator, Julia 的 macro,都是类似的意思
C 语言那种 macro 早就应该被淘汰了,或者说已经被淘汰了
不清楚区别的可以看看 wikipedia 的解释:
https://en.wikipedia.org/wiki/Hygienic_macro
【在 e*******o 的大作中提到】 : 现在还用lisp的都是死忠,因为macro才不换. : 如果lisp去掉macro,就是perl, js, python.
|
|
|
b*******s 发帖数: 5216 | 11 macro有时可以大幅度提高可读性
【在 w***g 的大作中提到】 : C的macro基本上就是过街老鼠人人喊打。 : C++11以后基本上就完全不需要用macro了。 : 为啥lisp的reputation就没被macro影响呢? : 我觉得是lisp用的人太少。版上的lisp用户怎么看?
|
w***g 发帖数: 5958 | 12 写lisp的好像从来不说refactor。这个macro好像不利于ide自动分析代码。
【在 a*****e 的大作中提到】 : 现代的 Lisp(比如 Racket 或者 scheme)基本上都是 sanitized macro,主要用途也 : 是 meta programming,方便实现 DSL,所以大可不必谈之色变 : Python 的 decorator, Julia 的 macro,都是类似的意思 : C 语言那种 macro 早就应该被淘汰了,或者说已经被淘汰了 : 不清楚区别的可以看看 wikipedia 的解释: : https://en.wikipedia.org/wiki/Hygienic_macro
|
e*******o 发帖数: 4654 | 13 哈哈 你一下子戳到痛处
lisp写下来 除了原作者 谁敢动啊
当然 lisp大牛写的代码 可能不需要refactor
【在 w***g 的大作中提到】 : 写lisp的好像从来不说refactor。这个macro好像不利于ide自动分析代码。
|
g****t 发帖数: 31659 | 14 现在refactor说的都是oo的吧?
代码重写一个版本lisp肯定也有不一定叫相同的名字
: 哈哈 你一下子戳到痛处
: lisp写下来 除了原作者 谁敢动啊
: 当然 lisp大牛写的代码 可能不需要refactor
【在 e*******o 的大作中提到】 : 哈哈 你一下子戳到痛处 : lisp写下来 除了原作者 谁敢动啊 : 当然 lisp大牛写的代码 可能不需要refactor
|
h*i 发帖数: 3446 | 15 不要瞎说哦。
Lisp的主要工作方式就是不停的refactor。所谓REPL driven bottom-up development,
"Lisp is not a language, it is a building material",这些都是一个意思,就是
写Lisp就是要不停的refactor,这是Lisp的生命所在。
作为一个vim person, 我用spacemacs的唯一原因就是emacs的Clojure layer (叫做
CIDER)有方便的refactor的功能. Clojure在IntelliJ的IDE(叫做Cursive),也有很强
大的refactor功能。
现在Clojure引入了spec,自动分析功能以后会更强。
【在 w***g 的大作中提到】 : 写lisp的好像从来不说refactor。这个macro好像不利于ide自动分析代码。
|
h*i 发帖数: 3446 | 16 不要不懂装懂哦。
我这天天写Lisp,带过一群新手从Lisp零经验,到三个月之后出产品上线的,可以负责
任的说,refactor是Lisp的生命。
【在 e*******o 的大作中提到】 : 哈哈 你一下子戳到痛处 : lisp写下来 除了原作者 谁敢动啊 : 当然 lisp大牛写的代码 可能不需要refactor
|
e*******o 发帖数: 4654 | 17 你写的clojure,如果不用macro的话,跟Python一样,不是我们讲的lisp。
refactor 没有test,我是不敢动原来的代码。
【在 h*i 的大作中提到】 : 不要不懂装懂哦。 : 我这天天写Lisp,带过一群新手从Lisp零经验,到三个月之后出产品上线的,可以负责 : 任的说,refactor是Lisp的生命。
|
h*i 发帖数: 3446 | 18 Clojure就是Lisp。Clojure语言核心很多都是macro,最基本的比如fn, loop, for,
and,or这些都是macro。所以用macro不是什么问题,只要是大家通用的macro。不鼓励
应用程序员自己写macro主要是为了提高代码可读性和composibility。
所有Lisp的一个共同点就是REPL driven, keep evolving a live image of running
code,这都是为了支持不停的refactor代码。这种编程模式与Java这类语言是完全不同
的,很多人一开始不习惯。因为refactor可能太根本了,所以Lisp programmers don't
think it should have a name?
还有我觉得用Clojure的一个好处就是改代码的胆子更大了。主要有两个原因,一个大
多数代码都是纯函数,所以改动只是影响局部,不影响全局;二是immutable data by
default,随便改,别的地方不会受影响。
【在 e*******o 的大作中提到】 : 你写的clojure,如果不用macro的话,跟Python一样,不是我们讲的lisp。 : refactor 没有test,我是不敢动原来的代码。
|
x***4 发帖数: 1815 | 19 很好。refactor,immutable data,没这两个我都不想写code了。
't
by
【在 h*i 的大作中提到】 : Clojure就是Lisp。Clojure语言核心很多都是macro,最基本的比如fn, loop, for, : and,or这些都是macro。所以用macro不是什么问题,只要是大家通用的macro。不鼓励 : 应用程序员自己写macro主要是为了提高代码可读性和composibility。 : 所有Lisp的一个共同点就是REPL driven, keep evolving a live image of running : code,这都是为了支持不停的refactor代码。这种编程模式与Java这类语言是完全不同 : 的,很多人一开始不习惯。因为refactor可能太根本了,所以Lisp programmers don't : think it should have a name? : 还有我觉得用Clojure的一个好处就是改代码的胆子更大了。主要有两个原因,一个大 : 多数代码都是纯函数,所以改动只是影响局部,不影响全局;二是immutable data by : default,随便改,别的地方不会受影响。
|
r*****z 发帖数: 906 | 20 C的macro和lisp的macro完全不同。C的macro是实现了一门和宿主语言实在没啥关系的
迷你语言,而且非常受限,所以才会那么危险。lisp的macro是lisp编程的核心。在
lisp中编程就是在不停地使用macro,并且在必要的时候设计新的macro。 |
|
|
T*******x 发帖数: 8565 | 21 数据怎么compose,能不能举个例子?
c
【在 h*i 的大作中提到】 : 别的Lisp不熟。Clojure社区里面,不鼓励用macro. Macro一般只用于作为library的用 : 户界面,提供DSL。应用程序一般不用macro。 : 因为macro不如函数composable, 比如a, b, c, d是macro的话,你不能((comp a b c : d) input), 而如果他们是函数,就可以随便往上垒高阶函数。 : 当然,要论composability, 函数还不如数据。所以在Clojure里面,优先级是Data > : Function > Macro
|
c*********e 发帖数: 16335 | 22 macro从来没在工作中用过。
【在 w***g 的大作中提到】 : C的macro基本上就是过街老鼠人人喊打。 : C++11以后基本上就完全不需要用macro了。 : 为啥lisp的reputation就没被macro影响呢? : 我觉得是lisp用的人太少。版上的lisp用户怎么看?
|
h*i 发帖数: 3446 | 23 函数compose的方式是有限制的,两个函数通过传参数来compose。数据compose是没有
限制的,两个数据结构如何compose是完全任意的。
data oriented programming就是把程序的逻辑用数据结构表达。这其实在分布式计算
已经用得很多了,各种逻辑可以变成数据结构在节点间传来传去。而Clojure社区现在
意识到,其实单机程序也可以这样写。一个逻辑,能用数据机构表达的,就用数据结构
表达,这样更灵活。
这个关于data的地位的问题,Alan Kay(就是因为Smalltalk拿图灵奖那位)与Rich
Hickey(就是发明Clojure的那个民科)还在hackernews上有一个争论https://news.
ycombinator.com/item?id=11945722)。前者认为"Data is a bad idea", 因为data总
是需要一个interpreter。后者认为Data是客观存在的,是第一位的,如何interpret是
第二位的。搞计算机技术,要以第一位的东西为中心。
显然,我是同意Rich Hickey的观点的。因为其实最终的interpreter,是在人的脑子里
面。就算再多的type checking, proof, blah blah, 最后还是要人来决定这个程序的
结果是对还是不对。不要以为程序能搞定这个interpreter的问题。
还有一个支持Hickey观点的arugment,是从信息论的角度,就是“信息永远不会增多”
的定理(https://en.wikipedia.org/wiki/Data_processing_inequality)。加个
interpreter不会增加任何信息。哈哈。
可惜OOP的祖师爷觉得Object应该成为这样的interpreter. 他举出的理想技术居然是一
个人造的用来与外星人通话的语言。所以我觉得图灵奖得主和民科似乎换位了。哈哈。
No wonder OOP is doomed to fail. It's philosophically and mathematically
unsound.
【在 T*******x 的大作中提到】 : 数据怎么compose,能不能举个例子? : : c
|
T*******x 发帖数: 8565 | 24 听着有点意思。但是有点抽象。
【在 h*i 的大作中提到】 : 函数compose的方式是有限制的,两个函数通过传参数来compose。数据compose是没有 : 限制的,两个数据结构如何compose是完全任意的。 : data oriented programming就是把程序的逻辑用数据结构表达。这其实在分布式计算 : 已经用得很多了,各种逻辑可以变成数据结构在节点间传来传去。而Clojure社区现在 : 意识到,其实单机程序也可以这样写。一个逻辑,能用数据机构表达的,就用数据结构 : 表达,这样更灵活。 : 这个关于data的地位的问题,Alan Kay(就是因为Smalltalk拿图灵奖那位)与Rich : Hickey(就是发明Clojure的那个民科)还在hackernews上有一个争论https://news. : ycombinator.com/item?id=11945722)。前者认为"Data is a bad idea", 因为data总 : 是需要一个interpreter。后者认为Data是客观存在的,是第一位的,如何interpret是
|
g****t 发帖数: 31659 | 25 他的意思可能就是多用lookup table
少if else?
: 听着有点意思。但是有点抽象。
【在 T*******x 的大作中提到】 : 听着有点意思。但是有点抽象。
|
n******t 发帖数: 4406 | 26 誰喊打了?你去看看kernel source code呢。
我認為template純粹誤人子弟,用來寫庫就算了,作為一個普遍的technique幾乎沒有
好處。
【在 w***g 的大作中提到】 : C的macro基本上就是过街老鼠人人喊打。 : C++11以后基本上就完全不需要用macro了。 : 为啥lisp的reputation就没被macro影响呢? : 我觉得是lisp用的人太少。版上的lisp用户怎么看?
|
h*i 发帖数: 3446 | 27 guvest虽然不是码农,用词也许不一定准确,但理解能力一流。
不一定是lookup table,而是各种数据结构:hashmap, list, vector, set, 等等。其
实现在流行的各种的service oriented architecture, REST, protobuf之类,都是在
往这个方向走。再往前稍微走一点点,就是程序里面也用这些,就成了面向数据的编程
了。 哈哈。
总之,如果解释器(也就是程序, 或者是guvest说的"if else")不能凭空给数据赋予
意义(根据信息处理不等定理),那么,你还不如简单直接地把数据传来传去,而不用
搞些对象啦,方法啦,等等来脱裤子放屁,因为这些增加的玩意不但不能增加信息,其
实还会减少信息。
【在 g****t 的大作中提到】 : 他的意思可能就是多用lookup table : 少if else? : : : 听着有点意思。但是有点抽象。 :
|
g****t 发帖数: 31659 | 28 不敢说每天,我每周都写代码的。很多很多年了。
现在本职出一些spec,有专家写代码。
我是正经EE科班出身。数据结构上过课.
【在 h*i 的大作中提到】 : guvest虽然不是码农,用词也许不一定准确,但理解能力一流。 : 不一定是lookup table,而是各种数据结构:hashmap, list, vector, set, 等等。其 : 实现在流行的各种的service oriented architecture, REST, protobuf之类,都是在 : 往这个方向走。再往前稍微走一点点,就是程序里面也用这些,就成了面向数据的编程 : 了。 哈哈。 : 总之,如果解释器(也就是程序, 或者是guvest说的"if else")不能凭空给数据赋予 : 意义(根据信息处理不等定理),那么,你还不如简单直接地把数据传来传去,而不用 : 搞些对象啦,方法啦,等等来脱裤子放屁,因为这些增加的玩意不但不能增加信息,其 : 实还会减少信息。
|
a****a 发帖数: 5763 | 29
macro 的确是极大的错误
实际上在我看来,任何基于机械式的文本替换都是问题
lisp里的macro问题太大了,基本上稍微大的lisp程序, macro多了就没法读
编程语言,不管哪个,我最讨厌的几个特性, macro一个, 排版决定语义算一个,纯
OO算一个
python基本算是我最厌恶的语言格式了
我一直觉得pascal的程序是最漂亮的
【在 w***g 的大作中提到】 : C的macro基本上就是过街老鼠人人喊打。 : C++11以后基本上就完全不需要用macro了。 : 为啥lisp的reputation就没被macro影响呢? : 我觉得是lisp用的人太少。版上的lisp用户怎么看?
|
r*****z 发帖数: 906 | 30 guvest,你是system engineer? |