I know this is going to seem old-fashioned, but I don't think much of using online tutorials to learn programming languages or platforms. These generally give you no more than a little taste of the language. To really learn a language, you need the equivalent of a "book", and in many cases, this means a real dead-tree book.
If you want to learn C, read K&R. If you want to learn C++, read Stroustrup. If you want to learn Lisp/Scheme, read SICP. Etc.
If you're not willing to spend more than $30 and a few hours to learn a language, you probably aren't going to learn it.
How about implementing something like SO does with the CAPTCHAs?
If you're using the site normally, you'll probably never see one. If you happen to reload the same page too often, post successive comments too quickly, or something else that triggers an alarm, make them prove they're human. In your case, this would probably be constant reloads of the same page, following every link on a page quickly, or filling in an order form too fast to be human.
If they fail the check x times in a row (say, 2 or 3), give that IP a timeout or other such measure. Then at the end of the timeout, dump them back to the check again.
Since you have unregistered users accessing the site, you do have only IPs to go on. You can issue sessions to each browser and track that way if you wish. And, of course, throw up a human-check if too many sessions are being (re-)created in succession (in case a bot keeps deleting the cookie).
As far as catching too many innocents, you can put up a disclaimer on the human-check page: "This page may also appear if too many anonymous users are viewing our site from the same location. We encourage you to register or login to avoid this." (Adjust the wording appropriately.)
Besides, what are the odds that X people are loading the same page(s) at the same time from one IP? If they're high, maybe you need a different trigger mechanism for your bot alarm.
Edit: Another option is if they fail too many times, and you're confident about the product's demand, to block them and make them personally CALL you to remove the block.
Having people call does seem like an asinine measure, but it makes sure there's a human somewhere behind the computer. The key is to have the block only be in place for a condition which should almost never happen unless it's a bot (e.g. fail the check multiple times in a row). Then it FORCES human interaction - to pick up the phone.
In response to the comment of having them call me, there's obviously that tradeoff here. Are you worried enough about ensuring your users are human to accept a couple phone calls when they go on sale? If I were so concerned about a product getting to human users, I'd have to make this decision, perhaps sacrificing a (small) bit of my time in the process.
Since it seems like you're determined to not let bots get the upper hand/slam your site, I believe the phone may be a good option. Since I don't make a profit off your product, I have no interest in receiving these calls. Were you to share some of that profit, however, I may become interested. As this is your product, you have to decide how much you care and implement accordingly.
The other ways of releasing the block just aren't as effective: a timeout (but they'd get to slam your site again after, rinse-repeat), a long timeout (if it was really a human trying to buy your product, they'd be SOL and punished for failing the check), email (easily done by bots), fax (same), or snail mail (takes too long).
You could, of course, instead have the timeout period increase per IP for each time they get a timeout. Just make sure you're not punishing true humans inadvertently.
Best Answer
Since you say "embedded system" and "small and fast" and "integrate nicely" I would say you are correct that Lua is the number one if not the only choice. But I no longer agree that the programming language has "quirky corners". Firstly, the book Programming in Lua is simply splendid, one of the best books I have ever read. Secondly, some of the "quirky corners" come from the fact that the language is very orthogonal and clean, which in the long run is an asset, not a drawback. I find for example JavaScript much worse. If you read "Javascript the good parts" the author explains in length why some constructs in the language are design mistakes and why one should avoid the new operator. Not so in Lua, the bad parts have been removed, for example the quirky upvalue stuff was replaced with standard syntactic scoping in version 5.x.
My view is actually that Lua is a language with far less quirky corners than most other languages! We use it in a commercial project and we are more than happy with it.