claird / starbase.neosoft.com (Cameron Laird) wrote:
>
>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 am opposing multi-threading to cooperative
multi-tasking models.  But I wouldn't say that you
never have good enough responsiveness with a cooperative
model, but that tends to happen.

I agree on the pain of multi-threading.

>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.

Suppose I have an existing library that does some
work which may take a minute.  Say it is a complex
database query.  If you want to build a wrapper
with a cooperative model, you are SOL.

Agreed on the, "Never see them finishing" complaint.
Software development carries a lot of risk.  The
bigger the project, the bigger the risk.  Failure
rates are absolutely abysmal on projects costing more
than a million dollars. :-(

(This is a common problem with "cool" Java projects.)

>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?

The issue is not limited to heavy client-side
interaction.  It also arises quickly when you want to
build a wrapper around an external thing which you do
not control, that may have slow-downs.  For instant
you have a step where you fetch something from an ftp
site.  What happens if the ftp site stalls halfway
through your fetch?  Do you continue?  For how long?

Of course most of this problem can be solved by having
reliable signal handlers.  Which Perl doesn't.  (It has
signal handlers, but they are not very reliable.)

And finally note that an interesting project might be
largely written in Ruby and then be scriptable in Ruby.
For most applications the complexity supported would be
unimportant.  But those applications depend on an
application that requires that.  For instance I have
heard that a good chunk of Microsoft Office is written
in VB.  VB is also the scripting language.  Very few
applications written in VB use much of what it can
theoretically do.  But they wouldn't be nearly as easy to
write in that language were VB not used internally for a
very complex project.

(Note, I am not a fan of VB, nor do I advocate that Ruby
look to it as a model.  It just happened to make a
convenient example so I used it.)

Cheers,
Ben
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com