Bryan Olson <[EMAIL PROTECTED]> writes:
> I don't see much point in trying to convince programmers that
> they don't really want concurrent threads. They really do. Some
> don't know how to use them, but that's largely because they
> haven't had them. I doubt a language for thread-phobes has much
> of a future.
The real problem is that the concurrency models available in currently
popular languages are still at the "goto" stage of language
development. Better models exist, have existed for decades, and are
available in a variety of languages.
It's not that these languages are for "thread-phobes", either. They
don't lose power any more than Python looses power by not having a
goto. They languages haven't taken off for reasons unrelated to the
threading model(*).
The rule I follow in choosing my tools is "Use the least complex tool
that will get the job done." Given that the threading models in
popular languages are complex and hard to work with, I look elsewhere
for solutions. I've had good luck using async I/O in lieue of
theards. It's won't solve every problem, but where it does, it's much
simpler to work with.
<mike
*) I recently saw a discussion elsehwere that touched on almost the
same topic, lamenting that diagnostic tools in popular programming
languages pretty much sucked, being at best no better than they were
30 years ago. The two together seem to indicate that something is
fundamentally broken somewhere.
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
