THT /
Why
Search:  


1.  Why THT

Why THT? Why bother, when you can use PHP which is, after all, everywhere already. Well, there are a few reasons as it turns out.

1.1  Simplicity

There are a number of disturbing usability issues with PHP (or Perl for that matter). Consider the following, an excerpt of PHP code that composes values from several variables and functions calls:

   echo "The ".$t." first ".Who("lang")." will get ".$h." butt kicked ".When().".";

The equivalent in THT might be:

   echo "The $t first [Who lang] will get $h butt kicked [When]."

Length-wise there is not too much difference. However, move almost any one of the 27 non-output characters in PHP and you will get a syntax error. THT has only 8 such characters.

Excessive use of syntax in PHP (and other languages) makes programming tedious and error-prone for users. A typical PHP program will multiply these syntactic gymnastics 1000's of times over, seriously lengthening the time it takes to compile and run a program. Tcl on the other hand is primarily a string based language. This makes it well suited for web scripting which is, after all, mostly string processing.

Thats because Tcl has little in the way of syntax. Rather it defines simple lexical rules that describe strings, lists and list elements.

1.2  Namespaces

Namespaces, which have long been a feature of Tcl, aren't avaiable in PHP (correction in 2009 version 5.3 introduced namespaces).

The lack of solid namespace support has some unfortunate consequences both for builtins and user defined code. For builtins, PHP mashes all functions into a single big global namespace. The result: hundreds of long-winded names with little organization or structure. The problem is worse for user code, where it's hard to avoid colliding with builtins or even other users code.

Tcl namespaces, on the other hand, allow simple partitioning of code. And it does so without the unnecessary complexity often associated with Object Oriented (OO). Moreover, with the advent of Ensembles in Tcl 8.5, namespaces are coming into their own.

1.3  Stability

PHP (and other languages) seem to evolve at a frentic rate. Every year or two seems to bring a new batch of fundamental changes to the language. Syntax changes, global variables and the addition of OO are a few recent ones that come to mind. Meanwhile, Tcl has hardly changed in nearly a decade. Scripts written in 2000 likely run with little or no changes today. Conversely, most new Tcl can run in old interpreters (eg. THT itself runs on 10 year old Tcl 8.3).

When a language changes, things break. Old code can get orphaned, and new code has only limited applicability, until, if, or when everyone upgrades.

1.4  Generality

Why is a purpose built language required for every problem domain? Why can't a language span multiple programing domains, like the web and desktop? Tcl/Tk can: it provides support for both embedded apps and lightweight, dependancy free GUI applications. This is in fact why so many other languages interface to Tk, eg. Perl, Python, Ruby, etc.

Nowhere is this situation more dire than on unix. For example, to download and build a single smallish application can involve 10 language environments eg: Make, M4, C, C-preprocessor, autoconf, bash, sed, awk, flex and bison. Debugging build systems based on such a mish-mash is incredibly difficult.

1.5  Validation

The issue of validation, or lack thereof, is troublesome and de bilitating. Most script languages (PHP and Tcl included) perform only minimal validation at runtime. For example, calls to functions with the wrong number of arguments (or functions not defined) are not caught until invocation time. Even ultra-mature languages like Perl don't really offer much in this quarter. How can this be? Certainly no programmer in their right mind would write a C application without prototypes, but somehow it's OK in scripted languages.

Even worse is that PHP (and standard Tcl) don't even detect syntax errors until that section of code is executed. Wize on the other hand allows an entire application to be validated, including syntax checks and function call verification. And this can happens everytime you run your application (during development). Moreover, auto-generation of prototype include files is now easy to do. And editors like Ted can use prototypes for auto-completion.

2.  What about Rivet, mod_tcl, or Websh?

Good question. These are all probably fine approaches. But they seem mostly to be concerned with beating PHP on performance. THT focuses on simplicity, ease of deployment and general applicability to situations other than running inside Apache. That said, you probably could run THT inside mod_tcl if you really wanted to.

© 2008 Peter MacDonald

Page last modified on February 02, 2010, at 07:43 PM