命名难，难于上青天

starwing83

回复 129# walleeee


    动态语言就没编译器了？编译成字节码不是编译器么？

所谓检查，是说：

def fac(n):
   return 1 if n == 1 else fac(n-1)*n

这种东西，如果你传个string，编译的时候是绝对不会报错的，运行的时候才会扔异常，如果这个“非法”的调用很少被执行到，则这个错你可能永远都发现不了（比如fac("abc")在极罕见的情况下被调用，则这个调用平时很难被检查出来有问题）。而且，如果fac函数非常非常深，里面某个分支对n做了非法操作，不执行到那里去你是发现不了的。

我支持ow，语言还是以静态检查为主，但是提供动态类型的能力，但动态类型必须显式地声明此类型为动态。

walleeee

回复 131# starwing83

1. Python 3.2.2 (default, Sep  4 2011, 09:07:29) [MSC v.1500 64 bit (AMD64)] on win
   
2. 32
   
3. Type "help", "copyright", "credits" or "license" for more information.
   
4. >>> def fac(n):
   
5. ...     return 1 if n==1 else fac(n-1)*n
   
6. ...
   
7. >>> fac(5)
   
8. 120
   
9. >>> fac(8)
   
10. 40320
    
11. >>> fac('8')
    
12. Traceback (most recent call last):
    
13.   File "<stdin>", line 1, in <module>
    
14.   File "<stdin>", line 2, in fac
    
15. TypeError: unsupported operand type(s) for -: 'str' and 'int'
    
16. >>>

复制代码

这个是我的执行结果，我不知道你所谓的错误检查是什么意思，这个不是良好的检查？难道静态语言，比如c这种会做得更好？

ps.
在我看来字节码级别要高于静态，因为字节码的自行器可以有很多的控制能力。但是对于直接给cpu执行的静态二进制则已经不具备动态性。

flw

OwnWaterloo 发表于 2012-02-10 21:16
那就不管ADT的定义纠结如何，以及这些东西是不是ADT，以及这些代码是否权威，Windows是不是屎。
只关注 ...

支持！

zhaohongjian000

walleeee 发表于 2012-02-15 13:19
回复 131# starwing83 这个是我的执行结果，我不知道你所谓的错误检查是什么意思，这个不是良好的检查？难道 ...

这是因为被执行到了。对很多动态语言来说，通常不被执行到的部分一些错误是不会被检查出来的，而静态编译的语言在类型上的错误编译时往往就能检查出来。

sonicling

强类型语言要进行类型检查。变量都和类型绑定，所以表达不自由。
弱类型语言不进行类型检查，变量不与类型绑定，所以表达非常自由。

多态、泛型之类的都是因为类型绑定而提出来的。弱类型语言没有这些限制，天生就可以多态，支持泛型。

OwnWaterloo

回复 132# walleeee

C语言不会允许 fac('8')。
在运行前就可以检查出这类错误。

OwnWaterloo

回复 135# sonicling

意图不是要选择一种而抛弃另一种，而是……
其实两者之间的界限并不是牢不可破的……

比如C++：

1. 
   
2. typedef map<string,any> Object;
   
3. any apply(Object& o, string f, any arg) {
   
4.       return any_cast<function<any (any)> >(o[f])(arg);
   
5. }
   

复制代码

大致是这个意思……

Java,C#保留有许多运行时类型信息，比如查询某个对象的所有方法。
而C#还有个dynamic的东东……  大致是这个意思：
dynamic o = ...;
o.f(x);  运行时查询o是否有f方法，有就调用，没有就抛异常。


上面是静态类型检测语言里绕过检测。
而动态类型检测里还有可以添加检测的例子，比如python与cl。


而混合型语言，当需要绕过检测时，可以比上面的C++,C#写得更容易；当需要检测是，可以比python与cl更严格。
但我觉得这种混合型语言不会成为主流……
玩法越灵活的语言，在可以玩出很好的表达的同时，更容易产生很糟糕的表达。

OwnWaterloo

回复 127# walleeee

硬件是给力了，现在更倾向于节省程序员而非机器时间，更倾向于语言用户而非编译器作者。
这里有篇文章，作者假想百年后的语言会是什么样子： http://paulgraham.com/hundred.html

比如里面提到string类型其实是一种优化，语意上其实是list+char。
并不需要百年后，现在就有语言这么做了，至少haskell是，erlang貌似也是。

还有一句：

As technologies improve, each generation can do things that the previous generation would have considered wasteful.

但效率瓶颈部分总是存在，至少目前，haskell与erlang还是得提供bytestring这样的东东。
那20%（甚至可能会继续缩水）也总是存在，必须得提供FFI这样的东东。
那些鼓吹运行效率不重要的语言以及其作者只说了80%的情况，没有说剩下20%的情况。
剩下20%的情况，恰好在那些语言以及那些语言的用户里是很难解决的。

我敢说纯python程序员是没能力用好它的FFI的，必须要有很充分的C或者类似的训练才行。
也就是说，始终得有人去干这样的"脏活"。


