Unicode support in Python 2 is basically the same as in Python 3. If you want to translate from binary strings to Unicode, you're going to need to specify a codec since the language doesn't just assume everything is UTF-8. The difference is that things like paths and command-line arguments are Unicode in Python 3 but plain binary strings in Python 2, so you wind up with this third "class" of strings that might be one or the other depending on which version of the language you're using.
But with a bit of care it's not hard to get a nontrivial amount of Python code to work unmodified in both versions by specifying import fallbacks and so on.
Haskell doesn't really have an "if" statement as such. It has an "if" expression (analogous to C's [expr] ? [expr] : [expr] conditional expression) but it's not widely used in my experience. Haskell folks would rather use guards and pattern matching to do the same job.
The whole point of HTML and CSS is that all this markup are suggestions to the client, who is free to rearrange elements, use different fonts or otherwise handle things differently for the benefit of the viewer. Making an entirely different, dumber, website for the benefit of some particular class of device defeats the purpose of a "world-wide web".
Make the devices better, not the websites worse.
Nintendo VS system was an adaptation of their home hardware for arcade use, not the other way around. The Famicom predates it by years, remember.
That's what I'm saying though, it's not all in the implementation, tail call recursion relies pretty heavily on the code being set up (and kept up) properly so that it is possible.
Writing code such that the last call in the function is always another call to itself isn't some deep mystery, though. The only question is whether the language is guaranteed to optimize that case.
Um, is that not sneaking in a normal iterative loop with a conditional check that's always true? What would be the difference from the code that generates and "while (1 == 1)"?
Since Haskell has no built-in "while" statement as such, you're going to need to either write an explicit recursive loop or just use one that's already been pre-built for running some action forever. It's just more obvious what's going on by using the latter.
Of course, in someplace like Haskell one can just use the "forever" function which loops some action forever rather than implementing an explicit tail-call loop and making sure to get it right. I'm just saying that recursion isn't guaranteed to blow up one's stack in all cases - it's all in the implementation.
Languages that guarantee tail call optimization won't have a problem implementing an infinite loop using recursion.
Turning de facto standards that have been implemented in actual browsers into a formal specification is how standards work best.
Coming up with a specification first and hoping someone will be able to implement it is how we wound up with Perl 6.
Though having to call up at all is annoying, I didn't have any trouble with it just a few days ago. I just told customer service I wanted the WiFi turned off and they transferred me over to the tech department and got it done in about 10 minutes after some address verification and whatnot.
If you call Comcast's customer service, they can put their new routers into bridge mode. This turns off its WiFi and other unnecessary features and makes it act like their old routers.
I go back and forth between OS X and Linux daily and a lot of OS X's window management is still sub-par. Its virtual desktop management still needs work, sloppy focus is never going to be an option, and hacks for tiling window management are about as terrible as one would expect.
It has its good points, but its double-buffered windows and nice aesthetics aren't enough to make me want to use OS X full-time while Linux environments do things better.
fortune: cpu time/usefulness ratio too high -- core dumped.