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.
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
