I present to you, uzbl

And don't forget statistics and data analysis!

Maths is always good, no matter what situation. It goes side by side with logic, and calculus is a way of thinking about the world and its processes.

For some areas, there's a lot of math involved. Consider data analysis. At first, it may seem like you will never need data analysis, but many people end up working for companies where they have to track performance and efficiency issues (if you can save those 5 bits for each of those 10M clients, you'll get a nice raise). Another example: picture a situation where you are developing a phone application to determine if the user is riding a bus or not. In these kinds of situations (not that rare), you'll need to know data analysis, frequency analysis, time-frequency analysis....and for that you'll always eventually wind up having to understand some concepts of 'Advanced Math' (though do note that this isn't 'advanced math' at all)

I often hear that there are engineers and programmers. If you just want to be a programmer, maybe you won't need maths, but if you want to be an engineer, it will not only boost your way of thinking, but also simplify a lot of problems. (I'm not saying you'll ever have to know how JPEG or GIF works -- this involves maths --, but I'm saying that if you do, then you can do great things with that information).

Then go RTFA!.

Oh, right, this is /. ...

AH! Brilliant, sir! Have all my internetz!

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.