>>>> 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.
>
> 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.

Hmm, yes, I suppose so...

> 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."

Indeed. :-S

Usually it's "we have 25 million LoC written in this thing, we can't 
change it now..."

Hence Haskell's infamous slogan, "avoid success at all costs". The idea 
that success implies eternal backwards compatibility, with is deeply 
evil. Then again, I tend to think if a system is designed right to start 
with, backwards compatibility isn't so bad.

Unless the thing changes purpose. *Then* backwards compatibility is pure 
liquid evil! >_<

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message