Because I Can. Also, because my Concepts of Imperative Programming Languages prof said it couldn't be done. Now, technically, intbigot probably doesn't qualify as an imperative programming language, as there is no control flow, but it would be a simple matter to add such a thing -- I'm just lazy.
I'm pretty sure intbigot is NOT disqualified as an imperative programming language because there's only one data type -- assembly is an imperative language too, right? And some architectures have uniformly 32-bit registers. intbigot would fit right in.
Update! My Concepts of Imperative Programming Languages prof has seen this, and has caved and admitted that yes, it is, in fact, possible. Which we already knew because you have a working copy in your hot little hands, right?
No, I went with the One True Data Type theme for two reasons. One, because it's impossible to mix static typing and dynamic scope if there's more than one type. Two, because I thought it'd be funny to have "Xtremely Static Typing to the Max!" Three, because "intbigot" is fun to say. intbigot! Yes, I know that's three reasons. No, I don't care. intbigot! intbigot! Heh heh heh.
You want the primer.
JIT is a nice little technology that allows you to conditionally compile code at runtime. What this means is that if intbigot had loops, instead of interpreting the same code in that loop over and over again, I can instead merely output the proper machine code and let the processor do the job as if the program had been compiled. It speeds things up and is generally a nifty technology.
As for why? Because I had been interested by this GNU lightning thing and wanted to see how hard it was to use. I figured the best way to learn it was to apply it to a project with no conceivable use. GNU lightning turned out to be pleasantly easy to work with, as a matter of fact -- there are a couple of things that I don't deal with and just cop out on, but they're few -- and I was able to implement the JIT compiler over the course of a day.
Perhaps. I do plan on adding control structures and things like that in the next release, but I don't plan on ever doing away with the "1 15 31337" example. Ever. I will not do anything that will kill the whimsical nature of the 32-bit integer-based language. If I ever add another type, to prove that it can be done (and it can), it shall be the unsigned 32-bit integer.
In other words, it's my pet project, it interests me, and I'll continue to tinker so long as I feel like it. =]