I don't know; Lua's treatment of both as the same type of data leads to unexpected behavior:

local a = { 1, 2, 3, 4, 5 }
a[3] = nil -- "Remove" an element
-- Now a is { [1] = 1, [2] = 2, [4] = 4, [5] = 5 }

On a similar note, Lua's "everything undefined is nil" behavior can lead to subtle bugs. For example:

local a = { alpha, betaa, delta, gamma }

Assuming those are previously defined, the misspelled "beta" will evaluate to nil and create an array hole, which will screw up the value returned by the length operator. It also means you can't do things like reliably get the count of { f() } if f() returns nil.

"crApple"? Next you're going to tell us Bill Gates at M$ is the devil, this year will be the year of Linux on the desktop, hot grits down your pants, Natalie Portman naked and petrified...

And yet, only 18 comments. Why? This was the most awesome article in MONTHS.

"Wine SDK" = Winelib. Just plug in the fact that Android has no X11, fix a couple of dependencies, and there you go. BTW, you still need Wine to run Winelib applications (those are compiled with the Win32 API implementation given by wine, that is, they are native, but still require, for instance, a wineserver). It's all native, though.

Just a little heads up. That library is called WineLib, and applications built with it also have to be run within Wine itself, I believe. (That is, they still need a wineserver, for instance)

You were modded informative, IMO, for part of your post. Wine is not stuck in the Windows 2000 era for sure, as I have run many applications specifically designed for XP (and some made for Vista and Seven). You are right when you say that it "is relatively slow compared to Win32 on actual Windows", but you should add that this actually isn't for the majority of cases, or at least not in my experience. Anything DirectX related is bound to be slower in Wine, yes, but I've had better performance in Wine on multiple occasions.

And yes, you are again right when you say it has numerous bugs ;]

Everything on the other side of the WIn32 API is native indeed, with Wine. I'm not sure if you were asking that or somehow implying it, though I figured I'd clear it up.

You're right, the performance difference is negligible. I guess it's just a habit I've developed, though when I come to think of it, it really makes some sense to leave that in release code. OTOH, it might reveal what you expect a function to do more easily, thus facilitating reverse-engineering if one is afraid of that.

This is not input checking. Input checking is checking the input for validity and acting accordingly. This is an assert, which is usually used as a way for programmers to make sure they didn't fuck up. If it is triggered, then the programmer fucked up. That's how it's supposed to be used.

Hence, the programmer fucked up, and this isn't input checking. It is nevertheless, IMO; a good practice to assert things (in debug code), but it also isn't checking for valid inputs, it's checking for programmer stupidity.

Java browser, eh?

Please don't call it an emulator, it makes me cringe. Wine really isn't an emulator, period.

And I loved those performances !
I guess you're right. However, I still don't think Java is the right tool for ANY job. But that's just me, and I'm known for hating Java.

That's not Java. It's a very strict and small subset of Java. You can't even have 2D arrays!