What madness! Everytime I think of a reason to do something in [C]/[C++],
I find a simpler (and quicker) way to do it in [Tcl].

This is hurting my (future) employability. In the past, I just watched the C++ coders slowly grind through
getting an app up and running, while I secretly implemented an alternative solution quickly in Tcl...
I can't bring myself to working (exclusively) in C/C++ again.

Standard C++ has a lot of good things going for it (its not your father's C++), but I find myself constantly
re-implementing ''nice to haves'' (like [fileevent], [glob], [file], etc) and quickly come to the conclusion that it won't
be anywhere near as stable as the Tcl Core implementations --- so I go back to Tcl.

In any I/O bound application (i.e. bound by human interaction, internet connections, etc), I am hardpressed to find C or C++ outperforming Tcl. Or, to put another way, I can send 3-5 emails per second using a pure
Tcl [SMTP] client (homegrown) in one [thread] of execution. The internet and SMTP is slowing me down. A similiar client in
C/C++ is no quicker (and using [Java] + JavaMail is actually slower).

Tcl + [Unix] + (insert Tcl bindings to C packages here) = a complete application framework.

In particular, I just implemented a [Tuplespace] in [Itcl] (+ [Metakit] for persistence) in just over 350 lines of code. 
It performs beautifully (you can even use [telnet] to attach to it and put/read/take items). I dropped plans to rewrite it in C++.

-- [Todd Coram] ''ranting and raving about not much of nuthin''

''Bravo, I can only nod in '''total''' agreement - and will add deployment hassles as a weak spot of C++ code.  I can't wait to see the [Critcl] system mature just a tad further, and really kill the (large-scale) use of C++ and even C.  -[jcw]''

Another idea would be to generate C++ source code ... -[jcw]

-------

See [Tcl as Sanity Check]