I was thinking you had a kid. If you don't, I can't imagine how busy you'll be if/when that happens
In all seriousness, you don't need to "have no life", be unemployed or single in order to do an activity for an hour or so without interruption. I find it very hard to believe that you are truly that busy, that's all.
I just find the implementation to clunky to tolerate and I miss my multi-tasking view. The iphone OS enforces this work mode
Yeah, I think you said just about all that needs to be said.
The iPad isn't going to replace a music player, it's too large.
It's not going to replace a movie player, it's too small. Unless you're watching something on your own? Can't imagine that the sound is too great either.
It's not going to replace e-book readers, it doesn't use e-ink (iPad has a supposed battery life of "10 hours", Kindle is 7 days)
It's not going to replace video games for anything but the casual market, the hardware isn't up to scratch.
Plus it's completely locked-in and controlled by Apple, with proprietary formats, where you own nothing, only rent and agree to whatever terms Apple dictate. No thanks.
It really depends on what language you write your code in. Object-oriented languages in general require less documentation since good design and properly named methods and properties do document things relatively well
Perl has support for OO, ranging from the built-in stuff to a full-blown object system like Moose. Perl also has an inline documentation system called POD that bears some similarity to Javadoc. This leads me to conclude that you either don't know what you're talking about, or have been working with very bad Perl programmers.
At my place of work, any code I write is likely going to be maintained for years, perhaps decades; even if it doesn't, someone else is going to end up having to fix something or add a feature, or perhaps it will be deprecated only to be pulled out of retirement later. I typically write a few paragraphs to describe the class (with example instantiation and usage) plus perhaps a sentence or two per method. None of that Javadoc-style documenting every argument and return value separately, though. But I make it decent, because even if the class is relatively simple, it might not be simple in a year's time - and if the documentation isn't there to begin with, future contributors might not bother to add their own.
Actually, English has exactly 7 vowel letters. I learned this in first grade, why didn't everyone else? A, E, I, O, U, sometimes Y, and sometimes W.
For example, Crwth, and Cwm. Look them up!
Because those last two words are Welsh, not English. You could also argue that é is a vowel letter because of words like café, but of course these words are French in origin, even though they show up in English usage.
This is not really a new thing. IE8 has no menubar by default. Chrome has no menubar. Both browsers succeed in usability.
Why? Think about what you do with your browser. For the vast majority, you'll want bookmarks, a back button and maybe access your history once in a while. This is not Microsoft Word, where there are hundreds of possible commands to run on a piece of text. Web browsers are perfect for the "Ribbon-style" interface because almost all functionality is encapsulated within the content window itself - i.e., viewing pages and clicking links.
It's funny that other posters bring up extensions to fix this. Many Firefox extensions eschew the menu bar entirely, because they know that users will ignore it. The extension is instead visible in the status bar, as a browser "tray icon", in the context menu, or in the toolbar itself.
Another sad thing about this is that it forges Windows UI style to Linux and other OS, and stops being consistent with the rest of the system.
A large number of modern Linux applications have already adopted the 'no menu bar' style, most noticeably for GNOME. I don't think having a menu bar just to be consistent with other applications, regardless of OS, is a positive goal for the Firefox developers.
In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982