begin quoting Lan Barnes as of Fri, Mar 30, 2007 at 01:01:45PM -0700: > I thought this discussion of threads in Tcl/Tk on comp.lang.tcl might be > of interest. > > I have read the statement "if you think you need threads in Tcl, you > almost certainly don't understand your programming problem."
I read that as "you're dumber than I am neener neener neener". The reason to use threads is that it can -- not will, but can -- simplify a programming problem. If it does so, it's good; if it doesn't, it's not so good. > I personally > don't know enough about threading to comment on this, but I know enough > about the people who make those statements to not want to take issue with > their opinions lightly. Heh. I'm less respectful. > http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/fcb74b8353ce2c90?hl=en There are so many scare-quotes in that first post, it's almost impossible to read. It's almost a parody of the stated position... There's a lot less froth in the followups, which is nice to see. I agree that "bolting threads on the side" is generally not a very good idea -- if you're going to have threading, BUILD IT IN TO THE LANGUAGE. Ada apparently did this, and Java did this as well, and there, it works fairly well. There are many alternatives, but each one comes with its own set of tradeoffs (just like threads), so pointing at one or the other and saying "That one is BEST" is really just someone who wants to force their view on to everyone else. I think we need some more languages with built-in threading support, 'cuz the future is looking like multi-core shared-memory systems. We're going to be dealing with concurrent programming issues no matter what. We should be exploring that problem space, not avoiding it. -- Not a fan of cooperative concurrence or coroutines. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
