5 ms·

https://letoverlambda.com/index.cl/guest/chap6.html https://letoverlambda.com/index.cl/guest/chap6.html Yeah, the sixth chapter sure bashes on Scheme a lot. :/

pepper_sauce 8y ago
Good heavens! Not Scheme!
- gekkonier 8y ago
  Hey! Why so angry! :-)
jhbadger 8y ago
I always wonder if Common Lispers who bash Scheme know that Guy Steele (who also is the chairman of the Common Lisp standards committee) was the co-creator of Scheme.
- mruts 8y ago
  Well he also designed Java, so...
  - lispm 8y ago
    That's new. Where did you get that information from?
- eadmund 8y ago
  I can't speak for others, but I know that, and I think that it is consistent, rather than inconsistent, with my points 1) that Scheme is fine as an academic language and 2) Common Lisp is preferable for real programs. Scheme's simplicity is awesome if you're implementing it; it's awesome if you're learning it; it's not so awesome if you're trying to actually use it. As LoL notes, it's dumb to throw away information in conditionals. As LoL also notes, hygienic macros are toys and DEFMACRO is generally what you really want. I'll add that having only a single namespace for variables, classes, functions, types, packages & everything else means that you end up having to be extremely verbose: foo, fooClass, fooFunc, fooType, fooPackage. call/cc is incredibly cool & powerful, but also really hurts efficiency in a way that I don't think is acceptable in a production system (it's fine, of course, in a teaching language, because the experience of understanding it is really useful). dynamic-wind is broken compared to UNWIND-PROTECT. And on & on & on. Steele also wrote the Java spec, and he wasn't wrong when he said 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp,' but I don't think in 2019 anyone thinks that his involvement with Java means it is anywhere near as good, powerful or acceptable a language as Lisp.
  - bjoli 8y ago
    This is uninformed and wrong. You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case). The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to be comparable to unwind-protect, but that would render continuations useless for other things than escapes. The single namespace has roughly one one common consequence: having to name your lists lst, which is easy. Types and classes are by convention <type>. Continuations are cool and useful, although full blown ones are ugly. Delimited continuations are making their way into some schemes. In guile they are used to build guile-fibers, which are really cool. The only thing common lisp really brings is cross-implementation compatibility. Compared to <your favourite scheme> it is mostly a matter of taste and, compared to some implementations, maturity.
    - kazinator 8y ago
      > You can implement defmacro in 8 lines of syntax case. Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda lists) Hygienic macros are basically wrong. A good way to express why they are wrong is by analogy. In visual art, as a joke, we can paint paintings that perpetrate deliberate errors of perspective: some feature obviously in a distant background reaches into the foreground in an incorrect way and overlaps or interacts with foreground objects. There is precisely such an absurd situation between the lexical scope of a hygienic macro definition, and that of the macro call site. The macro injects code into distant call sites, yet that code makes lexical references into the macro definition, like the silly character jumping out of an inner painting into an outer painting. I don't ever want that; I don't want the code generating system (the macro) to be wrongly mixed up with the generated site. If the macro generates some symbol X, that should refer to an X definition that is lexically (or in any other manner) apparent at the call site, even if that is a bug. If I make that bug, I will own that bug. I do want macro generated code to refer to a clearly defined set of run-time support symbols, if that is required, not coming from some random lexical scope enclosed in a macro definition, but from a global scope. Referring to a private scope of the macro definition is horribly wrong. That scope must completely die when the dust settles. It's not necessarily even on the same machine. When the macro is running and its scope is active, it's on some build farm. When the code is running, it's on a target system. Why would the target environment refer to the build environment? No hacker interested in constructing practical systems from the ground up could have invented hygienic macros; they are an ironic joke coming from idle minds.
- mschaef 8y ago
  He was also heavily involved in Java. "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." -Guy Steele https://news.ycombinator.com/item?id=2323963 https://news.ycombinator.com/item?id=2323963
- lispm 8y ago
  I always wonder if Schemers who bash Common Lisp know that Guy Steele (the co-creator of Scheme) was also the chairman of the Common Lisp standards committee.
PuercoPop 8y ago
As others have noted its written in 'rant form' so its bound to happen. The weird thing is that it doesn't seem to bash on Perl at all! The Appendix on Editors bashes Emacs a lot too. Its an OK book _if_ you enjoy reading rants, but if you want to Learn Lisp, Practical Common Lisp or Land of Lisp are way better.

pepper_sauce 8y ago

Good heavens! Not Scheme!

gekkonier 8y ago
Hey! Why so angry! :-)

jhbadger 8y ago

