《Practical Common Lisp》的原文摘录

  • 甚至像Java也会产生问题,它基于Unicode注定将成为未来主流字符编码这一理论,而从一开始就被设计使用Unicode字符。产生问题是因为Java字符被定义为16位值,而Unicode3.1标准将Unicode字符集范围扩展到了需要21位表示。太惨了。 (查看原文)
    1回复 2012-12-10 15:34:35
    —— 引自第107页
  • 可以输入 C-c C-q 来调用命令 slime-close-parens-at-point ,它将插入必要数量的闭括号以匹配当前所有开括号。 (查看原文)
    jiyixx 2013-01-15 12:17:04
    —— 引自第14页
  • 注意到宏所带来的区别:一个注意到代码中常见模式的Lisp程序员可以写出一个宏来获得对该模式的源代码级抽象。一个注意到同样模式的Java程序员只能建议Sun说,这种特定的抽象值得添加到语言之中,然后Sun将会发布一个JSR并组织一个业界专家组来推敲其细节。按照Sun的说法,这一过程平均耗时18个月。在那之后,所有的编译器作者都将升级其编译器以支持新的特性,并且就算那个Java程序员所喜爱的编译器支持了这个新版本的Java,他们也仍然可能无法使用这个新特性,直到被允许打破与旧版本Java的源代码级兼容性。因此,一个Common Lisp程序员在五分钟里可以自行解决的麻烦问题却会困扰Java程序员几年时间。 (查看原文)
    Stanley_Wang 2014-05-10 11:46:55
    —— 引自第73页
  • 我发明了术语面向对象,而我可以告诉你c++并不是我头脑里所想的东西 (查看原文)
    陈小奈 2014-12-27 10:39:22
    —— 引自第165页
  • 编写这些访问函数没有什么困难的,但是完全手工编写它们就跟lisp风格不太吻合了 (查看原文)
    陈小奈 2014-12-27 16:12:53
    —— 引自第183页
  • 调试一个运行在一亿英里之外且价值一亿美元硬件上的程序是件有趣的经历。一个运行在宇宙飞船上的读取-求值-打印-循环,在查找和修复这个问题的过程中,真是无价之宝啊。 (查看原文)
    CodeArhat 2017-08-31 20:34:12
    —— 引自第16页
  • A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head. (查看原文)
    bombadil 2011-05-27 16:43:33
    —— 引自第32页
  • not all operations can be defined as functions. Because all the arguments to a function are evaluated before the function is called, there’s no way to write a function that behaves like the IF operator (查看原文)
    bombadil 2011-06-03 17:45:20
    —— 引自第43页
  • Another binding form is a variant of LET, LET*. (查看原文)
    bombadil 2011-06-13 11:09:44
    —— 引自第68页
  • Control constructs are the other main kind of looping constructs. (查看原文)
    bombadil 1赞 2011-06-15 17:24:07
    —— 引自第83页
  • What you’d really like is to be able to treat the expression as both code and data. Whenever you want to treat code as data, that’s a sure sign you need a macro. (查看原文)
    bombadil 2011-06-22 14:39:55
    —— 引自第105页
  • At any given time, the most recently established binding shadows all other bindings. Conceptually, each new binding for a given dynamic variable is pushed onto a stack of bindings for that variable, and references to the variable always use the most recent binding (查看原文)
    摸鱼百分百 2011-07-15 14:31:44
    —— 引自第71页
  • A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head. (查看原文)
    梦里醉逍遥 1赞 2011-09-18 22:14:06
    —— 引自章节:Practical: A Simple Database
  • 原文:“至少从概念上来说,Common lisp中所有的值都是对象的引用。” 脚注:作为一种优化,特定类型的对象,诸如特定大小以下的整数与字符,可能会在内存中直接表示,而其它的对象将被表示成一个实际对象的指针。但由于整数和字符都是不可修改的,因此在不同变量中是否存在同一个对象的多个副本也就无关紧要了,这就是在第4章里所讨论的EQ和EQL的根本区别。 (查看原文)
    乌鸦狐狸 2011-10-26 10:36:24
    —— 引自第58页
  • Common Lisp 字符和数字是不同类型的对象。本该如此——字符不是数字,而将其同等对待的语言当字符编码改变时(比如说从8位 ASCII 到 21 位 Unicode)可能会出现问题。 (查看原文)
    leegorous 1回复 2012-01-20 12:35:18
    —— 引自第107页
  • 甚至像 Java 也会产生问题,它基于 Unicode 注定将成为未来主流字符编码这一理论,而从一开始就被设计使用 Unicode 字符。产生问题是因为 Java 字符被定义为 16 位值,而 Unicode 3.1 标准将 Unicode 字符集范围拓展到了需要 21 位表示。太惨了。 (查看原文)
    leegorous 1回复 2012-01-20 12:35:18
    —— 引自第107页
  • REDUCE 函数非常有用,无论何时,当需要将一个序列提炼成一个单独的值时,你都有机会用 REDUCE 来写它,而这通常是一种相当简洁的表达意图的方法。例如,为了找出一个数字序列中的最大值,可以写成 (reduce #‘max numbers)。 (查看原文)
    leegorous 2012-01-24 17:50:14
    —— 引自第120页