rebuiling from scratch would have been a waste of time. It seems like MACR
is screwed. Whatever code they use will be assumed to be best, even though a
good developer knows that what works for one situation will not be best for
another.
This entire thread is probably the biggest waste of time I've seen on this
list (and yea, I know I'm adding to it). If MACR chose the best code for
their site, that should be the end of it.
-Raymond Camden
>
> I understand the tradeoff. I'm just saying that MM is big
> enough with enough money and skilled programmers to write
> some of the tightest, fastest, most optimized code around if
> they wanted to. The extra few dollars to make the code 'fast
> but inflexibility' (it really isn't inflexible, it's just
> specific to the needs of the MM site) is worth it to avoid
> what started this entire thread. To have anyone see an error
> on a website, let alone for there to be an error in the first
> place is just not acceptable (in my mind when thinking of a
> multi-million dollar internet software company).
>
> > There is almost always a trade-off between flexibility,
> abstraction,
> > etc. and performance, but one typically tries to strike the right
> > balance between the two extremes. The right balance
> typically falls
> > between the cost of extending and maintaining a fast but
> inflexibility
> > application, and the cost of having to throw hardware or other
> > optimizations as a slow but highly configurable application. I'm
> > certain Sean's team understands this equation and has made their
> > decisions accordingly.
> >
> > Christian
> >
> >
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
