Michele Simionato <[EMAIL PROTECTED]> wrote: ... > I would not call that an attack. If you want to see an attack, wait > for > Alex replying to you observations about the low quality of code at > Google! ;)
I'm not going to deny that Google Groups has glitches, particularly in its user interface (that's why I'm using MacSOUP instead, even though Groups, were it perfect, would offer me a lot of convenience). We have a LOT of products (see <http://www.google.com/intl/en/options/index.html>, plus a few more at <http://labs.google.com/>; <http://en.wikipedia.org/wiki/List_of_Google_products> for an overview, <http://searchengineland.com/070220-091136.php> for a list of more lists...), arguably too many in the light of the "It's best to do one thing really, really well" ``thing we've found to be true''; given the 70-20-10 rule we use (we spend 70% of our resources on search and ads [and of course infrastructure supporting those;-)], 20% on "adjacent businesses" such as News, Desktop and Maps, 10% on all the rest combined), products in the "other" (10%) category may simply not receive sufficient time, resources and attention. We've recently officially raised "Apps" to the status of a third pillar for Google (after Search and Ads), but I don't know which of our many products are officially within these pillar-level "Apps" -- maybe a good starting hint is what's currently included in the Premier Edition of Google Apps, i.e.: Gmail (with 99.9% uptime guarantee), Google Talk, Google Calendar, Docs & Spreadsheets, Page Creator and Start Page. I do notice that Google Groups is currently not in that "elite" (but then, neither are other products we also offer in for-pay editions, such as Google Earth and Sketchup) but I have no "insider information" as to what this means or portends for the future (of course not: if I _did_ have insider information, I could not talk about the subject!-). Notice, however, that none of these points depend on use of Python vs (or side by side with) other programming languages, DbC vs (or side by side with) other methodologies, and other such technical and technological issues: rather, these are strategical problems in the optimal allocation of resources that (no matter how abundant they may look on the outside) are always "scarce" compared to the bazillion ways in which they _could_ be employed -- engineers' time and attention, machines and networking infrastructure, and so forth. Alex -- http://mail.python.org/mailman/listinfo/python-list