Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let over Lambda – Common Lisp Book (2008)

letoverlambda.com

Post reply on HN
Print view View original

81–90 of 99 posts

Re: Let over Lambda – Common Lisp Book (2008)

#81

Post by black-tea »

damsdu78 wrote: post #4
black-tea wrote: post #3

Earlier quoted context omitted.

I thought it was great, but I know it's not a book for snowflakes. When I hear someone say "this is right" or "this is wrong", I am able to effortlessly interpret this as "I believe this is right/wrong". It's just being efficient with language. I don't need people to add extra words for fear of offending me. Maybe the author was immature. That's great. Let it remind you what it's like to be young and so excited about…

Do you think it is useful for a Lisp noob?

No, it's not. Others have suggested other great books for beginners, like Practical Common Lisp. You'll get the most from Let Over Lambda after you've already got a bit of experience with Lisp.

Re: Let over Lambda – Common Lisp Book (2008)

#82

Post by vram22 »

cracauer wrote: post #63
rhizome31 wrote: post #59

Is there a prominent open source project written in Common Lisp? Something like Pandoc for Haskell or RabbitMQ for Erlang?

Common Lisp has a package manager/source repository called Quicklisp. https://www.cliki.net/Quicklisp%20tutorial There are some web frameworks in there that are fairly impressive. There is very little advertising going on. It goes a bit back to what your folks mentioned here, a bit of dejection and being condescending to other languages. Common Lisp is the only language with reasonable compile-time computing right no…

>Common Lisp is the only language with reasonable compile-time computing right now

How does D compare, with its CTFE (Compile-Time Function Evaluation/Execution)?

Re: Let over Lambda – Common Lisp Book (2008)

#83

Post by vram22 »

lispm wrote: post #71
sametmax wrote: post #70

Earlier quoted context omitted.

And I bet you $10k that mostly 10x programmers work on the code base. In fact, I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. And there is a limited pool of that. We, humans, also have work to do.

> I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that…

>Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp.

Ha ha, I read somewhere that years ago, in some org or the other, Emacs Lisp was programmed by secretaries to help them achieve their routine tasks. Apparently they were not told that it was "too difficult for them" :)

Re: Let over Lambda – Common Lisp Book (2008)

#84

Post by bjoli »

eadmund wrote: post #54
jhbadger wrote: post #37

Earlier quoted context omitted.

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.

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 i…

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 .

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 it is mostly a matter of taste and, compared to some implementations, maturity.

Re: Let over Lambda – Common Lisp Book (2008)

#85

Post by fiddlerwoaroof »

PuercoPop wrote: post #79
varjag wrote: post #29

Earlier quoted context omitted.

It sounds more like someone's musing of why Lisp should be bad idea rather than anything practical. Doubly so when they don't seem to know what Common Lisp is.

I agree it _sounds_ like an armchair critic, but I prefer to give the benefit of the doubt. Maybe they had a bad experience involving Lisp? The actively hostile to collaborative programming seems particularly misguided. Even an extreme case like the code from hu.dwim, which is written in practically a new language they built on top of CL and has barely any documentation is still fairly easy to understand.

Yeah, and the other thing is that the macrostep expander in slime makes it fairly straightforward to understand how an unfamiliar macro works: you just expand it a couple steps and see how its mapping the surface syntax to utilities you know. In fact, I often find function calls harder to grok now than custom macros :)

Re: Let over Lambda – Common Lisp Book (2008)

#86

Post by emmanueloga_ »

lispm wrote: post #71
sametmax wrote: post #70

Earlier quoted context omitted.

And I bet you $10k that mostly 10x programmers work on the code base. In fact, I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. And there is a limited pool of that. We, humans, also have work to do.

> I've never seen an average Joe taking interest in Lisp, let alone learning it to the point of making a living with it. Average Joe and Susi have been for 3+ decades nicely programming lots of extensions to AutoCAD and its various clones in Lisp. Generally I agree that Lisp programming is a bit more challenging due to the slight mathematical nature (lambda, ...), code as data and meta-programming. I don't think that…

Wow this opus modus tool looks super polished. I'd not mind paying for it, if it ran on windows!

I've heard about other tools like this before ([1] for composition, [2] for synthesis, [3] for mind-blowing :-p) but somehow never heard about opus modus before.

* Where did you learn about it?

* Are there other similar prog-lang music production tools with similar level of polish?

* Any cross-platform / Windows supported tools? -- unfortunately opus modus only runs on macs :-(

1: https://github.com/ctford/leipzig

2: https://github.com/overtone/overtone

3: https://extemporelang.github.io/

Re: Let over Lambda – Common Lisp Book (2008)

#87

Post by cracauer »

agumonkey wrote: post #68
cracauer wrote: post #61

Earlier quoted context omitted.

That is me, I'm half of that team (Martin Cracauer). If you have any questions I'd be happy to answer. If you want to learn more about the programming side of our work (not so chemical), check out our other videos. They are from programming conferences: Longer talk: https://www.youtube.com/watch?v=8X69_42Mj-g&t=177s&index=3&l... Shorter one from the LLVM meeting: https://www.youtube.com/watch?v=gYYH2zF41fc&list=PLbl4…

Oh well I just had a question but not related to cando itself more about how you structure your research project / team / finance. But maybe that's not a place to discuss this.

Feel free to message, here or on twitter or whereever.

Re: Let over Lambda – Common Lisp Book (2008)

#88

Post by z3phyr »

radiator wrote: post #80
eatonphil wrote: post #44

I enjoyed this book. I personally did not find it condescending. Additionally, the implementation of a Forth interpreter in this book is the best introduction to Forth I've seen (even after years spent playing with Forth and reading one or two books on Forth). But I don't recommend this book as an introduction to (Common) Lisp. I recommend this order: 1. Practical Common Lisp 2. On Lisp (kind of a big jump, so maybe…

- COMMON LISP: A Gentle Introduction to Symbolic Computation (1990) - Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp (1991) - Common Lisp Recipes (2015)

> COMMON LISP: A Gentle Introduction to Symbolic Computation (1990)

Its a great book for people coming out of non computing backgrounds!!!

Re: Let over Lambda – Common Lisp Book (2008)

#89

Post by kazinator »

bjoli wrote: post #84
eadmund wrote: post #54

Earlier quoted context omitted.

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 i…

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…

> 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.

Post reply on HN