Newbie switching from TCL

[Robin Becker]

In article <8nr6en0mh5 at news2.newsguy.com>, Alex Martelli
<alex at magenta.com> writes
>"Cameron Laird" <claird at starbase.neosoft.com> wrote in message
>news:3799AC8F18F40B22.120B7952059DF9AB.F280265F91BC2016 at lp.airnews.net...
>    [snip]
>> At the same time, Tcl is relatively isolated as a language in
>> its emphasis of event handling.  Most prominent languages today
>> promote threading as a multi-processing mechanism.  This popu-
>> larity in itself constitutes an argument for Python's threading.
>
>"And if everybody else was jumping off a cliff, would you jump
>off a cliff, too"?-)
>
>(P.S.: Visual Basic does allow threading [reluctantly, and only
>in recent releases], but event-handling is definitely at its core;
>considering that it probably has more users than Tcl, Python, and
>any one other scripting language you can name put together, it
>might be considered "prominent"...).
>
>
>Alex
....
true, but underneath a lot of the VB events are threads/processes that
do the event notification. The windows loop itself which you need to do
any significant events is often in a separate thread; when it's not you
get the awful unresponsive M$ window which can't be moved while the main
app is calculating. A nice article by Steve Uhler (DDJ Sep/99) on Event-
Based Servers in Tcl is quite honest about when event or threads are
good/bad. I think he asserts that non-blocking I/O is a requirement for
event driven servers and I seem to remember that the tcl implementation
uses a separate thread for that.
-- 
Robin Becker