Comparisons of Tcl with other systems

This page contains an assortment of comparisons between Tcl/Tk and other similar systems. Most of them are culled from comp.lang.tcl, but I would be happy to add any relevant articles that anybody wants to send to me. Special thanks go to Larry W. Virden (lvirden@cas.org) for forwarding many of the submissions.

More information about Tck/Tk can be obtained from the Sun Labs Tcl web page, maintained by John Ousterhout.

Another "comparison" page, The Tcl War, is being maintained by Glenn Vanderburg.

Please send submissions or comments to Wayne Christopher: wayne@icemcfd.com.


Current contents of this page, in the order they came to my notice:

  1. Tcl/Lisp/Python: A "User" point of view , by Jeffrey Templon
  2. Q: perl vs Tcl: complementary, orthogonal , by Tim Bunce
  3. Why you should not use Tcl , by Richard Stallman
  4. Re: Why you should not use Tcl , by John Ousterhout
  5. Comments on "Why you should not use Tcl" , by Adam Sah, UC Berkeley
  6. Critical review of Stk , by Dan Connolly
  7. Re: Why you should not use Tcl , by Wayne Throop
  8. Perl Peeves , by Tom Christiansen
  9. GNU Extension Language Plans , by Richard Stallman
  10. Re: GNU Extension Language Plans , by Juergen Wagner
  11. Matrix multiplication in several extension languages
  12. Re: What language would you use? , by Josef Dalcolmo
  13. Re: What language would you use? , by Kenneth Manheimer
  14. Re: What language would you use? , by Tom Christiansen
  15. Re: What language would you use? , by Tom Christiansen
  16. Re: What language would you use? , by Guido van Rossum
  17. GNU Script isn't fixing something that's broken, so is doomed , by Tom Christiansen
  18. Metalanguages in environments where code is data. , by Peter da Silva
  19. TCL is fat,slow,and lacks staying power. , by George J Carrette
  20. Re: Perl/Tcl Comparison , by Andrew M. Langmead
  21. Re: What language would you use? , by Jean-Jacques Girardot
  22. Extending W3 Clients , by Alan Falconer Slater
  23. Re: GNU Extension Language Plans , by Tom Christiansen
  24. Re: Should I use Tcl/tk or Motif , by Sriram Srinivasan
  25. Re: Should I use Tcl/tk or Motif , by Michael Hoegeman
  26. Re: Tk without Tcl , by Bennett Todd
  27. Re: Should I use Tcl/tk or Motif , by Sriram Srinivasan
  28. Re: Perl? Or tcl? Which to use for what? , by David A. Berson
  29. Re: Object Tcl & [incr Tcl] , by Dean Sheehan
  30. Opinions? Tcl Python Perl, Virtues/failings , by Dan Janowski
  31. Re: Opinions? Tcl Python Perl, Virtues/failings , by Ken Manheimer
  32. Re: Opinions? Tcl Python Perl, Virtues/failings , by Ian S Nelson
  33. Re: Opinions? Tcl Python Perl, Virtues/failings , by Mark Lutz
  34. An extensive analysis of Tcl, MetaCard, and the COSE Desktop Kornshell , by Scott Raney
  35. Re: Opinions? Tcl Python Perl, Virtues/failings , by Larry Wall
  36. Re: Opinions? Tcl Python Perl, Virtues/failings , by Tom Christiansen
  37. Re: python speed , by Tom Christiansen
  38. Tcl Considered Harmful , by Adam Sah
  39. Re: perl script w/in Tcl , by John Chambers
  40. Re: TCL/TK vs. Java , by Charles Thayer
  41. Re: TCL/TK vs. Java , by John Ousterhout
  42. Re: Tcl/tk vs Zinc? , by Tim Jones
  43. Re: TCL/TK vs. Java , by Jacob Levy
  44. Re: tcl vs. perl , by Aaron Watters
  45. Re: Why I want to dump TCL! , by Bret Bieghler
  46. Re: Why I want to dump TCL! , by Wayne Throop
  47. Re: Why I want to dump TCL! , by Wayne Throop
  48. Another view of Java and Tcl , by Cimarron Taylor
  49. Re: Tcl vs Perl , by Larry W. Virden
  50. Various "comparison" articles, , by Tom Christiansen (some duplicated in this page)
  51. Re: Tcl vs Perl , by Steve Simmons
  52. Re: Tcl vs Perl , by Sudish Joseph
  53. Re: Tcl vs Perl , by John Haxby
  54. Re: perl versus tcl/python/java , by Sriram Srinivasan
  55. Re: Meta Card versus TCL/TK? , by Scott Raney
  56. Table Geometry Manager && Visual Basic, My Opinion , by Steve Huang
  57. Re: Perl/Tk vs. Tcl/Tk , by Jeffrey Hobbs
  58. Re: OSF annoucement: Java ports , by Sam Taylor
  59. Re: A Lispish Perl? , by k p c
  60. Embedding Java (was: Calling java from C) , by Cameron Laird

Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.lang.python
From: templon@paramount.nikhefk.nikhef.nl (Jeffrey Templon)
Subject: Tcl/Lisp/Python: A "User" point of view
Message-ID: <1994Sep27.085636.23932@paramount.nikhefk.nikhef.nl>
Date: Tue, 27 Sep 1994 08:56:36 GMT

Hi,

I haven't yet read all 101 replies on this thread. I do want to make some comments from a more "user-oriented" standpoint; I mean, I will be making commments based solely on using this sort of language for "end-user" projects; you won't hear anything about O(1) vs. O(n) ...

My background, to put it all in perspective: I am a researcher in physics, use and program the computer daily, have been programming for more than 12 years, have lots of experience in FORTRAN, C, Basic (from the old days), Pascal, assembler, TeX/LaTeX (yes, these are programming languages, just that the DATA statements tend to dominate); worked under VMS, Unix, Macintosh, MINIX, Harris, IBM. For a "user" I am very experienced; however I am by no means an algorithms analyst; I do not understand what lambda constructs are and have never examined a garbage-collection algorithm.

My experience with Lisp: first exposed to it when I first picked up GNU Emacs and installed in on our VAX/VMS system in '88 or so. I understand it well enough to be able to figure out where I need to change something if I have to add something to a list; I have succeeded in writing functions of ten or so lines in the past, to do very simple things. However I have no desire to sit down and learn it, when it requires a completely different manner of thinking than C or ksh or FORTRAN; those kind of languages are what I use every day. My experience with about 95% of the people in our field is that they think the same way; Lisp is for computer science departments. Heck, they think I am crazy for using Python, which is readable.

My experience with TCL: this was chosen here at NIKHEF for an extension language for a hardware-control program being written here. At some point, the software-development group handed out an "example" TCL script to all the people who would eventually be using the system. The function of the script was to test the response of a detector, and using the results to determine the appropriate high-voltage setting for the detector. The unanimous response of the user team: 1) the procedure looked much longer than we all thought was necessary. We did not really understand why it had to be so, but based on our experience with "normal" languages, we had expected that the procedure would be about half as long as it was (long meaning number of code lines.) 2) It was VERY difficult to understand exactly what was going on at any given time. If the code had not been generously commented, it would have been even worse. People were not happy about this.

Note that this brings up an important rule: "users" often have the criterion that if they can't more or less figure out what is happening with an example program in an hour or so, then it is just too complicated and they will begin to hope that you will change to a different language.

My experience with Python (python was brought up as a possible alternative): I like this. Python is something that you can begin very simply with; you can use it instead of "bc" for example. I write Python scripts now to do a lot of the things that I used to do in awk, but found somewhat "awk"ward in awk (there are some things that just BEG to be done in awk). I have also now completed two rather sizeable projects in Python, and one (a code for working out nuclear reaction kinematics and cross sections) used Python's object-oriented facilities quite heavily. I recently gave this code to a colleague who needed to do something similar, and he really liked it, and found Python really easy to use after about an hour of playing with it. Mind you, these are the same people who will not switch from vi to Emacs because Emacs is just too complicated. Python is very good at scaling from small to large projects; I think that this is in part due to it being interpreted; you can play with the small pieces of a program individually, which encourages you to write this way; also you can pack things into modules, which encourages you to write "reusably".

If you want to choose a language which will really get used by a wide spectrum of people, I think Python is a good choice. I see people like me using it, and I also see computer science people posting parser generators written in Python. It seems that this language has enough flexibility and "dynamic range" to reach a large class of users.


Newsgroups: comp.lang.perl,gnu.misc.discuss
From: Tim.Bunce@ig.co.uk (Tim Bunce)
Subject: Q: perl vs Tcl: complementary, orthogonal
Organisation: Paul Ingram Group, Software Systems, +44 483 424424
Date: Mon, 26 Sep 1994 12:53:57 +0000
Message-ID: 

Perl sounds like an *ideal* candidate for the language with 'a more traditional algebraic syntax'.

Having worked as a perl5-porter for several months now I've lived with Perl 5 and seen it grow. I've never felt so positive about a computer programming language before.

Perl 5 is really very special.

I hope Larry will forgive me posting a snippet if the Perl 5 beta documentation here:

---snip---

Perl version 5 is nearly a complete rewrite, and provides the following additional benefits:

* Many usability enhancements

It is now possible to write much more readable Perl code (even within regular expressions). Formerly cryptic variable names can be replaced by mnemonic identifiers. Error messages are more informative, and the optional warnings will catch many of the mistakes a novice might make.

* Simplified grammar

The new yacc grammar is one half the size of the old one. Many of the arbitrary grammar rules have been regularized. The number of reserved words has been cut by 2/3. Despite this, nearly all old Perl scripts will continue to work unchanged.

* Lexical scoping

Perl variables may now be declared within a lexical scope, like "auto" variables in C. Not only is this more efficient, but it contributes to better privacy for "programming in the large".

* Arbitrarily nested data structures

Any scalar value, including any array element, may now contain a reference to any other variable or subroutine. You can easily create anonymous variables and subroutines. Perl manages your reference counts for you.

* Modularity and reusability

The Perl library is now defined in terms of modules which can be easily shared among various packages. A package may choose to import all or a portion of a module's published interface. Pragmas are defined and used by the same mechanism.

* Object-oriented programming

A package can function as a class. Dynamic multiple inheritance and virtual methods are supported in a straightforward manner and with very little new syntax. Filehandles may now be treated as objects.

* Embeddible and Extensible

Perl may now be embedded easily in your C or C++ application, and can either call or be called by your routines through a documented interface. The XS preprocessor is provided to make it easy to glue your C or C++ routines into Perl. Dynamic loading of modules is supported.

* POSIX compliant

A major new module is the POSIX module, which provides access to all available POSIX routines and definitions, via object classes where appropriate.

* Package constructors and destructors

The new BEGIN and END blocks provide means to capture control as a package is being compiled, and after the program exits. As a degenerate case they work just like awk's BEGIN and END when you use the -p or -n switches.

* Multiple simultaneous DBM implementations

A Perl program may now access DBM, NDBM, SDBM, GDMB and Berkeley DB files from the same script simultaneously. In fact, the old dbmopen interface has been generalized to allow any variable to be tied to an object class which defines its access methods.

* Subroutine definitions may now be autoloaded

In fact, the AUTOLOAD mechanism also allows you to any arbitrary semantics to undefined subroutine calls. It's not just for autoloading.

* Regular expression enhancements

You can now specify non-greedy quantifiers. You can now do grouping without creating a backreference. You can now write regular expressions with embedded whitespace and comments for readability. A consistent extensibility mechanism has been added that is upwardly compatible with all old regular expressions.

Ok, that's definitely enough hype.

---snip---

I really can't believe that the FSF would turn up the chance to adopt Perl 5 as a 'standard' language.

If they do I would have to question their reasoning and motives.

Regards, Tim Bunce.

ps I would just add that the Perl 5 documentation now comes in a generic markup form which can easily be converted to texinfo format.


Date: Fri, 23 Sep 94 19:14:52 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
Message-ID: <9409232314.AA29957@mole.gnu.ai.mit.edu>
Subject: Why you should not use Tcl
Newsgroups: gnu.announce,gnu.utils.bug,gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.windows.x.apps,comp.unix.misc

Why you should not use Tcl

Richard Stallman, GNU Project

As interest builds in extensible application programs and tools, and some programmers are tempted to use Tcl, we should not forget the lessons learned from the first widely used extensible text editor--Emacs.

The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that!

Extensions are often large, complex programs in their own right, and the people who write them deserve the same facilities that other programmers rely on.

The first Emacs used a string-processing language, TECO, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and it made extensions harder to write. Later Emacs implementations have used more powerful languages because implementors learned from the problems of the first one.

Another lesson from Emacs is that the way to make sure an extension facility is really flexible is to use it to write a large portion of the ordinary released system. If you try to do that with Tcl, you will encounter its limitations.

Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.

Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users. If Tcl does become the "standard scripting language", users will curse it for years--the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with.

For these reasons, the GNU project is not going to use Tcl in GNU software. Instead we want to provide two languages, similar in semantics but with different syntaxes. One will be Lisp-like, and one will have a more traditional algebraic syntax. Both will provide useful data types such as structures and arrays. The former will provide a simple syntax that hackers like; the latter will offer non-hackers a syntax that they are more comfortable with.

Some people plan to use Tcl because they want to use Tk. Thankfully, it is possible to use Tk without Tcl. A Scheme interpreter called STk is already available. Please, if you want to use Tk, use it with STk, not with Tcl. One place to get STk is from ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z


From: ouster@tcl.eng.sun.com (John Ousterhout)
Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.unix.misc,comp.windows.x.apps
Subject: Re: Why you should not use Tcl
Date: 26 Sep 1994 18:13:27 GMT
Organization: Sun Microsystems, Inc.
Message-ID: <367307$1un@engnews2.Eng.Sun.COM>

There have been so many follow-ups to Stallman's message that I'm not sure there's any need for me to respond, but I would like to say a few things anyway:

First, I'd like to encourage everyone to keep their responses cordial and technical, rather than personal, regardless of how strong your opinions are. Comp.lang.tcl has managed to avoid flame-wars pretty well so far; let's keep it that way by focusing on the technical issues rather than worrying about motives.

I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use *two* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions. For the Tcl scripts, ease of learning, ease of programming and ease of glue-ing are more important than performance or facilities for complex data structures and algorithms. I think these two programming environments are so different that it will be hard for a single language to work well in both. For example, you don't see many people using C (or even Lisp) as a command language, even though both of these languages work well for lower-level programming.

Thus I designed Tcl to make it really easy to drop down into C or C++ when you come across tasks that make more sense in a lower-level language. This way Tcl doesn't have to solve all of the world's problems. Stallman appears to prefer an approach where a single language is used for everything, but I don't know of a successful instance of this approach. Even Emacs uses substantial amounts of C internally, no?

I didn't design Tcl for building huge programs with 10's or 100's of thousands of lines of Tcl, and I've been pretty surprised that people have used it for huge programs. What's even more surprising to me is that in some cases the resulting applications appear to be manageable. This certainly isn't what I intended the language for, but the results haven't been as bad as I would have guessed.

I don't claim that Tcl is without flaws. Some of the flaws, like the lack of a compiler and the lack of module support, will get fixed over time. Others, like the substitution-oriented parser, are inherent in the language. Is it possible to design a language that keeps Tcl's advantages, such as simplicity, easy glue, and easy embedding, but eliminates some of its disadvantages? Almost certainly (there are several decisions that I would re-think if I were starting over). Is the two-language approach really the right one? I still think so, but reasonable people can disagree.

Language designers love to argue about why this language or that language *must* be better or worse a priori, but none of these arguments really matter a lot. Ultimately all language issues get settled when users vote with their feet. If Tcl makes people more productive then they will use it; when some other language comes along that is better (or if it is here already), then people will switch to that language. This is The Law, and it is good. The Law says to me that Scheme (or any other Lisp dialect) is probably not the "right" language: too many people have voted with their feet over the last 30 years. I encourage all Tcl dis-believers to produce the "right" language(s), make them publically available, and let them be judged according to The Law.


Newsgroups: comp.lang.scheme,comp.lang.tcl
From: asah@cs.Berkeley.EDU (Adam Sah)
Subject: Comments on "Why you should not use Tcl"
Message-ID: <ASAH.94Sep26204319@ginsberg.cs.Berkeley.EDU>
Date: 27 Sep 1994 03:43:18 GMT
Organization: University of California, Berkeley
Comments on "Why you should not use Tcl"
Adam Sah, UC Berkeley
-----------------------------------------

I wish to reply to Richard M. Stallman's recent criticism of Tcl, and his suggestion that programmers not use it. In doing so, I neither support nor reject the use of Tcl: it is a useful, but flawed, tool for building certain kinds of applications; it is assinine to invalidate the positive experiences many programmers have had with the system. It is of equal folly to embrace it as panacea without investigating its weaknesses, especially when a plethora of alternatives now exist. To those who enjoy Scheme's minimalist syntax, I wholeheartedly co-endorse his embracing of the language.

This commentary presents some technical points on the benefits and detractions of Tcl, and offers some insights as to the merits of languages like Tcl (in comparison to Scheme). I will be presenting similar arguments in the upcoming USENIX Symposium on Very High Level Languages, and a paper on the subject is online [1]. A more precise description of Tcl semantics and implementation may be found in [2].

As a student of John's and as a student of programming languages and their implementations, I've spent a lot of time over the past two years contemplating Tcl, its semantics and its performance. At both of the Tcl Workshops, I've presented papers of related work. It is from this standpoint that I add my comments to the flurry of responses that RMS's statement has generated.

>		     Why you should not use Tcl
>			Richard Stallman, GNU Project
>
> ... intro deleted...
> Tcl was not designed to be a serious programming language.  It was
> designed to be a "scripting language", on the assumption that a
> "scripting language" need not try to be a real programming language.
> So Tcl doesn't have the capabilities of one.  It lacks arrays; it
> lacks structures from which you can make linked lists.  It fakes
> having numbers, which works, but has to be slow.  Tcl is ok for
> writing small programs, but when you push it beyond that, it becomes
> insufficient.

Tcl lacks pointers or pointer-like references; for example, there is no way to pass by reference in Tcl. Tcl offers pass by name, so users not wishing to _copy_ an array's contents when passing to a subroutine are encouraged to either make the array a global variable (!) or to pass its _string_name_ (the variable's string name, as it appears in the source text of the caller procedure!) and have the callee use "upvar" or "uplevel" to jump back into the caller's scope and grab a reference to that variable and install it into the current one. In other words, Tcl relies on a form of dynamic scoping to achieve reference passing.

Tcl also lacks closures of any kind; it is impossible to "wrap" a section of code and data together into some meaningful unit, especially a stateful one (again, without use of global variables). The idea of passing closures as arguments to functions, so popular in languages that offer this, is unavailable to Tcl.

Tcl lacks automatic memory management facilities. To reclaim the memory associated with a binding, you have to explicitly "unset" it, altering your namespace. Tcl programs do not exhaust memory because they tend to be small and because for simple, reusable data structures, the Berkeley Tcl implementation automatically recollects values. Better stated: memory management is not a difficult problem in a language that won't let you use memory in very interesting ways.

Tcl is very slow. Tcl stores arrays as strings, making vector-ref take time linear in the number of elements. Tcl's associative arrays ("array variables") are implemented as hash tables, but the only key type is strings, making this facility very slow as well. Tcl passes data back to C as strings, and doesn't cache their native-typed values across computations; when counting from 1 to 10,000, >90% of the time was spent converting from strings to integers and vice versa. These problems are solvable, as my MS thesis suggests, but John (and hence Sun) have no intentions of implementing a faster Tcl interpreter for at least a year. Here are some performance numbers I've made on my DEC Alpha (figure 100 million instructions per second, or .01usec per instruction):

   scalar access  Tcl  set a        13 usec
                  Tcl  $a            9 usec
                    C  a            (can be optimized away, else 0.01usec)

   list access    Tcl  lindex $L1 200   500 usec
     (short         C  a[199]             0.02 usec
      elements)

More performance numbers can be found in the MS thesis, although their C equivalents are not shown.

Tcl also has some serious design flaws (not unlike most languages, I suppose). For example, it inherits C's arithmetic semantics, leading to behavior like:

   1234567890   * 1234567890   = 304084036           (Linux PC)
   1234567890   * 1234567890   = 1524157875019052100 (DEC Alpha)
   1234567890.0 * 1234567890.0 = 1.52527e+18         (Linux PC)
   1234567890.0 * 1234567890.0 = 1.52416e+18         (DEC Alpha)

The argument in favor of correct mathematics is not simply a beauty-contest argument, but purely in keeping with Tcl's claim to be a "Very High Level Language" (as per its appearance in the recent USENIX VHLL Symposium). If you want to abstract away the machine from the end user, it's wise to not propagate its internal word size to users trying to build user interfaces for scientific applications!

To be fair, Tcl does largely what it was intended to do. John Ousterhout's code is among the cleanest, best-written code I have ever had the pleasure of browsing, and it represents a terrific implementation of the given set of ideas, borne out of writing (and rewriting) many "mini" languages, none of which did everything he wanted. Tcl is a miracle solution to solving certain classes of problems, such as configuration, simple control, and other add-ons to much larger bodies of existing code. For prototyping small systems with user interfaces, it is fantastic. Research labs will adore Tcl, much as they have embraced Unix (as a hackable OS), C (allowing the programmer to do _anything_), Perl (as a Unix sysadmin tool second to none), etc.

> Tcl has a peculiar syntax that appeals to hackers because of its
> simplicity.  But Tcl syntax seems strange to most users.  If Tcl does
> become the "standard scripting language", users will curse it for
> years--the way people curse Fortran, MSDOS, Unix shell syntax, and
> other de facto standards they feel stuck with.

A stronger argument can be made: Tcl supports a single level of substitution, confusing nearly all new users of the language. While it is generally seen as unreasonable to foist parenthesized forms (and hence RPN mathematics, etc.) on the programmers of the world, Tcl's system is hardly a cure:

"expr $a+5" is not the same as "expr {$a+5}"

