Why you should not use Tcl 
Author Message
 Why you should not use Tcl

[ Article crossposted from gnu.announce,gnu.utils.bug,gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme,comp.windows.x.apps,comp.unix.misc ]
[ Author was Richard Stallman ]
[ Posted on Fri, 23 Sep 94 19:14:52 -0400 ]

[Please redistribute wherever appropriate.]

                     Why you should not use Tcl
                        Richard Stallman, GNU Project

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

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

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

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

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

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

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

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

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

--




Fri, 14 Mar 1997 19:43:56 GMT  
 Why you should not use Tcl

Quote:



>>>"Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in."

>Actually, I think Scheme and Lisp have bags of visual appeal.  I find
>them very poetic.

>mathew
>[ But then, my favourite poet is e.e. cummings ]

All right, that did it.  How many Scheme poems have *you* written?

Write me for a copy of "Camels and Needles:  Computer Language Poetry
Meets the Perl Programming Language"  (Winter Usenix, 1992).

See below for an example poem.  (Note -- it hasn't been updated for perl5;
Larry plugged most of the poetry holes and I haven't had time to find new
ones yet.)

--Sharon Hopkins

------------------------------  cut here ------------------------------
#!/usr/bin/perl

APPEAL:

listen (please, please);

    open yourself, wide,
        join (you, me),
    connect (us,together),

tell me.

do something if distressed;



        read (books,poems,stories) until peaceful;
        study if able;

        write me if-you-please;

sort your feelings, reset goals, seek (friends, family, anyone);

            do not die (like this)
            if sin abounds;

keys (hidden), open locks, doors, tell secrets;
    do not, I-beg-you, close them, yet.

                                accept (yourself, changes),
                                bind (grief, despair);

    require truth, goodness if-you-will, each moment;

select (always), length(of-days)

# Sharon Hopkins, Feb. 21, 1991
# listen (a perl poem)
#



Mon, 17 Mar 1997 11:04:13 GMT  
 Why you should not use Tcl

:Any collaboration between Richard and John or their
:systems could only help "serious programmers" and "hackers" alike!

Indeed.  I suspect that the vicarious collaboration between John
and Larry via Malcolm on tkperl will bring everyone joy.  The number
of tkperl postings in c.l.p is so climbing so quickly that we may
have to make a

    comp.lang.perl.tcl

newsgroup, with an "active" alias of

    comp.lang.tcl.perl

No, just kidding.  It would be a .tk group in any event.

On the other hand, Brian Kernighan (a user of tk, amongst other things :-)
once remarked to me only half jokingly that he wondered whether the union of
tk and perl would ever fit into the physical memory of any machine.

And no, I don't think bwk has the tk bindings for awk done yet.  Ask Henry
Spencer instead. :-)

--tom
--
"Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in."




Tue, 18 Mar 1997 06:47:48 GMT  
 Why you should not use Tcl

:   STk
:
:       (define f (make <Frame>))
:       (define l (make <Label>  
:                       :parent f
:                       :text "A simple demo written in STklos"))
:
:   tkperl
:
:       $f = Frame::new($path);
:       $l = Label::new($f, "-text" => "A simple demo written in tkperl");
:
:   tcl/tk
:
:       frame .f
:       label .f.l -text "A simple demo written in tcl/tk"

Actually, that's more noise characters in the perl than you need by a long shot.
That's because

    object->method(args)
    CLASS::method(args)

May always be expressed

    method object args;
    method CLASS args;

This reduces our perl version to:

    $f = new Frame $path;
    $l = new Label $f, "-text" => "A simple demo written in tkperl";

Which is considerably less busy, wouldn't you agree?  

One of the results of Larry's attendance at a REXX symposium while
he was writing perl's object system was an appreciation for REXXers
dislike for line noise all over their code. :-)

--tom
--
"Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in."




Tue, 18 Mar 1997 07:03:32 GMT  
 Why you should not use Tcl

Quote:

>:       $f = Frame::new($path);
>:       $l = Label::new($f, "-text" => "A simple demo written in tkperl");
...
>This reduces our perl version to:
>    $f = new Frame $path;
>    $l = new Label $f, "-text" => "A simple demo written in tkperl";

        By the way, would someone refresh my/our memory on why the tk
