Ken Tilton <[EMAIL PROTECTED]> wrote: > Martin P. Hellwig wrote: > > Bill Atkins wrote: > > <cut> > > > >> > >> How do you define scalability? > >> > > http://www.google.com/search?hl=en&q=define%3Ascalability&btnG=Google+Search > > > > Damn! Google can do that?! Omigod!!! Not joking, I never knew that,a
You're welcome; we do have several little useful tricks like that. > lways used dictionary.com. Thx! I meant: > > > The ability to add power and capability to an existing system without > > significant expense or overhead. www.yipes.com/care/cc_glossary.shtml Excellent -- just the definition of "scalability" that Google and its competitor live and die by ((OK, OK, I'm _not_ implying that such issues as usability &c don't matter, by no means -- but, I live mostly in the world of infrastructure, where scalability and reliability reign)). > The number of definitions explains why most respondents should save > their breath. Natural language is naturally ambiguous. Meanwhile Usenet > is the perfect place to grab one meaning out of a dozen and argue over > the implications of that one meaning which of course is never the one > originally intended, as any reasonable, good faith reader would admit. However, you and I are/were discussing exactly the same nuance of meaning, either by a funny quirk of fate or because it's the one that really matters in large-scale programming (and more generally, large-scale systems). E.g., if your existing system can gracefully handle your current traffic of, say, a billion queries of complexity X, you want to be able to rapidly add a feature that will increase the average query's complexity to (X+dX) and attract 20% more users, so you'll need to handle 1.2 billion queries just as gracefully: i.e., you need to be able to add power and capability to your existing system, rapidly and reliably, just as that definition says. When this is the challenge, your choice of programming language is not the first order of business, of course -- your hardware and network architecture loom large, and so does the structuring of your applications and infrastructure software across machines and networks. Still, language does matter, at a "tertiary" level if you will. Among the potential advantages of Lisp is the fact that you could use Lisp across almost all semantic levels ("almost" because I don't think "Lisp machines" are a realistic option nowadays, so lower levels of the stack would remain in C and machine language -- but those levels may probably be best handled by a specialized squad of kernel-level and device-driver programmers, anyway); among the potential advantages of Python, the fact that (while not as suited as Lisp to lower-level coding, partly because of a lack of good solid compilers to make machine language out of it), it brings a powerful drive to uniformity, rather than a drive towards a host of "domain-specific" Little Languages as is encouraged by Lisp's admirably-powerful macro system. One key axis of scalability here is, how rapidly can you grow the teams of people that develop and maintain your software base? To meet all the challenges and grasp all the opportunities of an exploding market, Google has had to almost-double its size, in terms of number of engineers, every year for the last few years -- I believe that doing so while keeping stellar quality and productivity is an unprecedented feat, and while (again!) the choice of language(s) is not a primary factor (most kudos must go to our management and its approaches and methods, of course, and in particular to the strong corporate identity and culture they managed to develop and maintain), it still does matter. The uniformity of coding style and practices in our codebase is strong. We don't demand Python knowledge from all the engineers we hire: for any "engineering superstar" worth the adjective, Python is really easy and fast to pick up and start using productively -- I've seen it happen thousands of times, both in Google and in my previous career, and not just for engineers with a strong software background, but also for those whose specialties are hardware design, network operations, etc, etc. The language's simplicity and versatility allow this. Python "fits people's brains" to an unsurpassed extent -- in a way that, alas, languages requiring major "paradigm shifts" (such as pure FP languages, or Common Lisp, or even, say, Smalltalk, or Prolog...) just don't -- they really require a certain kind of mathematical mindset or predisposition which just isn't as widespread as you might hope. Myself, I do have more or less that kind of mindset, please note: while my Lisp and scheme are nowadays very rusty, proficiency with them was part of what landed me my first job, over a quarter century ago (microchip designers with a good grasp of lisp-ish languages being pretty rare, and TI being rather hungry for them at the time) -- but I must acknowlegde I'm an exception. Of course, the choice of Python does mean that, when we really truly need a "domain specific little language", we have to implement it as a language in its own right, rather than piggybacking it on top of a general-purpose language as Lisp would no doubt afford; see <http://labs.google.com/papers/sawzall.html> for such a DSLL developed at Google. However, I think this tradeoff is worthwhile, and, in particular, does not impede scaling. Alex -- http://mail.python.org/mailman/listinfo/python-list