Ostensibly, this is a book for learning lisp through examples, exploration, and experiments - i.e. the hard way.
I did lpthw and it was very effective. This is NOT effective. I'm incredibly frustrated with the writer's tendency to assume the reader is tracking 100%. That every time a concept is mentioned - even without an example - it will just stick. After wading through the earlier and debilitatingly long chapters I had thought it would get better.
Maybe this will one day be a great resource for learning lisp. For now, I am going to other resources.
A friendly word to the author: thank you for taking the time to write this to the degree you already have. Please, if you choose to continue this project do these three things to improve your pedagogical approach:
Walk readers through the fundamental concepts many times and in useful examples. Take them to the edge of the concept - the place that defines an Atom from a Cons Cell and the functional difference between the two (like: why does this distinction matter? How will it affect me? What mistakes would I make if I didn't know this?)
Answer the questions: why is this built like this? and Why does this matter?
Use examples that are clear and easily parsable. This is a prime example of how not to do that:
(with-output-to-string (out)
(with-input-from-string (in "\"Can I ask who's calling?\"")
(let ((io (make-two-way-stream in out)))
(format io "~A It's the Jovian moon, Io!" (read io)))))
Why on someone's first exposure to streams in Lisp would you subject them to this complex, inscrutable, impractical atrocity? Oh yeah, you tell us: because we can. This is not the time to show off your clever lisp convolutions, nor your shitty moon puns.
At this point you haven't introduced anything about the difference make-string-input-stream and with-input-from-string, much less the make-two-way-stream, nor demonstrated any of them in isolated uses. You just throw them all together at once and tell us to swim. I understand that I can go try it myself, but then I could just go and read the documentation and do that anyway, the purpose of this is to learn - supposedly.
Teaching is not the time to be smart, it's the time to simplify so that your student can feel smart.
One final, unrequested feedback: Please think about the progression of topics. Make the development of these topics have some sort of logical progression. It currently feels like: here's another thing you might want to possibly know about a programming language in no particular order.
Alphabetical order is for documentation, motivated order is for education.
Ostensibly, this is a book for learning lisp through examples, exploration, and experiments - i.e. the hard way.
I did lpthw and it was very effective. This is NOT effective. I'm incredibly frustrated with the writer's tendency to assume the reader is tracking 100%. That every time a concept is mentioned - even without an example - it will just stick. After wading through the earlier and debilitatingly long chapters I had thought it would get better.
Maybe this will one day be a great resource for learning lisp. For now, I am going to other resources.
A friendly word to the author: thank you for taking the time to write this to the degree you already have. Please, if you choose to continue this project do these three things to improve your pedagogical approach:
Why on someone's first exposure to streams in Lisp would you subject them to this complex, inscrutable, impractical atrocity? Oh yeah, you tell us: because we can. This is not the time to show off your clever lisp convolutions, nor your shitty moon puns.
At this point you haven't introduced anything about the difference make-string-input-stream and with-input-from-string, much less the make-two-way-stream, nor demonstrated any of them in isolated uses. You just throw them all together at once and tell us to swim. I understand that I can go try it myself, but then I could just go and read the documentation and do that anyway, the purpose of this is to learn - supposedly.
Teaching is not the time to be smart, it's the time to simplify so that your student can feel smart.
One final, unrequested feedback: Please think about the progression of topics. Make the development of these topics have some sort of logical progression. It currently feels like: here's another thing you might want to possibly know about a programming language in no particular order.
Alphabetical order is for documentation, motivated order is for education.
/rant