perl5 binding didn't end up:

    $l = new Label $f, text => "A simple demo written in tkperl";

(without the leading "-", "text" could be bareworded, right?)

        Thanks.

                                        Craig Milo Rogers



Tue, 18 Mar 1997 08:43:33 GMT  
 Why you should not use Tcl
:       By the way, would someone refresh my/our memory on why the tk
: perl5 binding didn't end up:

:     $l = new Label $f, text => "A simple demo written in tkperl";

: (without the leading "-", "text" could be bareworded, right?)

I'm not sure I want more barewords, but what's the purpose of the
leading dash?
--




Tue, 18 Mar 1997 21:39:07 GMT  
 Why you should not use Tcl

Quote:

>>> By the way, would someone refresh my/our memory on why the tk
>>> perl5 binding didn't end up:
>>> :     $l = new Label $f, text => "A simple demo written in tkperl";

>It's part of the standard tk way of naming variables.  Malcolm kept it
>because it's easier for him that way.  If you think about it, "-text"
>is really just a reference in a hashed array with the value "A simple
>demo written in tkperl".  

        Actually, the hashed array is precisely why I reason that the
leading dash should be unnecessary.  Since Malcolm's code receives the
parameters from perl as a hashed array, he should be able to easily
add the leading dash, if necessary, in the interface to the underlying
Tk code.

        I suspect that the leading dash is a Tk or TCL convention for
separating named parameters from their values, rather than naming
variables, per se.  Considering the other syntactic differences
between the TCL and the Perl bindings to Tk, why don't we drop the
leading dash?  The resulting code will be (IMHO) shorter *and* easier
to understand, a desirable goal.

        Sigh.  I suppose that before I speculate further (or even before
I've inserted my foot in my mouth this far), I should retrieve a
copy of tkperl5, et. al., and see how big a change it really is.

                                        Craig Milo Rogers



Wed, 19 Mar 1997 02:06:28 GMT  
 Why you should not use Tcl

Josh> : By the way, would someone refresh my/our memory on why the tk
Josh> : perl5 binding didn't end up:

Josh> :     $l = new Label $f, text => "A simple demo written in tkperl";

Josh> : (without the leading "-", "text" could be bareworded, right?)

Josh> I'm not sure I want more barewords, but what's the purpose of
Josh> the leading dash?  --

It's part of the standard tk way of naming variables.  Malcolm kept it
because it's easier for him that way.  If you think about it, "-text"
is really just a reference in a hashed array with the value "A simple
demo written in tkperl".  

John



Tue, 18 Mar 1997 23:30:51 GMT  
 Why you should not use Tcl

Quote:



> Josh> : By the way, would someone refresh my/our memory on why the tk
> Josh> : perl5 binding didn't end up:

> Josh> :     $l = new Label $f, text => "A simple demo written in tkperl";

> Josh> : (without the leading "-", "text" could be bareworded, right?)

> Josh> I'm not sure I want more barewords, but what's the purpose of
> Josh> the leading dash?  --

> It's part of the standard tk way of naming variables.  Malcolm kept it
> because it's easier for him that way.  If you think about it, "-text"
> is really just a reference in a hashed array with the value "A simple
> demo written in tkperl".  

> John

Not very related thread:

OK, now my copy of BigInt.pm begins with:

package Math::BigInt;



So I can use it like

use Math::BigInt 'BigInt';
$a = BigInt 2;

What about prize for lowering noise level in the code :-) ?

Ilya



Wed, 19 Mar 1997 01:31:29 GMT  
 Why you should not use Tcl


Quote:

>:   STk
>:
>:       (define f (make <Frame>))
>:       (define l (make <Label>  
>:                       :parent f
>:                       :text "A simple demo written in STklos"))
>:
>:   tkperl
>:
>:       $f = Frame::new($path);
>:       $l = Label::new($f, "-text" => "A simple demo written in tkperl");
>:
>:   tcl/tk
>:
>:       frame .f
>:       label .f.l -text "A simple demo written in tcl/tk"

