Norbert,

Guido has a point on one front: slow machines can sometimes expose problems 
that might not otherwise be apparent.  It could be as simple as highlighting 
inefficiency or as involved as changing the fraction of time the machine spends 
doing various things.  Testing under extreme loads has value, and one way to 
create "load" is to (if only artificially) hobble a machine.

I will distance myself from personal attacks on Stef and blanket smears of the 
processes and hard work that have brought Pharo to its current state.

Bill


________________________________________
From: [email protected] 
[[email protected]] on behalf of Norbert Hartl 
[[email protected]]
Sent: Sunday, November 06, 2011 6:32 PM
To: [email protected]
Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

Am 07.11.2011 um 00:00 schrieb Guido Stepken:

>
>> Reading was not a problem. But I have problems to understand what I am 
>> supposed to understand?
>>
>> Norbert
>
> You are just coder, no software architect, right?
>
What is the difference?

> Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some 
> load on Seaside? Funny effects occurring... machine hangs, crashes, spends 
> lots of time in useless functions, unneccessarily locking resouces, memory 
> pumping, eating up resources while waiting for e.g. database answer, spending 
> increasing amount of time (up to 98%) in removing garbage ....
>
I need to think a little while to come up with a single reason why I should do 
this. I'll come back to you if I find some. But don't wait for it.

> It's a good way of identifying unmatured software designs.
>
Yes, and spending most of your time on non-realistic cases and yagni makes you 
just a bad developer.

> Colliding mental models (e.g. event driven vs. polling)
> Such things happen, when all members are just coding, fixing, refactoring, 
> without bothering about algorithms, that still work reliable at low memory 
> and high load.
>
Ok, how clever are you if you design your machines to have too low memory and 
suffer from high load? If I recap you are saying that the reason you need to be 
a good software architect is because you are a bad system architect? If that's 
right why you don't just learn a little bit about system architecture?

> Pharo at the moment is still very unreliable.
>
> Sorry to say that! Think about, why FreeBSD works reliably even at a load of 
> 50, whereas other OS stop working.
>
Explain it to me, please!

Norbert

Reply via email to