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.

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.

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.

Crysis Warhead is a good example of this - they invested so much into the engine and assets for the first game, it was good to see an extra set of levels that built upon Crytek's experience and was a vast improvement in level design and pacing. The problem with FPS games is they tend to get boring unless they regularly switch up the game play (e.g. Half-Life 2), which seems to be difficult for most designers who are content with churning out level after level of the same thing.

You're right, that's exactly what we need, shorter games. Never mind that most FPSs out today can be completed in an afternoon, and have very little depth (exploration, multiple routes, etc.) compared to the 20-60 hour RPGs on the market. I'm sorry that you can't spare the time in your busy life to play something longer than a couple of hours, but I think most of us want value for our money - especially if we're paying £35+ for the game.

Unfortunately in the UK, if you go into Currys, Argos, Maplin, pretty much anywhere and buy a netbook, it'll have Windows XP on it. The only way to get Linux on a netbook is to purchase an Acer Aspire One, buy Windows and install over it, or go to Amazon or another online seller and hope you can find a Linux version of the model you want.

You offer three points in rebuttal:

1) An increase in use of Centmail points could be flagged as suspicious

...after the fact? Or will you have an automated system that prevents the mails from being sent if they seem suspicious? Otherwise a spammer can simply do a hit and run and exhaust the user's account. Regardless of that, spammers are more likely to control a very large amount of zombie Windows boxes, sending out a small number of e-mails on each machine.

2) If a user gets hacked, he just ends up donating more money to charity

Which is wonderful and all, but doesn't really solve the problem.

3) Hackers are more likely to be interested in other aspects of the user's computer

Spammers have demonstrably took over swathes of Windows machines exclusively to send out spam. Even if they didn't, centmail offers the chance to send a mail that is practically verified as genuine, which is very rare, and worth hacking a computer for.

Whoops, thanks for pointing that out.

First and foremost Qt is not just a widget toolkit. It is a full development environment: it has a build system (qmake), a fully-developed IDE and widget layout editor (Qt Creator) and many, many extra libraries. To quote just a few examples, there are classes to handle tray icons (whether in KDE, GNOME, Mac OS X or Windows), classes for running TCP servers, integration with the Phonon media framework, the WebKit browser, SVG, databases, multi-threaded code and even scripting support using QtScript, an implementation of ECMAScript (JavaScript).

Qt is written in C++. GTK attempts to do object-oriented code in C and the result is a mess of explicit casting and macros. Seriously, most GTK C code looks horrible and is far less terse than the equivalent Qt program. This is mitigated when Python or Perl is used, but then you're sacrificing speed. With Qt writing C++ is basically as easy as using Java, C# or any other 'modern' language. All of the nasty stuff is taken care of. For example, Qt code is generally cross-platform.

Its signal and slot system is also very powerful. For example, you connect a button's click() signal to the QApplication's quit() slot, and the button will cause the app to close when clicked. These signal/slot pairs can even be set via the Qt Creator IDE, just like Visual Basic! Or you might start up a webpage download and assign a slot to handle the signal sent when the page has been downloaded. Qt's signal/slots are introspective and modifiable at runtime, and you define new signals and slots just like you define new methods for a C++ class. The drawback there is that Qt programs require a pre-processing pass by moc (the meta-object compiler), in order to generate meta-data for runtime signal/slot manipulation, and to offer some syntactic sugar around Qt's features. As a side-effect, Qt adds syntactic sugar for features some might find questionable, for example adding a foreach() loop for lists.

The build system, qmake, is quite simple: you list your source files, libraries and headers to link in a short configuration file (qmake can even generate this for you). qmake then generates a makefile from this data. This is useful as it also includes the 'moc' pass, but can be constrictive in some cases. You are, of course, not obligated to use qmake in your Qt project.

As far as widgets go, Qt's are comparable with GTK or any other toolkit out there. Qt does a better job of looking good on non-Linux platforms, such as Windows. It has a simple but flexible widget system that is much easier to use than GridBagLayout or any of Swing's more poweful layouts.

The main issue with Qt was that, up until recently, it was licensed under the LGPL and before that, it was under the restrictive 'Qt license'. This is no longer the case, so jump in!

Yes, because people love to read long pages of text and never just click the first button at the bottom of the dialog. More importantly, plenty of Firefox users don't know they're using Firefox, or don't care, and won't know how to react to such security notices.

The first notice is much simpler: users will recognise that they are 'upgrading' to a new version, almost all will allow it, and people who don't like the awesomebar or something have the option to deny. The second notice is just confusing to novice and casual users.