To add a wildcard to the mix, I tend to rapidly prototype some things in Perl. In fact, I do it so much that quite a few things don't get
out of the "rapid prototyping in Perl" cycle, and I spoil myself with the complete typeless nature of the language[1].
It is of course far slower than a proper compiled language (and while there's a "perl2exe" out there, it's both subjected to a trial period licence and really only bundles the perl interpreter in with the script it's interpreting, a bit like the original pkzip2exe did for self-extracting files) and I just can't get on with the Tkx module in windows (even though I can get Tk to sing and dance in a Linux environment). But there's a lot of power in the core code. Which probably makes it very bad for actually
learning, but does concentrate you into good programming practice (proper naming conventions, commenting, structuring your code and, though I don't do this nearly as much as I ought to, developing one's own library of Perl modules to handle common bits of code that one develops in lieu of (or despite) existing modules.
So, I'd never suggest it as a learning language, and probably not as a gaming one, but it could be a handy tool to work out processes. And alongside another language sufficiently different[2] to add to your computer-polyglotism without confusing yourself about syntax (i.e. mixing with PHP causes problems, IME[3]) but instead lets you work out the general idea of the data flow and forces you to learn what is and isn't possible in the eventual target language when converting.
As you can tell, this isn't so much a recommendation as a "I do this, but it probably wouldn't suit everybody" post, but I started out writing it with far better intentions than that... I now realise that I might as well suggest you use something like Forth (a nice little language but perhaps not best suited to gaming
. Or just about anything except COBOL, which was one of the most godawful languages I ever had the misfortune to have used, and (IMHO) severely compromised by the fact that it appears to have been developed entirely so that it was more human-readable than other languages of the age (not itself a bad thing, of course), and yet enforced silly syntactic requirements (as opposed to conventions) such as precise white-space indenting that were of practical use to neither man nor machine, in the long run.
Did that help, then? Probably not.
[1] e.g. Send a variable containing an array reference into a function, test to detect this when you access the parameter by reference
itself within the function and then operate both upon the given external array
and produce a value that you can poke directly back into the variable originally offered to the function so that the next function along sees it as a value
and can access the newly modified referenced array... I mean, you could do something like that in the likes of Delphi with "procedure Foo(var x: pWhatever)" and some awkwardness, and various C flavours lets you do it if you also wriggle the nature of pointers around a little more than K&R/ANSI really wants you to do.
[2] If in doubt, I suppose you could stick to function-orientation in Perl while using object orientation in whatever C-form you're working with.
[3] e.g. I write my web-site back-ends in pure Perl, serving up the HTML with home-grown routines. PHP confuses me slightly more than I think it should because it shares so much with Perl, yet is of course more or less as SSI and might as well be Javascript (IMHO) if not for putting most of the load on the server instead of the browser.