Personal tools
You are here: Home → Knowledge → Techie Central → OpenACS presentation → slide-14.html
Navigation
Log in


Forgot your password?
New user?
 
Document Actions

slide-14.html

Click here to get the file

Size 5.7 kB - File type text/html

File contents

<html>
<head>
  <title>TCL?</title>
</head>
<body bgcolor="white">
<table width="100%">
  <tr>
    <td align="left"><h2>TCL?</h2></td>
    <td align="right"><a href="slide-13.html">Prev</a> | <a href="slide-15.html">Next</a></td>
  </tr>
</table>
<hr>

<blockquote>

  TCL (pronouced <i>tickle</i>), or Tool Command Language, is a small
  interpreted scripting language that maintains a relatively low
  profile amongst the big languages of our time.  Most software
  developers have either never heard of TCL, or would deride it as a
  toy language.  Compared to the behemoths of development like Java
  and C it may occasionally appear to be a toy, but that may be an
  unfair assessment.<br/><br/>

  A lot of time is spent debating what language is the best.  Ignoring
  primarily interface design languages like Visual Basic, and also
  ignoring C-Sharp (Microsoft's Java-esque language) which I know
  nothing about, we are left with most people blathering on about the
  machine independence of Java, the speed of C, or the ease of
  development in PERL.  Not wanting to engage in the pointless pissing
  match of what language is best I will instead offer a brief defense
  of TCL as a programming language.<br/><br/>

  <i>TCL is slow</i> <br/><br/>

  Compared to a compiled language like C, or Java running on a fine
  JVM TCL is definitely slow.  There are two major compensating
  factors:

  <ol>
     <li>Oftentimes you are spending longer in the database then in
         the code, and in these cases the advantage of Java's speed is
         muted.</li>

     <li>Programmer time is expensive, hardware is cheap.  TCL is
         small, easy to learn, and has a satisfactory (if you're
         careful) macro-ing mechanism.  This, plus the fact that it is
         interpreted, makes development very fast.  Even if you know
         the J2EE standard inside and out you will be slower in
         writing your software then I will with TCL.  When you find
         that you are having trouble scaling you can often rely on
         machine upgrades to insulate you from <em>issues generated by
         the speed of your language</em>.  Hardware can't save you
         from bad design, but it can save you from language speed.</li>
  </ol>

  <i>TCL isn't OOP (doesn't have struct's etc.)</i><br/><br/>

  While Object Oriented Programming is all the rage right now, and it
  definitely can be a powerful paradigm, it is not the best tool for
  every situation.  Sometimes a functional or procedural language is a
  better fit.  While it is true that TCL's main language structure is
  the list (it does have an associative array), the list has been the
  backbone of LISP.  This is not to say that TCL's data structures are
  always good enough, there are some problems that are not list
  friendly, but with the addition of an RDBMS, TCL is up to the
  challenge of most website's needs.  <br/><br/>

  <i>TCL doesn't have as much available functionality as .. (PERL,
  PHP, Java, C)</i><br/><br/>

  I don't think that any language has as many packages tied to it as
  PERL.  The PERL community loves to create libraries for their
  favorite language.  This being said, it doesn't meant that everyone
  should use PERL.  While TCL may never catch up with these other
  languages in popularity it is the backing of a solid web toolkit,
  (as well as a nice graphical toolkit -- TK) and if you are working
  in these areas you should consider the toolkits on their own merits.<br/><br/>

  There are some real issues with TCL.  Although I sort of brushed it
  aside, the data structure issue will occasionally be an issue when
  building a complex website.  This will not often be the case, but
  when it does become a problem you may find yourself with a list of
  lists of lists of lists of lists.  This is a very unfortunate
  situation.  AOLserver tries to get around this with another type of
  associative array called an ns_set.  Unfortunately their
  implementation has linear lookup times on keys, which I personally
  find offensive.  TCL is also easily extensible via C for those of
  you who can't give up your struct's.<br/><br/>

  Another issue is that when designing a serious infrastructure (like
  OpenACS) you need to be fairly careful in design.  This is true in
  all languages, but TCL allows people to do very lazy things which
  are extremely frightening.  Consider "set_the_usual_form_variables",
  an old ACS function which would set a bunch of variables in the
  calling environment.  If you had a web request like:

  <pre>GET /object?oid=12&order=date_asc&user_id=145</pre>

  you would find that after running "set_the_usual_form_variables" you
  would have the variables oid set to 12, order set to "date_asc", and
  user_id=145.  Nowhere in the code had you expressly called for these
  variables to be set.  This means that anyone sending a web request
  can set variables in the calling environment.  Having a bunch of
  unspecified variables floating around leads to bugs, and even worse
  security issues.  If you are careless and don't initialize a
  variable you may find that some URL hacker has set the variable in
  your environment without you knowing.  This terrible practice is not
  limited to TCL, and in fact you find a lot of web-friendly languages
  doing just this.  Even worse is a language like PHP which sets these
  variables and if a variable is referenced and not set it substitutes
  "" for it's value.  This is a very dangerous and lazy practice.  Now
  that was quite the digression, but it does illustrate how TCL makes
  it easy for lazy programmers to make big mistakes thinking that they
  are good practices.  Any language can run into this problem, but
  languages like Java make it a little bit harder.

</blockquote>
<hr>
<a href="tristancohen@yahoo.com">tristancohen@yahoo.com</a>
</body>
</html>
by admin — last modified 2003-04-28 10:17
 

View My Stats