On Mon, April 2, 2007 1:11 pm, Andrew Lentvorski wrote: > Lan Barnes wrote:
> Either your language copes with multiple concurrency abstractions, or it > is at a dead end. Maybe *you* don't write threaded code, but the > package and library developers will have to. > > We can certainly argue about that. No argument from me on that. The way different languages at every level of abstraction present their features is what gives them their utility (and personality). And all of that comes from the language developers. Example. I'm not wild about Tcl namespaces. I find their syntax borrowed, un-Tclish, and klugey. And I can avoid them for 90% of what I program. My stuff just doesn't get complex enough to benefit from namespaces. I can still manage complexity with judicious naming conventions. BUT, I'm damn glad it's there. Otherwise many things would be frightening or close to impossible. Threads are probably the same sort of thing. I have no idea. I maintain a grand disregard for anything that doesn't pertain to my immediate situation. > >>> I have helped debug more than a few Tcl/Tk programs for beginners where >>> some UI callback sets a variable in the wrong order relative to the >>> mainline program flow. And this is for exactly *2* threads. Try >>> explaining to them what just happened; it's really hard. It shouldn't >>> be so blasted hard. > > I note that you ignored this. You shouldn't have. It is at the heart > of the problem. As I reread that, I'm not sure I understand the sin you're discussing, nor could I without an example. I know that I have frequently wrestled with sequenses, buffer flushes, blocking/unblocking, sync/async, circular callbacks, and event scope issues. It can get nasty. I think to handle these easily one must understand the assembler code. High level abstraction is not always your friend. Fortunately in Tcl (and I'm sure many other cultures) there are lots of nice, clean modules that encompass a solution. One can (and this one has) cut and paste a 9 line module from the Tcler's wiki that just works, and then elaborate it. > > Until I have a language that college students can use to program > concurrency and not get lost in a maze of subtle, evanescent, > unreproduceable bugs, there is no language that handles concurrency well. > How high exactly is this bar? ALL college students? English-bound freshmen who stumble into a CS course because their uncle said it was a good living? Play fair, here. No one said everyone could do this stuff. > And, why are you taking this as an attack on Tcl/Tk? It's not. I'm > sure their implementation of threads is fine. > Because I'm SEN-sitive! My mother said so. And you're nothing but a poopy old <think hard think hard> ELITIST, Andrew Lentvorski! So there! :-P -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