I always wonder if Common Lispers who bash Scheme know that Guy Steele (who also is the chairman of the Common Lisp standards committee) was the co-creator of Scheme.

mruts 8y ago
Well he also designed Java, so...
- lispm 8y ago
  That's new. Where did you get that information from?
eadmund 8y ago
I can't speak for others, but I know that, and I think that it is consistent, rather than inconsistent, with my points 1) that Scheme is fine as an academic language and 2) Common Lisp is preferable for real programs. Scheme's simplicity is awesome if you're implementing it; it's awesome if you're learning it; it's not so awesome if you're trying to actually use it. As LoL notes, it's dumb to throw away information in conditionals. As LoL also notes, hygienic macros are toys and DEFMACRO is generally what you really want. I'll add that having only a single namespace for variables, classes, functions, types, packages & everything else means that you end up having to be extremely verbose: foo, fooClass, fooFunc, fooType, fooPackage. call/cc is incredibly cool & powerful, but also really hurts efficiency in a way that I don't think is acceptable in a production system (it's fine, of course, in a teaching language, because the experience of understanding it is really useful). dynamic-wind is broken compared to UNWIND-PROTECT. And on & on & on. Steele also wrote the Java spec, and he wasn't wrong when he said 'We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp,' but I don't think in 2019 anyone thinks that his involvement with Java means it is anywhere near as good, powerful or acceptable a language as Lisp.
- bjoli 8y ago
  This is uninformed and wrong. You can implement defmacro in 8 lines of syntax case. The opposite is not possible. Anything you can do with defmacro is possible using whatever lower level macro facility available in scheme (be it based on syntactic closures, implicit/explicit renaming or syntax case). The extra complexity of dynamic-wind is required because scheme supports call/cc. You can easily limit dynamic wind to be comparable to unwind-protect, but that would render continuations useless for other things than escapes. The single namespace has roughly one one common consequence: having to name your lists lst, which is easy. Types and classes are by convention <type>. Continuations are cool and useful, although full blown ones are ugly. Delimited continuations are making their way into some schemes. In guile they are used to build guile-fibers, which are really cool. The only thing common lisp really brings is cross-implementation compatibility. Compared to <your favourite scheme> it is mostly a matter of taste and, compared to some implementations, maturity.
  - kazinator 8y ago
    > You can implement defmacro in 8 lines of syntax case. Even if that is so, that doesn't mean I want syntax-case. If I don't want syntax-case but do want defmacro, that requires a lot less code than implementing syntax-case (which I don't care for) and then eight more lines to get defmacro. (Are we talking with a defmacro that supports optional parameters, &environment? and how about macrolet? destructuring lambda lists) Hygienic macros are basically wrong. A good way to express why they are wrong is by analogy. In visual art, as a joke, we can paint paintings that perpetrate deliberate errors of perspective: some feature obviously in a distant background reaches into the foreground in an incorrect way and overlaps or interacts with foreground objects. There is precisely such an absurd situation between the lexical scope of a hygienic macro definition, and that of the macro call site. The macro injects code into distant call sites, yet that code makes lexical references into the macro definition, like the silly character jumping out of an inner painting into an outer painting. I don't ever want that; I don't want the code generating system (the macro) to be wrongly mixed up with the generated site. If the macro generates some symbol X, that should refer to an X definition that is lexically (or in any other manner) apparent at the call site, even if that is a bug. If I make that bug, I will own that bug. I do want macro generated code to refer to a clearly defined set of run-time support symbols, if that is required, not coming from some random lexical scope enclosed in a macro definition, but from a global scope. Referring to a private scope of the macro definition is horribly wrong. That scope must completely die when the dust settles. It's not necessarily even on the same machine. When the macro is running and its scope is active, it's on some build farm. When the code is running, it's on a target system. Why would the target environment refer to the build environment? No hacker interested in constructing practical systems from the ground up could have invented hygienic macros; they are an ironic joke coming from idle minds.
mschaef 8y ago
He was also heavily involved in Java. "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." -Guy Steele https://news.ycombinator.com/item?id=2323963 https://news.ycombinator.com/item?id=2323963
lispm 8y ago
I always wonder if Schemers who bash Common Lisp know that Guy Steele (the co-creator of Scheme) was also the chairman of the Common Lisp standards committee.

PuercoPop 8y ago

As others have noted its written in 'rant form' so its bound to happen. The weird thing is that it doesn't seem to bash on Perl at all! The Appendix on Editors bashes Emacs a lot too. Its an OK book _if_ you enjoy reading rants, but if you want to Learn Lisp, Practical Common Lisp or Land of Lisp are way better.