Lan Barnes wrote:
While you guys have been using this thread to rhaposidize about that which is new, shiny, hip slick and cool, I've been shaking my head and wondering if you really missed my original point that completely: that maybe 98% of the time, simple and direct is better than hip, slick and cool.
And what you are failing to get from my point is that I am not staring at concurrency because it's "hip, slick, and cool." I am staring at concurrency because performance is moving from "2x faster every 18 months" to "2x more cores *at the same speed* every 18 months".
Tcl/Tk gives me all that. I hope I live a long, productive life without ever having to write a line of threaded code, and with Tcl, I probably have that option.
Ah, this is the misunderstanding. Some of us believe, at this point, you don't get a choice. The speed formulation of Moore's law is dead; the cost/area formulation of Moore's law still holds though.
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.
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.
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.
My opinion on this subject is that threads are like C++. Superficially it's a good idea, but the cognitive load is too high for heavy use. Just as we have figured out that C++ has specific usage that it is good for (performance oriented hardware codes) and specific usage that it is not (dynamic behavior and code malleability), we will do the same for concurrency.
And, why are you taking this as an attack on Tcl/Tk? It's not. I'm sure their implementation of threads is fine.
What I'm saying is that language designers need to look beyond the assumption that "threads == concurrency".
-a -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
