Earthquakes don't typically open up 2.5mile deep fissures to cause leaks like this. For the shallow reserves, they've probably already leaked out if they were geologically unstable, and we probably didn't notice because we weren't paying attention for a dozen or so millenia, not centuries, if we existed at all when it occurred. Most oil is produced from stuff that lived 10 to 160 million years ago. If it leaked out even 1 million years ago, we'd wouldn't see any current ecological effects.
To summarize Limbaugh, it is natural, and nature will take care of it. Just not in our life time, and depending on how bad we fuck up, possibly not in the rest of human history.
H.264 provides a better experience for the user, which is why Apple chose it. It's their same reasoning for denying Flash on their mobile devices. Flash, in their browser, degrades the performance to a level they are unhappy with. Flash, as a common programming target, becomes a lowest common denominator and hands API control and release cycles over to a 3rd party. I don't like Apple making those decisions for me, so I don't own their devices, but there are millions of people who don't care about this and just want the best experience.
While I'm happy Google is giving me a choice to use Flash on my phone, I'm not overly excited about its arrival either, I've programmed in Flash before, and I agree with many of Jobs' criticisms. My hope is that Apple's scorn will force them to improve their product.
Browser based apps are about the "here and now...anywhere, usually for free". It's the delivery mechanism that matters. There are more games available to you at any moment on the internet than were ever available for the 486. Where's the 486 equivalent to Last.FM, Hulu/YouTube, or Picasa? Even stuff that was possible on a 486 was often much slower and/or far more expensive than current Google Apps alternatives.
Yeah, software hasn't progressed at all.
@posts = Post.where(:status => 'public').order('created DESC')
$records = $this->_model->blogs->fetchAll(array('status = ?' => 'public'), 'created DESC');
Assuming these would be returned from a framework library, or I can't readily access the source and this is just part of documentation.
The first example is fairly readable, concise and sensible. Knowing a little about how Ruby handles things as objects, I "get it" and am comfortable with what @posts would probably contain. I'm fairly certain @posts is a plural set/object of more Post objects, which represents a row in a database, where status is public, then ordered descending. I can probably iterate through it. As an outsider, I could read this, lookup the column names for the row and almost immediately start using it.
Knowing some of the problems with PHP and its community, I can make no assumptions about what $records will really be unless I know the author's style or am already familiar with the codebase. Ignoring your writeup justification for shortening, I can't guess what _model is, I don't know what blogs really represents, and I'm uncertain why fetchAll needs an array object passed as a parameter, I have to mentally replace the question mark with "public", then assume the second parameter is an order-by parameter since I see the DESC. Before I would be ready and comfortable to use $records in a meaningful way, I'd have to dump it to the screen or use a debugger, plus lookup the syntax for fetchAll, and I'd really want to know what _model and blog actually represented since you're now magically assuming the blog object links to a table somehow. I do not know if blog is iterable or if it's rows it has grabbed are even accessible. $records may be the result of some manipulation it performs on the query result. I just don't know, and that makes me uncomfortable.
So while you've reduced character quantity to near comparable levels, you've not matched readability or understanding. You've merely condensed complex code into short complex code. Honestly, I think it's a philosophy difference between PHP and Ruby. Ruby the language strives for the principle of least surprises, and if the programmers utilizing it adhere to that, I can grasp their code pretty quickly. PHP is a grab-bag; you can make no assumptions, which is both a strength and a weakness.
Granted, PHP can still be used successfully to start and run a business, but as a programmer with no professional experience in either language, I'm gravitated towards the Ruby example.
Unless you're an international traveler, refuse to use subsidized phones, or obsessed with the iPhone, Sprint is the clear winner.
So...a truth table of tubes?
- 5 years of excellent service
- Significant features (first great spam filter, threaded conversations, search)
- First to offer generous storage quotas
- Service integration with Chat, Docs, Calender, Reader, Maps, etc
- Adequate and responsive mobile support
- One of the first to bring IMAP and SSL connections to everyday email
- Unobtrusive ads on page, and none have ever been injected into sent email
Sure, AOL has caught up to a lot of these, but strictly as a "me-too" effort to not alienate and lose [even more] users.
While it's probably not right to make judgments based on email domains, even while AOL has historically been associated with low technical competency, I see nothing wrong with discriminating based on usernames. For professional disclosure, I would expect a professionally acceptable username (i.e. no l33tspeak, nothing using "420", "69", drug-related or sexually provocative words, and nothing too crazy sounding unless you've got an significant and established online identity under that guise, and no generics like admin or email@example.com).
Vista and 7 improve on it, but neither are as slick as Ubuntu's liveCD method.