>Actually, that's more noise characters in the perl than you need by a long shot.
>That's because

>    object->method(args)
>    CLASS::method(args)

>May always be expressed

>    method object args;
>    method CLASS args;

>This reduces our perl version to:

>    $f = new Frame $path;
>    $l = new Label $f, "-text" => "A simple demo written in tkperl";

>Which is considerably less busy, wouldn't you agree?  

>One of the results of Larry's attendance at a REXX symposium while
>he was writing perl's object system was an appreciation for REXXers
>dislike for line noise all over their code. :-)

[A partial version of this posting may just have escaped, sorry.]

That's not quite right, unfortunately. The two equivalent versions
    method CLASS args
    CLASS->method args
correspond to the version
    CLASS:method CLASS, args
(in other words, the subroutine itself gets passed an extra first argument
in the first two forms. This helps inherited method from determining which
class the call was actually for). tkperl was around before the new-fangled
versions "method CLASS args" and "CLASS->method args" were invented
(perl5alpha3 perhaps?). tkperl widget code already copes with both Tk/Tcl
pathnames and having a parent widget and I haven't added the extra
checks for a classname argument prepended too. It will get done. Since
I've been on leave this week, I've been doing some work on tkperl for
things like transparent remote processing via "proxy objects". These
are objects which can be treated as local objects but any method calls
get sent transparently to some remote process for execution. The Proxy
class itself if transport-independent (the Proxy::Tk derived class
uses the same "append to property" transport as Tk/Tcl "send").
Further, almost all data types (*) including objects and references to
lists, associative arrays and scalars get transparently frozen,
sent across to the remote process and thawed there so the programmer
can use subroutines and methods without bothering to encode complicated
data structures or worry about where they will be executed. A little
emacs server process similar to the "emacsserver" that handles
emacsclient requests means that a tkperl program can execute elisp
in a remote emacs process on the same X display. The next step is
thawing the lisp structures on the emacs side in such a way that
perl associative arrays, lists and references become their elisp
equivalents automatically.

--Malcolm

--

Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee



Thu, 20 Mar 1997 20:55:39 GMT  
 Why you should not use Tcl


Quote:

>>:       $f = Frame::new($path);
>>:       $l = Label::new($f, "-text" => "A simple demo written in tkperl");
>...
>>This reduces our perl version to:
>>    $f = new Frame $path;
>>    $l = new Label $f, "-text" => "A simple demo written in tkperl";

>    By the way, would someone refresh my/our memory on why the tk
>perl5 binding didn't end up:

>    $l = new Label $f, text => "A simple demo written in tkperl";

>(without the leading "-", "text" could be bareworded, right?)

Firstly, because there is still some of the orginal Tk/Tcl code
in tkperl which processes "-foo" arguments itself (especially in
the canvas code and some other bits for which tkperl just wraps
standard Tk calls in a wrapper to avoid Tcl parsing). Secondly,
lower-case barewords are especially deprecated. The preferred way
around this (well, i think *I* prefer it anyway), is to do
    use TkEnglish;
(that's alpha5, you'll currently have to do "use Configsubs" instead).
Then you can do
    $l->configure(Text => "A simple demo");
or whatever.

--Malcolm

--

Oxford University Computing Services
"Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee



Thu, 20 Mar 1997 21:06:41 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. awk, scheme, tcl, and/or perl (was: Why you should not use Tcl)

2. Why you should not use Tcl

3. Ever Wonder Why Not Everyone Uses Modules?

4. O_OBJECT uses warn() not croak(), why?

5. Ever Wonder Why Not Everyone Uses Modules?

6. Tcl and Tcl::Tk w/ Tcl 7.5, 7.6 and Tk 4.1, 4.2

7. Why Tcl "extensions suck" (Marshall/Ousterhout)

8. Why Tcl instead of Perl?

9. Why is perl faster then Tcl

10. Using perl inside of Tcl

11. using TCL or DBMs in Perl

12. Using Perl with Tcl/Tk

 

 
Powered by phpBB® Forum Software