Hacker News Reader

Visual Basic 6 compiled to actual native code though, while TCL teached me to never use such languages beyond bare scripting tasks.

Even Visual Basic 3's P-Code interpreter was faster than TCL string based one.

View on HN

What was the last version of TCL you used? These days they have an extremely cunning system involving multiple representations: Being TCL, every value is of course canonically a string, but if you do (eg) integer operations the result will be stored only as an integer until its needed as anything else. And the body of a 'proc' will be compiled to bytecode on first use, so subsequent calls will go much faster. One could even add a specialising JIT to this if you wanted to.

Version 8.x, the ones where bytecodes where introduced (1999 - 2003).

Thing is, if you want to speak about modern TCL implementations, then the comparison needs to be against VB.NET, with its 64 bit SIMD aware JIT/AOT compilers.

Also, modern Tcl can be compiled to machine code to a large degree thanks to TclQuadCode and LLVM.

Interesting I wasn't aware of it, how mature is it?

It is still experimental, but the output code is stable -- most of the work is in expanding its support for the Tcl language.

Reply on news.ycombinator.com