On Mon, April 2, 2007 12:42 am, Andrew Lentvorski wrote: > Lan Barnes wrote: >
>> [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*. Sure we are. Me and people like me. 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. I want a language that lets me -- not some CS PhD or PhD wannabe -- write efficient, scalable, maintainable and understandable programs. I want to write them quickly and I want the language to be cross platform and close to bullet proof. I want international language support without having to bend my programming style or learn a gazillion new constructs. And I don't want to be locked out of any low level thing I might want to do. 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. Another thing. Someone (I forget who) made a sideways comment about the "performance hit" that writing a program in Tcl entails. Umm ... how to put this? ... bullpucky. A comment like that can only come from complete inexperience (which is a kind way of saying ignorance). Sure, if you chose to put scripted computations or data base accesses in a scripted double loop, you'll notice some performance degradation in the thousands to hundreds of thousands of iterations area ... maybe. Sometimes if you write it rough or sloppy, expecting to tune it later, you find out that performance is just fine and doesn't need any tuning. But there is absolutely nothing preventing an ordinary Tcl'er from writing (or copping) a time-consuming procedure in C or asm and then adding it to Tcl as a new native command. You can even loop it in C if you so desire and have it return its conclusion to Tcl. People who sneer at the performance of modern scripting languages are, IMO, repeating a slander that they have not personally tested. I can write a scripted grep in perl OR Tcl that is imperceptably slower than the compiled grep on huge text files. And guess which takes me longer, writing in in Tcl/perl or writing in in C? And then debugging it. And debugging it. And more debugging it. So you bleeding edge jockeys can continue to sail off into the blue chatting about the latest through-the-looking-glass hot flashes. I am content to stick with a language that lets me put into production relatively sophisticated programs the same afternoon I conceive of them. :-P > > 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 > -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
