Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Tue, Apr 14, 2009 at 8:40 PM, Jon Watte <jw...@gm...> wrote:

> Sebastian Sylvan wrote:
> > That's not the same as saying that flexibility isn't desirable,
> > though. What I said was that if you evaluate a certain system you
> > would put "flexible" and "general" in the "pros" column, and
> > conversely you would put "rigid" and "specialized" in the "cons"
> > column. There may be a whole host of other things going into the two
> > columns which guide you to your final conclusion, but that doesn't
> > mean that flexibility in itself isn't a desirable trait, nor that
> > restrictions/rigidity is.
>
> That's the "guns don't kill people" argument. It turns out that, in real
> life, you never get "generality" or "flexibility" without a cost, and
> often, those costs and benefits are evaluated by someone who has a very
> different set of goals than you do.


I didn't say that, I said they were data points worth considering.
Also "never" is a very strong statement word to use, there are plenty of
cases when you can arbitrarily restrict an API for no real benefit because
you just didn't think of a way of doing it better when you first wrote it.
There are other cases where you can restrict an API because you think it
will buy you something, but then it turns out that the rigidity actually
hurts you because people have to work around the restrictions in ways which
end up costing more than the imagined benefits..



>
> To tie it back to asynclib: Asynclib is written by a transaction server
> programmer, who solved a transaction server problem, and is now trying
> to expand it to solve more kinds of problems. However, there are some
> classes of problems (such as, in my argument, micro-tasks for games)
> where the fundamental assumptions are so different that it doesn't make
> sense to apply a "one size fits all" component to solve that problem.
> Smaller, more well defined components are almost always a better match,
> as long as you can find those smaller, more well defined components that
> match your needs.


Well I certainly disagree with that, and I don't think you've demonstrated
the win, but I think we've had that argument to death already so no point
going over it again.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862