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?

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

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

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

Post a reply to this message

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

Am 08.03.2011 19:35, schrieb Darren New:

> Since we were talking about programming
> languages, not implementations or individual programs

Are we?

The OP was about computer systems, not languages.

Post a reply to this message

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

Le 08/03/2011 20:56, Orchid XP v8 nous fit lire :
> 
> Unless the thing changes purpose. *Then* backwards compatibility is pure
> liquid evil! >_<

Take the motto of the days: It's a revolution!

(subtitle: you must buy everything again, nothing is compatible)
(from the apple's Job parodies about the ipod/itouch/i... )

If the world was to be backward compatible, sciences would be in greek;
Laws would be in latin; and Rome would rules the world. (not the
monotheistic Rome...). That's from a mediteranean western point of view.

Post a reply to this message

Orchid XP v8 wrote:
> I tend to think if a system is designed right to start
> with, backwards compatibility isn't so bad.

Yes. In my experience, the biggest backward compatibility problem is when 
you go from a very limited special-purpose something and slowly and 
progressively turn it step by step into something tremendously general.

Think, say, of XML being used to specify a programming language.

If you have lots of defaults that nobody ever uses, or lots of syntax to 
indicate old-style vs new style, you're probably screwed.

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

Am 08.03.2011 20:56, schrieb Orchid XP v8:

> 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! >_<

Now, why would you ever want to /change/ a system, if not to reflect 
certain changes in purpose? Thus, backwards compatibility is /always/ 
pure liquid evil :-P

Post a reply to this message

On 08/03/2011 11:51 PM, clipka wrote:
> Am 08.03.2011 20:56, schrieb Orchid XP v8:
>
>> 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! >_<
>
> Now, why would you ever want to /change/ a system, if not to reflect
> certain changes in purpose?

Perhaps to fix something that wasn't quite right before.

> Thus, backwards compatibility is /always/ pure liquid evil :-P

...oh, wait...

Post a reply to this message

On 7-3-2011 11:18, Invisible wrote:
> Now here's a random thought.
>
> There are several computer systems out there which basically started off
> either as small-scale experiments, or as a single person's personal
> useful tool. These then "escaped" and became wildly popular, despite the
> fact that they were never properly designed and scale horribly.

bloatware might cover some aspects.

> There should be a name for that... but I can't think of one.

Me neither. I should know, I am supporting one such package.


-- 
Apparently you can afford your own dictator for less than 10 cents per 
citizen per day.

Post a reply to this message