Perl has access to socket programming primitives. You can essentially do ''everything'' you can do in C (with often the same function names).

I had to do some hardcore (200+ 6KB UDP messages/sec across 6 sockets) networking. It had to run 24x7 and there was no room for memory leaks. Naturally I prototyped it in Tcl (plus TclX and the TclUDP extension).

But Tcl is slow. To satisfy a caching requirement, I queued the messages in a Tcl list and used Tclx's lvarpush and lvarpop to store/fetch the messages. That was an order of magnitude slower than the same algorithm in Perl (using push and shift on arrays).

Still, the Perl app wasn't any faster. ''The network is the bottleneck''. But, more interestingly, I had to implement some common Tcl idioms (involving fileevent, after and non-blocking/non-buffering puts) in Perl. And, that is where I learned how well thoughtout the Tcl I/O system was.

As a side note, I added a very slim "udp_read" C function to my app to compare it with going through the channel based Tcl read proc (as TclUDP does). Not much performance improvement was gained by doing that.

In the end, Perl did allow me to tweak a few more things (but I could easily do that with a couple of Tcl extensions). Perl networking is much richer (without having to go to C). However, after struggling with partial writes (using syswrite) and mucking with IO::Select to get it to act like the Tcl event loop, I've come to appreciate the things Tcl does for me.

The lesson learned: Perl has better low level networking access, but the Tcl code contains a lot of built-in idiomatic functionality that you'll find yourself hand-coding to duplicate in Perl (and to less effect). See [POE].

-- [Todd Coram]  ''Once again, it looks like my Tcl prototype will make it into production without the often obligatory C rewrite!''

''[jcw] - Imagine having the best of both world: a 1-to-1 mapping of C system calls to Tcl, with the event system coded in Tcl...''
It could tie in nicely with [a critical mindset about policy], and make such a Tcl system considerably more modular (package require sockets?).  It also means someone who needs UDP could add it in Tcl, and instantly have it work on all platforms with the same system call interface.  It would not rule out a more efficient C-coded implementation, it would just provide more choices and portability.

[DKF]: I think that's one of your less well-baked suggestions jcw.  :^)  The ''good'' thing about Tcl is that it hides all the crap.  Expose it, and many people will insist on using it (because they're mindlessly reading off how to do it in some out-of-date networking bible) no matter how much there are better APIs available.  And the main problem with [UDP] is that it doesn't fit with Tcl's channel abstraction; AKu's been looking into this.  (As always, external packages can do whatever they want.)

[Todd Coram] - Sometimes I need access to the crap. What I really want is a backdoor (without relying on the crutch of dropping down to coding C extensions everytime). Maybe a ''package require posix'' or ''package require tcp''? I think Tcl is too slow to efficiently manipulate a low level api. This isn't a criticism though. Most of the time I just need Tcl's high level of I/O abstraction. What I (probably) really need is fconfigure on steroids. Sometimes I need to tweak socket/TCP parameters... The problem with ''fitting'' UDP into the channel abstraction is that it isn't a natural fit. It's a forced fit. Just like unix making ''read(2)'' deal with UDP. UDP isn't a streaming protocol. The ''one unifying abstraction'' tries to force the ''one true way'' with abstracting a family of similiar facilities (which usually leaves the edge behaviors/neeeds unsatisfied).