Don't forget: computers have no true intelligence, and thus require humans to put things into some form of structure in order for the computer to understand it. The type of structure you can get away with using for simple tasks can often look beautiful, but beyond a certain point, you need to impose distinction and isolation so you can compartmentalize separation of concerns and so forth. This structure is the foundation of programming language design.
The major issue with all of this is that program code is built through a process of iteration: one brick on top of another. But once you hit the wall I just described, you have to face the scientifically organized structure of programming in order for the language itself to not be a mess (see PHP) or the programs written in it to be spaghetti (see BASIC and particularly GOTO).
I say this not to be a downer, just as strong encouragement to take this into account and try your best to factor this into your design. If you can make something that lets people scale really high before hitting that wall (if at all!), that would be awesome.
> You shouldn't need a manual for something simple.
That's like saying "Everyone knows how to drive a car, you just keep it pointing forward and engage the engine".
Everything needs some sort of documentation, whether it be through examples (the way love2d.org/wiki is done, for example, is both informative and useful), documentation, BNF, etc. The fact that a manual exists is not a detriment, but a success -- you have enough features and complexity worthy of documenting it (although I don't mean to imply that larger is bigger :) ).