另外，是不是脏活留给他人干，自己舒舒服服过日子就行了呢？
这篇文章： http://www.joelonsoftware.com/articles/fog0000000026.html 里有一种观点。
对自己而言至关重要的部分，一定得选择low level的，能够完全控制的工具。而不能依赖他人将这些脏活做掉。

OwnWaterloo

回复 121# walleeee

网络卡，该帖只发出了一半内容是怎么回事…… 现在貌似不能删帖了……
于是，完整回复在下面……

OwnWaterloo

回复 121# walleeee

至于lisp在实用方面不行的问题，我也觉得它确实不行……
前面提到lisp怎么怎么强大，都只是从语言角度而言。
但语言仅仅是编程活动的一部分，从实践角度来说，我还是觉得语言的简洁、优美、强大，很难比得上有丰富的库……

以前看到过一个人的文章（地址忘记了……）。
大致是说他先用python实现了一个东西，之后又用ocmal重写。最终代码行数差不多，因为ocmal缺了一些库，得自己写。
虽然代码行数差不多，但工作量我感觉应该是python的较小。
python代码长，但写的都是自己关心且熟悉的部分。
ocmal也许代码短， 容易编写，但为了弥补库不足而写的那部分很有可能就是自己不关心又不熟悉的部分，就很惨了， 本末倒置了。


库不够丰富（虽然在进步，但相对于其他语言而言还是渣渣）我觉得是影响实用的原因之一。
为什么库不够丰富？ 小众肯定是原因之一。
为什么小众， 不符合思维习惯， 但不是你说的那个意思，后面会继续说。
昨天晚上与sw也对这个问题纠结了很久， 为什么好东西就是没人用？ 还是没能理出头绪， 历史么， 只能猜， 没法证明， 就是这样……
也许是因为， 第1门高级语言fortran与第2门高级语言lisp从一开始就走着完全不同的路。
而lisp因为效率问题（在以前是很严重的问题）一直都没法成为主流。而遭殃的不仅仅是lisp的语意， 还有它的prefix notation也一直都没能成为主流。
往后硬件越来越给力了， 许多语言也从lisp里面借鉴语意了(dynamic typing, recursion, lexical closure, gc, expression only...)， 但：
1. infix notation已经是主流了， 它们不愿意改
2. 即使改了也没有实质上的收获， 因为它们很多都还没有引入宏。



对，就是在说"lisp的思维习惯不符合常人习惯"。

我一直没明白的是后缀定义的语法为什么会导致写程序时要记住很多东西？ 那些思考栈是怎么造成的？
递归上面已经说了， 而函数(f x y) 与 f(x,y) 在语法上都没多大区别。
你指的是算术运算符？  x = 2 * y 与 = x * 2 y？

1. 一个很牵强的理由是， lambda演算（数学）就是前缀的……  lisp是从那里学来的。
但没多少人在编程前需要学lambda演算…… 这不构成理由

2. lisp里面其实是 (= x (* 2 y)) 而不是 = x * 2 y。
将后者解析为前者确实需要像你说的那样， 在头脑里维护栈才行。 但实际上代码里是已经解析过了的版本。

3. lisp自然也是可以写 x = 2 * y 的……  这可是lisp……
一种方式是在read time将上面转化为prefix。
另一种是在eval前通过macro将上面转换为prefix，比如(parse-from-infix-arithmetic x = 2 * y)。

由此带来的问题是： 并不是特别复杂的事， 为什么没人这么做？
至少我的观点是 1) 算术运算并不是特别多 2) 习惯了(= x (* 2 y)) 理解起来没什么困难
类似的问题是，许多关于makefile的抱怨是tab引起的bug，但其实makefile(至少gnu make)是可以用空格的。 为什么没人这么做？

5. 我认为不符合思维习惯其实是不符合以前学过的使用infix的语言的习惯
初学语言的人需要建立、训练出很多思维习惯， (= x (* 2 y)) 只是其中一个而已， 难道真的是一个很严重的问题？
我见过说"lisp不符合习惯的"都不是用lisp作为第一门编程语言的。
要多考察一下那些第一门语言就是学lisp的人的感觉才有说服力： 这对初学者也是一个问题？

6. 无论学没学过编程这真算不上什么障碍
理由就是前面的mit， 以及你提到的SICP， 后者可是面向编程人员而非初学者的哦。
要写一本像SICP这样的书，演示代码该用什么语言？ 许多其他书采取的是各种主流语言写一个版本……
而SICP为什么敢这样选择？ 会scheme就直接看， 不会？ 我现教你……

7. 这种记法是有好处的，值得去习惯
还是说python吧， 它也能够将代码解析为一个树， 然后操作， 然后再编译为代码。
但python在source里面写的东西，与解析得到的树， 在感官上相差太多了。
而lisp，写作什么基本上就读作什么。在这里反而不需要在人脑中维护一个栈并完成text->tree的转换， 因为代码本来就写成tree的样子了。
许多语言都有元编程的能力， 但只有在lisp里这种能力的易用程度发生了质的区别， 我想这与它的代码表示有很大的关系。