命名难，难于上青天

三月廿七

感觉 lisp 是科研人员用的

OwnWaterloo

OwnWaterloo 发表于 2012-02-10 19:00
比如链表的length()，可以没有对应的成员，直接数。（btw：C++标准要求std:: list:: size常数时间返回，所以std:: list 是有这个成员的）

此处有错误。
size() 常数时间是C++0x draft新增加的， C++03并没有， 是我弄错了。
而且C++11不一定有，我这里没有最终版本(400美刀好贵的)，但我这里的其他draft都说必须常数时间。

感谢xyfree同学指正。

sonicling

回复 142# OwnWaterloo


    网上有最终版本

INTERNATIONAL
STANDARD
ISO/IEC
14882
Third edition
2011-09-01

Information technology — Programming languages — C++
Technologies de l'information — Langages de programmation — C++

赶紧去下。
的确没说list::size()。

OwnWaterloo

回复 143# sonicling

盗版神马的，才不会做呢
不是在list相关的地方说的，而是在container requirements里面。
早先draft里size()在complexity列里面是标记为note A，后续说被标记为note A的必须是常数。
后续draft里size()在complexity列里直接就被标记为constant。


于是又去翻了C++03的相同部分……发现也是有note A，后续说note A必须是常数。
为什么不将constant直接写在complexity列里？
这问题到底是怎么回事……
我糊涂了……

walleeee

回复 140# OwnWaterloo

我还是觉得语言的简洁、优美、强大，很难比得上有丰富的库……

很赞成，但是加4个字“好用，一致”

之后又用ocmal重写

为什么不用haskell，这个库很多啊？

infix notation已经是主流了， 它们不愿意改

不是，而是中缀更符合数学的思维

你指的是算术运算符？  x = 2 * y 与 = x * 2 y？

你看那个更好看？更易懂？当然，我是指对从没接触过c也没有接触过Lisp的人，即新手。

lisp里面其实是 (= x (* 2 y)) 而不是 = x * 2 y。

我懂lisp的语法，我这么写只是方便，更是讨厌一大堆括号。看(= x (* 2 y))这种代码，我要注意看到1个=，我就要看到x才知道是对x的赋值，然后看到一个*，要记得前面有个=赋值，(* 2 y)的返回会被赋值给x。你不解决这里存在一个记忆栈？尽管x=2*y也存在一个记忆栈，但是我只需要时刻关注当前的，看到x后面的=，知道是对x的赋值操作，那么赋什么值，后面就是。这是顺向的思维，更接近于人的思考习惯。lisp注重的是当前做的事，而c等则关注的是当前被操作的物。

lisp自然也是可以写 x = 2 * y 的……  这可是lisp……

算了吧，我知道你是lisp。前缀，中缀，还是后缀都只是文法形式，计算能力确是图灵等价的，没有任何区别，现在的语言计算能力其实和汇编是等价的。唯一不同，就是现在的东西视乎用起来稍微方便一些而已。就像knuth说的，计算机编程语言领域已经30多年没什么进步了。

并不是特别复杂的事， 为什么没人这么做？

虽然有时候我们需要很多选择，但是最终只会用一种方法来做，这个方法就是各人认为‘最好’的，而这个‘最好’也在在别人看来确并不那么完美。总之，我近来的观点是，不管什么方法，一致的使用才是关键，天下大同才是进步。

这对初学者也是一个问题？

我觉得是中缀更符合数学表达，这个东西可是几万年前就有了啊，也是人主要需要学习的东西之一。所以这里的‘初学者’是不存在的，除非不是人类，而且从小不学数学。当然，说Lisp好用，并实际使用到工作中的人有，至少写《黑客与画家》那个作者就是用lisp发家的，还有一些人也喜欢用lisp来标榜自己，因为用lisp的人实在是太少了，而且视乎在语言领域的地位很高，是鼻祖级别的，会这个是一个荣耀。我没有大量使用过Lisp，只是以前用了2年的emacs，编了一些插件（几个），写了一些配置（3000+行），所以估计不会超过1万行，也看了很多emacs插件的代码而已。我在这里说lisp，感觉有点不好意思，总之个人观点而已，交流学习。

以及你提到的SICP

这个书好像就是Mit还是斯坦福的入门课教材，好像是斯坦福，不记得了。此书的确另类，但是也是一本好书。我觉得它更偏重理论，而面向编程人员的不多啊。

还是说python吧， 它也能够将代码解析为一个树， 然后操作， 然后再编译为代码。
但python在source里面写的东西，与解析得到的树， 在感官上相差太多了。
而lisp，写作什么基本上就读作什么。在这里反而不需要在人脑中维护一个栈并完成text->tree的转换， 因为代码本来就写成tree的样子了。

对，其实一切都是树，一切都是选择，所有东西都是状态和迁移，也就是静和动，这个就是哲学的高度了，呵呵。但是我不太明白你这里说"人脑需要维护一个栈并完成text->tree的转换"。我觉得我写程序没有刻意去text->tree啊？可能是潜意识吧，但是我还是坚持中缀比较好理解。罢了，您给我举几个个大于10万行代码的某项目使用lisp写的吧，除了emacs，haskell两个。（我曾经在哪里看到过有个航空系统是Lisp写的，30万行，好像后来改用其他语言了，c++？）

元编程听说好像很强，但是接触的少，这里不讨论了。


ps.
和你讨论学到很多东西，感谢！

