This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.

Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.

Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?

Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.

That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.

Problem is, object-oriented programming is useful when it is applied on an as-needed basis.

Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.

So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.

There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.

WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.

I don't know whether you've gotten caught up in the UML/"design lots of patterns"/"writing code is for suckers" hoopla of the late 90's early 2000's--as if you didn't, you'll have a much easier time learning state of the art in development, while being able to apply enough experience from your younger days. (Consider everything that has to do with J2EE Enterprise Java of early 2000's as an example of what not to do.)

If you want to become current, you are going to need to learn to do:

1) Test-driven development
2) Write clean, expressive code (with much less need for comments and documentation)
3) Object-oriented design, as used to solve actual problems (not just putting functions into classes)
4) Design for what you need now or in the immediate future and refactor only as needs change
5) The Do Not Repeat Yourself principle. No duplication or copy/pasting.

The best advice I give to any starting out developer these days is to read Robert Martin's book Clean Code. It distills the wisdom of many an experienced programmer into a clear, well-explained format. It's Java-centric, but principles apply everywhere. Read it and see why separation of concerns is good, why keeping your functions at the same level of abstraction is good, why the single responsibility principle is good.

That book is the first book that explained to me properly why I should give a crap about the Law of Demeter. That law has been around since 1987 and yet I rarely came across anything but explanations with sterile, academic examples. Yet, "Clean Code" showed me why it's bad in closer-to-home terms AND, best of all, instantly provided a rewritten version that didn't violate the law and was clearly better.

One important point: it's not the languages you know, it's whether you know how to code well, design well and analyze problems well. All languages are just tools.

Modern development has finally stopped pissing over code and began respecting code. Gone are the days of trying to make UML diagrams generate Java (Model-Driven Architecture seems to have successfully passed us by without doing too much damage). In the web apps world, I think Ruby on Rails exemplifies latest thinking in software engineering, namely the thinking of "less code = better" and how to add abstraction layers without imposing code overhead in your application (e.g. convention over configuration).

Just because something is easier to use and works right without having to FK with it, doesn't mean it sucks for the advanced user.

No, if you return it, you are not obligated to the contract.

1) Standards & development:

You're right.

2) Usability:

"home screen is just an app," "keyboard is just an app" -- don't care. Don't care to install any OS version I want. Don't care to install a different home screen. That's not usability, that's just a pain in my neck.

Widgets are probably cool, but for multitasking, quoth Larry Page: "software running in the background that just sort of exhausts the battery quickly."

For me usability is not caring about anything like how many apps are open or whether anything's draining my battery. I just want to do things and care as little as possible about anything other than the thing I'm doing. With the iPhone, I don't ever think about closing any apps. My friend, who has a PocketPC phone, is always compulsively tries to close the browser on my iPhone before putting it away and I always tell her "it doesn't matter, just hit the sleep button." You don't have to exit out of anything, you don't have to close anything, there are no trojans that can stay running in the background. It's nice.

3) Upgradability:

That's nice. And you can swap multiple MicroSD cards, which, while a pain, can come in handy if use your phone in different enough sitautions.

4) Flexibility:

That's nice too. However, in general, I have been very happy with the choice of apps on the Apple app store and they do a lot of different things. I haven't felt the need to get a different browser--I quite like what comes with the phone.

The new sensor is bigger now, maintaining the same pixel size.

So you get more megapixels due to a larger sensor AND you get better sensitivity due to backside illumination.

I have a DSLR for quality pictures... for the rest, social situations and what not, 5 megapixels is plenty good and better low light performance just might make this good enough to obviate the need for a separate point & shoot camera.

I'd love to see some HTC Evo 8MP vs iPhone 4 5MP camera quality comparisons.

Bullshit back on you. False comparison. Lacking features != a crappy product. It just means a product that does less. First iPhone OS version didn't have exchange integration or copy/paste, but what was there worked well and was designed to work well. In fact, until Apple was convinced that it could do copy/paste well, it didn't release that feature. That's just not biting off more than you can chew.

There's a gulf of difference between shipping something that's limited in functionality to something that is crappy. Have you ever used the PocketPC PDAs back in the day? I've used a Palm OS-based Handspring and a PocketPC Dell Axim, and let me tell you, the Handspring, with its limited feature set and a slow CPU, did the core PDA things (calendar, todo) a lot better than the Axim. The Axim felt slow (despite a several times faster CPU) and it was harder to work with the calendar (more taps to do things, weird options I didn't need). I hated using it and wrote off PocketPC after that (which is why I never bought a Treo with Windows). That's what "shipping crap" means.

I think you're naive in putting down the iPad (or any Android or WebOS tablet) as a cheap device that's not fit for real work. How much horsepower do you think you really need? Do you need multi-GHZ processors to run bloated apps on top of Windows? These tablets run lean apps that are optimized for these "cheap devices"--and they certainly don't feel any slower. The fact is my Palm Handspring felt faster and snappier to use than a PocketPC Axim I had, despite the latter having four-five times as fast a processor.

With all the Slashdot bitching and moaning about how bloated apps have become these days, you should be happy that a cheap device can run web browsing, word processing and photo editing software at what feels like full desktop speeds.

Open source player to be someone's bitch?

Are you serious? How is this different from any other digital transfer method? And how could this possibly plug the analog hole? As long as you gots a speaker and a microphone or an analog transfer of audio (e.g. to your headphones), you have the whole. Tell me, is this going to do away with headphones?

Paint that eats asphalt? Please, paint did not let the asphalt breathe and soak in water, which caused in issues in the winter. Should they have known that? Yes, but apparently it's a new technology. If they didn't use it, you would've been complaining that Taxachusetts is still using decades-old paint technology, instead of this newfangled thermoplastic paint that's working so great in Texas.

http://wbztv.com/curious/white.paint.lines.2.1021788.html

So yeah, now they will have to repave Rt 24 earlier than scheduled (and it was already scheduled for repaving).

The acquisition FAQ says that they are excited to work on new webmail interfaces.

However, I just don't get that spirit of insight and innovation from the Opera team or the Fastmail team. I don't think they really have the chops to look past gmail and think about what the next best e-mail experience is. I feel that they will forever be constrained by the old-school thinking of the underlying protocols.

I agree. One of Fastmail's big draws was its lightweight, fast-loading, reasonable web interface. Sadly, that interface has stagnated and is barely keeping up.

I don't do local e-mail clients anymore (other than my smartphone). For any desktop e-mail needs, it's the web browser. So a lot of the value is in the web browser.

For example, Gmail had autosave way-way before Fastmail (to protect against browser crashes). Fastmail, as a commerical e-mail provider, should've been jumping on copying that, to match their web interface with those of the free competitors. Sadly, they didn't and that says a lot about what the company's vision is and what it isn't.

Their spam filtering is very good, but not as good as Gmail's. Yeah, I can define custom rules via Sieve, which was a fun novelty until I got tired of writing the rules by hand. At some point, e-mail becomes that damn thing that has to work and you want to spend less time tinkering and more time doing other, more interesting things.

There really is very little keeping me at Fastmail now and this acquisition makes me think twice about switching away. I have a $35/yr top-notch account.