Lan Barnes wrote:
Do you include QNX? Because they've had a working, bitching microkernel
Posix OS for years. Proprietary, of course.
Yes, I would include it. However, its proprietary nature limited its
adoption.
Concurrency is the Achilles' heel of almost all of the current crop of
languages. I don't think Tcl, Python, Perl, or Ruby are going to
survive that weakness.
Do you say this from a position of having tested all those languages and
their threading? Or is this a guesstimate?
I say that in general about *threading*, not the individual languages.
Threading with shared state is a poor concurrency construct. It does
not compose. Composition is the keystone of programming.
The fact that none of those languages seem to be looking at other
concurrency constructs (I have seen nothing about Actors or shared
transaction memory in those) does not bode well for their ability to evolve.
A language which cannot evolve will die.
I can speak from experience about Python. They don't even get *threads*
right. The Global Interpreter Lock drove me nuts. If they don't fix
that, I will eventually toss Python. I just haven't quite found the
replacement yet.
But I'm not ignorant of the Tcl core community. I've sat in their
discussions (Tcl USA '05 in Portland) and followed the discussions on
line. They are the most thoughtful, substantive, and courteous group I
have ever sat on the sidelines with. Nothing is initiated that isn't
discussed, accepted, and designed to the most stringent of standards.
At no point did I suggest otherwise.
[0] I have written lots of concurrent programs as well as a couple of
async socket c/s programs. Tcl makes these absurdly easy. I haven't looked
at tcl threading, but if it allows you to open a new interpreter in a
different thread, even I could utilize it without losing my feeble mind.
Maybe, and maybe not. But we're not talking about *you*.
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.
This is not limited to Tcl/Tk. We don't have any good multithreaded UI
toolkits. All of them that I know of require that update be done in a
single thread (the UI thread) and that other threads must set state and
wait for the UI thread to service them. If the really smart guys can't
seem to crack the nut, what chance do us mortals have?
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
