If you've seen the Lisp Koans in the past, you might want to revisit them someday. Around half a year ago I've rewritten[0] the original set of koans, fixed multiple correctness issues, added some content, and cleaned up the test framework; they now look much better than the original version.
Cool, I started doing these a couple of years ago, nice to have an updated version. I haven't done lisp in a long time but I'm trying to get back into CL.
One question: using SBCL I can run the script with sbcl --script contemplate.lisp but how do I load the koans into the repl in a way that has all the helper/test functions available? If I just (load "test-framework.lisp") or do sbcl --load contemplate.lisp, I get a bunch of warnings and things like (assert-equal t t) throw "undefined function". It's mentioned in the original PR that this "should" be possible now but I didn't see it in the README.
One thing I'm very not familiar with yet is the quicklisp/abcl and packaging system so this is probably very obvious. Thanks!
Hmmm. Koans in the original form will warn because they are incomplete, so loading them altogether is going to not work very well. I don't think that the current version of koans is very well-suited for interactive development; please feel free to open an issue for that and perhaps it will get done someday.
Okay cool, I can just eval the actual code separately from the koan test framework for now, it's fine. Sounds like an interesting problem for the reader for sure. :)
edited with suggestion to call use-package I'm not very familiar with the lisp packaging stuff yet.
Here's what I was trying to do:
* (load "test-framework.lisp")
T
* (use-package :lisp-koans.test)
T
* (assert-equal t t)
debugger invoked on a UNBOUND-VARIABLE in thread
#<THREAD "main thread" RUNNING {1001570143}>:
The variable LISP-KOANS.TEST::*KOAN-ASSERT-LIST* is unbound.
Aha it looks like it's part of the code that is testing for blanks in the original form.
That seems like it's fixable, maybe I will open a bug for that. I don't think it expects to run outside of the run-koan function. That's fine, I'll stop there until I know enough to fix it haha.
Also thanks for answering my noob questions! I just realized you also wrote the Common Lisp Condition System which is on my TO-READ list (after I do about 100 hours of lisp refresher stuff lol).
Yes, none of this expects to be run outside of the standard koan run. Sorry about this; please open an issue and eventually I'll patch this code to be runnable outside of the koans file.
For that, you should be able to load the test framework and the koan helper file separately. Then try to evaluate individual koans in emacs/slime - it should work.
Just started learning Emacs Lisp. Common Lisp is on my todo list. Glancing through these tasks, I realize I have a lot to learn before I can call myself proficient. But I am very eager. Started reading Guy Steele and Touretzky. Love the concepts, the simplicity, homoiconicity, Lisp macros, and the fact that it is time tested.
## Edit
Years ago when I was confronted with a new technology that caught my interest, I‘d ask myself: Is it in use? Is it wide-spread? Is it used by companies in commercial situations?
My questions have changed. Now I tend to apply questions like: Does the hacker in me get excited? Does this technology help me solve problems? Does it make my life easier?
Awesome guide :). I've been meaning to learn the basics of LISP since trying out Emacs and this was finally an easy enough introduction to it that I've read a fair amount. Thanks for this!
Nah, it was a conscious choice to limit the amount of material in the guide as not to overwhelm the beginner.
The various textbooks on lisp are great and this wasn’t aimed to replace them, but just guide the reader through the initial phase where they may be overwhelmed.
About the questions that has changed over time. I see them as questions that depend on the context rather than experience and/or time.
If you're trying to build something many people should be able to build upon, you as a developer should be easily replaceable and you want to have a high hiring pool with mid-level developers (like how the typical startup thinks), then your first questions are more appropriate.
But if you're looking to build something for fun, to scratch your own itch or trying to do something more innovative than a CRUD app, then perhaps your latter questions are more appropriate.
I really like the koans format of language learning. I find they pique and sustain my interest more than rote tutorials or trying to glean purpose, feel and function of languages.
It feels much more like a puzzle, the hints can be more cryptic and requires me to be more bought in than an introductory podcast or an online set of lessons.
I'd love to see this format applied to other topics and fields, although none will likely lend themselves to the format as natively as programming languages will.
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Awesome to see such a comprehensive update to the lisp koans. much thanks!
Like you said, elisp-koans was forked from lisp-koans awhile back. Bringing over the additional coverage you added will be a great improvement!
I love the addition of the `koans-solved` directory. I was using a separate branch, but that was a pain to keep in sync with master. Will definitely bring that over :)
Google’s standard employment contract gives it default ownership of basically any software produced by an employee if it has anything to do with the employee’s job or Google’s business, which means basically everything. But it’s also very easy for an employee at Google to open-source software. The consequence of this is that frequently when a Google employee has a side project that they want to share with the world it will end up released as a Google open-source project under a permissive license.
[0] https://github.com/google/lisp-koans/pull/111