gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: [RT] Gump Architecture
Date Fri, 26 Mar 2004 07:43:41 GMT
Stefano Mazzocchi wrote:
> Leo Simons wrote:
>> (did I mention I'm an avalon guy? :D)
> did I mention that Avalon is dying out of flexibility cancer?

nope, and you shouldn't over here, wrong list :D

> Dude, let's just fix things incrementally.

well, "duh" :D. No one said anything about development process. Well, 
not in this thread, until now :D

> Lazyness is a virtue and Darwin is your man.

Gump has no competition; darwin won't work!


Even if you're fixing things incrementally, I think you need to have a 
goal. You take small steps, but its a good idea to take them in a 
particular direction. Especially when working in teams. Otherwise 
everyone walks in different directions and you lose track of each other.

In other words, incremental development doesn't mean "stop thinking 
about architecture". IMO.


Did you read what I wrote? Did you actually disagree with the four 
suggestions I made? Do you think they lead to flexibility cancer? Why? 
How? Is there no way to circumvent that? What's the alternatives then? 
Don't jump at the word "architecture" or at avalon but at the lame ideas 
I'm supposedly ranting on about...I think soundbites don't help us very 
much here!

Let's revisit some of this...tell me what those bad ideas are, dude!

 > - Replace the batch concept with a command/action/event concept.

This came up before as "get rid of the punchcard model and run things 
persistently". If you run things persistently you do need another 
abstraction. You can't run things if you have no abstraction.

 > - Replace the "giant tree transformations" with a "end-user view of
 > the tree".

This came up about 2 hours later after I posted this message when 
/someone/ (ie, you :D) suggested to start running a dynamic forrest. 
Isn't that about using an end-user view of the tree instead of a giant 
transformation? Isn't it?

 > - Think hard about the best way to represent the graph.

How can you disagree with that? Do you think we're doing a real good job 
at representing our gump graph? Do you think this is not an area where 
it's desireable to change things?

 > - Introduce node history as opposed to tree history.

Here, I'm /really/ interested in your opinion (as in, even more). You 
seem to agree that batch transformation of our trees is a bad idea, so 
you probably agree we need an alternative here as well. Is this the 
right one?

 > - A question that might pop up: but who sends the commands? Right now,
 > this is an algorithm which sorts the nodes in the tree into a flat
 > list and calls them in order. That's how it should stay for a while,

in other words, do it incrementally.


- Leo Simons

Weblog              --
IoC Component Glue  --
Articles & Opinions --
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message