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.
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
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.I didn't see any big performance problems with this object system.- 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"))
= 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".
- 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.
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)
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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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)
[note: this is not all native scheme; I think some functions used need definition.]
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
The C like syntax and the X toolkit calls should be easily translatable into
python and tk calls.
>* 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.
shriram@asia.cs.rice.edu (Shriram Krishnamurthi) writes:
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
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:
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)
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.
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.
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
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.
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:
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:
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.
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:
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?
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:
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.
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.
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.)
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 :
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
(Note: this is the introduction from the document available at
http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/slater/ew3c.html).
>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.
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
> 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?
From: Tom Christiansen
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)]
}
}
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 :-)
--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
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.
From: Guido van Rossum
From: Tom Christiansen
--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
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
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
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.
>Had you considered TCL ?
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
20912 60293 568786 total
>In addition, there is a version which is supposed to be 'safe' for server's
>to run client submitted code ;-)
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.
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
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 -------- ------- ------ -------
Extending W3 Clients
Alan Falconer Slater,
Department of Computing and Electrical Engineering,
Heriot-Watt University,
Edinburgh, Scotland.
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, CaliforniaIn 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]
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
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
In article <3gofh4$i2k@cronkite.cisco.com>, fjiao@fjiao-ss10.cisco.com (Fan Jiao) writes:
I thought I should put in my 2c. worth on this, in support of Tcl/Tk
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.
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.
["Interesting" stuff deleted]
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)
Mike Campbell (mcampbel@offenbach.sbi.com) wrote:
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:
Any comments or suggestions welcome.
David.
berson@cs.pitt.edu
Hoshi Takanori wrote:
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:
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
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?
Dan Janowski (danj@netcom.com) wrote:
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.)
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.
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...
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...
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.
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.
The "word basis" of tcl operations breaks down pretty quick. What
about:
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.)
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:).
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
Excerpts from netnews.comp.lang.python: 30-Mar-95 Opinions? Tcl Python
Perl, .. by Dan Janowski@netcom.com
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.
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:
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]:
- 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
In article
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.
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.
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
In comp.lang.python,
Ian S Nelson
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:
Or even as a more reasonably indented
Or even a more reasonably structured:
Doesn't mean that it isn't considerably clearer to write it more like
this:
(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.
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.
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.
In comp.lang.python, yosef@adsc.com (Yosef Gold) writes:
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:
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.
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 ...
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.
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. :)
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.
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).
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.
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
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:
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:
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.
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.
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, 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. )
But by all means, try out TkPerl and Stk. But I must say,
rumors of Tcl's intractability are vastly exaggerated.
But "simplicity", at least relative to Tcl, is still Just Plain Silly.
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?"
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.
No, by prettier I mean
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.
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.
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. :-)
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
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 :-)
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 -
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.
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.
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 ?
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.
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.
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.
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
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.
Hi Vania -
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.
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:
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.
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.
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.
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):
Points 2. and 3. are under my control; 1., though, is
just a killer. Is there anything going on in the
porting projects
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:
I've trimmed follow-ups a bit; feel free to do more.
>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.
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
> I don't think there are much comparisons between Motif and 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.
> 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.
> 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.
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
> 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?
From: Dean Sheehan
> 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.
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).
___________________________________________________________________________
__ __ __ __
| |\ / /| | 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
--
danj@netcom.com |
Dan Janowski | :-(insert witty comment here)
New York, NY
From: Ken Manheimer
> 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
> 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
> 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.
[expr {($hostsNoticed > 1) ? "s" : ""}]
> 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.
ken.manheimer@nist.gov, 301 975-3539
From: Ian S Nelson
> 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...]
--
Ian S. Nelson
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
def intersect(item1, item2):
result = []
for x in item1:
if x in item2: result.append(x)
return result
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()
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
: 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...
lwall@netlabs.com
From: Tom Christiansen
: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.)
for(split(/:/,$ENV{'PATH'})){next if/^\.?$/;s![^/+]*$!man!&&-d&&
!$s{$_}++&&push(@mp,$_);}print join(":",@mp),"\n";
for (split(/:/, $ENV{'PATH'})) {
next if /^\.?$/;
s![^/+]*$!man! && -d && !$seen{$_}++ && push(@manpath,$_);
}
print join(":", @manpath), "\n";
for (split(/:/, $ENV{'PATH'})) {
if (/^\.?$/) { next; }
if (s![^/+]*$!man!) {
if (-d and !$seen{$_}++) { push(@manpath,$_); }
}
}
print join(":", @manpath), "\n";
@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";
: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.
--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
> 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.
--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.
> 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 ;-)
(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!)
--
John Chambers
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).
/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
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.
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).
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).
#include "allobjects.h"
#include "modsupport.h"
#include "ceval.h"
#ifdef STDC_HEADERS
#include
#!/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)))
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
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.
: 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.
: Oh and forget pointers. The best you can hope for is to store
: variable names in variable names in variable names. ..
: 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.
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
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.
:: 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.
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
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
$ 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
instead of
$help->subwidget('message')->configure(-justify => 'left');
etc.
: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
From: Sudish Joseph
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.
> 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".
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
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
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.
....
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
"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 ?"
- 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.
>>> 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.
>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
light weight medium weight heavy weight
------ Visual Basic ------
-------- Visual/Borland C++ ------------
----------------- Tcl/Tk -----------------
---------------- Motif -----------------
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
>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.
--
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
> - Ports of the software to other platforms than those already
> ported by Sun, and evaluation of portability and quality.
> - Technology assessment: performance, completeness,
> investigation of security issues and adequacy of
> the technology to be used as mobile code.
-------------------------------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
Quoth Tom Christiansen
> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---
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
--
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