(if a is set to "45" (the string four-five), then both work, if it's a math expression itself such as "4+5" the former works where the latter errors. Similar bizarrities can be found throughout the language.)

Furthermore, Tcl doesn't really eliminate RPN notation. For example, to assign a variable, you have to say:
set a 5 instead the more obvious
a = 5
Of course, the second argument ("a") is just a string, it's not really a binding or a variable. Thus you can accidently say,
set $a 5
and this will mean to assign some variable whose string name is the _value_ of the variable "a" (assume it exists). If teh current value of "a" were "b", then this would do something very weird:
set b 5
set a b
#...many lines later...
set $a c

Tcl uses two different namespaces for procedures and data. You cannot use "set" to define a procedure, for example. Thus you can have variables with the same names as procedures.

More generally, you're allowed to give variables and procedures almost any name, including names beginning with arbitrary punctuation and/or numbers. For example:

     proc 5 {a} {...}

     # you forgot a backslash at the end of this next line.
     # and tcl tries to call the function "5" with the value "6".
     myFun blah blah blah ................................... blah blah
     5 6

Since this is obviously horrible coding style and not at all valuable in practice, this can only serve to confuse programmers with rare but bizarre errors.

> For these reasons, the GNU project is not going to use Tcl in GNU
> software.  Instead we want to provide two languages, similar in
> semantics but with different syntaxes.  One will be Lisp-like, and one
> will have a more traditional algebraic syntax.  Both will provide
> useful data types such as structures and arrays.  The former will
> provide a simple syntax that hackers like; the latter will offer
> non-hackers a syntax that they are more comfortable with.

Scheme as a Replacement for Tcl
----------------------------------------

I personally don't see Scheme as a replacement for Tcl in the long run. Scheme lacks the following features found in Tcl:

Scheme is not the only possible replacement language; ML works just as well, depending on your stance re:dynamic vs. static typing. Again, more elaborate arguments may be found in the online papers, and I'll be presenting related commentary at the upcoming USENIX VHLL conference. I should add, however, that I'm sufficiently convinced that this is the "right way to do things" that I've devoted part of the past year to designing and implementing Rush, a language that trivially compiles into Scheme, but offers these features. Without attempting heroics, Rush clocked in at 50-300x faster than Tcl.

Rush is still "in the lab", but STk (as Stallman points out) is a viable alternative to Tcl for those not scared off by parentheses.

Adam Sah
PhD student
UC Berkeley Dept. of Computer Science
asah@cs.berkeley.edu


References
--------------

[1]  A New Architecture for the Implementation of Scripting Languages.
     to appear in USENIX Symposium on Very High Level Languages.
     ftp://ginsberg.cs.berkeley.edu:/pub/papers/asah/rush-vhll94*

[2]  TC: An Efficient Implementation of the Tcl Language
     UC Berkeley Technical Report #UCB/CSD-94-812
     ftp://ginsberg.cs.berkeley.edu:/pub/papers/asah/msthesis*

From: connolly@hal.com (Dan Connolly)
Newsgroups: comp.lang.tcl,comp.lang.scheme
Subject: Critical review of Stk [Was: Why you should not use Tcl]
Date: 28 Sep 1994 18:30:52 GMT
Organization: HaL Computer Systems, Inc.
Message-ID: <CONNOLLY.94Sep28133053@austin2.hal.com>

I just grabbed the Stk-2.1.3 source distribution and built it on my 486/33 Linux-1.1.51 box. Here are my impressions:

+ The build went very smoothly. There were a bunch of warnings:
In file included from tclInt.h:60,
                 from tclGet.c:33:
/usr/include/stdlib.h:197: warning: `malloc' redefined
But for the supported platforms, I would expect no installation problems.

- Every occurence of malloc() in STk is replaced by must_malloc(), which lonjump()s to the toplevel. Hmmm... I'm not sure how this non-local exit would affect the correctness of code throughout the system.

+ There are small, medium, and large demo applications to verify the build. The demo apps did signal a few strange errors, but mostly they worked well. In the floorplan demo, after switching floors a couple times, I got this error: *** Error: bad screen distance "U": **** Tk error ("") "" The inspector window reported this traceback: (storereference (w (quote create) (quote polygon) 175 168 97 168 97 131 175 131 :fill "" :tags "floor3 room") "317") (fg3 w color_offices) (cond ((eqv? active (quote 1)) (fg1 w color_offices)) ((eqv? active (quote 2)) (fg2 w color_offices)) ((eqv? active (quote 3)) (fg3 w color_offices) ... (begin (w (quote delete) (quote all)) (set! activefloor active) (bg1 w color_bg1 color_outline1) (bg2 w color_bg2 color_outline2) (bg3 w color_bg3 c ... (if (not (equal? activefloor active)) (begin (w (quote delete) (quote all)) (set! activefloor active) (bg1 w color_bg1 color_outline1) (bg2 w color_ ... (name)

- STk doesn't seem to be _exacly_ compatible with Tk. For example, I have Tk shared libraries, and I don't think I can use them with STk because the Tk source in the STk distribution has been modified. The ability to go from one menu to another without releasing the mouse is present in my "wish" demos, and not in my stk demos. I assume this is because the version of Tk used in STk is slightly out of date.

- STk start-up is noticeably slower than Tk. The STk "widget" demo takes about 5 seconds to start up. The Tk version takes less than a second. This is not a precide measurement, but I believe it is significant enough to blame it on the STk implementation or design, and not system fluctuations.

- STk seemed to operate noticeably slower. For example, the floor plan takes a little longer to come up in STk than in Tk. I have no data to back this up -- just an observation. STk still seemed plenty fast enough for any sort of application I might be interested in. We can assume the impelementation will improve. Still -- this shows that despite the laguage features of Tcl that might seem slow, in practice, it's quite speedy.

+ STk includes bignums, implemented with the GNU mpz library. A slower, non-GPL implementation is included.

+ STk includes a CLOS style object system. Typical code looks like: (define f (make <Frame>)) (define l (make <Label> :parent f :text "A simple demo written in STklos")) (define c (make <Canvas> :parent f :relief "groove" :height 400 :width 700)) (define m (make <Label> :parent f :font "fixed" :foreground "red" :text "Button 1 to move squares. Button2 to move circles"))

I didn't see any big performance problems with this object system.

= Aside from the fact that STk has real closures and continuations to take advantage of lexical scoping, STk does little to solve the global-namespace problem. There's one big namespace of functions to keep track of. Oh well, no worse than C. But not as good as Modual-3 or python, for my purposes.

- STk does not support TK's feature of multiple interpreters. The interpreter state is global. BIG LOSE.

= Executable size of STk is roughly the same as Tk's wish, I think. I have shared libraries for Tcl and Tk:

-rwxr-xr-x   1 connolly users      562194 Sep 27 23:52 stk-bin*

-rwxr-xr-x   1 slackwar opt        357380 Nov 24  1993 /usr/X11/lib/libtk.so.3.1*
-rwxr-xr-x   1 slackwar opt          1452 Nov 24  1993 /usr/bin/X11/wish*
-rwxr-xr-x   1 slackwar opt        140292 Nov 24  1993 /usr/lib/libtcl.so.3.1*

			total:     499124

- STk seemed more memory intensive. After brigning up the floorplan demo on each platform, here's some data (I have a heck of a time reading ps output, but here it is):

USER       PID %CPU %MEM SIZE  RSS TTY STAT START   TIME COMMAND
connolly  5626  2.3  7.5  405 1148 pp3 S    12:01   0:01 wish -f widget
connolly  5628 26.8 10.5 1341 1608 pp0 S    12:01   0:05 ../Src/stk-bin -f wid
                         ^^^^ ^^^^
+ Documentation is good, though I'm not in a very good position to judge, since I'm already intimately familiar with Tcl, Tk, and scheme. The best doc for me was the demo code. The STk reference documentation assumes a certain familiarity with the scheme specification R^4RS.

+ Foreign Function Interface seems quite good, though I haven't looked closely at the garbage collection issues. It seems to have a lot of the simplicity of the Tcl FFI, without the reference counting nightmares of the python FFI. Tcl style FFI is also supported. I'm not sure what the type-safety considerations are. The exception/error handling mechanism isn't clear to me either.

- The STk library uses global names that might conflict
with other C libraries. For example:
libstk.a(stklos.o):00000eb0 T _class_of
libstk.a(tk-util.o):00000200 T _widget_name
libstk.a(error.o):000000b0 T _err

Summary: Stk works, and is fairly stable. The performance is no better than Tk/Tcl -- perhaps a little worse. It lacks some of Tcl's maturity -- especially it's squeaky-clean foreign function interface and disciplined use of the C namespaces. But you like scheme's language features, they're all available in STk.

The question for me is: which facilitates the development of large bodies of reusable code, and which has large bodies of reusable code available for building applications? It appears that Tcl has more large bodies of reusable code (expect, tcl-dp), though I don't know how much of the scheme code out there in various archives is usable with STk.

I would like to think that scheme is superior to Tcl for development of reuable code -- superior enough that STk libraries will be developed and deployed faster than Tcl/Tk libraries, and eventually scheme will be the way to go.

Scheme has suffered from an emphasis on theoretical computer science to the exclusion of large scale software engineering principals. But that trend is changing. The lessons learned from wigged-out analysis of scheme are being employed in practical implementations like STk, scheme48, and others that I'm not as familiar with (EuLisp, Dylan, etc.).

"We want to take over the World" Ian Horswill --- ian@ai.mit.edu in "The Scheme Underground" at http://www.ai.mit.edu/projects/su/su.html

I hope to see large bodies of reusable, interoperable scheme code emerge over the coming months. Specifically, I'm interested in distributed hypermedia applicatoins. For this, I need networking and threads support. The trouble with scheme right now is that there are so many ways to do things like objects that large bodies of scheme code tend to be incompatible.

The reason I'm so big on Modula-3 is that there are large bodies of code built around a well-specified thread interface. For example, they have an X11 library called Tresle with the best features of Interviews, decent performance, and an interactive applications builder.

Perhaps there will be a marrying of the minds between the scheme48 folks and the STk folks, and we'll end up with something similar.

Dan -- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 <connolly@hal.com> http://www.hal.com/%7Econnolly/index.html


From: throopw%sheol.uucp@dg-rtp.dg.com (Wayne Throop)
Newsgroups: gnu.misc.discuss,comp.lang.tcl
Subject: Re: Why you should not use Tcl
Date: 29 Sep 1994 17:12:15 GMT
Organization: Alcatel Network Systems (Raleigh, NC)
Message-ID: <36eshf$cno@aurns1.aur.alcatel.com>

: From: djohnson@seuss.ucsd.edu (Darin Johnson)
: And this got me to thinking that perhaps there are a lot of Tcl users
: claiming that it's simpler to use than Lisp for the same sorts of
: reasons.  They've heard that Lisp is hard, and they figured out Tcl,
: so Tcl must be simpler and more elegant. 
An interesting perspective, but I think there are legitimate reasons for a claim that tcl is simpler than lisp, and more approachable as a scripting language.

In approaching each language for the first time, just consider explaining how the basic forms of the language are interpreted. In lisp, you tend to have a discussion about functions, macros, and special forms, and why it is that you sometimes need to quote things, and sometimes you don't because the context does it for you, and why some things are funcallable and others aren't. And to write macros of any complexity, you need quote and backquote and on and on and on.

In tcl, the evaluation rules are a tad simpler and more lexically explicit, and while there's still the need to explain things like the fact that conditional expressions and codebodies get rescanned while most commands don't rescan their arguments, this is a property that is regular and applies to all invocations, rather than a distinction of a *kind* of invocability.

This same contrast applies to lots of other topics, like variable namespaces, symbol namespaces, data types, and many more. Try explaining EQ/EQL/EQUAL, and why fixnums and bignums behave as they do, as compared to a similar explanation for tcl. And that's before we even get into historical bizarities like why both CAR/CDR and FIRST/REST. In each case, tcl kills 80% of the birds with 20% of the stones. This makes the learning curve for tcl noticeably less steep than that for lisp.

Note I am not saying in any way shape or form that tcl is "better" than lisp, or that lisp is *fundamentally* a hard language to learn. I'm saying that there are legitimate reasons for categorizing tcl as "simpler" than lisp, and legitimate reasons for supposing that the kind of simplicity tcl displays is useful in many scripting language domains.

-- Taking off on a tangent related to a specific case of "simplicity", I'll even take the bizarre stance of criticizing both tcl and lisp for being too lexically complicated to make a good scripting language (!!?).

Yes, you heard. "Lexically too complicated".

lisp: ; " ' | () # ` , \s [0-9/+\-] [a-zA-Z] : tcl: # " {} [] $() \s \ \n ; In a scripting language, I prefer something at least a little more spartan. The reason is, the application into which the scripting language will be embedded will doubtless have its own notational conventions. To have "all the good characters already taken" by the scripting language means that lots of quoting needs to go on. Some relevant tricky tradeoffs are,

- should variables and procedures overload a convention, so that [] and $ can be unified or partly unified

- should you stick to \n and \, or go with explicit ; (or ()) for line-spanning statements (and note that whether there is a read-eval-print loop being typed at can affect this tradeoff)

- should commands each be able to specify inter-argument separators and quoting/bracketing conventions, or should they be lexically static

Despite other shortcomings, I particularly like DG's mxdb debugger's command language's choice of lexical tradeoffs. But then I'm prejudiced, since in a former life, I participated (as a junior hanger on) in the design of that command language. Suffice to say, (at least in the language's purest form... some "corruption" occured later) the only characters at top level that are *interpreted* by the lexer are whitespace, backtick, and comma (though some others have some minor lexical significance).

Another language with somewhat extreme minimalism (at least insofar as I understand it... I admire it more from a distance than DG's cp), is SMDS's lakota.

Now why is such ... "extreme" (to say the least) lexical minimalism valuable? Again, in a *scripting* language, specifically an *embedded* scripting language, it is valuable because the application being scripted is then free to introduce notational conventions of its own, without tripping over an "outer" or "encapsulating" set of lexical/notational conventions. This is important for DG's mxdb, because that command language needs to be able to manipulate expressions in multiple programming langauges. This is important for lakota, because (I think) it is a command shell that needs to run in multiple environments, and hence needs to adapt itself to to multiple "shell" syntax conventions.

I feel that this "lexical minimalism" is a much-overlooked and seldom-provided feature of a good general-purpose scripting language, and tcl (while IMHO slightly deficient) comes closer than many another to having it. Consider, for example STk and tkperl, as compared to tcl notations for the same thing.

STk (define f (make )) (define l (make Now, the point is, there are startlingly fewer "noise" characters in the tcl/tk example. And the reason is, in scheme and perl, there are already notational conventions in the language for how objects are supposed to be refered to, how objects get parents, how keyword arguments are denoted, how constructors ought to be specified, and so on and on. In tcl, on the other hand, the *application* was free to design most of the notation, and thus could streamline it to the specific case, while the tcl language itself stomped only on the outermost global namespace to keep multiple applications out of each other's hair.

Granted, *some* of the "noise" characters come from an incomplete conversion of the tk toolkit, but on the whole, the tcl/tk example profits by making the parent/child relationship an abbreviated notational convention, and the lack of variable, namespace, and quoting markers.

Just as a lark, btw, here's how a hypothetical cp/tk example would look (the DG mxdb command processor I refered to above)

frame .f label .f.l, text A simple demo written in (hypothetical) cp/tk -- Wayne Throop throopw%sheol.uucp@dg-rtp.dg.com throop@aur.alcatel.com


From: tchrist@cs.colorado.edu (Tom Christiansen)
Newsgroups: comp.lang.perl
Subject: Perl Peeves
Message-ID: <1993Nov19.134521.26256@convex.com>
Date: 19 Nov 93 13:45:21 GMT
Organization: University of Colorado, Boulder

A few days ago, someone asked what things people disliked about Perl, and no one answered. Well, I've worked, played, and fought with Perl quite enough to have by list of personal pet perl peeves. Some are inherent to the language and beyond redemption, others could in theory be fixed, and others already have been. In fact, I've omitted some minor ones that are fixed in Perl5. Yes, this will become a FAQ; note the long expiration date. All but the last question/issue are new.

    1.  Scalar vs Array
    2.  Strings and Numbers
    3.  Barewords
    4.  Unary-Op vs List-ops
    5.  Filehandles not real objects
    6.  Filehandles need funny vars for ops
    7.  Sometimes need scalar, other times tolerate expr
    8.  Remembering Defaults
    9.  Do {} isn't a controllable loop
    10. Variable suicide



1.  Scalar vs Array

    The absolutely toughest thing for me to teach people is the scalar
    versus array context stuff.  I mean, I can get them to get this

	$count = @list;
	@nlist = @olist;

    But the hidden things mystify them.   In some languages, the world
    acts differently if you call them with the wrong type.  Perl is 
    largely typeless, but calling things in the wrong *context* is
    what really confuses you.  No one can grasp this quickly.

    For example, these are all different:

	$x = /pat/;
	($x) = /pat/;
	$x = /(pat)/;
	($x) = /(pat)/;

	$x = $var =~ /pat/;
	($x) = $var =~ /pat/;
	$x = $var =~ /(pat)/;
	($x) = $var =~ /(pat)/;

    Or what difference is between all these:

	$x = @x;
	$x = %x;
	@x = %x;
	@x = $x;
	%x = @x;
	%x = $x;

	$x = `cat`;
	@x = `cat`;
	%x = `cat`;

	($x) = `cat`;
	$x[3] = `cat`;
	@x[3] = `cat`;

    I just can't stop people from using @x[3] to mean $x[3].  Perl 5's
    -w switch should help that.

    Or what all this has to be done to reverse lines and characters:

	print reverse `cat`;
	print scalar reverse scalar `cat`;

    Because it's not the argument types that make these overloaded, but
    rather that they overload on return type, which is set as a sideeffect
    of things few people can anticipate even with training.  I used to 
    like it, but that was before I had to teach it.

    I cannot offer any solution to this difficulty.  It's just
    too deeply set as part of the language by now.


2.  Strings and Numbers

    No one ever remembers to use "eq" instead of "==".  

	"foo" < "bar"
	$a["foo"]

    In Perl 5, all possible numbers that can be misconverted get 
    flagged as warnings with -w, but before that, it's quite silent.
    Soemtimes I'm not sure that it wouldn't be an evil thing to just
    punt and assume the other thing, but that would mean automatic
    conversion to this:

	"foo" lt "bar"
	$a{"foo"}

    which while I might tolerate in the first case, would not in the
    second one.


3.  Barewords

    The use of barewords is a real source of trouble.  That because
    in something like this:

	1a.  $x{ "date" } 	= 42;
	1b.  $x{ "time" } 	= 24;

	2a.  $x { date } 	= 42;
	2b.  $x { time } 	= 24;

	3a.  $x{ date() } 	= 42;
	3b.  $x{ time() } 	= 24;

    You can't tell which type of thing the class 2 cases are. 
    There's no way to look at a bareword and no what it's going
    to do.  In this case, 2a is like 1a, but 2b is like 3b.
    No noe can know that time() is a built-in, or that it hasn't
    been declared a list-op kind of sub.  And there's nothing to
    stop them from say

	sub DATE;

    So even the capitalizied ones aren't safe.

    So always use quotes and parens and you'll steer clear of this?


4.  Unary-Op vs List-ops

    There are some built-in functions that take one argument only, 
    like chop() and chdir(), but others like print() and unlink(),
    which take lists.  People using || die get burned:
	    
	    chdir "/tmp" || die;
	    unlink $file || die;

    Are *NOT* consistent.  These are really:
	    
	    chdir("/tmp") || die;
	    unlink( $file || die );

    Which isn't what you want, but rather:
    
	    unlink ($file) || die;

    Of course, they get bitten by print as well

	    print (4+5)*8;

    Which does at least elicit a warning with -w these days.

    The real problem is you CANNOT predict which does which!
    And while you can make your own listops in Perl v5.0, you 
    can't make your own unary ops.  

    So the only solution is to always use parens, which makes
    things harder to read.

5.  Filehandles not real objects

    Filehandles are strange creatures.  They appear to be 
    barewords.  People expect them to be variables as they 
    are in other languages.

	open(FILE, $path);
	print FILE "stuff\n";
	$line = <FILE>; 
	close(FILE);

    But folks would more expect something like this:

	open($fh, $path);
	print $fh "stuff\n";
	$line = <$fh>; 
	close($fh);

    That's especially true because then you don't become mystified
    by how to pass things to subroutines.   While you are officially
    supposed to do this

	&flush("FILE");

    because of barewords, this works:

	&flush(FILE);

    but down in the function you have

	sub flush { 
	    local($file) = shift;
	}

    and now you use it normally.  I think the best solution here is
    never to use bareword filehandles.   Right now, you have to 
    remember to fill them in:

	$fh = $path;
	open($fh, $path);

    But it's too bad that this doesn't happen automatically.
    In fact, in Perl 5.0, existing scripts that people tried to 
    use this way but without filling in the are currently going to 
    *BREAK*.  It would be far better to fill in the $fh, I think.

    Another difficulty with filehandles is that if you pass one
    to a subroutine in a different package, you can't use it without
    name-munging, which isn't something folks expect to have to 
    do.  You find yourself doing this:

	# force unqualified filehandles into caller's package
	local($fh) = shift;
	local($package) = caller;
	$fh =~ s/^[^']+$/$package'$&/;

    I believe that file handles, directory handles, and formats
    should always be used with $foo indirect objects.  Of course,
    you have to declare the format with a BAREWORD though.

    Furthermore, there's no way shy of heavy-handed and potentially
    perilous type-globbing to declare a local filehandle.  But if 
    all you did were this:

	local($fh);
	open ($fh, "> $path");

    and it got filled in, this wouldn't be a problem.  You just have 
    to be able to pass it on to subs in other packages.

    Then there's the issue of directory handles not acting like
    filehandles:

	$line  = <FH>;
	$fname = <DH>;  # doesn't work.


6.  Filehandles need funny vars for ops

    Another filehandle-related problem is that you have to do this
    crufty select business:

	$ofh = select(WISH); 
	$| = 1; 
	select($ofh);

    or

	$ofh = select($wfh); 
	$| = 1; 
	select($ofh);

    Rather than saying 

	WISH->flush();
	$wfh->flush();

    But I think that we've pretty much scoped out how to fix
    that in Perl v5.  Filehandles will be objects with methods.
   
    The non-fh funny variables will themselves have some sort of
    mnemonic alias, although whether this is $SYS'ERRNO or whatnot
    hasn't been precisely worked out yet.


7.  Sometimes need scalar, other times tolerate expr

    As it is, people have a great deal of difficulty making lists
    or tables of things.  That's because there are things in the
    grammar which absolutely require a literal scalar variable, (or
    sometimes a list or table), like

	print $fh "stuff\n";
	&$funcptr():
	push(@foo, "bar");

    but others that tolerate expressions:

	open(foo.bar, "file");

    Some of this is fixed in Perl 5.0:

	&{$functable{$keystroke}} ( $args );
	push( @$foo, "bar" );

    but much is now.  I would like that everywhere that took a scalar
    thing would also take an expression that evaluated to one of those.

	open($fh[1], "fname");
	print $fh[1] "stuff\n";


8.  Remembering Defaults

    People have a hard type remembering that some functions
    default to $_, or @ARGV, or whatever, but that others which
    you might expect to do not.  For example, the split works on 
    $_, but the unpack doesn't even compile:

	@x = split ( /\s+/ );
	@x = unpack( "A10" x 10 );

    Of course, a solution to this is never to use defaults.  


9.  Do {} isn't a controllable loop

    Because you can write this:

	$x = 7 + do {
	    local($i);
	    for(@a) {$i += $_}
	    $i;
	} * 8;

    you can't get out of a do{} early.  This is VERY counterintuitive
    for C programmers.  You can get out of an eval{} early in Perl 5
    with a "return", but better not use that with do.  Someone, the 
    normal next, last, and redo should be made to work.  Perhaps even 
    warnings could be issued until then on loop control to non-named
    (first enclosing) loops.


10.  Variable Suicide

    Variable suicide is a nasty side-effect of dynamic scoping and
    the way variables are passed by reference.  If you say

        $x = 17;
        &munge($x);
        sub munge {
            local($x);
            local($myvar) = $_[0];
            ...
        } 

    Then you have just clubbered $_[0]!  Why this is occurring 
    is pretty heavy wizardry: the reference to $x stored in 
    $_[0] was temporarily occluded by the previous local($x)
    statement (which, you're recall, occurs at run-time, not
    compile-time).  The work around is simple, however: declare
    your formal parameters first:

        sub munge {
            local($myvar) = $_[0];
            local($x);
            ...
        }

    That doesn't help you if you're going to be trying to access
    @_ directly after the local()s.  In this case, careful use
    of the package facility is your only recourse.

    Another manifestation of this problem occurs due to the
    magical nature of the index variable in a foreach() loop.

        @num = 0 .. 4;
        print "num begin  @num\n";
        foreach $m (@num) { &ug }
        print "num finish @num\n";
        sub ug {
            local($m) = 42;
            print "m=$m  $num[0],$num[1],$num[2],$num[3]\n";
        }
    
    Which prints out the mysterious:

        num begin  0 1 2 3 4
        m=42  42,1,2,3
        m=42  0,42,2,3
        m=42  0,1,42,3
        m=42  0,1,2,42
        m=42  0,1,2,3
        num finish 0 1 2 3 4

    What's happening here is that $m is an alias for each 
    element of @num.  Inside &ug, you temporarily change
    $m.  Well, that means that you've also temporarily 
    changed whatever $m is an alias to!!  The only workaround
    is to be careful with global variables, using packages,
    and/or just be aware of this potential in foreach() loops.
The Perl 5 statically scoped autos available via "my" will not have this problem, and the loop index on foreach() in Perl 5 will now be statically, not dynamically scoped.
Date: Wed, 19 Oct 94 00:20:18 -0400
From: Tom Lord <lord@gnu.ai.mit.edu>
Newsgroups: gnu.announce,gnu.utils.bug,comp.os.linux.misc,comp.lang.tcl,comp.lang.scheme,comp.lang.misc
Subject: GNU Extension Language Plans

GNU Extension Language Plans

Richard Stallman, GNU Project

[Please redistribute widely]

Many software packages need an extension language to make it easier for users to add to and modify the package.

In a previous message I explained why Tcl is inadequate as an extension language, and stated some design goals for the extension language for the GNU system, but I did not choose a specific alternative.

At the time, I had not come to a conclusion about what to do. I knew what sort of place I wanted to go, but not precisely where or how to get there.

Since then, I've learned a lot more about the topic. I've read about scsh, Rush and Python, and talked with people working on using Scheme as an extension and scripting language. Now I have formulated a specific plan for providing extensibility in the GNU system.

Who chooses which language?

Ousterhour, the author of Tcl, responded to my previous message by citing a "Law" that users choose the language they prefer, and suggested that we each implement our favorite languages, then sit back and watch as the users make them succeed or fail.

Unfortunately, extension languages are the one case where users *cannot* choose the language they use. They have to use the language supported by the application or tool they want to extend. For example, if you wanted to extend PDP-10 Emacs, you had to use TECO. If you want to extend GNU Emacs, you have to use Lisp.

When users simply want "to write a program to do X or Y," they can use any language the system supports. There's no reason for system designers to try to decide which language is best. We can instead provide as many languages as possible, to give each user the widest possible choice. In the GNU system, I would like to support every language people want to use--provided someone will implement them.

With the methods generally used today, we cannot easily provide many languages for extending any particular utility or application package. Supporting an extension language means a lot of work for the developer of the package. Supporting two languages is twice as much work, supposing the two fit together at all. In practice, the developer has to choose a language--and then all users of the package are stuck with that one. For example, when I wrote GNU Emacs, I had to decide which language to support. I had no way to let the users decide.

When a developer chooses Tcl, that has two consequences for the users of the package:

* They can use Tcl if they wish. That's fine with me.

* They can't use any other language. That I consider a problem.

Sometimes developers choose a language because they like it. But not always. Sun recently announced a campaign to "make Tcl the universal scripting language." This is a campaign to convince all the developers who *don't* prefer Tcl that they really have no choice. The idea is that each one of us will believe that Sun will inevitably convince everyone else to use Tcl, and each of us will feel compelled to follow where we believe the rest are going.

That campaign is what led me to decide that I needed to speak to the community about the issue. By announcing on the net that GNU software packages won't use Tcl, I hope to show programmers that not everyone is going to jump on the Tcl bandwagon--so they don't have to feel compelled to do so. If developers choose to support Tcl, it should be because they want to, not because Sun convinces them they have no choice.

Design goals for GNU

When you write a program, or when you modify a GNU program, I think you should be the one who decides what to implement. I can't tell you what language to support, and I wouldn't want to try.

But I am the leader of one particular project, the GNU project. So I make the decision about which packages to include in the GNU operating system, and which design goals to aim for in developing the GNU system.

These are the design goals I've decided on concerning extension languages in the GNU system:

* As far as possible, all GNU packages should support the same extension languages, so that a user can learn one language (any one of those we support) and use it in any package--including Emacs.

* The languages we support should not be limited to special, weak "scripting languages". They should be designed to be good for writing large programs as well as small ones.

My judgement is that Tcl can't satisfy this goal. (Ousterhout seems to agree that Tcl doesn't serve this goal. He thinks that doesn't constitute a problem--I think it does.) That's why I've decided not to use Tcl as the main system-wide extension language of the GNU system.

* It is important to support a Lisp-like language, because they provide certain special kinds of power, such as representing programs as data in a structured way that can be decoded without parsing.

** It is desirable to support Scheme, because it is simple and clean.

** It is desirable to support Emacs Lisp, for compatibility with Emacs and the code already written for Emacs.

* It is important to support a more usual programming language syntax for users who find Lisp syntax too strange.

* It would be good to support Tcl as well, if that is easy to do.

The GNU extension language plan

Here is the plan for achieving the design goals stated above.


* Step 1. The base language should be modified Scheme, with these features:

** Case-sensitive symbol names.
** No distinction between #f and (), for the sake of supporting Lisp
   as well as Scheme.

** Convenient fast exception handling, and catch and throw.
** Extra slots in a symbol, to better support
   translating other Lisp dialects into Scheme.
** Multiple obarrays.
** Flexible string manipulation functions.
** Access to all or most of the Unix system calls.
** Convenient facilities for forking pipelines,
   making redirections, and so on.
** Two interfaces for call-outs to C code.
   One allows the C code to work on arbitrary Scheme data.
   The other passes strings only, and is compatible with Tcl
   C callouts provided the C function does not try to call
   the Tcl interpreter.
** Cheap built-in dynamic variables (as well as Scheme's lexical variables).
** Support for forwarding a dynamic variable's value
   into a C variable.
** A way for applications to define additional Scheme data types
   for application-specific purposes.
** A place in a function to record an interactive argument reading spec.
** An optional reader feature to convert nil to #f and t to #t,
   for the sake of supporting Lisp as well as Scheme.
** An interface to the library version of expect.
** Backtrace and debugging facilities.

All of these things are either straightforward or have already been done in Scheme systems; the task is to put them together. We are going to start with SCM, add some of these features to it, and write the rest in Scheme, using existing implementations where possible.

* Step 2. Other languages should be implemented on top of Scheme.

** Rush is a cleaned-up version of the Tcl language, which runs far faster than Tcl itself, by means of translation into Scheme. Some kludgy but necessary Tcl constructs don't work in Rush, and Tcl aficionadoes may be unhappy about this; but Rush provides cleaner ways to get the same results, so users who write extensions should like it better. Developers looking for an extension language are likely to prefer Rush to Tcl if they are not already attached to Tcl. Here are a couple of examples supplied by Adam Sah:

*** To pass an array argument without copying it, in Tcl you must use upvar or make the array a global variable. In Rush, you can simply declare the argument "pass by reference".

*** To extract values from a list and pass them as separate arguments to a function, in Tcl you must construct a function call expression using that list, and then evaluate it. This can cause trouble if the other arguments contain text that includes any special Tcl syntax. In Rush, the apply function handles this simply and reliably.

*** Rush eliminates the need for the "expr" command by allowing infix mathematical expressions and statements. For example, the Tcl computation `"set a [expr $b*$c]' can be written as `a = b*c' in Rush. (The Tcl syntax works also.)

Some references:

[SBD94] Adam Sah, Jon Blow and Brian Dennis.  "An Introduction to the Rush
        Language."  Proc. Tcl'94 Workshop.  June, 1994.
        ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-tcl94.*

[SB94]  Adam Sah and Jon Blow.  "A New Architecture for the Implementation of
        Scripting Languages."  Proc. USENIX Symp. on Very High Level Languages.
        October, 1994.  to appear.
        ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-vhll94.*
** It appears that Emacs Lisp can be implemented efficiently by translation into modified Scheme (the modifications are important).

** Python appears suitable for such an implementation, as far as I can tell from a quick look. By "suitable" I mean that mostly the same language could be implemented--minor changes in semantics would be ok. (It would be useful for someone to check this carefully.)

** A C-like language syntax can certainly be implemented this way.

* Distribution conditions.

We will permit use of the modified Scheme interpreter in proprietary programs, so as to compete effectively with alternative extensibility packages.

Translators from other languages to modified Scheme will not be part of any application; each individual user will decide when to use one of these. Therefore, there is no special reason not to use the GPL as the distribution terms for translators. So we will encourage developers of translators to use the GPL as distribution terms.

Conclusion

Until today, users have not been able to choose which extension language to use. They have always been compelled to use whichever language is supposed by the tool they wish to extend. And that has meant many different languages for different tools.

Adopting Tcl as the universal scripting language offers the possibility of eliminating the incompatibility--users would be able to extend everything with just one language. But they wouldn't be able to choose which language. They would be compelled to use Tcl and nothing else.

By making modified Scheme the universal extension language, we can give users a choice of which language to write extensions in. We can implement other languages, including modified Tcl (Rush), a Python variant, and a C-like language, through translation into Scheme, so that each user can choose the language to use. Even users who choose modified Tcl will benefit from this decision--they will be happy with the speedup they get from an implementation that translates into Scheme.

Only Scheme, or something close to Scheme, can serve this purpose. Tcl won't do the job. You can't implement Scheme or Python or Emacs Lisp with reasonable performance on top of Tcl. But modified Scheme can support them all, and many others.

The universal extension language should be modified Scheme.

Request for Volunteers

If you understand Scheme implementation well, and you want to contribute a substantial amount of time to this project, please send mail to Tom Lord, lord@gnu.ai.mit.edu.

If you expect to have time later but don't have time now, please send mail when you do have time to work. Participation in a small way is probably not useful until after the package is released.


From: gandalf@Csli.Stanford.EDU (Juergen Wagner)
Newsgroups: comp.lang.tcl
Subject: Re: GNU Extension Language Plans
Date: 20 Oct 1994 12:51:45 -0700
Organization: Stanford University

[As somebody who has conducted several (successful) projects with Tcl/Tk, including contract research for industrial partners, I'd like to add some points from a different angle to this discussion.]

Religious wars usually start when people are *very* convinced of their favourite language/system/hardware or whatever gadget. I'd like to avoid this by starting from the application requirement's point of view on extension languages.

[1] Interpreted Language

An extension language should support the rapid prototyping of applications, i.e., it needs to be flexible in various respects. The success of Tcl/Tk shows that a language which is easy to use (cf. the good ol' BASIC days), and which provides a full set of operations from very low-level basics to higher-lever graphics will find user acceptance because it meets users' needs.

From this, I infer that we call for an interpreted, not primarily compiled, language. A copmiler may come handy for performance boosts once the built system has reached some maturity, but it should be avoided to compile code (long edit-compile-run cycles inhibit prototyping).

[2] Dynamic Type System

The data types supported by the extension language should be the standard data types (integer, floats, strings, characters), plus sequential lists and hash-indexed arrays of data objects. This is a direct lesson from several languages.

Especially the hash-indexed arrays are crucial when it comes to implementing associative structures. Lists are a natural form of variable-length collections. As Tcl/Tk shows, the syntactic typing of data objects (which is due to the fact that strings are the only real data type in Tcl) is insufficient and awkward for many applications, e.g., when an object-oriented database is interfaced. Explicit type markers will be necessary, making the handling of such marked data objects somewhat obscure.

In LISP, every object "knows" its type. This certainly is an approach which is superior to that of classical compiled languages where it is impossible to tell what kind of object a pointer actually points to. In LISP, type casts are meaningless: either you convert the object to a different type (possibly also changing the semantics), or you have to stick with the object as is.

A facility similar to that of defstruct/Flavors in LISP would allow users to introduce their own first-class data types, including object systems resembling those of any application. This can be implemented in a few pages of LISP code, so it shouldn't be a problem.

[3] Syntax

Syntax is probably what keeps so many people from using basically comfortable language environments such as Smalltalk and LISP. I remember a package called CGOL which basically introduced ALGOL-like infix notation for LISP. The resulting programs very much looked like ALGOL or PASCAL programs.

I guess, if we manage to separate syntax from the extension language implementation, this would be a big win. Of course, some kind of standard syntax would have to be defined, but an extension language should be able to significantly change its syntax if needed.

Granted that feature, there isn't really a question of whether the GNU extension language is Scheme or LISP or Tcl or Python. There would be a semantics for certain data types, function primitives, and control structures. That's all. Map that onto your favourite syntax. RMS may prefer to provide a Scheme-like base system. Others may want to implement a C-like syntax.

[4] Built-In Features

Tcl by itself is nice but not perfect. I suppose, much of the success of Tcl is contributed by the availability of Tk. The large user community facing the problem of having to prototype user interfaces has been calling for such a system for a long time. Smalltalk had comparable features but was too difficult to handle and too exotic for most people.

In my opinion, an extension language should define built-in operations in the following areas:

- string and pattern manipulation (ever done programming in SNOBOL?);

- file manipulation (this is essential for replacing many shell and awk/perl scripts);

- invocation of programs and capture of results (this requires some transparent use of pipe mechanisms);

- inter-process communication (not just bits and bytes, but structured objects), including an event mechanism.

With the de-facto standard X11/Motif, there is a common user interface programming API on many platforms. Even PC windowing systems aren't that different from Motif in their functionality anymore.

This added functionality should be provided as a separate GNU X toolkit on top of the extension language. Graphical user interfaces have become as essential for programs as arithmetical operations. In the case of Tcl/Tk, one isn't really sure if Tcl and Tk are designed as separate systems or an integrated environment. The separation is there in some points, at others it isn't.

A tight integration of a visual toolkit will help prototyping significantly. The integration should be tight because of the need of a seamless integration with the object system of the extension language.

[5] Extensions

So how about extending the language? Extensions can be built in one of three ways:

- programs written in the extension language itself provide new functionality through a well-defined API (something like a LISP package system would be useful to keep name spaces separate);

- the dynamic loading of modules provides a way of dynamically including implementations of defined APIs which are provided by some compiled-in extension (this may be the preferred way of handling the GUI extension).

- adding new commands in *some* other language requires the definition of an interface protocol regarding control flow and data passing (this is the Tcl model).

The first alternative certainly is the LISP way of doing it. In order to be of use even for complex extensions, an optimizing compiler must be available (looking at the KCL/AKCL LISP, you can see how this may be done by going over a conventional language like C).

The second and third alternative require the rebuilding of the language interpreter (aka "wish inflation") unless a generic protocol for the automatic integration of dynamically loaded modules is defined (e.g., loading a dynamic library could put the resepctive symbols into a new name space/package, and a special segment in a shared library could be used to specify the parameter passing conventions of the exported functions).

-----

To summarize: in my opinion, an extension language should have rapid application prototyping as its foremost goal. This will facilitate the prototyping of entire applications as well as the quick writing of small scripts. Consequently, an interpreted language with dynamic typing and a user-definable syntax is needed. Some basic non-standard operations (when compared, e.g., to C or C++) will be required for string and file manipulation, and for inter-process communication (as distributed environments become more and more common). The language should encourage users to write extensions in the extension language itself, but allow the dynamic linking of code at the same time.

If you ckeck these requirements against Tcl/Tk, you'll notice that with the exception of the syntax issue, the typing system, and the extension mechanism, pretty much everything else is there. That's why Tcl/Tk is successful. However, when it comes to writing serious applications requiring complex typing (e.g., a project management system for concurrent engineering, or a product documentation and information system for mechanical engineering), Tcl/Tk is not suited well primarily because it is lacking a proper type system. In the realm of multimedia applications and computer-supported cooperative work (that's what I'm interested in), communication and information exchange are important. The simple Tk "send" command certainly doesn't satisfy those needs.

-----

Well, I hope the above provides some useful ideas for to the ongoing discussion, as well as a rationale for some features a scripting or extension language should have.

Greetings,

--Juergen Wagner

Juergen.Wagner@iao.fhg.de
gandalf@csli.stanford.edu

Fraunhofer-Institut fuer Arbeitswirtschaft und Organisation (FhG-IAO)
Nobelstr. 12c Voice: +49-711-970-2013
D-70569 Stuttgart, Germany Fax: +49-711-970-2299
J. Wagner


Matrix multiplication in several extension languages

Contributed by: lwv26@cas.org (Larry W. Virden, x2487) aaron@funcity.njit.edu (Aaron Watters) davis@pacific.mps.ohio-state.edu (John Davis)

Scheme

(define (matrix*matrix m1 m2) (if (not (= (num-cols m1) (num-rows m2))) (error "Matrix sizes do not match -- MATRIX*MATRIX" m1 m2) (let ((m1cm1 (- (num-cols m1) 1))) (generate-matrix (num-rows m1) (num-cols m2) (lambda (i j) (let ((r1i (vector-ref m1 i))) (sigma (lambda (k) (* (vector-ref r1i k) (matrix-ref m2 k j))) 0 m1cm1)))))))

[note: this is not all native scheme; I think some functions used need definition.]

Python

def mmult(m1,m2): m2rows,m2cols = len(m2),len(m2[0]) m1rows,m1cols = len(m1),len(m1[0]) if m1cols != m2rows: raise IndexError, "matrices don't match" result = [ None ] * m1rows for i in range( m1rows ): result[ i ] = [0] * m2cols for j in range( m2cols ): for k in range( m1cols ): result[i][j] = result[i][j] + m1[i][k]*m2[k][j] return result

S-Lang

define mult_matrix (m1, m2) { vriable i, j, result, imax, jmax, k, sum, kmax_m2; (imax, kmax) = matrix_info (m1); (kmax_m2, jmax) = matrix_info (m2); if (kmax != kmax_m2) error ("Matrices are wrong size."); result = create_array ('f', imax, jmax, 2); for (i = 0; i < imax; i++) { for (j = 0; i < jmax; j++) { sum = 0; for (k = 0; k < kmax; k++) sum = sum + m1[i, k] * m2[k, j]; result[i, j] = sum; } } return result; }


From: josefd@albert.ssl.berkeley.edu (Josef Dalcolmo)
Newsgroups: comp.lang.python,comp.lang.tcl,comp.lang.scheme,comp.lang.misc
Subject: Re: What language would you use?
Date: 3 Nov 1994 20:32:42 GMT
Organization: Center For Extreme Ultraviolet Astrophysics

In article <39b7ha$j9v@zeno.nscf.org>, Jack C. Roberts wrote:

>The organization I work for develops educational software for high school
>age students.  The software is run in classrooms on a Unix server and X
>terminals.  The courseware is broken up into many hundreds of small "pages".
>These pages are written in a home grown language.  This language has a C
>like syntax and a toolkit based on the X Motif widgets. (no flames please :)

The C like syntax and the X toolkit calls should be easily translatable into python and tk calls.

>Our current system has many problems, such as not being event driven, so
>I am advocating that we switch to a more mainstream language.  There are
>three languages I see as alternatives: tcl, python, scheme.  I would be
>very interested in hearing anyones opinion on this subject.  Below is a
>listing of issues we see as important.  It should be somewhat in
>order of importance.

>* Usable in a commercial environment

Pythons copyright allows commercial use.

>* User interface features (windowing).

Both python (with the tkinter module) and STk are good candidates.

>* Easy to learn and use

Python is the clear winner here. I have recently been trying to learn all of them: Python, STk (Scheme) and Tcl. I have a litte experience in all these language styles. I found pythons syntax so much clearer and easy to read than Scheme. True Scheme is simple, but not easily readable. I want to understand what I was doing a month ago without analyzing the program details.

Even Tcl I found somewhat confusing. In particular it is difficult to concentrate on the concepts because it lacks the power of pythons data structures, which make it actually simpler to program in python.

I only have some reservations about pythons object oriented approach to the tk interface. I think it's great, but not easy to understand for a beginner. If someone makes the basic calls available as routines, it should be digestable, though.

>* Future of language

Who knows. Tcl has a large users group. Scheme is Lisp and will stay around because of some special features or Lisp: a program may be just a little data structure ... But still not everybody likes to think in scheme and readability is a problem. Python ? I hope it will succeed, it has the potential, but who knows. You may contribute to it's succes.

>* Ability to move to PC/Mac platforms

Scheme is available for both, although not as STk (I believe). Tcl and Tk are being ported to the MSWindos environment and an NT version i believe exists. I don't know of Mac. Python definiteley runs on all these platforms, there is NT support, the Tk interface has the same limitations as the others, but there are also other graphics toolkits than tk available (STDWIN for example, but that's weak, and mxwindows)

>* Extendability

python has been designed with extendability in mind. Use python, C or C++ for that.

>* Availability of other free tools in language >* dynamically loadable extensions

Python consists of modules. Dynamic loading is currently supported for some OS, sureley more to come.

>* speed

Scheme may be the winner here, although python may be equal (I've seen benchmarks showing either one of them as winner). Tcl is the looser here.

>* process size

Depends so much on extensions and toolkits loaded. I guess they are all comparable, although I guess python may be a bit more bulky than the others.

> >While I personally like Python the best, I see Tcl as being the winner >based on the above criteria. It seems to me that tcl would be easier for >a non-programmer to use.

I disagree. Clarity is the key and I believe Python is the clear winner here. I am not a real programmer (actually I am an EE), but I found it much easier to deal with python than with the others. Tcl may be easy to write ``hello world'' in X, but as soon as you want some more complicated concepts, it's more confusing.

If you are teaching students with this, keep in mind that you may have to read their code too: I'd _much_ rather read somebody elses python code than tcl or scheme.


Newsgroups: comp.lang.python,comp.lang.tcl,comp.lang.scheme,comp.lang.misc
From: klm@nist.gov (Kenneth Manheimer)
Subject: Re: What language would you use?
Organization: National Institute of Standards and Technology
Date: Fri, 4 Nov 1994 20:34:30 GMT

shriram@asia.cs.rice.edu (Shriram Krishnamurthi) writes:

> josefd@albert.ssl.berkeley.edu (Josef Dalcolmo) writes:
> 
> > I found pythons syntax so much clearer and easy to
> > read than Scheme. True Scheme is simple, but not easily readable.
> 
> Some of Scheme's simplicity comes *from* its syntax.  What could be
> simpler than to neutralize the syntactic differences between
> user-defined functions and system "primitives"?  And also to get rid
> of obscure rules of precedence?

I happen to like both scheme and python, and respect stallman's plan to have GEL depend on (an enhanced implementation of) scheme. However, i still prefer to do my extension, scripting, etc coding in python. I was provoked to some interesting thoughts by some scheme heads at the VHLL conference, when i was asked why i don't simply use scheme, granting that it's a good and powerful language, and considering that i would deem it worthwhile to have a translator from python to scheme.

Now, my reason is ultimately based on a gut response. I have a sense that python is easier for me to use - to read and write. I suppose, on trying to pinpoint the reasons for that, that has to do with a balance between the power of the language and the degree to which it is constrained. I almost suspect that people are often referring to this issue, mistakenly expressing it purely in terms of syntax.

To contrast with some prevalent extension languages:

- TCL has the just about the most rudimentary syntax imaginable, with most of the effective semantics implemented in commands, rather than the expressive structure of the language. Where semantics are expressed in the code syntax, as with variable scoping, you have commands like 'upvar', which is used because it is not just rarely necessary to work around any intrinsic (and, i think, simplistic) constraints.

The point is that the language offers little in the way of high level abstraction of procedure, objects, etc. You can create your own (as you can with most general purpose computer languages), but i think the language provides little (besides rudimentary procedure call semantics) to help you do so, and my experience is that it's an uphill battle, the further you try to go.

- My sense of perl is that it has just about the most elaborate syntax imaginable. I haven't used it much, but that's partly because i find myself unable to do so. (My problem may be ideosyncratic - i suspect i have an unusually poor immediate memory, dependening intensely on my context for helping me remember what' i'm doing. 1/2:-) I am unable to recognize, and handle in a consistent way, abstractions that i develop in perl, because i find it difficult hard to recognize what i was trying to do in the first place. I have the feeling that the language does not help me to resolve a systematic way to look at a problem, because i need to use too many diverse handles on my data structures in implementing my solution. It provides so many ways to get around whatever abstractions i may have developed, and too little regularity to help me avoid doing so.

- Scheme certainly is very compact and powerful - it provides an incredibly cogent and compact set of primitives, by which one can develop almost any programming abstraction imaginable. My problem with this, and the item that i think determines my direction, is that there are several higher-level abstractions that are quite adequate, which often ought to be used instead of the many, more (or less) exotic mechanisms that can be built from the scheme primitives. The problem is that i (1) have to build these more suitable abstractions myself, and (2) i, or other people, may neglect to do so, so that i will have to read and work with respect to code that varies, conceptually (or lack-of-conceptually), widely.

Consider scheme's call-with-current-continuation, versus pythons try/except/finally. They both can be used to handle exceptions in a comprehensive way. call/cc can be used for much more - you can produce reentrant code frames, and so forth, which is harder (!) to do with python's constructs. However, reentrant code frames are not often necessary, except in special circumstances, and python's try/except provides a more refined and extensive exception handling mechanism than i would be likely to create if i had to develop the abstraction myself, using call/cc. So i can trust that python programmers will be more prone to use the high-level try/except mechanism when suitable. This can help make code quite understandable.

I suppose that many scheme dialects do support a higher-level try/except style mechanism. However, that is just an example of one case where a judicious choice of a good, high-level base can make a lot of coding easier. I think many of such cases exist when you compare python and scheme, with python trading off some of the extreme flexibility for more easy coverage of any common situations...

I think that python manages to provide an particularly powerful and suitable level of base abstractions and structure for building on them, while also being very simple and forthright. This is very compelling, especially when taken together with it's facilities for extension and embedding.

I have been surprised numerous times by having my python code run the first try, much more often than has happened with any other language i use. (Admittedly, i do a lot of bourne shell, awk, and elisp coding, which are not exactly supportive of error-free programming. However, i have worked at times with common lisp, pascal, as well as a specially developed, clean communications language named praxis - midway between pascal and ada - and so forth, without anything near the same ease.)

Moreover, i find i have a dramatically easier time reading other people's python code than i do reading code in other languages. And this is not because i was reading trivial or unsophisticated code - i'm talking about packages for things like rpc interfaces, language debuggers, OS pipes, and so forth.

Both these facts are quite extraordinary, and perhaps more important and telling attributes of a general-purpose programming language than you might expect...

Ken ken.manheimer@nist.gov, 301 975-3539


From: Tom Christiansen 
Newsgroups: comp.lang.python,comp.lang.tcl,comp.lang.scheme,comp.lang.misc,comp.lang.perl
Subject: Re: What language would you use?
Date: 6 Nov 1994 03:12:57 GMT
Organization: Perl Consulting and Training

:-> In comp.lang.tcl, roberts@alpha (Jack C. Roberts) writes:
:The organization I work for develops educational software for high school
:age students.  The software is run in classrooms on a Unix server and X
:terminals.  The courseware is broken up into many hundreds of small "pages".
:These pages are written in a home grown language.  This language has a C
:like syntax and a toolkit based on the X Motif widgets. (no flames please :)
:
:Our current system has many problems, such as not being event driven, so
:I am advocating that we switch to a more mainstream language.  There are
:three languages I see as alternatives: tcl, python, scheme.  I would be
:very interested in hearing anyones opinion on this subject.  Below is a
:listing of issues we see as important.  It should be somewhat in
:order of importance.
:
:* Usable in a commercial environment
:* User interface features (windowing)
:* Easy to learn and use
:* Future of language
:* Ability to move to PC/Mac platforms
:* Extendability
:* Availability of other free tools in language
:* dynamically loadable extensions
:* speed
:* process size
:
:While I personally like Python the best, I see Tcl as being the winner
:based on the above criteria.  It seems to me that tcl would be easier for
:a non-programmer to use.  This is only a guess.  Does anyone have any
:experience they'd like to share? 
:
:Please note: I am not trying to start a flame war based on which language
:is better.  I would just like to hear from those who have an opinion on
:which they think would be better for this particular task.
:
:I know little about scheme and will soon delve into the docs on it.

That's an interesting question: when Evi Nemeth asked at VHLL what language should be taught first (to college freshmen), someone suggested English. :-)

Jon Bentley suggested that it was much easier to teach his 11 year-old son visual basic than C, and a better investment of the kids time.

As someone else has already pointed out, which one you select depends on where the student is expecting to go. For the sake of their future marketability as a programmer, a prospective CS major should probably be exposed to C and C++ not too late in the picture -- or possibly an easier but reasonably similar thereof, like in perl taught in the right way. (Python doesn't count for this, as it doesn't really support all the C operators, let alone its flow control) a assembler and scheme and prolog and MANY others for the sake of breath, but a PC owner with occasional hacking needs probably needs know no more than Visual BASIC. I might seriously consider suggesting that.

That being said, I'm going to pay my obligatory chime in for perl, since no one else has done so, and since you didn't even post your query to comp.lang.perl. Well, I'm going to answer you particular issues, but I'm still not sure that perl is best for what you want (nor any of the others either), even though I do know that there are folks out there for whom perl is their first-learned computer language. Honest. :-)

A nice interpreted Pascal system, like the old UCSD pascal, might not be a bad idea either, although Visual BASIC is more modern (I think). I don't talk about them a lot below, but you should still think about them.

Here are the perl answers;

* Usable in a commercial environment

Yes, perl has both the GPL as well as a more LGPL-like licensing alternative available to it.

* User interface features (windowing)

Currently supported are tk, athena and Xlib (via SX), and curses. The PC/Mac etc versions have certain arch-specific windowish extensions.

* Easy to learn and use

Depends on your background. Certainly it's easier than C, but so are most things that don't drive you mad with variable declaration, data typing, and memory allocation issues.

However, I think you'll find that if someone understand this:

	long fact(long i) {
	    if (i < 1) {
		return 1;
	    } else {
		return i * fact(i - 1);
	    } 
	} 

    That this isn't very far removed from it:

	sub fact {  
	    my $n = shift;
	    if ($n < 1) {
		return 1;
	    } else {
		return $n * fact($n - 1);
	    } 
	} 

    I'd be surprised if someone really found things constructed like this:
    (I realize that these examples aren't similar in complexity)

    (define (read:eval-feature exp)
      (cond ((symbol? exp)
	     (or (memq exp *features*) (eq? exp (software-type))))
	    ((and (pair? exp) (list? exp))
	     (case (car exp)
	       ((not) (not (read:eval-feature (cadr exp))))
	       ((or) (if (null? (cdr exp)) #f
			 (or (read:eval-feature (cadr exp))
			     (read:eval-feature (cons 'or (cddr exp))))))
	       ((and) (if (null? (cdr exp)) #t
			  (and (read:eval-feature (cadr exp))
			       (read:eval-feature (cons 'and (cddr exp))))))
	       (else (error "read:sharp+ invalid expression " exp))))))

    or like this; syntactic fascism WRT indentation doesn't seem like
    the best thing for a novice.  Just make them always use curleys
    for C/C++/awk/perl/etc, the way tcl does.

    params = al.queryparams(dev)
    for i in range(1, len(params), 2):
	params[i] = -1
    while 1:
	time.sleep(0.1)
	old = params[:]
	al.getparams(dev, params)
	if params <> old:
	    for i in range(0, len(params), 2):
		if params[i+1] <> old[i+1]:
		    name = al.getname(dev, params[i])
		    if params[i] == AL.INPUT_SOURCE:
			if 0 <= old[i+1] < len(source_name):
			    oldval = source_name[old[i+1]]
			else:
			    oldval = ''
			newval = source_name[params[i+1]]
		    else:
			oldval = `old[i+1]`
			newval = `params[i+1]`
		    print string.ljust(name, 25),
		    print '(' + string.rjust(oldval, 10) + ')',
		    print '-->',
		    print string.rjust(newval, 10)
	    print

    or even like this:

    proc parray a {
	upvar 1 $a array
	if [catch {array size array}] {
	    error "\"$a\" isn't an array"
	}
	set maxl 0
	foreach name [lsort [array names array]] {
	    if {[string length $name] > $maxl} {
		set maxl [string length $name]
	    }
	}
	set maxl [expr {$maxl + [string length $a] + 2}]
	foreach name [lsort [array names array]] {
	    set nameString [format %s(%s) $a $name]
	    puts stdout [format "%-*s = %s" $maxl $nameString $array($name)]
	}
    }

easy to understand, although it's certainly possible that this is a factor of your initial programming languages. For the record, I learned BASIC(-PLUS), Fortran, Pascal, (PDP-11) Assembler, and C before actually becoming a CS major and being exposted to other things. This may color my initial legibility, but then again, maybe less so than you'd think; after all, while I prefer RPN calculators, most non-techies don't.

* Future of language

Well, a brand-new implementation (v5.0) was just released. It makes for a smaller, but more extensible language. We hope to someday separate our byte-code interpreter into a standalone entity, as well as compile all the way to C.

* Ability to move to PC/Mac platforms

Version 4 of perl is available for virtually any sort of Unix box as well as MS-DOS, Mac, Windows-NT, VMS, Amiga, OS/2, Atari, LynxOS, MVS, MPE, Xenix, and Netware. Many of these have architecture specific extensions. Version 5 is already available on non-unix platforms like MS-DOS and VMS, with more in testing.

* Extendability

Not sure what you mean by this. It's not as extensible syntactically as tcl is, but does support dynamically loaded user code in C or perl, as well as embeddeding in C or C++ code.

* Availability of other free tools in language

Perl comes with a debugger and various libraries. Profilers and emacs-formatters are also available.

* dynamically loadable extensions

Yup.

* speed * process size

Regarding these two, let me show you one particular benchmark.

The x= values below are the number of times the C execution speed it took.

1000 iterations of factorial(20)

    C           0.230u 0.040s 0:00.34 79.4% 0+206k 	x=  1.0
    scheme      2.170u 0.130s 0:02.81 81.8% 0+659k 	x=  9.4
    perl5       2.800u 0.110s 0:02.95 98.6% 0+616k 	x= 12.2
    python      4.710u 0.120s 0:05.18 93.2% 0+504k 	x= 20.5
    perl4       9.820u 0.180s 0:10.61 94.2% 0+825k 	x= 42.7
    tcl        26.950u 0.080s 0:28.43 95.0% 0+459k 	x=117.17
    sh		don't ask :-)

The drastic speedup before version 4 and version 5 was largely due to a bug I had to work around in perl5,

Python is usually closer to only one-third slower than perl rather than two-thirds, except for particularly clever regexp stuff at which perl is quite hard to beat.

A string-oriented oriented benchmark would manifest different proportions, as would different architecutures. I used scm4e1, tcl7.3, perl4.036, perl5.000(production), and python-1.1. I can't guarantee that the non-perl interpreters were optimal.

* object-oriented paradigm

You didn't mention this. :-) Yes, perl has oo support, as do most of the others, but this may not matter to high-school students.

Whatever you choose, you need to let them concentrate not on syntax, but on programming itself -- algorithms, etc. A "do what I mean" language approach is probably best here.

Again, think about Visual BASIC or an interpreted Pascal system as well.

--tom
-- 
Tom Christiansen      Perl Consultant, Gamer, Hiker      tchrist@mox.perl.com
You know, by the time you get done with all this, the "Swiss Army
Chainsaw" is going to be more like a Swiss Army Tactical Nuke....  :-)
    --Brandon Allbery on perl in <1991Feb21.002412.20045@NCoast.ORG> 
-- 

From: Tom Christiansen 
Newsgroups: comp.lang.python,comp.lang.tcl,comp.lang.scheme,comp.lang.misc,comp.lang.perl
Subject: Re: What language would you use?
Date: 6 Nov 1994 15:14:51 GMT
Organization: Perl Consulting and Training

:-> In comp.lang.perl, davis@amy.tch.harvard.edu writes:
:In article <39hhjp$lgn@csnews.cs.Colorado.EDU>, Tom Christiansen
: writes: 
: :     1000 iterations of factorial(20) 
: : 
: :     C           0.230u 0.040s 0:00.34 79.4% 0+206k  x=  1.0
: :     scheme      2.170u 0.130s 0:02.81 81.8% 0+659k  x=  9.4
: :     perl5       2.800u 0.110s 0:02.95 98.6% 0+616k  x= 12.2
: :     python      4.710u 0.120s 0:05.18 93.2% 0+504k  x= 20.5
: :     perl4       9.820u 0.180s 0:10.61 94.2% 0+825k  x= 42.7
: :     tcl        26.950u 0.080s 0:28.43 95.0% 0+459k  x=117.17
: :     sh              don't ask :-)
:
:I would like to see the actual code used in each case.  Is it possible to
:post it?  Perhaps you coded Tcl in such a way that it does not exploit some
:features of the language.   For example, `i = i - 1' my be better coded in a
:way that executes faster, e.g, `decrement i'.

Hm... neither decr nor decrement worked. Anyway, here's the code. It's certainly possibly the case that it's not craftily coded. It was, however, what appeared to me to be the straightforward, recursive approach for all of them.

tcl:

    proc fact x {
        if [expr $x < 2] {
            return 1
        } else {
            return [expr $x * [fact [expr $x - 1]]] 
        }   
    }   

lisp, i mean scheme:

    (define fact 
	(lambda (arg) 
	    (cond 
		( (< arg 2) 		1) 
		  (else 		(* arg (fact (- arg 1))))
	    )
	)
    )

python:

    def fact(x):
        if (x <= 1):
            return 1
        return x * fact(x -1)

C: 

    long
    fact(long i) {
        if (i < 1) {
            return 1;
        } else {
            return i * fact(i - 1);
        } 
    } 

perl:  (v5; v4 has a bug needing a param copy into local variable)

    sub fact {  # think of $_[0] as arg 0 of 0..n
        if ($_[0] < 1) {
            return 1;
        } else {
            return $_[0] * fact($_[0] - 1);
        }
    } 

You could also have written the C and perl versions more as 

    sub fact { 
        ($_[0] < 1) ? 1 : $_[0] * fact($_[0]-1);
    } 

but it's not like it gains you a great deal.  These
compilers aren't *THAT* stupid. :-)

By the way, I tried to write these all in the recursive
way.  The iterative timings on perl reduce the time spent
*dramatically*.

$ perl fact.pl

Benchmark: timing 1000 iterations of To iterate is human, and to recurse divine...
To iterate is human:      3 secs ( 2.63 usr  0.00 sys =  2.63 cpu)
and to recurse divine:    1 secs ( 0.87 usr  0.00 sys =  0.87 cpu)

$ cat fact.pl  # shifted 

    #!/usr/bin/perl

    require 5.000;
    use Benchmark;

    $ITERATIONS     = 1000;
    $NUMBER         = 20;

    sub fact_recur { 
        if ($_[0] < 1) {
            return 1;
        } else { 
            return $_[0] * fact_recur($_[0]-1);
        }
    } 

    sub fact_iter { 
        my $x = $_[0];
        my $total;
        for ($total = 1; $x > 1; $x--) {
            $total *= $x;
        } 
        return $total;
    } 

    timethese $ITERATIONS => {
        'To iterate is human'           =>      "fact_recur $NUMBER",
        'and to recurse divine'         =>      "fact_iter  $NUMBER",
    }

As you can see, the iterative version in perl is 3 times faster than
the recursive one.  

If you're really into benchmarks, I'd love it if someone were to code up
the following problems in tcl, python, and scheme (and whatever else you'd
like).  Separate versions (one optimized for speed, one for beauty :-) are
ok.  Post your code so we can time it on our own systems.

0)  Factorial Test  (numerics and function calls)

        (we did this already)

1)  Regular Expressions Test

    Read a file of (extended per egrep) regular expressions (one per line), 
    and apply those to all files whose names are listed on the command line.
    Basically, an 'egrep -f' simulator.  Test it with 20 "vt100" patterns
    against a five /etc/termcap files.  Tests using more elaborate patters
    would also be interesting.  Your code should not break if given hundreds
    of regular expressions or binary files to scan.  

2)  Sorting Test

    Sort an input file that consists of lines like this

        var1=23 other=14 ditto=23 fred=2

    such that each output line is sorted WRT to the number.  Order
    of output lines does not change.  Resolve collisions using the
    variable name.   e.g.

        fred=2 other=14 ditto=23 var1=23 

    Lines may be up to several kilobytes in length and contain
    zillions of variables.

3)  System Test

    Given a list of directories, report any bogus symbolic links contained
    anywhere in those subtrees.  A bogus symbolic link is one that cannot
    be resolved because it points to a nonexistent or otherwise
    unresolvable file.  Do *not* use an external find executable.
    Directories may be very very deep.  Print a warning immediately if the
    system you're running on doesn't support symbolic links.

I'll post perl solutions if people post the others.

--tom -- Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com

"But Billy! A *small* allowance prepares you for a lifetime of small salaries and for your Social Security payments." --Family Circus


From: Guido van Rossum 
Subject: Re: What language would you use? 
Organization: CWI, Amsterdam
Date: Wed, 9 Nov 1994 22:42:15 GMT

[I apologize beforehand -- this should go to all mentioned newsgroups
but I can't post news from here so I'll mail it to Tom and to the
Python mailing list, which is gatewayed into comp.lang.python.  Maybe
Tom can quote this when posting his promised Perl solutions?]

Tom Christiansen wrote:

> If you're really into benchmarks, I'd love it if someone were to code up
> the following problems in tcl, python, and scheme (and whatever else you'd
> like).  Separate versions (one optimized for speed, one for beauty :-) are
> ok.  Post your code so we can time it on our own systems.

OK, I'll bite.  Here are three samples coded in Python.  I spent at
most an hour and a half coding these three files -- with
interruptions.  I'm actually not horribly interested in performance
comparisons, although I used a few tricks to speed things up
(actually: to avoid slowing them down).  I wrote these solutions
because I think that a collection of problems like these coded in a
number of languages may give people a better idea of what "real"
programs in the various languages look like.  Of course, Tom's choice
of problems is bound to favor Perl, but not extremely so.  Perhaps I
should counter with a set of problems that I think favor Python.

======================================================================
regextest.py:
======================================================================
#! /usr/local/bin/python

# 1)  Regular Expressions Test
# 
#     Read a file of (extended per egrep) regular expressions (one per line), 
#     and apply those to all files whose names are listed on the command line.
#     Basically, an 'egrep -f' simulator.  Test it with 20 "vt100" patterns
#     against a five /etc/termcap files.  Tests using more elaborate patters
#     would also be interesting.  Your code should not break if given hundreds
#     of regular expressions or binary files to scan.  

# This implementation:
# - combines all patterns into a single one using ( ... | ... | ... )
# - reads patterns from stdin, scans files given as command line arguments
# - produces output in the format ::
# - is only about 2.5 times as slow as egrep (though I couldn't run
#   Tom's test -- this system, a vanilla SGI, only has /etc/terminfo)

import string
import sys
import regex
from regex_syntax import *

regex.set_syntax(RE_SYNTAX_EGREP)

def main():
	pats = map(chomp, sys.stdin.readlines())
	bigpat = '(' + string.joinfields(pats, '|') + ')'
	prog = regex.compile(bigpat)
	
	for file in sys.argv[1:]:
		try:
			fp = open(file, 'r')
		except IOError, msg:
			print "%s: %s" % (file, msg)
			continue
		lineno = 0
		while 1:
			line = fp.readline()
			if not line:
				break
			lineno = lineno + 1
			if prog.search(line) >= 0:
				print "%s:%s:%s" % (file, lineno, line),

def chomp(s):
	if s[-1:] == '\n': return s[:-1]
	else: return s

main()
======================================================================
sortingtest.py:
======================================================================
#! /usr/local/bin/python

# 2)  Sorting Test
# 
#     Sort an input file that consists of lines like this
# 
#         var1=23 other=14 ditto=23 fred=2
# 
#     such that each output line is sorted WRT to the number.  Order
#     of output lines does not change.  Resolve collisions using the
#     variable name.   e.g.
# 
#         fred=2 other=14 ditto=23 var1=23 
# 
#     Lines may be up to several kilobytes in length and contain
#     zillions of variables.

# This implementation:
# - Reads stdin, writes stdout
# - Uses any amount of whitespace to separate fields
# - Allows signed numbers
# - Treats illegally formatted fields as field=0
# - Outputs the sorted fields with exactly one space between them
# - Handles blank input lines correctly

import regex
import string
import sys

def main():
	prog = regex.compile('^\(.*\)=\([-+]?[0-9]+\)')
	def makekey(item, prog=prog):
		if prog.match(item) >= 0:
			var, num = prog.group(1, 2)
			return string.atoi(num), var
		else:
			# Bad input -- pretend it's a var with value 0
			return 0, item
	while 1:
		line = sys.stdin.readline()
		if not line:
			break
		items = string.split(line)
		items = map(makekey, items)
		items.sort()
		for num, var in items:
			print "%s=%s" % (var, num),
		print

main()
======================================================================
systemtest.py:
======================================================================
#! /usr/local/bin/python

# 3)  System Test
# 
#     Given a list of directories, report any bogus symbolic links contained
#     anywhere in those subtrees.  A bogus symbolic link is one that cannot
#     be resolved because it points to a nonexistent or otherwise
#     unresolvable file.  Do *not* use an external find executable.
#     Directories may be very very deep.  Print a warning immediately if the
#     system you're running on doesn't support symbolic links.

# This implementation:
# - takes one optional argument, using the current directory as default
# - uses chdir to increase performance
# - sorts the names per directory
# - prints output lines of the form "path1 -> path2" as it goes
# - prints error messages about directories it can't list or chdir into

import os
import sys
from stat import *

def main():
	try:
		# Note: can't test for presence of lstat -- it's always there
		dummy = os.readlink
	except AttributeError:
		print "This system doesn't have symbolic links"
		sys.exit(0)
	if sys.argv[1:]:
		prefix = sys.argv[1]
	else:
		prefix = ''
	if prefix:
		os.chdir(prefix)
		if prefix[-1:] != '/': prefix = prefix + '/'
		reportboguslinks(prefix)
	else:
		reportboguslinks('')

def reportboguslinks(prefix):
	try:
		names = os.listdir('.')
	except os.error, msg:
		print "%s%s: can't list: %s" % (prefix, '.', msg)
		return
	names.sort()
	for name in names:
		if name == os.curdir or name == os.pardir:
			continue
		try:
			mode = os.lstat(name)[ST_MODE]
		except os.error:
			print "%s%s: can't stat: %s" % (prefix, name, msg)
			continue
		if S_ISLNK(mode):
			try:
				os.stat(name)
			except os.error:
				print "%s%s -> %s" % \
				      (prefix, name, os.readlink(name))
		elif S_ISDIR(mode):
			try:
				os.chdir(name)
			except os.error, msg:
				print "%s%s: can't chdir: %s" % \
				      (prefix, name, msg)
				continue
			try:
				reportboguslinks(prefix + name + '/')
			finally:
				os.chdir('..')

main()
======================================================================

--Guido van Rossum, CWI, Amsterdam 


From: Tom Christiansen 
Newsgroups: gnu.misc.discuss,comp.lang.misc,comp.unix.shell,comp.unix.admin,
+           comp.lang.perl,comp.lang.tcl,comp.lang.python,comp.lang.scheme
Subject: GNU Script isn't fixing something that's broken, so is doomed
Date: Mon Oct 31 21:45:25 PST 1994
Organization: University of Colorado at Boulder

After attending the VHLL Symposium at Santa Fe where zillions of languages were showed off and talked about, I've been thinking about this new universal scripting language that RMS proposes, the one that's supposed to obsolete all other scripting languages in existence. I now believe doomed his plan to make a universal scripting language, especially one derived from scheme. He would like this language to be used by any application wanting embeddability or extensibility will employ. Essentially, it will fail due to lack of consideration of these issues:

The only points RMS makes which I recall to have substantial weight are that you need a fully-featured and reasonably fast language for real-world applications and that tcl isn't very good at this. Well, maybe the latter is indeed true, but given that people are using tcl for this and are doing so with reasonable efficacy proves it works sufficiently well for this purpose. tk and expect prove that. Please remember that as a glue language, tcl doesn't need to handle large 50,000-line programs well. Making it do so could in fact impair its being good glue language.

If the language is good for generating and parsing things like .Xdefaults or Makefiles or .cliprc files, fine, but if this just forces sysadmins to code in scheme or rush or something, they'll just laugh at you. Well, until they're FORCED to use it, at which point they'll kick and scream for something easier.

Declarative languages, perhaps with escapes into code (a la yacc, escaping into C or perl), are the best way of handling a lot of problems, and both yacc and tcl make it easy create these, and perl certainly is good at parsing such files. There's no reason for all config syntaxes to to be the same. To the contrary: problems are just too varied for one declarative syntax describing them. And that's ok.

I'll tell you a place the FSF can perhaps help. Consider the benefit from the perl<->ksh portability dialog, or better, the refined and streamlined C API for tk that I presume will come out of the tkperl<->tkpython dialog. This is the kind of thing we need. It's good to have a common C API. If GNU can standarize things like that, then great. But telling someone they must use language GNU Blah for an extension language, well, get real: it really just isn't going to happen.

I genuinely don't see that there's enough substantially wrong with the way we make little languages now, either for extension or embeddability, that a huge niche will suddenly be filled by gnu script. GNU only succeeds when there's a technical niche to fill, not when there's a political need to fill.

We'll all just keep using yacc and tcl and perl for these (and maybe even ksh and python) and we'll all be happy. They've decades of combined use to hone and perfect. GNU script will not have that. Without TREMENDOUS incentives, nothing will change. Can you imagine all dot files and config files and macro files and rc files all being in one syntax? This will never happen. And if you try to enforce it, it'll blow up in your face. Straitjacketing won't win you friends.

In summary, I truly fear you're wasting a great deal of time attempting to create something no one wants or needs badly enough to put up with. In other words: it's not broken, so don't try to fix it.

--tom
-- 
Tom Christiansen      Perl Consultant, Gamer, Hiker      tchrist@mox.perl.com

if (shm == (char *)-1)  /* I hate System V IPC, I really do */
    --Larry Wall, from doio.c in the v5.0 perl distribution


Newsgroups: comp.lang.misc,gnu.misc.discuss,comp.lang.scheme,comp.lang.tcl,comp.lang.perl
From: peter@nmti.com (Peter da Silva)
Subject: Metalanguages in environments where code is data.
Organization: Network/development platform support, NMTI
Date: Fri Nov 04 07:18:52 PST 1994

In article <39bo03$d4e@csnews.cs.colorado.edu>,
Tom Christiansen   wrote:
> :-> In gnu.misc.discuss, peter@nmti.com (Peter da Silva) writes:
> :It has the same problem as AREXX and Python, in that it's a procedural
> :and algebraic language, 

> For some things, that's just fine.   I'm suppose that you think their
> opposite must be the soi-disant data-driven or object-oriented programming
> styles.

I'm not talking about coding styles at all. I'm talking about a basic capability common to all Lisp-derived languages that there's no syntactic distinction between code and data. This makes it *easy* to define a metalanguage that's declarative, or embedded, or object-oriented, or what have you. You bring up the example of makefiles... converting a Makefile to Tcl (I'll use Tcl instead of Lisp or Scheme because I'm rusty in Lisp) is a simple mechanical *local* translation:


        CFLAGS=-O -g
        OBJS=main.o frob.o
        LIBS=-lreadline

        frob: $(OBJS)
                $(CC) $(CFLAGS) $(OBJS) -o frob $(LIBS)

Becomes:

        source makefile.tcl

        set CFLAGS "-O -g"
        set OBJS "main.o frob.o"
        set LIBS "-lreadline"

        rule frob "${OBJS}" {
                shell "${CC} ${CFLAGS} ${OBJS} -o frob ${LIBS}"
        }

        make

I doubt that a clean Scheme version would be much, if any, more complex. As you can see, the resulting Tcl makefile is just as readable and maintainable as the original. Why look, Tcl is now a declarative language! Nope... but the metalanguage put together from this subset of Tcl *is*. What was your other example? Oh, an embedded language. OK... here's how I'd do that:

        source runoff.tcl
        runoff {
        Here you can have your running text,
        isolated from the rest of the world,
        safely quoted,
        with embedded Tcl commands like [exec date]
        handily sucked into the code,
        with no effort expended whatsoever.
        I know this is little harder in lisp itself
        because I used a similar technique
        in an adventure program back in 1979 or 1980,
        in Lisp 1.5
        on the PDP-11.
        }
        flush

In Perl you'd have to define some new encapsulation method for the procedural fragments associated with each rule of the makefile. Probably using HERE documents, I guess. You'd have to write some sort of parser for the running text. You're no longer using the SAME language in each place, and you're putting a lot more demands on the new language designer that the designer of a metalanguage doesn't have.


Newsgroups: comp.lang.scheme,comp.lang.tcl,comp.lang.lisp
From: gjc@world.std.com (George J Carrette)
Subject: TCL is fat,slow,and lacks staying power.
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 17 Nov 1994 22:30:55 GMT
Please, can we lay to rest the myth that TCL is small and lisp interpreters are big? The TCL source code is at least 5 TIMES BIGGER, and the stripped binary is at least TWICE AS BIG as a classic scheme interpreter like SIOD.

This posting is prompted by a knee-jerk response I got recently on a mailing list when I suggested using SIOD as a way to script some arbitrary filenaming-munging into a very nice Microsoft-Windows-for-Work-Groups compatible file server for Unix called Samba.

The questions were so wonderfully typical of TCL bigotry that I figured others may enjoy feasting on them too.

Somebody said:
>Had you considered TCL ?

Yes. My suggestion to use SIOD was after serious consideration of the trade-offs involved.

>I believe it may be smaller than the one you mentioned.

Why would you want to say you believe something like that?

1. Distribution sizes: (ftp.std.com ...someplace...)
-rw-r--r--    1 bzs      staff    1822720 Nov 23  1993 tcl7.3.tar
-rw-r-xr-x    1 gjc      gjc       211603 Apr 28  1994 siod-3.0-shar
2. Stripped binary built on SGI IRIX MIPS:
-rwx------    1 gjc      sys       199552 Nov 17 16:15 tclsh
-rwx------    1 gjc      sys        95792 Nov 17 16:15 siod
3. Source code, using wc on *.c and *.h files:
[TCL]
 tcl library source        26738    100447    734901 total
 required "compat" source   1929      8576     56127 total
[SIOD]
 source including SQL support for both Oracle and RDB commercial databases
 and macintosh support      4981     12903    136440 total

And to consider the case in question, which was to add script-driven dynamic file-hook to the LANMAN server samba-1.8.05, the wc *.c *.h for the files that go into smbd:

                           20912     60293    568786 total

So you think TCL is small, yet it is bigger than the thing you want to add it to? The source to TCL is some 30% bigger. Does that make sense?

When somebody asks for a small interpreter to add to something, if I suggest SIOD it is because SIOD *is-in-fact* small.

Lots of people beleive that TCL is small because certain things about TCL have been *justified* by claiming "... did it that way to keep it small." But that doesn't make it small.

Of course, as Prof. Fano told me on a bad-weather day last winter at the local Stop and Shop, "interpreters are always small, it is the subrs you need that make things large." (Historical note, Fano was the head of the MIT Laboratory for Computer Science many years ago. Or was it Project Mac?)

>it has a generic 'embeddable' interpreter in the PD.

Lots of lisp interpreters, including SIOD are distributed that way too.

>In addition, there is a version which is supposed to be 'safe' for server's
>to run client submitted code ;-)

Well, all I can say about that is that if you want to use the theory of programming languages to *prove* that something is safe you are a heck of a lot better off with a language that has been extensively studied in the computer science literature, such as Scheme.

The only thing worse than a known unsafe methodology is an unproven "safe" one.

But seriously, safety in practice comes down to some fairly simple ideas, like syntax checking and name hiding.


Date: Mon, 28 Nov 1994 09:59:18 -0500
From: aml@world.std.com (Andrew M. Langmead)
Subject: Re: Perl/Tcl Comparison
Newsgroups: comp.lang.perl,comp.lang.tcl
> I am a relative beginner in both the Perl and Tcl environments.
> Clearly both products have merit.  They appear to me to cover much the same
> ground, and this ground is clearly expanding due to the ever growing
> range of extensions to both products.

In my opinion, they two languages started with different goals. Tcl started out not to be a self contained language, but one in which the major functionality of a program would still be written in C, inserted as new tcl comands and glued together with tcl code. Perl was designed to be a complete language for a range of tasks that that were of a greater complexity than could be managed in a shell script, but not at a level that a lowish high level language like C is required. But as you said, they are nearing each other. Perl now has the ability to easily add new features as compiled C code (the XSUB mechanism) or even have a perl interpreter embedded into a compiled program, and tcl has added more features to make it less necessary to go outside to C for necessary functionality.

The major difference that I see is the mind set of the language designers, which affects the mindset of the programmer using the language. The closer the programmer can get to the way the language designer was thinking when they designed certain features, the easier the programmer will have with the language.

The most obvious example of these differences, are two passages in the books the language designers have written about their language. In "tcl and the tk toolkit" (or whatever the title is, the book isn't in front of me at the moment.) Ousterhout talks about how sometimes the way to code a statement isn't what would be immediately intuitive, but if one thinks about how the parser in processing its input, the proper method will always be apparent. In the book "Programming Perl", there is a part in where Larry Wall says, "These operators always return what you want, unless what you want is consistancy."

Perl is written in a way that what Larry Wall thinks the programmers first guess is will probably be right. (Probably how accurate Larry's idea of the programmers first guess depends on the programmers exposure to the shell/awk/sed/C programming concepts pieces of perl are based on.) If the programmer doesn't get it right, it is almost certain that they will need to look in the documenation to get the right answer. Tcl is written in a way that the programmers first guess may not be right, but they can deduce the right answer from learning a few simple rules (and rarely need the manual for the answer.)


From: girardot@cambur.emse.fr (Jean-Jacques Girardot)
Newsgroups: comp.lang.perl
Subject: Re: What language would you use?
Date: Tue, 15 Nov 94 15:39:47 +0100
Organization: University Computing Services - Oregon State University

I have been testing some scripting languages, using the Fibonacci function which is helpful in testing the performances of the interpreter of the language. The algorithm used is : fib(n) = if n<2 then 1 else fib(n-1)+fib(n-2).

Tests are performed using a command such as :

time xxx <fib.xx

on a Sun4 Sparc Station SLC, where "xxx" is the name of the interpreter, and "fib.xx" contains the "adequate" definition of fib and the call to fib(30);

Just for the information, here are some results so far :

            CPU Time   Elapsed Time       C Ratio     CT Ratio
C               6.2u           0:08           1.0        0.086
CTalk          72.0u           1:14          11.6        1.000
GLisp          76.6u           1:19          12.4        1.064
SCM           149.6u           2:32          24.2        2.078
PSI           299.0u           5:04          48.2        4.153
Smalltalk     306.5u           5:19          49.4        4.257
SIOD          371.0u          14:41          59.8        5.153
XSCHEME       492.2u           8:20          79.4        6.836
WOOL          525.0u          10:14          84.7        7.291
Elk          1182.8u          20:18         190.8       16.428
Python       1627.4u          27:55         262.5       22.603
Tcl          3478.0u        1:00:27         561.0       48.306
APL90        4424.0u        1:28:43         713.5       61.444
MIT Scheme   7018.8u        2:02:22        1132.1       97.483
J           13648.9u        4:01:00        2201.4      189.568
PERL        --------        -------        ------      -------

Languages used are Scheme (SCM, PSI, SIOD, Elk, MIT Scheme), Lisp/Scheme-like (GLisp, WOOL), APL/APL-like (APL90, J), a C-like Lisp (CTalk), compiled C itself (C), Smalltalk (due to Tim Budd), and other scripting languages (Python, Tcl). Some of the versions I used may be outdated, so the whole thing does not necessarily make much sense...

Jean-Jacques Girardot - girardot@emse.fr


Extending W3 Clients

Alan Falconer Slater,
Department of Computing and Electrical Engineering,
Heriot-Watt University,
Edinburgh, Scotland.

(Note: this is the introduction from the document available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/slater/ew3c.html).

World-Wide-Web (W3) browsers, such as Mosaic, are powerful tools which have been proven to be directly applicable in a large number of domains. However, although browsers can support localised customisation of the mechanisms used to display particular types of data through the use of facilities such as MIME, the internal structures and processes of systems are typically not exposed in a manner that supports more radical modifications.

This paper firstly addresses what benefits may be gained through the provision of mechanisms for the extension of W3 clients before examining how these additional software components may be realised.


From: Tom Christiansen <tchrist@mox.perl.com>
Newsgroups: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.lang.misc,comp.lang.perl
Subject: Re: GNU Extension Language Plans
Date: 22 Oct 1994 04:16:20 GMT
Organization: Perl Consulting and Training
Message-ID: <38a3mk$lr8@csnews.cs.Colorado.EDU>
:-> In comp.lang.tcl, peter@nmti.com (Peter da Silva) writes:
:> Thanks, Peter.  See Larry's release notice posted elsewhere in these
:> language areas for details, and/or glance at my implementation of a
:> Patricia trie in perl, recently posted elsewhere in this thread.
:
:Yes, I had a look at it. You didn't use postix if at all, that I could see.

Um .... postix? Is that a typo, or have I just been programming in shell too long? :-)

:> Do you want big languages and little programs or vice versa?
:
:I want little languages and little programs. I don't believe you can't
:get there (watch out, he's got something under his coat! Oh no! He's got
:a Forth interpreter! Run!) from here...

Peter, be aware that the common man has neither the time for nor any appreciation of your spartan minimalism. In fact, he in general has no time for programming languages at all. He's not looking for beauty in his code -- I'm quite certain that he couldn't care less about its aesthetic appeal. He's just trying to get stuff done. Why is it, do you suppose, that languages like BASIC, sh, awk, perl, tcl, REXX, and Visual BASIC have enjoyed the popularity they have? It's really very simple: they're easy to use for someone who hasn't had the questionable good fortune of having done graduate work in programming languages.

Period.

To a large extent, most people design computer languages the "wrong" way. They make them beautiful gems, with subtle properties, like deep binding, first classness of arbitrary objects, dynamic vs lexical variables, multiple inheritance of potentially overloaded methods, etc. These tiny, balanced, sparkling works are some computer scientists' pride and joy, but their subtleties escape the junior high school graduate trying to put together a quick application.

Truth and beauty may make you feel good, but realize that your truths, your beauties, mean nothing to the vast majority of the computer *user* out there. Sure, you can communicate in a spoken language with 300 words, but you're reduced to cumbersome circumlocutions. Having 5000 words -- some of which mean nearly the same thing as each other -- yield much greater freedom of expression.

You're suffering from delusions of clinically committable magnitude if you begin to think for one moment that anything as counterintuitive to the kid off the street as Forth -- or Lisp for that matter -- has a chance of actually gaining sufficient acceptance and widespread use to become a the cyber lingua franca you're looking for. Even RMS in his guise as the Avatar of the Lisp God has realized the severe limits of raw Lisp's accessibility to the masses; be not quick to discard Richard's notions in that particular area.

The problem is, you see, is that quite simply, you're designing the wrong languages for the wrong crowd. Ousterhout is more right about the Law than most in their Ivory Towers here seem to care to admit: the people will use gleefully only that which comes easy to them, and these languages will drive out the others. If you force something strange down their throats, they'll choke; witness how many high school students use Scheme instead of BASIC. John's also right that while we would-be scholars casually sit here debating the number of angels who might dance upon the head of a pin, we're on the verge of being overrun by marauding Mongols whose monetary and thus marketing might constitute a force with which we cannot begin to reckon: that is, Microsoft -- and Visual BASIC -- are coming.

Before you start redesigning languages that many, many people find perfectly acceptable and proven utility, you would do well to better remember these uncounted multitudes out there who are already using to their satisfaction those extension languages you are so quick to discredit. These people are even less apt to grab up gnuscript than someone with a dozen years of strictly BSD sysadmin experience has of cheerfully downgrading from SunOs to Solaris. Whether it's good or bad is immaterial; it's different, and all stable systems resist change.

Furthermore, you cannot in some miraculous wink of an eye catch up to the hundreds of thousands of manhours of testing and refinement that those languages which you (or more properly RMS, I should probably say) hope to supplant have undergone. You must commit a commensurate investment of time and trauma to reach a similar level of sophistication. And even thought this should be done, nevertheless it will inevitably suffer from a sinister onus of mistrust analogous to that suffered in the initial releases of Solaris, one which to a not inconsiderable extent persists still, irrespective of any measure of its technical merit.

I note that to this day, it's still faster to run s2p on a complex sed script and send it through perl than it is to send it through GNU sed. One cannot but wonder what ramifications that this small data point might well portend for gnuscript.

Mind you, it is not my intent to suggest that one blithely foist off some shoddy language on the world just so that the whole world might find itself sufficiently technically astute (that is, barely at all) to make use it. I don't believe that having a language sufficiently straightforward that anyone can program in it after nothing but a few simple hours of intruction necessarily precludes its potential as a fundamentally solid work lending itself to the necessary goals of reliability, extensibility, and eventual optimization. You can permit a longer learning curve if you want to attain those lofty goals so cherished by computer language theorists, but you MUST make it perfectly usable for those willing to travel never more a short way along that path .

:> I guess all we need is a elisp-to-perl (or is that scheme-to-perl)
:> translator now and even rms will be happy. :-) (Someone else reports
:> working on a tcl-to-perl translator already, but progress is slow.)
:
:I don't think that you're going to get a good translator from any of these
:data-driven languages to a procedural language any time soon. Run-time
:manipulation of code is too much a part of what makes them interesting.
:And it's also too much a part of what makes them useful extension
:languages.

I disbelieve. While it's true that the intensely lexical nature of tcl present interesting challenges for the person trying to generate cold, frozen machine code, that doesn't stop them from working on it. But I was never talking about such a thing. I'm perfectly content to interpret data as code from perl. In fact, I've had highly successful experiences writing and using programs whose extension and configuration language was in fact perl (albeit with certain per-program conventions, of course). [See the "clip" program, just to name one.]

But perhaps you can I have a different idea of just what precisely constitutes a data-driven language or program.

When it comes to lisp or tcl, while the extensive run-time nature of those languages make machine language generation (at least of certain constructs) difficult, compiling them into native perl (probably with a run-time emulator library) should in theory present no insurmountable hurdles. I'm not necessarily saying it's worth doing: just that I fail to understand your reasoning for discounting its likelihood and technical feasibility in what would otherwise appear to be an out-of-hand and little considered fashion.

--tom
-- 
Tom Christiansen      Perl Consultant, Gamer, Hiker      tchrist@mox.perl.com
"Umm, square root of two?  Ouch!"
--The guy who blew a hole in the Pythagoreans' assertion that all numbers can
   be represented as a ratio of two integers, so they killed him

From: sriram@tcs.com (Sriram Srinivasan)
Newsgroups: comp.windows.x.motif,comp.lang.tcl
Subject: Re: Should I use Tcl/tk or Motif
Date: 2 Feb 1995 00:50:25 GMT
Organization: Teknekron Communications Systems, Berkeley, California
In article <3gofh4$i2k@cronkite.cisco.com>, fjiao@fjiao-ss10.cisco.com (Fan Jiao) writes:
: I don't think there are much comparisons between Motif and Tcl/Tk.

I thought I should put in my 2c. worth on this, in support of Tcl/Tk

: First of all Tcl is an interp. lang so it runs slower than compiled 
: programs especially if you are using a RISC machine.

This is debatable. TCL is interpreted, but all the UIs I have seen with Tk seem to come up at least as fast as eqvt. Motif screens, if not faster. Take a look at Ptolemy, or SimCity for Unix. These have fairly complex UI requirements, but performance is not an issue (at least because of TCL). TCL is used as a glue language to set up the different widgets, and the idea always has been that the majority of the time is spent executing C code.

: Secondly, Tk is not Object-Oriented - Motif is, although both are 
: implemented in C. For example in Motif, one can implement a customized dialog 
: by subclassing it from either XmFormDialog or XmPromptDlalog.

Just because it has inheritance doen't mean much . The question is , what does it take to build a custom dialog? I do the same thing in Motif that I do in Tk - use composition. If anything, I find it far more easy to write a widget in Tk than to write a corresponding one in Motif. Strings such as "inheritance", "object-oriented" don't mean much - simplicity of usage and extensibility do.

Incidentally, there is an extremely nice object-oriented extension available for TCL, called "incr TCL", which has become a standard of sorts within the TCL community. There are a number of compound-widgets available using this extension.

: Moreover, Tk is built on top of X, not Xt - that prevent one to use any
: good public domain Motif widgets in Tk. And one cannot use Tk widgets in
: Motif either. Tk is not "Open Architecture".
: 
: With Motif 2.0, one would get much more functionalities, much more C++ 
: support, and much more stable code - one won't look back for Tcl/Tk.
: 
: Enclosed please find some other interesting e-mail about Tcl.

["Interesting" stuff deleted]

  • I'd like to know your definition of "Open". It is true that the two widget sets don't co-exist, but the implication above is that Tk is not open, but Motif is. How so ? Xaw and Motif are both Xt based widget sets, but they don't coexist too well themselves. Moreover, Tcl and Tk are free, and in my book, as open as Xaw is, in this regard.
  • Tk has tonnes of public domain widgets, including a pretty decent canvas widget, and an excellent text widget.
  • What does "much more functionalities" mean here ? The fact that the Motif text widget gets to do compound strings ? Or that there is a combo-box ? What does "much more C++ support" mean ? One can subclass from the Primitive and Manager classes, but what does one do if one wants to subclass from existing widgets ? - Compare Tk4.0 with what Motif 2.0 provides. Motif is still catching up.

From the list of interesting material that you provide, your complaint seems to be with TCL primarily. You should compare Tk development with Motif development. Performance should not be an issue, if you consider that TCL is intended to be a glue language - one is not expected to write entire applications in TCL. Even if one does so, there are enuf respectable applications that are written completely in TCL/Tk that have good performance. Compare xman and TkMan. Lemme know what it would take to write TkMan's functionality using Motif.

I do apologize if the above stuff sounds harsh - the fault lies is in the choice of words, not in how I feel or intend. I would be interested in hearing more arguments about Motif vs. Tcl/Tk.

Thanx.

Sriram (sriram@tcs.com)


Newsgroups: comp.windows.x.motif,comp.lang.tcl
From: mh@roger.wx.gtegsc.com (

Michael Hoegeman

) Subject:

Re: Should I use Tcl/tk or Motif

Organization: GTE Government systems Date: Thu, 2 Feb 1995 04:42:51 GMT

In article <3gofh4$i2k@cronkite.cisco.com>, fjiao@fjiao-ss10.cisco.com (Fan Jiao) writes:

|> I don't think there are much comparisons between Motif and Tcl/Tk.

You can say that again. Motif pales in comparison ;-)

|> I have been doing Motif since '90 and just finished one project using
|> Tcl/Tk.
|> 
|> First of all Tcl is an interp. lang so it runs slower than compiled 
|> programs especially if you are using a RISC machine.

Tcl runs slower than C but for the type of stuff you use Tk for (namely creating and manipulating X widgets) I don't think you can demonstrate to me or the anyone else an appreciable run-time difference. This is open for endless debate but just keep in mind that Motif isn't exactly lean and mean speed-wise either. Do you really think that Plowing through endless X Resource database records isn't all that far removed from "Interpretation"?

|> Secondly, Tk is not Object-Oriented - Motif is, although both are 
|> implemented in C.

Calling Motif "Object-Oriented" is being very liberal minded of you I think. The Xt widget system was the first toolkit created for X and it's really showing it's age. Xt is dead. Not only is dead, it's starting to smell real bad too.

I grant you that there are some very primive object oriented concept's in the Motif toolkit. However, when you actually get around to trying to use them in practice, they are a complete headache.

I have written C based widgets in both Tk and Motif and from my personal experience I think it's easier to write them with the Tk toolkit. I'm willing to account for personal tastes and say it's equally hard to write widgets in both of them though. The Real difference in my mind is that it's rare that you actually have to write a Tk widget in C. And when you do have to write one it automatically works in harmony with all the other Tk widgets. If a write a graphing widget i can use it in canvas widget or inside a text widget or I can place it in a dialog etc.. etc..

|> For example in Motif, one can implement a customized 
|> dialog by subclassing it from either XmFormDialog or XmPromptDlalog.

The question that counts regarding things like customs dialogs is

"How easy is it to make my own flavor of form Dialog or Prompt Dialog"

And the answer is that in Motif it's pretty darn hard whereas in Tk it's pretty easy. It takes you lots of C-code to "subclass" a dialog and endless tinkering to get it right. To be honest with you, I fail to see how it is a superior solution to composing a 50 line Tcl/TK script.

Unfortunately, you have seem to missed entirely the "Tk way of doing things" The way the Tk allows you to create your own dialogs and such is through *composition*. All the Tk Widget's are designed to be composed in any arbitrary combination with one another. The scrollbar is designed to be composed seamlessly in conjunction with a graphics canvas, or a entry widget or a text widget or any other widget you care to use it with.

|> Moreover, Tk is built on top of X, not Xt - that prevent one to use any
|> good public domain Motif widgets in Tk. And one cannot use Tk widgets in

I have seen very little available in the way of good public domain widgets written for Motif. There are some commercial ones that seem useful but even there I would not say the cup runneth over with such offerings.

|> Motif either. Tk is not "Open Architecture".

You have a very strange notion of "Open architecture". The Tcl/Tk source is freely available. The Developers of Tcl/Tk Have a very open dialog with users right here on comp.lang.tcl and at the yearly tcl conferences. When I encounter bugs in Tk/Tcl and I send in patches to fix them they show up (usually in the next release) It'll be a cold day in Hell when I ever get that out of the Motif boys. Given all this, maybe you can enlighten me on how Motif is more "Open" than Tk.

|> With Motif 2.0, one would get much more functionalities, much more C++ 
|> support, and much more stable code - one won't look back for Tcl/Tk.

Your vacuous assertions seem to to know no bounds. Simply stating that Motif has "much more functionalities" and "much more C++" support does not magically make it so. If you're going to make such claims, at least a feeble attempt at justifying them would be in order I think.

------------------------------------------------------------------------------
Mike Hoegeman               email: mh@wx.gtegsc.com  tel: (818)706-4145
GTE Weather Systems Group   31717 La Tienda Dr, Westlake Village CA. 91359

From: bet@std.sbi.com (Bennett Todd)
Newsgroups: comp.lang.tcl
Subject: Re: Tk without Tcl
Date: 13 Jan 1995 23:08:24 GMT
Organization: Salomon Brothers, Inc.

In article , Mark Friedman wrote:

>In article <3ek5tl$4uc@smlinews.Eng.Sun.COM> ouster@tcl.eng.sun.com
>(John Ousterhout) writes:
>
>   I'd phrase it just a bit differently.  My view is that much of Tk's power
>   has come from its association with Tcl.
>
>My view is that Tk is a nice, highly available GUI library. In
>concept, all it seems to get from Tcl is a language for callbacks and
>the use of Tcl variables for text variables. It seems clear that, in
>priciple, another langauge could provide the same things pretty
>easily.

I used to feel that way also. But now I've looked at STk, tkintr, and tkperl (the Perl5 version), and damn me if they don't all have one loathesome feature in common: simple programs are much harder to read and understand, much harder to modify, much harder to debug by inspection, than in Tk+TCL, because _everything_ you do is cluttered with many more punctuation marks.

I've seen another example that seems to reflect the same point: the only other language kit I know of that offers comparable functionality to Don Libes's "expect" is Randal Schwartz's chat2.pl, and again, it's so much more cluttered with punctuation that code using it is much less clear.

I think there are jobs for which TCL is the best language invented to date, and I think that Tk and expect are terrific examples. So far, efforts I've seen to bind Tk onto other languages have failed to preserve Tk's beautiful source-code clarity and ease-of-use; as long as this remains true, I can't see getting too worked up about reorganizing the primary Tk library release in a move to partition it from TCL. What's the point, if TCL-free uses are all gonna be so much more cumbersome and ugly?

-Bennett bet@sbi.com


From: sriram@tcs.com (Sriram Srinivasan)
Newsgroups: comp.windows.x.motif,comp.lang.tcl
Subject: Re: Should I use Tcl/tk or Motif
Date: 2 Feb 1995 00:50:25 GMT
Organization: Teknekron Communications Systems, Berkeley, California

In article <3gofh4$i2k@cronkite.cisco.com>, fjiao@fjiao-ss10.cisco.com (Fan Jiao) writes:

> I don't think there are much comparisons between Motif and Tcl/Tk.

I thought I should put in my 2c. worth on this, in support of Tcl/Tk

> First of all Tcl is an interp. lang so it runs slower than compiled 
> programs especially if you are using a RISC machine.

This is debatable. TCL is interpreted, but all the UIs I have seen with Tk seem to come up at least as fast as eqvt. Motif screens, if not faster. Take a look at Ptolemy, or SimCity for Unix. These have fairly complex UI requirements, but performance is not an issue (at least because of TCL). TCL is used as a glue language to set up the different widgets, and the idea always has been that the majority of the time is spent executing C code.

> Secondly, Tk is not Object-Oriented - Motif is, although both are 
> implemented in C. For example in Motif, one can implement a customized
> dialog  by subclassing it from either XmFormDialog or XmPromptDlalog.

Just because it has inheritance doen't mean much . The question is , what does it take to build a custom dialog? I do the same thing in Motif that I do in Tk - use composition. If anything, I find it far more easy to write a widget in Tk than to write a corresponding one in Motif. Strings such as "inheritance", "object-oriented" don't mean much - simplicity of usage and extensibility do.

Incidentally, there is an extremely nice object-oriented extension available for TCL, called "incr TCL", which has become a standard of sorts within the TCL community. There are a number of compound-widgets available using this extension.

> Moreover, Tk is built on top of X, not Xt - that prevent one to use any
> good public domain Motif widgets in Tk. And one cannot use Tk widgets in
> Motif either. Tk is not "Open Architecture". 
> With Motif 2.0, one would get much more functionalities, much more C++ 
> support, and much more stable code - one won't look back for Tcl/Tk. 
> Enclosed please find some other interesting e-mail about Tcl.

["Interesting" stuff deleted]

  • I'd like to know your definition of "Open". It is true that the two widget sets don't co-exist, but the implication above is that Tk is not open, but Motif is. How so ? Xaw and Motif are both Xt based widget sets, but they don't coexist too well themselves. Moreover, Tcl and Tk are free, and in my book, as open as Xaw is, in this regard.
  • Tk has tonnes of public domain widgets, including a pretty decent canvas widget, and an excellent text widget.
  • What does "much more functionalities" mean here ? The fact that the Motif text widget gets to do compound strings ? Or that there is a combo-box ? What does "much more C++ support" mean ? One can subclass from the Primitive and Manager classes, but what does one do if one wants to subclass from existing widgets ?
  • Compare Tk4.0 with what Motif 2.0 provides. Motif is still catching up.

From the list of interesting material that you provide, your complaint seems to be with TCL primarily. You should compare Tk development with Motif development. Performance should not be an issue, if you consider that TCL is intended to be a glue language - one is not expected to write entire applications in TCL. Even if one does so, there are enuf respectable applications that are written completely in TCL/Tk that have good performance. Compare xman and TkMan. Lemme know what it would take to write TkMan's functionality using Motif.

I do apologize if the above stuff sounds harsh - the fault lies is in the choice of words, not in how I feel or intend. I would be interested in hearing more arguments about Motif vs. Tcl/Tk.

Thanx.

Sriram (sriram@tcs.com)


From: berson@cs.pitt.edu (David A. Berson)
Newsgroups: comp.lang.perl,comp.lang.tcl
Subject: Re: Perl?  Or tcl?  Which to use for what?
Date: 17 Feb 1995 14:03:14 GMT
Organization: Univ. of Pittsburgh Computer Science

Mike Campbell (mcampbel@offenbach.sbi.com) wrote:

> My question is, what *types* of problem sets would tcl be a clear winner over
> perl?  (And which for perl over tcl?)  I know both are good at a LOT of things,

> Can anyone tell me where tcl has facilities which are clearly easier to use
> than in perl, and which facilities in perl are not it tcl?

I have used tcl as an optional interactive testing harness for the implementation of my research. I.e., I have a couple of C files that interface tcl to functions and variables in my program. Thus, I can set variables and call functions to test specific conditions in my program. Since this test harness is optional, my program should not know about tcl's copies of variables.

Once I get the bugs worked out of my code I need to run a bunch of benchmarks, varying alot of parameters and such. I would like to switch the test harness to perl because I prefer script writing in perl to tcl, probably because I'm a C programmer at heart and perl's much closer than tcl.

There are three things currently holding me back from switching to perl:

  1. Tcl has much more of a imperative command feel to it, which is better for testing purposes. I also use gnu's readline/history library to provide command line editting before I pass the commands to tcl. I haven't figured out the most comfortable way to retain this feel in perl. I'll probably write a little command line module and swith between it and full perl scripting.
  2. Tcl allows call back functions for its variables. This allows you to keep the program's copies of variables in sync with tcl's copies, as well as implement variables that are read-only to tcl. I have had some problems retaining the callback links when tcl variables get deleted and readded. To keep variables in sync with perl I have only come up with calling special sync functions in the api when going in either direction between perl and C. I don't see an easy way to implement read-only variables in perl, but this is not critical.
  3. I'm not sure how much time must be invested to get up to speed on perl's api. I've read the man pages, but haven't had the time to play with it yet.

Any comments or suggestions welcome.

David. berson@cs.pitt.edu


From: Dean Sheehan 
Subject: Re: Object Tcl & [incr Tcl]
Date: Wed, 8 Mar 1995 12:24:56 GMT
Organization: IXI Limited

Hoshi Takanori wrote:

> I just posted a question:  What is the difference between Object Tcl and
> [incr Tcl]?  Especially, I want to know if otcl is faster than itcl, and
> if it is easy to port itcl scripts to otcl.

Object Tcl faster than [incr Tcl]?

Well, the first implementation of Object Tcl incurred about 60% LESS than the [incr Tcl] overhead but it turns out that the overhead of both Object Tcl and [incr Tcl] is very small compared to the Tcl consumption.

B1.0 of Object Tcl is a complete re-write and I haven't performed any comparisons between Object Tcl and [incr Tcl] but I would expect it to have changed too much.

As Object Tcl is designed to support inheritance from C++ (see below) classes then it becomes trivial to move classes into C++ for performance gains.

The general differences are:

        o       Object Tcl is designed to support the specialisation of
                C++ classes in Tcl (OO Tcl that is).

                a C++ class like:

                class Animal
                {
                public:
                        virtual void makeNoise (void);
                        void foodTime (void);
                };

                can be exported to the Object Tcl system using a
                class description of

                class Animal {
                        method makeNoise -dynamic {void} {void}
                        method foodTime -static {void} {void}
                }

                Animal C++ class and the C++ code generated by the Object Tcl
                CDL processor can be linked with tclsh and then:

                otclInterface Dog -is Animal {
                        method makeNoise {}
                }
                otclImplementation Dog {
                        method makeNoise {} {
                                puts "Bark, bark"
                        }
                }

                %set a [otclNew Dog]
                %$a foodTime
                Bark, bark
                %

                If the $a object was passed back into C++, C++ could call
                a->foodTime() and "Bark, bark" would still be printed.

        o       Object Tcl supports management of C++ classes.

                From the example above in Tcl you could
                % set a [otclNew Animal]
                % $a foodTime

        o       Object Tcl makes it trivial to export C++ classes
                to Tcl.

        o       Object Tcl is a standard extension to Tcl, it can even be
                dynamically loaded (after a little hack on the Beta, next
                version should support it directly).

Is it easy to turn [incr Tcl] classes in Object Tcl classes?

Well that depends on how many unusual features of [incr Tcl] you use. Object Tcl supports all of the standard OO concepts but its syntax is obviously different from [incr Tcl]. [incr Tcl] provides some features that wouldn't be considered standard OO. For example, the configure method on [incr Tcl] classes.

I haven't tried to port an [incr Tcl] script to Object Tcl.

Finaly, Object Tcl is not pitched as a replacement for [incr Tcl] but if you want cool C++ integration...

- Dean

___________________________________________________________________________
 __  __ __  __
|  |\  /  /|  |  Dean Sheehan        Vision Park      Email: deans@x.co.uk
|  | \/  / |  |  Software Architect  Cambridge
|  | /  /\ |  |                      CB4 4ZR          Tel: +44 1223 518034
|__|/__/__\|__|  IXI Limited         England          Fax: +44 1223 518001
___________________________________________________________________________


Newsgroups: comp.lang.tcl,comp.lang.python
From: danj@netcom.com (Dan Janowski)
Subject: Opinions? Tcl Python Perl, Virtues/failings
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Wed Mar 29 22:12:15 PST 1995

I almost hate to pose this question because of the possible flaming thread that it may produce, but alas, I must.

Simply, it has been asserted that the fact that Tcl is 'typeless' is a 'problem', mostly for reasons of speed, and that it has some syntactic failings (no a=1, $ to use variables, and such). Interp speed, although theoretically significant, has not bit me in any way that I couldn't take care of with a C binding. The lack of a=1 syntax attests to the regularity of the languange, every evaluated 'line' begins with a command, like 'set'.

The non Tcl packages have Tk 'ports' but it somehow seems contrived. Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It looks like a language of regexps, seems messy, hard to read. Python, seemingly new in the fray, is interesting but has a wierd indention scheme for block definitions (while, for, if, etc). Both of them seem to suffer from many 'implied' operations and results. From a coding standpoint, the word basis of Tcl operations, as opposed to %^@: characters, means that the code is actually readable. Having named commands that do operations is a GOOD thing, as opposed to relying on non-alpha characters.

My opinion is that all of these interps are for prototyping and growth applications that may become partially or completely compiled at some point. Fast, easy to remeber, english coding means less time is spent on being clever and more on the idea. Tcl seems to fit this notion more than Perl or Python.

Opinions?

-- 
danj@netcom.com         |
Dan Janowski            | :-(insert witty comment here)
New York, NY

From: Ken Manheimer 
Cc: python-list@cwi.nl
Subject: Re: Opinions? Tcl Python Perl, Virtues/failings
Date: Thu, 30 Mar 1995 12:29:54 -0500 (EST)

Dan Janowski (danj@netcom.com) wrote:

> I almost hate to pose this question because of the possible flaming
> thread that it may produce, but alas, I must.

Well, i have a sick day here, and the topic is a dear one to my heart, so i'd like to take a few moments to address it.

The relative virtues of these languages is an important question. Also, certainly, it is a complex one, difficult to address because it is so much easier to get a focus on the more superficial issues - syntax, simplicity of trivial programs, speed - than on the deeper, more stuctural issues - semantic power, data abstraction, management of complexity - that the dialogue can quickly become meaningless.

The real question, in my view, is, which languages provide the biggest payoffs for effort invested? The issue of payoffs has different components for different people. However, one component that is always important for me, and one that i think transcends most application boundaries, is integratibility. When you build a system or a tool, will you be able to use it for more than just a single application?

Will you be able to use all your tools together, gaining more leverage as you go, or are you always starting from scratch? Will you be able to go back and directly use, or indirectly adapt, code you have already developed for other purposes? I think python is the big winner in this regard. (I happen to think it is the big winner, in the scripting/extension domain, in most regards, but that's a whole nother story.)

> Simply, it has been asserted that the fact that Tcl is 'typeless' is a
> 'problem', mostly for reasons of speed, and that it has some syntactic

Tcl's "typelessness" is a serious issue, and issues of speed are the most extremely superficial ramifications of it. The real problem has to do with data abstraction - tcl does not adequately provide it unless you create your own special extension data types, and then you sacrifice the integration benefits that come with native data types.

When i explored tcl, i tried some substantial programming in it - a dns domain cataloguer - and i found myself needing a simple nested data structure. The problem is, i could *not* directly construct it in a manageable way. Ie, as best i recall, i had to use indirection through variable names, because eg nesting an array within an array is really just putting a string within a string, and the boundaries can be lost depending on the data. This is NOT NOT NOT adequate.

Of course, you *can* create your own extension data types in tcl, to accomplish this kind of thing. However, this sacrifices the generality of powerful data types that are native to the language.

Either you build extensions to implement your own fundamental structuring mechanisms, inventing extrinsic rudiments that ought to be intrinsic. Or you make disparate extension structures for each system you develop, and arrive at type-discrepancies that prevent good integration of the systems with eachother. In either case you sacrifice the ease and cleanliness of well-reconciled, native data structuring mechanisms, something which python offers to a profound degree.

In my opinion, the lack of simple but sophisticated native data structures is one of the main impediments to building clean, large systems with tcl. That, together with the excessively rudimentary scoping mechanisms, convinced me that the effort necessary to do substantial things with the language would not nearly pay off in the integratibility i need from my tools.

People say it is a simple language, i suggest it is simplistic, the distinction being that it is handy for doing very simple things, and not handy for doing less than simple things.

> The non Tcl packages have Tk 'ports' but it somehow seems contrived.

That's about as vague a criticism as i could imagine. I mean, the ports **are** contrived - contrived to implement the tk functions in the other languages. Question is, were the contrivances successful? I've only been fooled with, not done any substantial things, with tk and tkinter. (I have done very little with perl, in general.) I have the impression that they're both very effective, with tkinter having the benefit, in my perspective, of being python...

> Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It
> looks like a language of regexps, seems messy, hard to read. Python,

As i said above, i have done very little with perl.

When i first looked at it (twice, really, once during perl 3 and once during perl 4, i think), i was very daunted by the complexity of the language, and the difficulties in nesting data structures. (I have a feeble memory, in some ways, and the apparent burden on the programmer of using different operations to accomplish the same thing, depending on the object data types, was very daunting.) Evidently, perl 5 addresses the nesting problem, but still seems overly complex to me.

Even supposing the complexity to be a misperception on my part, the reknowned difficulty in reading and adjusting established perl code, even your own code, betrays my integratibility criterion...

> seemingly new in the fray, is interesting but has a wierd indention
> scheme for block definitions (while, for, if, etc). Both of them seem

Have you tried the language's indentation scheme, for any substantial purposes? It certainly is different. You may find it to be an improvement, as most people do who give it a real try.

> scheme for block definitions (while, for, if, etc). Both of them seem
> to suffer from many 'implied' operations and results.  From a coding

Not certain what you mean here by "implied operations and results", but i do know that you need to be well acquainted with python class object's intrinsic special disciplines (__init__, __add__, __del__, etc) before you can be confident using these objects. However, there's a ton of stuff you can do with python without even touching class objects, that i consider to be extremely simple and straightforward.

> standpoint, the word basis of Tcl operations, as opposed to %^@:
> characters, means that the code is actually readable.  Having named
> commands that do operations is a GOOD thing, as opposed to relying on
> non-alpha characters.

The "word basis" of tcl operations breaks down pretty quick. What about:

	[expr {($hostsNoticed > 1) ? "s" : ""}]

The string-nature of the native types in tcl drives me *crazy*, when it comes to distingushing structure from syntax. Granted, this doesn't come up with simple structures holding simple data. But it is a real world problem when it comes to real tasks and real world data.

(I also happen to be uncomfortable with a lot of C's syntax, which shows up more or less in all these scripting languages, but i'm probably in the minority on this in the Unix world. Sigh.)

> My opinion is that all of these interps are for prototyping and growth
> applications that may become partially or completely compiled at some

Actually, i think the relative prominence of compiled languages will be decreasing as we continue into the network age, where passing code across the wire increasingly makes the network the computation (to warp a phrase:).

> point. Fast, easy to remeber, english coding means less time is spent
> on being clever and more on the idea. Tcl seems to fit this notion more
> than Perl or Python.

I see nothing "english" about tcl coding. It uses words, but so do most natural languages. Tcl's phrase structure is almost non- existent, in marked contrast to any modern spoken language. Most importantly, the structure is simplistic, in ways that become unwieldy when the ideas you are trying to express - the algorithms - are anything more than extremely simple. This is not a virtue.

I realize that the simplicity of tcl *is* a real virtue for some applications. Have you tried doing some substantial things with each of the languages? If not, i would be interested to hear what your opinion is once you have gotten a feel for their relative versatility...

Thanks for your indulgence,

ken
ken.manheimer@nist.gov, 301 975-3539


From: Ian S Nelson 
Newsgroups: comp.lang.tcl,comp.lang.python
Subject: Re: Opinions? Tcl Python Perl, Virtues/failings
Date: Thu Mar 30 20:22:30 PST 1995
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.python: 30-Mar-95 Opinions? Tcl Python Perl, .. by Dan Janowski@netcom.com

> I almost hate to pose this question because of the possible flaming
> thread that it may produce, but alas, I must.
>  
> Simply, it has been asserted that the fact that Tcl is 'typeless' is a
> 'problem', mostly for reasons of speed, and that it has some syntactic
> failings (no a=1, $ to use variables, and such).  Interp speed,
[...etc...]

Well my feeling on the subject is this: I'm not terribly fond of perl, it's kind of neat and it does some great things for people, but it's not my cup of tea.

TCL is pretty cool, it's on just about everthing, you can even do gui stuff on a lot of machines (not OS/2 yet...) Byte and the other rags are billing it as a key piece of "agents" and the 411-interstate... I would definitely keep an eye on it.

Python is really cool in my book. It's just like C, at least to me it is; and that's a very good thing, C and I have been together ever since pop bought MS C 2.0 for that ancient XT back in the glory days. Python picked up really well. It is also well suited for objects, OOP/D is one of my favorite things and it makes life really easy. There is also a large number of tools in the library which makes it that much more attractive. It doesn't have tha fame of TCL, but it's really cool. The OS/2 support isn't the greatest, but it's not too bad. Pretty good for prototyping and stuff like that.

Then there is REXX and Java. I've always been bothered by the small amount of ligt REXX is given, it's a really powerful language for scripting, complete with new object ready versions and IBM supports it left and right. Java is Sun's brand new thing that I've been hearing about everywhere. It sounds like it's going to be big, but only time will tell...

I could go on... The biggest problem with Perl, TCL, Python, etc. is that there are so many interpreted languages that are supposed to fit that "prototyping/batch/scripting" role. They all have a lot of things in there favor and a lot of them have huge weaknesses (I looked at this one perl for about half an hour, it was only 30-40 lines and I couldn't figure out how it was working.) My advice is this, they are all fairly simple to learn and use; find one you like, use it, if it becomes obsolete or something learn a new one. If you are starting a project that is long term and fairly important, I think you might be better off with a compiler and some good ANSI C++ or Ada or something. If you are just doing simple/small stuff, then jsut use what you like.

--
Ian S. Nelson                    finger for PGP key
Carnegie Mellon Computer Science/Math    
Home Page:http://www.contrib.andrew.cmu.edu/usr/in22/ian.html
My opinions are not the school's, although they should be!

From: lutz@kapre.com (Mark Lutz)
Subject: Re: Opinions? Tcl Python Perl, Virtues/failings
Organization: KAPRE Software, Inc., Boulder, Colorado
Date: Fri Mar 31 09:19:18 PST 1995

This is one of those hopeless religious arguments that always come down to a matter of taste. But since you asked (and since I've got way too much time on my hands waiting for C++ builds! ;-), here's a few opinions from a Python perspective. All IMHO of course:

- READABILITY. Python's easier to write and read. It has a simple statement-based, procedural syntax. Here's an example which intersects 2 sequences:

      def intersect(item1, item2):
          result = []
          for x in item1:
              if x in item2: result.append(x)
          return result

Here, item1 and item2 can be any sequence data type (lists, strings, user-defined classes, C extension types,..).

- SEMANTIC POWER. Python's also usually considered more powerful than TCL, yet applicable to the same problem domains -- extension-language work, shell scripts, prototyping, etc. It's a step-up from TCL as a language, but still has great interfaces to/from C (dynamic loading, C modules act just like Python ones,..).

Python's an object-oriented language, and has powerful built-in data and program structuring tools -- lists, dictionaries, modules, classes, exceptions,... For instance, if 'intersect' above were a class's method, we could overload the '&' operator to run it; we could also speed it up by using dictionaries, make it more generic...

Here's a more relevant example: a simple Tk program in Python which puts up a window with a single button [this could be more compact]:

      from Tkinter import *                     # get the Tk module
 
      class Hello(Frame):                       # subclass our app
          def __init__(self, master=None):
              Frame.__init__(self, master)
              self.pack()
              self.make_widgets()
 
          def make_widgets(self):
              self.hello = Button(self, {'text': 'Hello GUI world!',
                                         'command' : self.quit})
              self.hello.pack({'side': 'left'})
 
      Hello().mainloop()

- TRY IT, YOU'LL LIKE IT... Have you ever tried Python? For instance, indentation syntax turns out to be pretty handy in a rapid-development language, and is an implicit quality-control feature (whatever that means :-).

Because of its features and readability, Python can be better than TCL for non-trivial tasks. Like all dynamic languages, Python may not be the best tool for delivery of large, static components. But it's great for 'front-end' type tasks in mixed/hybrid systems, as a prototyping tool, etc. For example, I'm currently using it as an extension language for on-site customization of C++ binaries.

But examples beat words: I've tacked-on another example below, from a module that redirects standard input/output streams to instances of classes that simulate files; probably not the best example, but enough to illustrate some distinctions between TCL and Python.

Again, YMMV on all of this. And to be fair, Python's borrowed the Tk tool-kit, a TCL-land invention. But I'd encourage you to have a look at Python before closing-the-book.

Mark Lutz
lutz@kapre.com

# file (module) redirect.py
# part of an example that redirects i/o streams to objects


import sys                              # load a module (python or C)

 
class FakeStream:                       # a class def
    def close(self):                    # its methods
        pass         
    def flush(self):
        pass          
    def isatty(self):
        return 0


class Input(FakeStream):
    def __init__(self, input):          # plus readline,...   
        self.text = input 

    def read(self, *size):
        if not size:
            result, self.text = self.text, ''
        else:
            bytes = size[0]
            result, self.text = self.text[:bytes], self.text[bytes:]
        return result 

 
class Output(FakeStream):
    def __init__(self): 
        self.text = ''

    def write(self, string):
        self.text = self.text + string         

    def writelines(self, lines):
        for line in lines: self.write(line)   


def testfunc(input, function, args):            # a function def
    save_stdio = sys.stdin, sys.stdout
    sys.stdin  = Input(input)                   # make instances
    sys.stdout = Output()
    try:                                        # catch errors here
        apply(function, args)                   # run the function
    except: 
        sys.stderr.write('error during function!\n')
    result = sys.stdout.text
    sys.stdin, sys.stdout = save_stdio
    return result                               # output as a string


Newsgroups: comp.lang.tcl,comp.lang.python
From: lwall@netlabs.com (Larry Wall)
Subject: Re: Opinions? Tcl Python Perl, Virtues/failings
Organization: NetLabs, Inc., Los Altos, California.
Date: Sat, 1 Apr 1995 08:49:37 GMT

In article , Kenneth Manheimer wrote:

: When i first looked at it (twice, really, once during perl 3 and once
: during perl 4, i think), i was very daunted by the complexity of the
: language, and the difficulties in nesting data structures.  (I have a
: feeble memory, in some ways, and the apparent burden on the programmer
: of using different operations to accomplish the same thing, depending
: on the object data types, was very daunting.)

For things you deal with all the time, this is actually somewhat of a benefit, because the different operations *look* different. Natural languages work this way too--the most ragged-looking parts of a language are usually the parts most used, such as pronouns, or forms of "to be". It's harder to learn, but then there are more visual distinctions to make use of later.

: Evidently, perl 5 addresses the nesting problem, but still seems
: overly complex to me.

There's the kind of complexity that maps naturally onto complex problems, and the kind of complexity that doesn't. Many of the changes in Perl 5 were actually to remove the second kind of complexity. Many language designers make the mistake of trying to avoid the first kind of complexity, and end up forcing the users to write more complex programs to make up for it. This is no fun.

: Even supposing the complexity to be a misperception on my part, the
: reknowned difficulty in reading and adjusting established perl code,
: even your own code, betrays my integratibility criterion...

Well now. I happen to see every reference to Perl that goes by on Usenet, and apart from the occasion slam-dunk quote from non-users about rot13 or uuencode, this "renowned difficulty" is simply not so renowned as all that. I don't think I've seen anyone complain that they couldn't come back and read their own code, unless they were being intentionally obfuscational to begin with (Hi Randal). And I've never heard anyone *not* complain about working on someone else's code. :-)

Frankly, I think it's easy to write beautiful code in Perl 5. But I may be slightly prejudiced in the matter...

Larry Wall
lwall@netlabs.com


From: Tom Christiansen 
Newsgroups: comp.lang.tcl,comp.lang.python,comp.lang.perl
Subject: Re: Opinions? Tcl Python Perl, Virtues/failings
Date: Sat Apr 08 08:42:28 PDT 1995
Organization: Perl Consulting and Training

In comp.lang.python, Ian S Nelson writes:

:I could go on... The biggest problem with Perl, TCL, Python, etc. is
:that there are so many interpreted languages that are supposed to fit
:that "prototyping/batch/scripting" role.  They all have a lot of things
:in there favor and a lot of them have huge weaknesses (I looked at this
:one perl for about half an hour, it was only 30-40 lines and I couldn't
:figure out how it was working.)  

Few and far between are the programming languages in which it is the least bit difficult to write code which is hard to read, debug, understand, and maintain. You should be judging the people writing the code, not the language. You're shooting the messenger (the language) rather than the message (the code as implemented).

As one trivial example, just because someone *can* write something like that looks like an obfuscated C contest entry:

    for(split(/:/,$ENV{'PATH'})){next if/^\.?$/;s![^/+]*$!man!&&-d&&
    !$s{$_}++&&push(@mp,$_);}print join(":",@mp),"\n";

Or even as a more reasonably indented

    for (split(/:/, $ENV{'PATH'})) {
        next if /^\.?$/; 
        s![^/+]*$!man! && -d && !$seen{$_}++ && push(@manpath,$_); 
    }
    print join(":", @manpath), "\n";

Or even a more reasonably structured:

    for (split(/:/, $ENV{'PATH'})) {
        if (/^\.?$/) { next; } 
        if (s![^/+]*$!man!) {
            if (-d and !$seen{$_}++) { push(@manpath,$_); } 
        }
    }
    print join(":", @manpath), "\n";

Doesn't mean that it isn't considerably clearer to write it more like this:

    @bin_path = split /:/, $ENV{PATH};
    @manpath = ();  
    foreach $path_component (@bin_path) {
        if (substr($path_component, 0, 1) ne ".") {
            $man_component = $path_component;
            $man_component =~ s{        (?# replace basename with "man"... )
                                [^/+]   (?# 1 char: neither plus nor slash )
                                *       (?# 0 or more of these things      )
                                $       (?# but only at the end            )
                            }{man}x;
            if (-d $man_component ) {
                if ( $already_seen{$man_component} == 0 ) {
                    @manpath = ( @manpath, $man_component );
                    $already_seen{$man_component} = 1;
                } 
            }
        }
    }
    $colon_separated_version = join ":", @manpath;
    print $colon_separated_version, "\n";

(The real code actually has regular comments in it as well.)

Those of you averse to $ and @ might think back to the many discussions of using Hungarian notation for variable naming, that is c_blah for character variables, i_blah for integer variables, s_blah for string variables, etc. It turns out that that's what perl's type indicators are doing: $ and @ are just singular and plural semantic markers, things which help a great deal in most languages. If you thing of letting $ mean "the" or "a", and letting @ as saying "these" or "some", it might all make more sense to you.

:My advice is this, they are all fairly
:simple to learn and use; find one you like, use it, if it becomes
:obsolete or something learn a new one.  

Well, possibly. The danger is that you might have gotten yourself in too deep. Languages can run out of steam. For example, appalled by the primitive and restrictive nature of the bourne shell and seduced by the built-in programming constructs in the korn shell, you write this 900-line ksh program and then find that it just doesn't have the datatypes, modularity, and control flow for what you really want to do. Or that the 27 little shell programs you called don't work when your program is fed unexpected data (long, binary, etc). Or that you can't scale your data set to two or three more orders of magnitude. This happens all the time in shell programming, and occasionally using the other languages mentioned here. It would appear to me that out-of-the-box python and perl have a better chance of scaling well on significantly larger programs and data sets than tcl does.

:If you are starting a project
:that is long term and fairly important, I think you might be better off
:with a compiler and some good ANSI C++ or Ada or something. If you are
:just doing simple/small stuff, then jsut use what you like.

Oh, I don't know about foisting C++ or Ada on someone that hastily. They have a much greater entry cost (how much you have to know about the language before you can use it effectively) than most attribute to them.

--tom
-- 
Tom Christiansen      Perl Consultant, Gamer, Hiker      tchrist@mox.perl.com

"Make is like Pascal: everybody likes it, so they go in and change it. "
            --Dennis Ritchie

From: Tom Christiansen 
Newsgroups: comp.lang.python
Subject: Re: python speed
Date: 4 May 1995 14:49:13 GMT
Organization: Perl Consulting and Training

In comp.lang.python, yosef@adsc.com (Yosef Gold) writes:

> I am looking into using python as an extension and scripting language.
> I need to know how it's speed compares to TCL and RUSH (the new TCL
> like complied language).  does anybody have benchmarks or personal
> experience comparing their speed.

Tcl, being strictly interpreted, is quite slow. Python, being byte-compiled, is much faster. For that matter so is perl, usually around the same speed as python or a bit faster for very unixy things. Rush on the other hand compiles into scheme, for which very efficient scheme-to-C compiles exist.

But that doesn't mean you should automatically choose rush. Speed is not always the most important criterion. These also matter a great deal, possibly more:

  • maturity of the language
  • how many users it has
  • how portable it is
  • how many extensions are available for it
  • how many built-ins or libraries are packaged with it standard
  • how sound a language design it is
  • how "standard" it is (what if any systems ship with it? why or why not?)
  • what support tools are available for it
  • how easy its api is
  • how responsive its author is to bugs

While tcl is quite popular these days (the python:tcl:perl popularity ratios is something like 1:5:12 or so) and meets many of these criteria, I believe that it is in the long term doomed as a general apps language (for which is wasn't even designed). Why? Because even if they do get a non-proprietary compiler for it, its underlying language design is still great for a macro processor and not so hot for a more serious applications language. tcl only flourished because its tk package filled a niche that perl and python didn't catch up to for a long time, long enough to allow a lot of tcl/tk apps to be written tht would have been better written in tk using perl or python for a base.

So unless you're designing your own new language for which tcl would be a nice language construction kit, I wouldn't look at it too seriously. Rush has certain interesting promises, but so far, it's still a research toy not a mature language in any sense of the word. I would say you should look at perl and python instead. Which of those two you end up preferring seems largely a matter of taste and prior experience/contamination: if you are comfortable and familiar with C and UNIX shell programming (as most UNIX systems administrators and many systems programmers are) then you'll probably choose perl over python, and perhaps the other way around.

If you're doing graphic stuff, both perl and python have nice tk interfaces (perl's is v4.0b3 tk; dunno on python.)

You can read about rush (and probably should) in a paper by on from the usenix vhll conference in santa fe, or probably by mailing its authors. It's got some interesting results, but please don't take it's performance numbers seriously: the benchmarks were designed to show what the authors wanted you to believe rather than making the tests first and then making decisions and surmisals. In particular, the perl numbers are off by about an order of magnitude too slow, and their analysis of language issues was sadly lacking. Adam Sah in particular appears to deeply Belieeeeve in scheme to the utter exclusion of real-world experiences and points of view. Adam was also Ousterhout's grad student before John left for Sun, so felt a bit burned by being deserted, and so has a bone to pick with tcl. Nonetheless, his technical points and criticisms about tcl are not inaccurate. He really didn't understand perl much when he wrote about it. Jon Blow, his co-author (and I believe the current rush maintainer) has more well, worldly, experience with it. I don't know whether either knows python now.

--tom
(pardon the typos; i'm on a keyboard that is kinda broken)
-- 
Tom Christiansen      Perl Consultant, Gamer, Hiker      tchrist@mox.perl.com
    OOPS!  You naughty creature!  You didn't run Configure with sh!
    I will attempt to remedy the situation by running sh for you...
        --Larry Wall in Configure from the perl distribution

From: jmc0@roger.gte.com (John Chambers)
Newsgroups: comp.lang.tcl
Subject: Re: perl script w/in Tcl
Date: 1 Jun 1995 21:08:37 GMT
Organization: GTE Laboratories
In article <3qkvpn$jil@superb.csc.ti.com> frazerw@dseg.ti.com writes:
>In comp.lang.perl, jmc0@roger.gte.com (John Chambers) writes:
>> It seems that I read recently that Perl5 was going to have all of the
>> tk library as builtins.  Is this true?  If so, I for one would be very
>> happy to drop tcl and start writing everything in perl.
> 
> Have you tried Embedded Tcl, etcl ? This enables straightfoward
> integration of C code with Tcl/Tk. I feel that this is _the_ way
> forward. Most people I meet who object to using Tcl/Tk because of
> performance arguments have problems arguing againt etcl.

Actually, speed is a minor concern. Most of our applications are limited by other things than wish's speed. For example, I have several scripts that display data gotten via SNMP, and the network turnaround on such requests is the major bottlenect.

My main reaction to tcl is that it's fine for a quick and dirty language; I've implemented such languages myself. Thus, I have a curses-based "form shell" that produces the usual sort of 2-d forms with fields of fixed text and fields that can be modified. Fields can have actions bound to them, and so on. The language has some cosmetic differences, but it's basically like tcl. It took me less than a day to write the interpreter. I've so far resisted the temptation to foist it on the world, because of a general distaste for the intractability of such languages. True, it's quite powerful, but for anything nontrivial, such languages tend to be very wasteful of human capital. I don't want to be stuck supporting one.

My main complaints about tcl aren't subtle or sophisticated. They are little things: It generally takes a lot of passes to get all the global declarations right. (In perl, the default is global and you need local declarations; this is much less error prone.) I've used up lots of passes getting all the initializations right. (In perl, variables appear by magic with null/zero values, which is almost always right.) I use a lot more passes inserting "if [info exists ...]" and "if [winfo exists ...]". (In perl, again everything appears when first used, so I don't waste my time or the interpreter's with trivial like {set foo ""; set bar 0}.) And I *always* have to look up lappend and the other list operators before using them, because of the difficulty of remembering which one is the weird one. (In perl, I haven't consulted the manual on list operators since the first week I used the language.) And as for regexp and regsub - don't get me going on how much time I've lost to *those* little monsters ...

So my complaints are the everyday, practical ones of what it takes to get a program running correctly. Perl and tcl are both interesting scripting languages. Tcl is simple, elegant, and powerful. Perl is large, semi-elegant, and powerful. I can remember perl and write code that is usually correct the first time. I just wrote a 70-line perl script that grovels thru some files picking off some names, starting subprocesses for each names, and then watching them and restarting any that die; it worked correctly the first time. I can't do such feats with tcl. And perl comes with an interactive debugger; tcl doesn't (though I need it in tcl much more than I do with perl).

In fact, I'd say that the -d option is the main argument that perl has going in its favor. If something similar were added to tcl, about half of perl's advantage as a practical tool would instantly disappear.

On the other hand, there's the neat little "rmt" program in the tcl book. I *alway* have it running here. If someone can produce a perl equivalent, it would be a giant leap forward for perl ...

> I have had great success with this toolkit and would recommend
> everyone at least have a look at it. Its certainly preferable to using
> a pseudo programming language like Perl5 with nasty object
> implementations and other clutter ;-)

Hmmm ... It seems to me that tcl has more than a bit of object-oriented stuff in its implementation. Not that I'm very doctrinaire there; you may have gotten the impression above that I'm more interested in the pragmatics than with the dogma. Both languages are theoretically quite interesting. But perl is a better everyday tool. What it lacked was a graphics capability, and tk looks like the most practical graphics package to pop up so far.

Gee, I sound like I really hate tcl. Hereabouts, my reputation is actually that of a tcl partisan. I've given lots of demos in which I type a wish command and then fill in a bunch of buttons and labels and entries on the fly; anyone with any experience with other graphics packages are duly impressed. My general summary has been that it's the best graphics thing going, but it has a lot of problems that may or may not be fixed in future releases. In particular, while it's easy to do very simple things, when you try doing anything sophisticated, it rapidly bogs down, and building reliable programs that interact correctly with unsophisticated users is far from easy.

-- 
John Chambers   
  The most important part of any research publication is the paragraph 
  near the end which begins with "Further research is needed ...".

From: thayer@news.cs.columbia.edu (Charles Thayer)
Newsgroups: comp.lang.tcl
Subject: Re: TCL/TK vs. Java
Date: 11 Jun 1995 16:30:49 -0400
Organization: Columbia University Department of Computer Science
> What are others impressions? Could not TCL/TK be integrated into
> WWW browsers as an alternative to JAVA (e.g. Safe-TCL?) etc.
My impression is that they solve different problems and have different features, however it would be nice to integrate the tk widgets and layout managers for the Java graphics classes (which are going to change soon anyway).

Experiences:

I've worked with tk-4, blt-1.7, and itcl-1.5 on a GUI under Unix. Tk is great because it integrates well with the c-code backend. I have to use itcl, because the gui is not small, however I'm definitely looking forward to [incr tk] to solve some of the problems I have with building widgets.

I'm also working on Web sites and java is well suited for doing graphics and Web type programming (some security, good portability, and a class system well designed for incremental building). It's very new though, and I expect lots of changes in the graphics class interfaces, the compiler, and the development environment (or lack thereof).

Commentary:

I thought about trying to get tcl/tk to work as a Web-programming tool, but the big problem is the dependence on X11. If one could draw into gifs instead, it would be great. One could imagine an interface to tk via clickable imagemaps, but it seems really ugly and difficult. Another alternative would be running a tk application in the X11R6 virtual framebuffer (which exists only in memory), then dumping gifs from X11 windows in Web pages. This seems a bit heavy-handed. Anyone tried??

I thought about implementing GUIs in java, but it's really not suited for integrating with existing c-libraries (at least not the way tcl is) and doesn't have much in the way of support tools or widgets. That may change, but the os-system integration problem is at odds with the security and portability goals aimed at the Web. Anyone converted a tk gui to java yet??

Future:

Expect Java to be the way to do Web work, and tk to continue to be strong on desktop development. An interesting note is that both are supposed to be working under unix, mac, and windows nt environments. Maybe the tcl/java people will get together at Sun to work out an integration strategy through the TK widgets, so that the look- and-feel could be identical. Maybe a gui-builder will be modified to generate both java and tk code. :)

/charles
-- 
Charles Thayer, Columbia University, Dept. CS, Tech-staff... my words only.
Charles Thayer's Home Page

From: ouster@tcl.eng.sun.com (John Ousterhout)
Newsgroups: comp.lang.tcl
Subject: Re: TCL/TK vs. Java
Date: 12 Jun 1995 05:22:08 GMT
Organization: Sun Microsystems, Inc.
In article , elf@ee.ryerson.ca (Luis Fernandes) writes:
|> 
|> A bunch of us were discussing this topic just the other day and we
|> concluded, without much argument, that java, from a multi-platform
|> standpoint; i.e. write one app which runs identically everywhere,
|> would obsolete tcl/tk.

I've said most of this before, so apologies in advance to those of you that have already seen it.

I don't think Java will obsolete Tcl/Tk (or vice versa) any more than C and C++ have obsoleted Tcl/Tk (or vice versa). Java is a very different language than Tcl: it's a system programming language, whereas Tcl is a scripting language. The comparison between Tcl and Java is pretty much like the comparison between C and C++. Tcl is good for high-level scripting, rapid development (particularly for GUIs), and gluing. Java (like C or C++) is great for programming large complex structures where performance is critical. Java has the advantage over C and C++ that its code is mobile across networks whereas C and C++ code isn't.

We have every intention of making Tcl/Tk and Java work together just as smoothly as Tcl/Tk works with C and C++, so you can have the best of both worlds.


Newsgroups: comp.lang.tcl
From: tjones@indirect.com (Tim Jones)
Subject: Re: Tcl/tk vs Zinc?
Organization: Internet Direct, indirect.com
Date: Sat, 10 Jun 1995 21:35:17 GMT
stephenh (stephenh@netcom.com) wrote:
: I would like to collect opinions on using Tcl/tk versus Zinc
: with OSF/Motif.  Please send to stephenh@netcom.com. If enough
: interest, I'll repost a summary.  Thanks in advance.

This is like comparing a Porsche to a machine shop. Zinc is a set of class libraries that have been ported to multiple platforms. You only create the interface from the Zinc standpoint (I use it, BTW). tcl/tk is/are an interpreted programming environment that has been ported to many platforms/environments. With Zinc, you get a graphical interface toolkit that you can write C/C++ code to add the actual functionality (ala machine shop) while the tcl/tk combination let you get in and drive away (ala Porsche).

Tim Jones
tjones@indirect.com

From: jyl@noam.eng.sun.com (Jacob Levy)
Newsgroups: comp.lang.tcl
Subject: Re: TCL/TK vs. Java
Date: 14 Jun 95 10:33:54
   Having browsed Sun's home-page and having looked at the information
   about both projects, I came away with the impression that the two
   projects accomplished pretty much the same thing (in the very
   *broadest* sense), and that the two projects were somewhat redundant
   (as someone also pointed out in the Java mailing list).

As John pointed out the two projects really address different programming needs. Java is (currently) much more efficient and gives you every ounce of performance that the box you're running on has to offer. On the other hand it is better to program lightweight and small applications in Tcl, and to use Tk especially if you're in need of an active, malleable GUI.

(I attributed this redundancy to Sun's cynicism: what are the odds that *two* projects would "fail"; if both Java and tcl succeed, even better!)

If they both succeed, great. We definitely hope that Java will succeed and in our most ambitious day dreaming we fantasize about it replacing C++ :). As Bjarne (is attributed to have) said, "Within C++, there is a smaller, cleaner language struggling to get out". :)

There was no indication that Tcl/tk/Java could even work together (until the preceding post). An example, a sneak preview if you will, illustrating the possibilities, would help immensely.

The following are speculations, not actual plans, OK? With that said, I can imagine Tcl being compiled to the Java byte codes, or Tk being used as the GUI for Java, or any number of schemes like that. The resulting combination would allow you to run Tcl and Java programs within one application and use each language for what its best for. Also, we probably want to make each language usable stand alone. Java is valuable without using Tcl, and the same holds for Tcl.

You can get a preview of how Tcl might be embedded within Java by looking at http://java.sun.com/applets/notapplets/tcl/index.html. This is a prototype and lacks important features, like being able to safely execute an untrusted script, but it's an indication of where things might go.

--JYL


Newsgroups: comp.lang.perl
From: aaron@funcity.njit.edu (Aaron Watters)
Subject: Re: tcl vs. perl
Organization: New Jersey Institute of Technology
Date: Fri, 7 Jul 1995 20:31:04 GMT

In article <1995Jul3.163933.26999@il.us.swissbank.com> gerryg@il.us.swissbank.com (Gerald Gleason) writes:
>In case anyone missed it, perl is a complete language with all the  
>features necessary to implement the most complex software systems.  On the  
>other hand, it does not enforce any development methodology, so it is also  
>possible to produce the most ugly unmaintainable mess you might immagine  
>(worthy of many assembler programmers of decades past).

Something like this is also true of Python, except that it is far less tempting to write "ugly unmaintainable messes" in my view. Just as tchrist and others have proven that disciplined Perl code can be beautiful and elegant many times. But Python also seems easier to extend with compiled add-ons for special purposes. Look at the distributed docs for both languages. I've been trying to decode those for Perl for a couple days now, and I fear it's beyond me. I wrote my "hello world" Python extension in C on the first day:

#include "allobjects.h"
#include "modsupport.h"
#include "ceval.h"
#ifdef STDC_HEADERS
#include 
#else
#include 
#endif
/* a new Python-interfaced C function! */
static object *sayHi(object *self, object *args)
{
   return newstringobject("Hi there!");
}
/* tell Python how to find it */
static struct methodlist hello_methods[] = {
  {"sayHi",    (method)sayHi},
  {NULL, NULL}            /* sentinel */
};
/* put it in a module */
void inithello()
{
  initmodule("hello", thingy_methods);
}

With a one line change to a configuration file and "make" -- whamo!

But, you can write ugly code in any language -- even really nice ones I snarf the following from the Python group:

#!/usr/local/bin/python -- -export-a-crypto-system-sig -RSA-in-4-lines-Python
>from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
'-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))

Yuck! And I hope I don't go to prison for this!

Perl and Python and Visual Basic and the like are definitely the wave of the future. I really think TCL is out of the list however, the only reason you might want to use TCL is that it's easy to extend with compiled modules -- but Python is too, and it's a modern programming language as well with lotsa neat conveniences.

here


From: jobell@bnr.ca (Bret Bieghler)
Newsgroups: comp.lang.tcl
Subject: Re: Why I want to dump TCL!
Date: 14 Jul 1995 16:03:14 -0500
Organization: Bell-Northern Research, Richardson, TX

In article <3u6ggo$ol5@aurns1.aur.alcatel.com>,
Wayne Throop  wrote:
>   1)  $  always expands variables (() for hashed arrays)
>   2)  [] always expands a tcl command sequence
>   3)  {} always a completely quoted string
>   4)  "" always a whitespace-only-quoted string
>The only part even vaguely complicated is working out the consequences
>of rule 0, which is

>   0)  all these rules are lexically interpreted only 1 level deep [1]

Then put rule 0 at the top...  it does screw things up, depending on how
many levels you are in, and I assume you mean a level by braces in braces,
etc.

>( Yes, I've left out some "\", ";" vs "\n" and some whitespace behaviors,
>  but even those aren't very complicated in light of rule 0. )

Yeah...sure...try the regexp command.  If you want to use things such as
as \t or \n then you have to use quotes around the expression, and then if you
want to escape something like a parenthesis you have to "double escape" it -->
ie \\( or \\)  major pain.

>And what is the oh-so-simple alternative Bret proposes?

If you read the .sig I explicity said that my name is NOT Bret.  It's Joe.
Bret is the account owner.

>
>: Perl --> the scripting language from heaven!
>
>Um.  Yeah.  Much simpler.  Let's compare, say, just the first rule.
>
>   1) $ expands scalars, unless it looks like it might be the end of
>        a regular expression, or followed by a digit, in which case
>        it's a remembered string from a match.  But if you want to
>        force composite-type evaluation, you use @ or %, objects of
>        which type have indexing syntax with [] and {} respectively.
>        I won't attempt to give all the "mnemonic" builtin single-char
>        codes for other special-case $-expansion, but suffice to say
>        it's a bit more convoluted than argv env() and tcl_precision.

Its called operator overloading, and it's quite nice.  Remembering the
different $, @, and % is easy compared to all the crap in Tcl. Variables
are always referenced with the $ operator, regular scalar indexed arrays
are accessed via $name[$index], and associatives are accessed as $name{$index}.
If you want to refer to the whole thing, either @ or %.

>I am, in fact, a user (and fan) of both tcl and perl.  Further, perl5
>has been vastly regularized.  But the claim that perl (even perl5) is
>*lexically* or *syntactically* simpler than tcl is preposterous.  Larry
>intentionally, unabashedly, and arguably felicitously made perl a
>DWIM-extrordinaire, syntax-from-Hell, lexically convoluted language, and
>to claim that he failed to out-convolute tcl is Just Plain Silly. 

Lexically and syntactically, Perl is superior, imho.  I'm no oaf, and Tcl gives me
headaches, while Perl is simplicity personified, IMHO.

>Wayne Throop   throopw%sheol.uucp@dg-rtp.dg.com
>--
>
>    IMHO, the sadly widespread urban legend that tcl syntax is
>    complicated is largely due to people who ignore rule 0, and
>    uncritically suppose that any deviation from the haphazard rules of
>    the unix shells is "more complicated" (when the truth is quite the
>    reverse). 

Now I wonder why its an urban legend...perhaps because thats the way the
language comes across:  difficult, unintuitive, and a pain.

:-)

Joe
-- 
* Joseph A. Bell (NOT Bret Bieghler)			   *
* Northern Telecom / Bell-Northern Research		   *
* Email: jobell@bnr.ca					   * 

From: throopw%sheol.uucp@dg-rtp.dg.com (Wayne Throop)
Newsgroups: comp.lang.tcl
Subject: Re: Why I want to dump TCL!
Date: 22 Jul 1995 09:01:44 GMT
Organization: Alcatel Network Systems (Raleigh, NC)

: From: frankf@phoenix.princeton.edu (Frank P. Flannery)
: There is no doubt about it.  Tcl is a terrible language, even as
: scripting languages go.  It is slow, laborious to working with, weak,
: and totally unstructured. 

Yet it is faster than the unix shell family, less laborious than the ed/sed family, stronger than the Basic family, its interface to adding new primitives in C is more structured than any of the above, and its introspection features are stronger than any of the above.

In short, Tcl does many things better than commonly available alternatives, and its relative lexical parsimony (note I didn't say simplicity, I said parsimony) makes it attractive as an embeddable control language.

: First off, tcl's claim as event driven falls flat on its face.  I
: can't even trace function calls, I can't pass arguments easily to
: traces. 
Rename the function and write a trace wrapper. Sorry about those arguments. I must confess I've never been discomfited by that.

: If I write a function that doesn't have any updates and runs for a
: long time, well, forget about your program talking to you. 
Trace a strategically chosen variable and meter out updates therefrom. Tcl claims to be event-driven, not multitasking/multithreading. So don't be surprised that if there are no events, nothing gets driven.

: Tcl has no structure whatsoever.  Forget what they taught you in cs
: 101, global variables are your friends! Yes, simply because there is
: no such this as structure. 
Use itcl. Or tclx keyed lists. Or use the top-level global namespace as a module namespace, and access via $module(varname,idx1,idx2) as needed.

Further, Tcl has (simulated) lexically scoped local variables, while many scripting languages (eg, elisp or perl4) have only dynamically scoped variables. Tcl allows new control-flow structures to be coined, which is an important structuring primitive.

Simply because the global variable and function namespace is one-dimensional is not a legitimate rationale for any claim that Tcl has "no structure whatever".

: Oh and forget pointers.  The best you can hope for is to store
: variable names in variable names in variable names.  .. 

Oh, the *horror*. They took pointers away and left us only with hash tables. (Adopt best Karl Malden impression) "You're on vacation. A sneak-thief takes your old reliable American Express Pointers you've been shooting yourself in the foot with for years, and leaves a clean, modular, scoped, portable, distributable, equivalently-powerful mechanism. What will you do? What *will* you do?"

( Yes, yes, yes, it's not quite equivalently powerful. But in essence, pointers are (ineffable) names for things. The only serious disadvantage of strings in this role is they aren't ineffable. )

: Oh yes, and if you change one line here, be prepared to change every
: other line in your program.  That's the nature of global variables. 
: Tcl is only good for Tk, and even that lacks.  It's good for
: prototyping, but anything over a few thousand lines, and your
: programming time goes up exponentially.  And a few thousand lines
: isn't going to do it for any real program.  Not only that, but Tk is
: slow.  This slowness leads to problems with event ordering, that leads
: to all sorts of dumb tricks. 
I will merely point out that my mileage varies. My working environment's editor, mail, news, reminder, calendar, xclock, C source browser, and Unix directory and trivial file browser, are all implemented as wish scripts, and all operate many times faster and more portably than the alternatives they replace. (Or is "displace" a better term.)

: I just hope TkPerl and Stk are better.  [...]
: My sound advice to newbies out there: Stay away. 
If I had listened to such advice, I'd still be struggling with a slow, non-portable, uncustomizable environment.

But by all means, try out TkPerl and Stk. But I must say, rumors of Tcl's intractability are vastly exaggerated.

Wayne Throop   throopw%sheol.uucp@dg-rtp.dg.com
               throop@aur.alcatel.com

From: throopw%sheol.uucp@dg-rtp.dg.com (Wayne Throop)
Newsgroups: comp.lang.tcl
Subject: Re: Why I want to dump TCL!
Date: 20 Jul 1995 23:56:58 GMT
Organization: Alcatel Network Systems (Raleigh, NC)

::: From: jobell@bnr.ca (Bret Bieghler) (actually Joseph A. Bell)
::: Tcl, simple? You've got to be kidding.... 
::: Remembering all the rules about when you need to use variable
::: substitution and when you don't,

:: Wayne Throop 
:: [.. Tcl syntax is very simple, if you keep in mind rule 0 ..]
:: 0) all these rules are lexically interpreted only 1 level deep

: From: jobell@bnr.ca (Bret Bieghler) (actually Joseph A. Bell)
: Then put rule 0 at the top... 
This bears out my conjecture that those who think the rules are complicated haven't even cracked a man page. What I called "rule 0" in my ad-hoc presentation IS placed at the top of the Tcl(n) man page. All the rules[1] for lexing and interpreting Tcl source code are there.

: Remembering the different $, @, and % is easy 
: compared to all the crap in Tcl. 
Other than having too *few* lexical primitives in regexp, Joe hasn't managed to identify for me any "crap" (by which I mean complicated or hard-to-remember rules) in Tcl.

:: I am, in fact, a user (and fan) of both tcl and perl.  Further, perl5
:: has been vastly regularized.  But the claim that perl (even perl5) is
:: *lexically* or *syntactically* simpler than tcl is preposterous. 
:: Larry intentionally, unabashedly, and arguably felicitously made perl
:: a DWIM-extrordinaire, syntax-from-Hell, lexically convoluted
:: language, and to claim that he failed to out-convolute tcl is 
:: Just Plain Silly. 

: Lexically and syntactically, Perl is superior, imho.  I'm no oaf, and
: Tcl gives me headaches, while Perl is simplicity personified, IMHO. 
I might find "superior" arguable, depending on "at what". The gusty bus is a nondescript tandem, and all that.

But "simplicity", at least relative to Tcl, is still Just Plain Silly.

:: IMHO, the sadly widespread urban legend that tcl syntax is complicated
:: is largely due to people who ignore rule 0
: Now I wonder why its an urban legend...perhaps because thats the way
: the language comes across: difficult, unintuitive, and a pain. 
May be "unintuitive". May be "a pain". I don't find it so, but may be.

But "difficult" because complicated? Just Plain Silly. See [1] below. It still looks to me that the urban legend persists because people's brains have been turned to mush by exposure to the Unix shells.

"This is your brain. This is your brain on /bin/sh. Any questions?"

Wayne Throop   throopw%sheol.uucp@dg-rtp.dg.com
               throop@aur.alcatel.com

[1] The Nine Rules of Tcl Nobody Seems to Bother to Read
             (my own paraphrasings)

        1) a script is broken into commands at newline and semicolon
        2) command evaluation proceeds by simple dispatch on the first
           word of a command after substitutions described in 3-9
        3) a command is broken into words at whitespace
        4-8) if the first character of a word is " or {,
                 do " or { quotation to form the word,
             if a word contains [, $ or \,
                 do command, variable, or backslash substution into the word
        9) if a # is encountered as the first character of the first word
           of a command, the characters up to and including the 
           following newline are ignored as a comment

    True, some of the subtleties aren't captured here, especially that
    rules 4-8 can gobble up whitespace, and some \ behavior.  But the
    above 9 rules[2], subtelties and all, with rules 3-9 being applied
    on a single level scan, are all there is to lexing and parsing Tcl,
    and they are all right on the Tcl(n) man page. 

    Anyone care to post a Perl BNF?


[2] (really a *count* of 5 rules, if we group recursive expansion rules)

From: cimarron@automation3.acgeas.com (Cimarron Taylor)
Newsgroups: comp.lang.tcl
Subject: Another view of Java and Tcl
Date: 03 Jul 1995 04:56:16 GMT
Organization: Automation Consultants Group

I find it interesting to see discussions of Java and Tcl. I see Java as a better C or C++, not as a better Tcl. Even though it can probably be interpreted, it looks to me as a compiled language. As such, I think it makes people working on medium to large projects happy because the compiler helps everything stay efficient, consistant, and maintainable. Tcl does hardly anything in this area. However, Tcl makes it possible to do small things quickly, and to write programs that can be customized by end users with very little effort. In this respect, Java is lacking.

IMHO, the ideal would be to have an implementation of Tcl in Java, or at the least be able to link Tcl and Java together in a way to allow the result to be able to load new Tcl commands which were implemented in Java. I believe this is possible now, but only on solaris :-(

To me, a Java implementation of Tcl should be trivial, since both are already so well engineered. This would also help put an end to the neverending woes of dynamically loading new object code into a Tcl app since Java already does this so well. Anyone else interested in a Tcl/Java combination.

	Cimarron Taylor
	Enterprise Guy, Automation Consultants Group
	cimarron@acgeas.com

Newsgroups: comp.lang.tcl
From: lwv26@cas.org (Larry W. Virden:)
Subject: Re: Tcl vs Perl
Organization: Nedriv Software and Shoe Shiners, Uninc.
Date: Tue, 15 Aug 1995 13:07:04 GMT

No, by prettier I mean

$ cat tkmotd
set file [open /etc/motd]
set motd [read $file]
 
message .title -font lucidasanstypewriter-bold-14 -justify left -width 180m \
-relief flat -text "Press any key or any button to dismiss"
 
message .t -font lucidasanstypewriter-bold-18 \
-aspect 200 -justify left \
-relief groove -bd 5 -text $motd
 
pack .title -side top -anchor c
pack .t -side top
 
bind .t  exit
bind .t  exit
focus .t
 
wm title . "Press any button or hit any key"
wm geometry . +200+175
instead of

$help->subwidget('message')->configure(-justify => 'left');
etc.

sorry - I haven't translated the above Tcl/Tk script to perl/tk yet.

The extra 'noise' characters required to do configuration, etc. and the mix of what appears to be old Tcl/Tk flags (-justify) and arguments such as ==> 'left' makes it difficult for a novice to read a Perl/Tk program - and even harder to write them.

:s Larry W. Virden                 INET: larry.virden@cas.org
:s My new WWW home is coming...
:s Unless explicitly stated to the contrary, nothing in this posting should 
:s be construed as representing my employer's opinions.

From: scs@iti.org (Steve Simmons)
Newsgroups: comp.lang.tcl
Subject: Re: Tcl vs Perl
Date: 16 Aug 95 12:37:34 GMT
Organization: Various Organizations

tcl vs. perl, tcl vs. perl, tcl vs. perl....

Faugh!

Both languages have good points, both have bad points. Neither is the beginning or end of the universe. Perl is hell to teach a non-technical person, but basic tcl syntax they get down pretty quickly. Funny thing, tcl was originally written as `tool command language', to be imbedded into tools as a command language. In that, it's great. It's small, regular, easy to learn, has unexpected power. But it's like basic in a lot of ways, and as with basic people are building excessively large systems in it.

Perl, on the other hand, is more like a systems programming language. You can do just about any UNIX administration task quickly (meaning it runs fast) and flexibly (meaning there are a zillion ways to do it). But it's hell for the non-technical person (`this dereferences your variable'), or for the non-unix person (`this is like awk, this is like sed, this is like sh, . . .'). Would you build a perl interpreter into a command-line interface for a program intended to be used by non- technical folks? I didn't think so.

Arguing the relative merits is silly. Use each where and as appropriate, get the job done, and then move on to the next task.


From: Sudish Joseph 
Newsgroups: comp.lang.tcl
Subject: Re: Tcl vs Perl
Date: 17 Aug 1995 05:42:13 -0400
Organization: The Ohio State University Dept. of Computer and Info. Science

In article <40u93b$ns1@superb.csc.ti.com>,
frazerw@dseg.ti.com (Frazer Worley, #909980 DAD) writes:
>   Yeah all very well and good - but its ramshackle - not at all well
> organised - I didn't even see an index or table of contents [there
> could be one - probably is at page 123 or some such]. Speaking for
> myself I don't have the time to wade randomly through 250 pages of
> documentation.

I do not know what your definition of "ramshackle" or "organised" (sic) is, but I taught myself Perl entirely by reading the perl 5 docs. I had the advantage of knowing C/the shells/awk/sed. The manual pages Tom Christiansen refers to are very well written, concise, clear, and in all ways great to use for both learning from and referring to. And that is the key point here: they're great for learning _and_ for reference.

To contrast with the Ousterhout book: I read the section on Tk in the draft, then stuck exclusively with the excellent manual pages. The main difference is that it would be very difficult to learn the basic concepts of Tk from the manual pages alone (ie., you need the book's background stuff for the most part), and the book is pretty useless by itself, since it refers you to use the manual pages for actual use. The book itself is very well written, I just prefer having books I can refer to.

I'm not participating in this particular Perl vs. Tk flamefest for the language thing. It's just that, to me, the docs you denigrate are an excellent role model for what things should be like in general. Of course I love the Emacs docs too. :-)

>   Conspiracy ? No but O'Reilly and others must be printing money,
> and through selling old news. They'll wait till sales drop off and
> then bang - another $30 book describing the "New Super OO Perl5".

Why would you expect the sales from a book that you describe as having been around for 4 years to drop off overnight? (Other than it being part of your own particular "bugeyed monsters taking over" scenario.)

-Sudish


From: jch@isode.com (John Haxby)
Newsgroups: comp.lang.tcl
Subject: Re: Tcl vs Perl
Date: 18 Aug 1995 08:46:45 GMT
Organization: ISODE Consortium

In article <40qn4g$re6@csnews.cs.colorado.edu>, Tom Christiansen  writes:
|> In article <1995Aug11.144357.20292@chemabs.uucp> you write:
|> :
|> :Perl 5 is easily extensible and has Tk as well.
|> :
|> :I myself think that Tk/Tcl is 'prettier' to read than Tk/Perl, but then
|> :I am not as familar with Perl programming as I am Tcl.
|> 
|> Hmm... is this really hard that to read?
[snip]
|> sub get_article {
|>     my @arts = `ls -t /tmp/rrn.*`;
|>     chop @arts;
|>     clear_article();
|>     if (@arts) {
|> 	unless (open(ART, "< $arts[0]")) {
|> 	    warn "can't open $arts[0]";
|> 	    return;
|> 	}
|> 	parse_article(*ART);
|>     } 
|> } 

I think perhaps this illustrates the point. I can read this snippet and make some sense of it but people do find it hard to write this kind of thing since I have a hard time remembering the difference between "$" and "@" and occasionally forgetting that they are always needed, almost. It generally doesn't, I agree, take long to look it up when you have forgotten and eventually it does stick. (yes, I know, this is a somewhat artificial and contrived point, but you get my meaning, I trust)

The Tcl syntax, on the other hand, is so small I have little trouble remembering it. On the other hand, that's three hands now, some people have a hard time remembering, or at least understanding, that Tcl doesn't have any flow control structure, it just has built-in commands called "if" and "while" and whatnot.

The upshot is, in the end, when you've got four hands, that both Tcl and Perl are fine for people that understand them. For the novice of either language, there are significant pitfalls. For Tcl, it's the quoting hell that people manage to get themselves into and for perl, well, its the small syntactic marks I suppose.

Perl is a fine, pragmatic language and has no equal. Tcl, is a fine embedded scripting language and also has no equals. You'll get religious wars about which language to choose, but the choice always comes down to what is best for you. Work out what you want to do and take a little time to explore the alternatives, then decide. Maybe change your mind later, or do both :-)

John Haxby						J.Haxby@isode.com
ISODE Consortium					+44 181 332 9091
These are my opinions and have nothing to do with my employer.

From: sriram@glock.tcs.com (Sriram Srinivasan)
Newsgroups: comp.infosystems.www.authoring.cgi,comp.lang.perl.misc
Subject: [LONG] Re: perl versus tcl/python/java
Date: 22 Aug 1995 18:59:03 GMT
Organization: Teknekron Communications Systems, Berkeley, California

In article <41ac13$r2u@csnews.cs.colorado.edu>, Tom Christiansen  writes:
: 
: Commentary welcome (especially things I left out or got wrong).
: 

Appreciated reading your commentary on both Python and Tcl. I have my differences, however.

I teach Perl, and like Perl for all it's power. I recommend it for text processing, system adminstration and such "stand-alone" tasks.

I've done some reasonable amount of coding in both Tcl and Python and like them for *entirely different reasons*. They are -

  1. Simplicity of language/grammar - Perl's much touted OO features aren't easy to understand by non-experts - most of the important stuff is in the "Bag of Tricks" documentation, reflecting the spirit of the approach.
  2. Ability to be easily extended - Whatever you may say about Tcl, this is one reason why people "still develop applications" in Tcl (the other reason, of course, is Tk). I use it in the dosage prescribed by Ousterhout - use it as a "communications" language , where different applications can talk to each other, or the programmer can communicate with a system's internals - not for developing full-blown production applications. Witness the Tcl-Tk combination - use it in the ratio Ousterhout himself saw fit - as a glue language between communicating screens.

    Re. datatypes, there is no single COMMON representation for what an integer looks like - Perl has it different from COBOL; but every one understands the ASCII *printed* version of an integer.

    I've used TCL very successfully in several large projects, with several communicating processes - it's bloody easy to debug when you see strings going across. TCL interpreters are light-weight, and it is easy to create software agents .. one wouldn't do it with perl. It is easy to create a DDE interface to EXCEL using Tcl - do that with Perl.

    It is not easy to teach the average programmer about embedding Perl.

  3. Re. Python - most of your objections have to do *purely with syntax* You have to write one simple project in Python to get used to the indentation stuff - I've suddenly begun to like it a lot, because there's a lot more code visible per page. Also it is very refreshing not to have to put $'s and @'s - easier on the hand and eye. But as I said earlier - this is purely syntactic sugar. You say "don't screw up on the indentation stuff" - it's like saying "don't screw up on curly braces. I've done things like this in C/Perl before ..
    			....
    			i++;
       		}
    	}
    
    .. only to realize later that I should have moved the i++ to the outer loop. Illegal indentation in Python is caught as immediately as illegal braces elsewhere

    The important stuff:

    How easy is it to create new data types in Perl ? In Python, defining a class automatically creates a self-describing data type, which can automatically be marshalled across a network interface or serialized to disk.

    You say it doesn't resemble any Unix like stuff, or the kind of thing a C programmer may be familiar with. I say "Good". Fully half my perl classes are filled with people from non-unix areas. References to awk/sed/sh specifics are not always appreciated. I also believe that to a C/C++ programmer, Python is much more intuitive than Perl.

    Python, to me, is an excellent choice for teaching programming principles and embedding. It does Unix well too, btw. Take regular expressions for example - in Perl, one can refer to grouped expressions as \1,\2 etc - whereas in Python, one can optionally give named tags, and there is no limit to the number of such tags. I'm not fully sure about what you mean by Python not supporting "deep closures" .. can you please give a perl fragment that does the same, and I'll see if I could do the same in Python? I have always understood Python as having closures.

    Take a look at Grail - a hotjava like browser that uses Python instead of Java (http://monty.cnri.reston.va.us/grail/).

    All in all, I like the simplicity of the language.

  4. The thing that I disagree with most in your comparisons is the heavy reliance on syntactic stuff -
       "Why can't I do set $${something}"
       "Why can't I do a = 3 * 5
                           -12 ;"
    			
       "Why can't I put braces where I want to"
       "Why can't I comment out code intuitively ?"
    
These are not technical issues, in the sense that I can still do *my* job effectively. One does not go to a foreign country and say, "Drat, why don't they have a single Pizza Hut around this place ?" Maybe someone else sells pizza; maybe someone has a different food item that you would not get in your native place.

Summary: All these languages have their own non-overlapping features

Use Perl when you need something to munch your data

Use Tcl/Python where you need an embedded scripting language.

If you are a programmer learn all three.

Thanks, TOM, for creating something to comment on. It is definitely easier to criticize or comment on something that exists already.

Comments ?

- Sriram
(sriram@tcs.com)

From: raney@psych.colorado.edu (Scott Raney)
Subject: Re: Meta Card versus TCL/TK?
Date: Mon Sep 04 14:14:33 PDT 1995
Organization: University of Colorado at Boulder

>>>and it's not freely available, which
>>>will severely limit it's initial popularity. 
>>
>>Possibly true.  But MetaCard comes with a GUI builder, and its
>>objects are persistent (no need to reset atributes in scripts).  How
>>much is your time worth?

>I don't believe that cost is the issue, MetaCard is
>not expensive, it's pretty cheap actually. I think a serious drawback to
>MetaCard is that it isn't easily graphically extended. Now you can write C
>functions and call those functions from MetaTalk (the scripting language) 
>and this is about as easy as writing C functions and calling them from Tcl. 
>This isn't the problem. The problem is that it is impossible to change 
>anything about the graphical widgets that isn't already there. You can't add 
>new widgets and you can't add functionality or change the behaviour (outside
>of the predefined bounds) of existing widgets.

That's what the pixmapId property of the image object is for. With that, you can implement any type of control, and any type of behavior, that you need. Of course, all that has to be written in C.

>>>  Finally, the extremely powerful canvas and
>>>text widgets in tcl/tk are heads and tails above anything else I've
>>>ever seen.
>>
>>MetaCard's text widget and graphic objects are at least as powerful
>>as Tk's and MetaCard also has bitmap image objects *and* an image
>>editor built-in.
>>

>I can't in anyway agree with this. MetaCard's text widget is probably
>as powerful as Tk's text widget, but the canvas widget blows away anything
>in MetaCard. Using graphic objects it is almost impossible to do anything
>remotely complicated. In fact I think it is impossible to do even simple
>things. Take the froggy graph example in the MetaCard demo stack. I can't
>figure out the script. This would be far simpler using the Tk canvas, and
>much easier to understand.
Except that you couldn't implement the frog demo at all using the canvas widget since it relies on MetaCard's ability to overlay image objects *with masks* on top of graphic object's. The Tk canvas object can't do this, and my guess is that it would take you several weeks to make use of Tk's extendability to add this capability.

MetaCard's graphic object *is* as powerful as the canvas widget, and in many case more powerful since support for pixmap fill styles is built in. The other MetaCard graphing demos couldn't be implemented with Tk's canvas object either.

>I'm a happy user of both products, and think that using MetaCard is a viable
>alternative to Motif (ughh) and Tcl/Tk. It's not as flexible as Tcl/Tk 
>in terms of extendability, but it is still very useful.

From: shuang@idirect.com (Steve Huang)
Subject: Table Geometry Manager && Visual Basic, My Opinion
Date: 12 Sep 95 02:02:48 GMT

Thanks for the response.

My assumption is that the Tk 4.1 release supports Win32/Mac. Does this mean that a Tk 4.2 would be released with Table Geometry Manager to support SpecTcl?

Now some comments on Tcl/Tk versus Visual Basic:

1. I am not a UNIX guru and have always dreaded the thought of using Motif to build usable displays. Of course you can buy a Motif GUI builder such as TeleUse or UIM/X for 5-7k $US (x1.33 in Canada) but you still have to understand Motif.

Our company has just completed a medium weight X-Windows application in Tcl/Tk/BLT using a 3rd year CS coop student as the coder. The application took 4 weeks, which is quite reasonable. This version runs faster than a failed attempt in Motif by another "experienced" programmer in the group. => well coded Motif may perform better than Tcl/Tk however poorly coded Motif can easily perform slower!

2. I have done a number of applications in Visual Basic and am a fan of it. Ease of use is the primary advantage of VB as well as a rich set of VBXs. However I feel that VB is really better suited for light weight GUI applications, unless you can get the perfect VBX companion to do the dirty work. Tcl/Tk can be stretched farther especially if you code compute intensive activities in C and add these functions to your 'wish'.

==> Here is my personal analysis of suitability of the different GUI technologies for different tasks.

light weight               medium weight              heavy weight

------ Visual Basic ------

                          -------- Visual/Borland C++ ------------

----------------- Tcl/Tk -----------------

                          ---------------- Motif -----------------

3. A number of people have talked about the advantages of VB over Tcl/Tk. Here are three advantages of Tcl/Tk over VB:

a. Number of widgets

Can have a very large number of widgets in your application. Our above application pre-builds the widget hierarchy for a number of spreadsheet-like display pages. Approximately 2000 text entry widgets and 500 label widgets. My hope is that widget limitations are only constrained by X-Windows.

In Visual Basic v3.0 (Windows 3.1) there are finite limits on the number of controls (Windows term for widgets) that can be dynamically created in a form/application. In testing the maximum number of text boxes was ~400 and labels ~400. This I can understand since we are dealing with 16 bit Windows.

At Comdex Canada, I asked a Microsoft representative how much improvement there would be in VB 4.0 (uses Win32 API). To my surprise, the representative said that there would be a 30-40% increase in the number of controls allowed. This I felt was disappointing since VB is now using 32 bit addressing.

=> does Sun have a feel of the number of widgets that can be created in an application in the Win32 Tcl/Tk port? Hopefully much better than VB.

b. dynamic nature of Tcl language

By using the 'eval' command it is possible to dynamically create/run Tcl programs and store scripts in databases to be invoked at any time. This is a very powerful feature.

VB on the other hand binds the program statements at edit time.

c. interactive (live) nature of debugging

In Tcl/Tk it is possible to debug from the 'wish' prompt as the application is running (true multi-tasking obviously helps here).

In Visual Basic it is possible to debug from the prompt window, however it is first necessary to break the running program. Therefore it is only possible to see static snapshots of the program. To interact with the GUI again, it is necessary to restart the program.

Anxiously awaiting the Win32 version of Tcl/Tk since our company is interested in cross-platform GUI development. Most UNIX/Windows cross-platform development tools now on the market are quite expensive (5-10k $US) and a number don't even work that well! In addition you must pay additional money for each flavour of UNIX you wish to support.

Steve Huang


From: jhobbs@cs.uoregon.edu (Jeffrey Hobbs)
Newsgroups: comp.lang.perl.misc
Subject: Re: Perl/Tk vs. Tcl/Tk
Date: 20 Oct 1995 09:24:34 -0700
Organization: University of Oregon Computer and Information Sciences Dept.
In article <466q09$o11@yercaud.alantec.com>, Mani Chinnappan wrote:
>I am new to Perl/Tk and Tcl/Tk. I am wondering if anyone has evaluated which
>one of this flavor is suitable for doing large GUI projects on a variety of
>platforms such as SunOS, Solaris, HP_UX, AIX, and MS Windows using SNMP.

My $.02:

Tk is more stable based on Tcl because that is where all the original development work is done (the Sun Tcl group). Perl, however, is a more capable language. Of course, Tcl is meant to make use of being embedded in C (or vice versa, since it now supports shared libraries on most platforms, including Windows DLLs). Tk currently only makes it to windows with Tcl, with no guarantee on a timeline for Perl/Tk-Windows. Also, Tcl will have sockets in core in about a month or so.

If you really want to look at a good multi-platform solution (both versatile language and good GUI all in one), you might want to take a look at Python (http://www.python.org/). It uses Tk as well for the interface, although I'm not sure of the GUI status on Windows or Mac.

-- 
     Jeffrey Hobbs                           Office: 503/346-3998
     Univ of Oregon CIS GTF                  email: jhobbs@cs.uoregon.edu
		URL: http://www.cs.uoregon.edu/~jhobbs/

From: Sam Taylor 
Newsgroups: comp.lang.java
Subject: Re: OSF annoucement: Java ports
Date: 17 Oct 1995 01:37:32 GMT
Organization: Australian National University

Hi Vania -

> - Ports of the software to other platforms than those already
>  ported by Sun, and evaluation of portability and quality.

On your homepage you also suggest that you will be undertaking a port to Digital Unix. Do you have any kind of timetable for that port? Will you be making these ports publicly available? We hope to use Java on DEC Alpha machines and I may be able to help with the port to that platform.

On your homepage you mention that you will be porting the Alpha3 release of Java. Is there are particular reason you are not porting the pre-beta release? Given that both Sun and Netscape are fully commited to the pre-beta, interest in the Alpha3 is likely to be limited.

> - Technology assessment: performance, completeness,
>      investigation of security issues and adequacy of
>      the technology to be used as mobile code.
 

I am in the process of performing a similar assessment, with a particular emphasis on the development of portable client applications for a standard client-server architecture. In the first instance I have been comparing the following languages:

  1. Tcl/Tk and extensions (such as Tcl-DP)
  2. The desktop Korn shell (dtksh) as included in CDE
  3. Java
  4. Combined Tcl/Java architectures, as advocated by John Ousterhout

At some later stage I hope to add Perl/Tk and Guile to this list. There appears to be some significant overlap in what we are doing. I would be very interested in your initial impressions of Java, and the basis for your comparrison.

-------------------------------oOo-------------------------------
                            Sam Taylor
          Distributed High Performance Computing Project
             Centre for Information Science Research
                 Australian National University
 
          Sam.Taylor@anu.edu.au           +61 6 279 8124
-------------------------------oOo-------------------------------

Newsgroups: comp.lang.lisp,comp.lang.perl.misc,comp.lang.scheme,comp.lang.python,comp.lang.tcl
From: k p c 
Subject: Re: A Lispish Perl?
Organization: NASA Ames Research Ctr., AI Research and Aero. Facil. Branches.
Date: Tue, 31 Oct 1995 02:28:57 GMT
Quoth Tom Christiansen :
> :matching, and string processing) with straightforward Lisp-like syntax
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
> :Lisp, and I wish I could combine their strengths.  Please send mail (I
                            ^^^^^^^^^^^^^^^^^^^^^^^

Hmm, reading in and between the lines, I think he is pretty clearly saying that he wants something close to the syntax and everyday semantics and library of Common Lisp, but with the regexps and pipes and similar scripting language conveniences that Perl offers. That is not an unreasonable desire, IMHO. Many of us want that, too. In any case, he explicitly mentioned a straightforward Lisp-like syntax.

> It's been too long for me to recall all that lisp offers -- what kinds of
                                                              ^^^^^^^^^^^^^
> data structures are you looking for?  Perl has a pretty rich set of
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Here I think it's fair to say that you did not answer his question.

Let's say for the sake of the discussion that Perl has all the data structure flexibility of CLOS and more. Then unless Perl has made some truly unprecedented changes recently, it is still the case that its syntax is very different from Lisp.

To me and others, Perl is the most different from Lisp in syntax of any programming language in widespread use today. Perhaps to you Perl and Lisp have similar syntax. Speaking as somebody who has looked closely at Perl (before Perl 5) but rejected it almost solely on the basis of its syntax, I find that an extraordinary opinion!

Perl has many features, even unusual things Lisp has like multiple-value-setq. But I would not call its syntax like Lisp.

> What other stuff would you be looking for?

I presume that he wants, as many of us do, a Lisp that does easy pipes and fast regexps. I would be satisfied with a fast, small CL with built-in regexps and threads, but know of nothing perfect yet.

In addition to gcl, cmucl, clisp, and commercial Lisps, he might consider such programs as scsh, guile, various other schemes, emacs lisp (emacs -batch), and xlisp. Some of these might require foreign functions. Some (the CL's) can implement partial regexps in Lisp itself. Some have them built in. They have varying piping capabilities and varying startup speeds and sizes. I happen to prefer CL, so the progress in speed and Unixisms by scheme compilers is only relevant to me inasmuch as they have improving CL libraries as well.

Until I get a suitably CLish, fast, small, regexping Lisp, I'm sticking with zsh and all those little Unix utilities, not Perl, for most shell scripts, We're not too far away from what we need, and some (such as some of the above scheme authors) think we're there already.

If you post a followup to this article, please also send a courtesy verbatim copy by email to help work around potentially unreliable feeds.

---
Have you learned something today?
                      Have you taught something today?
                                          Have you exercised free speech today?
kpc@ptolemy.arc.nasa.gov.  AI, multidisciplinary neuroethology, info filtering.

From: claird@Starbase.NeoSoft.COM (Cameron Laird)
Newsgroups: comp.lang.java,comp.lang.misc,comp.lang.tcl
Subject: Embedding Java (was: Calling java from C)
Date: 31 Oct 1995 06:19:54 -0600
Organization: NeoSoft Internet Services   +1 713 968 5800
In article <30951BF2.2C2C@UK.Sun.COM>,
Andrew Coupe   wrote:
>Larry Rau wrote:
>> 
>> M.Ranganathan wrote:
>> >
>[...]
>> >
>> > How do you call java from C ? I would like to run the byte code
>> interpreter
>> > as a thread and communicate with another thread that runs a C program.
			.
			.
			.
>Well, if I understand the original question correctly, you don't need 
>Java source to do this.
>
>Given that you can call native code from Java (see the java_h docs
>for more details) it is possible to "wrap" a C program in Java
>so that you can execute the whole lot from within the Java virtual
>machine. It is then simple to have your C code calling Java code
>or even to have your C program use Java as a scripting language.
>
>I have seen this done, although haven't done it myself.
>
>You won't be able to embed your C code within an applet in this
>way, but you could effectively embed an equivalent to the HotJava
>browser within your C program.
			.
			.
			.

Let's examine this just a bit more. I'm also in the market for a network-aware embedded language. I need a small, easily manageable embedding that I can attach to a bloated, gargantuan legacy ex- ecutable; the thought of launching the latter "from within the Java virtual machine" makes me uneasy. I'd sure appreciate hearing from anyone who has real-world experience with this.

Other reasons that I'm leaning to Safe-Tcl (plus maybe other Tcl extensions):

  1. I'm wary about the portability of Java. I know the development team has done great work in language design and implementation, but I must *deliver* on a variety of Unix platforms, not just promise, and Java just won't be there for some time;
  2. I have a weak belief that my end-users will prefer the (non-)syntax of Tcl;
  3. I have more experience and corresponding comfort with Tcl.

Points 2. and 3. are under my control; 1., though, is just a killer. Is there anything going on in the porting projects that would change my mind? I don't need all of Hot- Java; I'd be happy with a portable virtual machine that could handle even a subset of the full Java specifica- tion. My impression, though, is that the kernel is the hardest part; everything after that comes naturally.

As usual, I'd welcome news from Pythonians, Perlites, Schemers, or Forthniks about even better ways to pro- ceed; for now, my belief is that, marvelous as those languages are, no one has put in the work to make them as agent-able as Safe-Tcl and Java.

Recommended reading: , for a comparison of Tcl and Java (note to JDO: the last link in this page, , isn't live); and the language comparison that Wayne Christopher edited.

I've trimmed follow-ups a bit; feel free to do more.

-- 
Cameron Laird           http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com      +1 713 623 8000 #227
                        +1 713 996 8546 FAX

This page is a copy of the original comparison page of Wayne Christopher,
Andreas Borchert, November 28th, 1995