Bill,

don't take my email too serious. I just tried to meet the same level when 
replying to the original author. 

Am 07.11.2011 um 01:18 schrieb Schwab,Wilhelm K:

> 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.
> 
So you are doing it right, Bill. You say it "can" expose problems. That's true 
because you change the environmental parameters of the running program which 
has the potential to destabilize it. So you might identify a problem in that 
scale. What you don't get is an easy conclusion how this applies to your modern 
hardware. Assuming that all machines are equal and just move on the scale 
slow-fast is a bit naive. Only if you are like that you can compare an old 
computer with high load. 
Architectures change and the odds are high that you identified a problem which 
will never happen if you try it on a different hardware. There are 
optimizations that make things just faster. But a lot of optimizations are 
based on resource shortage. As much as these optimizations make a system more 
usable/reliable on a certain hardware generation as much they might destabilize 
the overall system. And some only bring you the gain in a single hardware 
generation.

So my response is more targetted to the fact that the author is capable of 
demanding things from this community to care about a problem he made up based 
on his own weak assumptions. No prove, nothing concrete to talk about. Just 
complains and demands for weird things like the need to "analytically 
identifying" "unpredictable" things??? Come on!

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

Agreed. To build a community you need to get rid of some of your own ego 
effects. Maybe that's a reason why ego based mails have a huge potential to 
harm such a community. Hmmm, but then I didn't do any better in replying :) 
Rats!

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