Comparing Node.js with Tcl
pietersz.co.uk
pietersz.co.uk
The main potential, though, is portability and future-proofing. Tcl is so ridiculously simple that it's been implemented on about every OS and architecture. That's batteries included due to all the existing code and ActiveState's development tools. People can extend live apps, run shell scripts, configure networks, and so on all using the same (or a similar) language. Any change in underlying platform just requires porting the (simple) lower layers. Makes Tcl a powerful future-proofing option if used judiciously.
I'm sure an equally minimal http implementation using the net module would match or beat that, but since you'd never use either of them in production, the results are meaningless.
2. In which case you would be opened up not only to performance benchmarks but usability, simplicity, and features - whether you are talking about the language or the implementation.
That being said, I have nothing against your opinions or work though and understand that your implementation is also from 2008 :)
Yeah, but in which software's favor?
TCL has been battle-tested for decades, even in industrial automation...
Now, this particular server might be just some guy's quick project, but Node also started as a ho-hum experiment...
Right but I believe the point was that this http implementation was less battle-tested than node's and that if you're willing to strip away features from the node version, it too could outperform node's version in a microbenchmark.
That said, while it's a fair test, I don't think it's a particularly useful one. It would be interesting to see how the two compete when they do something equivalent but non-trivial.
It was not meant to be more than a limited test of the TCL event loop and my code.
[0] http://benchmarksgame.alioth.debian.org/u32/performance.php?...
[1] http://blog.chromium.org/2009/02/irregexp-google-chromes-new...
On the other hand, I think the point that real world performance will depend on the task in hand stands.
Regexes are the only way to do more advanced text manipulation in JavaScript, so they're being used far more than in other languages. Lua is similar here, having only a couple most basic string operations built-in and relying on regexes for anything even slightly more advanced. This makes it natural for these languages' implementations to focus heavily on optimizing regexes.
Also, regexes are easily JITable and of course implementations having a JIT are going to be much more performant than normal interpreters. This explains the results of your [0] - I didn't check, but I suppose it's a vanilla Lua interpreter and not LuaJIT.
I was never all that great a TCL programmer - it was the first language I did any real work in, and I had quite limited experience at the time I wrote that.
So this comparison is as skewed as can be. Writing server (or even client) software in Tcl is a pure travesty.
> it's the most god-awful language I've ever seen
I wonder, how many and which exactly languages have you seen, used and learned? Are you sure you're versed in PLT enough to be able to really understand all the TCL features and their impact on the language?
I'd say TCL is fairly similar to Lisps and REBOL, which makes it both simple and hard to master. It also makes it very different from BASIC...
[EDIT: typo]
At least there's no need for any kind of toString() method...
This is a design decision which makes the language smaller and easily composable. It also helps greatly with metaprogramming, because the code itself is also just a string - this makes Tcl homoiconic, which is a nice property to have. Last but not least, you can easily type-tag the values you use in more than one way if you want; you also have a built-in object system for cases where you need more structure in order for things not to get hairy.
> Dynamic scoping rules and `uplevel` & Co
Tcl is lexically scoped by default, it just provides ways to break out from lexical context. It's a good thing, allowing you to write for example this: http://rosettacode.org/wiki/Generic_swap#Tcl without any hassle. Like all design decisions it has its downsides, but it's a powerful tool if used correctly.
Tcl is not a bad language, it's just ill-suited for you or for your use case.
That was the point! I pasted it as an example of what you can do with upvar, by bypassing lexical scoping. Take a look at other entries on that page: almost all high-level languages either pack the two variables into a list of some kind (passed by reference) or have a specialized language construct for this (inout etc.)
> neither has Tcl
This is very easy to disprove, take a look. This code:
proc g {} {
echo $a
}
proc f {} {
set a 10
g
}
f
can't read "a": no such variable
while executing
"echo $a"
(procedure "g" line 2)
invoked from within
"g"
(procedure "f" line 3)
invoked from within
"f"
(file "main.tcl" line 35)
(defun g ()
(message "%s" a))
(defun f ()
(let ((a 10))
(g)))
(f)
> just a really bad one.
It (upvar and uplevel) lets you easily define new control structures (think "unless", "until", "await", things like these). I don't think you can convince me that adding a powerful feature to the language is a bad decision... but that's indeed a matter of preference and there are people who use Go, so I'm not going to argue about this :)