I have been using Hy as an alternative to Python. It is delightful to use. Highly recommended.
I think that you are not getting in the proper punning spirit of the language.
https://github.com/rcarmo/sushy
I'm currently re-writing it in Python 3.6 because Hy has taken a hard stance in backwards compatibility and deprecated "let" (with a replacement macro, but still) and isn't tackling async (both for understandable, but sad reasons), so it doesn't really work for me anymore.
But while it did, I loved it to bits. Python with a LISP syntax is just wonderful, and if someone ever finds a way to add back the stuff I like, I'm more than willing to deal with the quirks.
(let ((pi 3.14))
... code goes here ... )
(Alternatively, you don't need to set a initial value.)
One of the interesting uses of let is that it can also redefine dynamic variables (aka special variables, think of them as "global variables).
So for example let's assume i define timeout to 300, so within my whole package, this special variable has the value of 300. Let's suppose this variable is going to be read by function "my-function", and others.
So i create this special variable:
(defparameter *timeout* 300)
(let ((*timeout* 1000))
(my-function))
Let, thus, allows you easy use of lexical environments.
Another use is creating closures by using the combination of "let" with "lambda."
Welcome to the wonderful world of Lisp.
I'd recommend to you to install Portacle (the Portable Common Lisp Environment), this allows you to code in Lisp straight away.
As for tutorials, "Practical Common Lisp" (free online book) is fun, modern, and excellent for introducing you to most CL concepts, including of course use of let, let*, etc.
How romantic!
I also use it for small personal scripts.
My first choice for one-off scripts would have been Clojure. But the long startup time for Clojure apps makes it unusable for quick command line scripts. Hy gives us the best of both worlds.
One thing that I've also done is write the first draft in Hy, and then used Hy2Py to generate the version that I'm going to publish. This does result in a lot of compiling-by-hand, but the end product is often surprisingly robust.
On the other hand, it's also very (!) un-pythonic. Hy discourages classes in favor of closures, like Scheme, so I end up with a lot of nested sub-functions. My project git-linter looks like that. Hy encourages highly functional thinking, and git-linter is just that: the inputs are things like the configuration file, available linters, the command line, and (depending on the command) either the output of a "git-status --porcelain" or just "find . -type f"; the output is a report on the various outputs of the linters. It's a very straightforward map/reduce/filter, so no object-orientated code at all was required.
To an engrained Pythonista who must make a class for every last step, this land-of-verbs approach tends to look strange.