Orchid XP v8 wrote:
> On 08/03/2011 05:09 PM, Darren New wrote:
>> Invisible wrote:
>>> Poor performance is the exact opposite of scalability.
>>
>> I think it depends on whether you're talking about scalable at runtime
>> or scalable at coding time. I.e., is it a question of how big a program
>> you can write, or a question of how big a program you can run?
> 
> I've not seen it applied to code size. Usually it's applied to run-time 
> performance. (E.g., if you have a program that uses an O(N^2) algorithm, 
> it probably works just fine for 10 users, but it's going to fail 
> spectacularly for 10,000,000 users. It does not "scale".)

Yep. But if you're talking about whether a programming language is scalable, 
one could use that word to mean "how big a program can you reasonably 
write?"  I.e., modularity leads to better scalability but not better 
performance. Various language features like separate compilation, safety, 
garbage collection or other resource management, etc all lead to the ability 
to better manage program complexity and hence let you write larger scale 
programs. Since we were talking about programming languages, not 
implementations or individual programs, I assumed the word "scalability" was 
referring to how much abstraction and generalization there is in the language.

The problem is that it's possible to put abstraction and generalization into 
a language yet do it poorly, such that the different abstractions battle 
with each other. This is usually what happens when a poorly-planned personal 
project escapes into the wild and grows organically over many years without 
either someone saying "No, that would make it bad" or someone saying "this 
has gotten out of hand, let's start over."

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message