RR keeps the original HC metaphor of the stack of cards. An application is a series of stacks of cards. Within a stack cards are metaphorically one behind the other. Stacks can have substacks. Cards contain objects, such as fields or buttons. Writing a program in RR consists of first creating a stack or stacks, then creating cards, then putting the appropriate objects on them. Actions or events involving these objects result in messages being passed (roughly) from object to card to stack to system, and you write scripts to handle these messages. The language in which this scripting is done used to be called Transcript, now Revolution, and is close to the classic Hypercard scripting language. It has quite good support for regular expressions and text and string manipulation - so that the refugee from the Linux shell may at some point have the blinding flash of misleading illumination that he is really dealing with a clone of awk with a gui stuck on the front. It's much, much more than that of course, but it is certainly very powerful in dealing with the kinds of problems that awk is/was used for.
I've used it in anger for two tasks, apart from playing - ie things where the result was going to be used seriously by some other person or group. One was parsing and extracting data from a file, which a friend did. One could have done it in awk, and it would have been considerably more compact and probably run faster, but this took a weekend to do, is easy to use, and works fine. Perl is presumably the natural choice for this for most people. The second is a very simple little application for an organisation where the computer users can't be expected to use the keyboard at all. They will simply turn on the computer, and use a barcode reader. In addition to reading in codes of items, there will be two or three barcodes corresponding to buttons: delete, total ticket, stuff like that.
The main issue has been figuring out how to handle lookups and store data. You can use arrays (yes, them), if you can figure out when and why and how. You can store in an external text file. You can store on a series of cards, or in a field or fields on one card. The great flexibility of the language in allowing you to create new fields or cards as needed, and inheriting properties, makes all these choices confusingly readily available. Or you can use a real database engine like mysql or sqlite, or the intriguing No Sql, if you can figure out how to connect and use. Sometimes there is too little documentation for a new user on how to do one of these, sometimes there's too little on why to choose one rather than the other.
The thing that is super fast and very easy is to layout the screens, and to the extent that this determines how the application is going to work, this ease, and the requirement to start there, enforces a certain discipline of design that the amateur will find helpful. You pretty much have to plan it out before you start, because if you don't, planning is the first thing you'll find yourself doing anyway.
You can also use a sort of interactive interpreter called the Message Box, to perform your scripts one or a few steps at a time, which makes it easy to debug. In addition, the fact that you are always scripting some object - card, stack, field, button - means that you necessarily write your application in a modular way one piece at a time. Write a bit, then test it, then move on to the next chunk. It can be a little disconcerting to have one's program scattered over lots of objects without a few pages of code to look at as a whole, but probably the modularity more than compensates, at least for small projects. You have to discipline yourself to avoid go-tos. If you want to write spaghetti, this modularity makes it easy, though you'll soon realise how impossible it also makes it to keep track of the strands, and stop. There is an application browser which displays all the different objects in an application, so you can see at a glance what stacks you've made, what cards are in them, and what objects are on those, and there are some third party development add-ins, not all of which work on Linux.
For a Linux user, it's a bit irritating that virtual desktops aren't supported. So you sit there with five or six empty workspaces, and on the RR one, you have all these windows stacked up one behind the other getting in each others way - application browser, cards and stacks, script editor, card designer, message box - and you cannot move a few of them away to get rid of the clutter. This may change in the next upgrade. It does give you a vivid insight into what the usability gurus have missed in every Mac and Windows release for the last twenty years, and a deep desire to watch someone else trying to work like this, rather than have to do it yourself.
What are the amateur's alternatives to RR? Here are a few. For a real database application, Filemaker is the obvious one. It is easy and powerful, if not cheap either. But, it doesn't run on Linux. PythonCard is a Free/free package using the HC/RR/MC card and stack metaphor, but with Python as the scripting language. Documentation of PC is pretty sketchy, but of course Python is very well documented and cross platform. There is a fairly low activity but generally helpful forum, and some decent starting tutorials, a couple by Dan Shafer. Then there are the various Free database packages - Rekall, Knoda, Kexi, Base, Glom. Knoda is generally rated the best of these. The difficulty for the amateur with all of them will be scripting, which is pretty much undocumented or inaccessibly documented. If all you want to do is make tables, put data in and access it, any is probably fine. But then, you can also use Tellico, which will give you a great premade environment for handling anything that can be construed as a non-relational collection. And Treeline is very interesting on Linux as a powerful package for less structured data.
For RAD type packages there's Dabo and Datakiosk. REALbasic is a non-Free (but financially free for Linux) serious development environment, exhaustively documented, maybe too steep a learning curve for the amateur? Gambas is very promising, but only runs on Linux, sketchily documented (but VB is well covered and that's probably the starting point). It's intended as an open source replacement for Visual Basic. The (non-Free) sleeper for our purpose may be rebol. This is fast, small, easy, very high level, runs on everything, and has a great series of tutorials and examples as well as comprehensive detailed manuals. Entry level versions are financially free but not open source.