In article <LAW2-F178WGxegIqunL0000470d / hotmail.com>,
Ben Tilly <ben_tilly / hotmail.com> wrote:
			.
		[lots of true and
		significant points]
			.
			.
>costs that people tend to ignore until it is too late.  But
>people tend to judge overall performance of GUIs by how
>responsive it is, so for interesting GUIs, multi-threading is
>usually the right choice.
			.
			.
			.
I want to be clear on this:  you're opposing
multi-threading to cooperative multitasking
models, is that right?  And then saying that
cooperative concurrency never is adequately
responsive in serious GUIs?  I understand
both those propositions, and can sort of
agree on my own with the latter--but multi-
threading's a cure that's worse than the
disease!

I should clarify.  OK, if I had to recode
FrameMaker, say, I'd probably choose a threaded
model (and use it *very* carefully!).  Is
that really the "market" Rubyists are target-
ing?  I've lost almost all interest in Big
Serious Projects with integrated GUIs; I just
never see them finishing and going into pro-
duction.  Even the most safety-conscious
"mission-critical" industrial users that I
know as successful emphasize time-to-market
and simplicity.  They're receptive to a 
naturally OO-aware, maintainable, rapid-devel-
opment language like Ruby; it doesn't have to
be Ada or Eiffel.  A co-operatively multitasked
GUI is not a serious constraint for the appli-
cations that actually need to be built on a
daily basis.

Are we talking about the same things?  Are
there shops that seriously want to develop
mega-source-line client-side processes, that
would consider Ruby even if it had the world's
most perfect GUI binding?
-- 

Cameron Laird <claird / NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html