walleeee

回复 137# OwnWaterloo


   

玩法越灵活的语言，在可以玩出很好的表达的同时，更容易产生很糟糕的表达。

折中吧，看实际，选工具。

walleeee

回复 138# OwnWaterloo


    一门好的语言应该提供可嵌入的接口，让程序员能灵活的选择解决问题的方式。高层语言对底层语言的支持现在大多都是靠动态库来实现。我在想有没有可能实现类似cgi的功能：
A语言balabala B语言balabala A语言balabala....
然后用A语言的编译器或解释器会自动把其中B的代码给B的编译器或解释器来执行，甚至只是编译成native的。好像在编程语言中嵌入sql一样，有工具生成代码，但是这个更高层。

walleeee

回复 144# OwnWaterloo


    http://gcc.gnu.org/projects/cxx0x.html
这里看c++11的各个条款要求。还有，标准最后那个draft应该比较靠谱吧。

OwnWaterloo

回复 145# walleeee

元编程可以解决很多问题。
一种机制解决许多问题，而不是每个问题一个机制，导致语言根本就没法学完，比如C++。更好过那些根本就不想解决这些问题的语言。

比如现在就在首页的，吐槽不支持二进制literal。
程序员肯定知道如何将二进制的字符串表达，比如"111"转换成整数表达，7，只要一个int int_from_string(char const* s, int radix);
问题是这个函数是运行时而非编译时。

C++终于通过添加了user defined literal，可以让上面那个函数在编译时求值，获得一个编译时的值。
这是通过添加一种非常专用的机制。谁能预料到是否还有其他需求呢？有的话又在添加另外的机制？并且等到下一个标准支持，编译器实现？


在lisp里面根本就不需要等待语言去支持，lisp(至少el/cl)已经通过一种非常范化的机制提供了足够的支持。
而且在lisp里面，编写这种程序与编写其他的运行时使用的程序使用的是同一套机制。

比如emacs lisp里，运行时字符串到整数的转换是： (string-to-number "111" 2) ; => 7
让它在编译时被求值可以定义一个宏：

1. 
   
2. (defmacro 0b (s) (string-to-number s 2))
   
3. (setq x (0b "111"))
   

复制代码

编译上面的代码，就可以发现x是直接被设置为7而不需要运行时计算。

这是因为子程序(setq x (0b "111"))在编译时展开，得到另一个子程序，同时也是编译器最终编译的程序：(setq x 7)。
metadata是描述数据的数据，metaprogram就是产生程序的程序。

还可以让上面的程序在语法上更像C一点，比如：(setq x (c-style-literal 0b111) y (c-style-literal 0x7))。
cl还支持一种叫read-macro的东西，可以让代码更像一个literal， 比如： (setq x @b111 y @bx7)。
它可以在read-time将@b111转换为(c-style-literal 0b111)并让evaluator继续求值，甚至可以直接进行更多的计算返回7。
program-text -(read)-> lisp-object -(eval)-> result
可以在不同时期将程序转换为另一个程序让余下部分继续计算。


还是binary literal的例子，再从另一个角度说某种技术的易用性。
在C与C++03里，如果确实需要，是可以完成的。boost有个预处理库，可以BIANRY(111)。
C++可以 binary_literal<111>::value。
但因为它们的实现太繁琐（或者说猥琐）了，权衡一下，不如直接写0x7算了……
直到C++11，才让0b111真正可用。

现在可以说明你的疑问了：
>> 我觉得我写程序没有刻意去text->tree啊？
那是因为python里面要将程序transform到另一个程序太困难，所以这种技术不具有实用性。
自然就很难训练出code transformation这种思维，也就不会去想text->tree这回事。

OwnWaterloo

回复 145# walleeee

>> 罢了，您给我举几个个大于10万行代码的某项目使用lisp写的吧，除了emacs，haskell两个。
现在说这个。如果真要我回答，我也只会去google而已…… 或者可以去问问"冰河"。
另外，比如Java编写的成功的项目肯定多得多，这能说明Java语言本身很好么？
所以我从其他方面说：越是具有表达能力的语言，越不会受到商业重视。

首先，鉴于lisp的表达能力，10万行已经是很大很大的项目了。
如果退一步，万行左右的lisp项目，我感觉依然不会很多（相对于其他主流语言的项目而言）。
这里想说lisp不能很好投入工业使用的另一个可能的原因： 这东西太难控制了。

以C++作为对比，它在难以控制方面与lisp很像。
那些各种特性可以写出很好的代码，但更容易被玩脱，写出很糟糕的代码。
存在各种公司出台的《XXX C++编码规范》，说白了就是这不许用那不许用。宁可减少写出一些好代码的可能也要禁止更可能出现的坏代码。
即使这样做过裁剪，也越来越难招到合格的C++程序员。我想除非不得不用C++的部分，公司是不愿意用C++写的。

lisp在这些方面比C++更极端。我倒是见过已经用lisp写成的项目被其他语言改写的，比如yahoo某某东西从cl改到python。
而反过来的例子可能就找不到了……
这里编程语言只是公司为获取利益而选取的工具，工具对程序员是否顺手并不是他们最首要考虑的因素。

于是lisp很可能一直就是这样的地位：黑客小打小闹的玩物。
不太会有公司雇佣程序员用lisp去新开发什么商业项目。如果程序员自发地想做点什么，可能才会选择lisp。