Q: perl vs Tcl: complementary, orthogonal 
Author Message
 Q: perl vs Tcl: complementary, orthogonal

I think this thread can safely be put to rest in view of Richard
Stallman's recent post trashing TCL.

--




Thu, 13 Mar 1997 20:53:51 GMT  
 Q: perl vs Tcl: complementary, orthogonal

Quote:
>I think this thread can safely be put to rest in view of Richard
>Stallman's recent post trashing TCL.

Yeah, he got that one right, but he's supporting something even worse,
LISP. Would that he support Perl instead...

        -Kartik



Fri, 14 Mar 1997 07:12:21 GMT  
 Q: perl vs Tcl: complementary, orthogonal

: >I think this thread can safely be put to rest in view of Richard
: >Stallman's recent post trashing TCL.

: Yeah, he got that one right, but he's supporting something even worse,
: LISP. Would that he support Perl instead...

Well, he is looking for an extension language.  Perl is probably
percived as more heavy-weight than an extension language.

IMO, perl5 is a good language to extend, not the other way around.
--




Fri, 14 Mar 1997 19:50:17 GMT  
 Q: perl vs Tcl: complementary, orthogonal

Quote:
>I think this thread can safely be put to rest in view of Richard
>Stallman's recent post trashing TCL.



Not quite. Richard Stallman's recent post does not define the second
language they plan to provide.

For those who missed it I'll include it here (I've not seen it ib c.l.p yet).

---snip---
Date: Fri, 23 Sep 94 19:14:52 -0400


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
Followup-To: gnu.misc.discuss,comp.lang.tcl,comp.lang.scheme
Lines: 62

[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

---snip---

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.



Fri, 14 Mar 1997 20:53:57 GMT  
 Q: perl vs Tcl: complementary, orthogonal
Quote:

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

This was a silly thing to say and I withdraw it.

Over enthusiasm on my part. Sorry.

Regards,
Tim Bunce.



Sat, 15 Mar 1997 02:24:49 GMT  
 Q: perl vs Tcl: complementary, orthogonal

Quote:


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

[Licking my chops, salivating...It's only a day more 'till the release,
right :-)]

Quote:
>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.

I've been questioning their reasoning and motives for quite a while now...

        -Kartik



Fri, 14 Mar 1997 22:31:31 GMT  
 Q: perl vs Tcl: complementary, orthogonal

Quote:

>* 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.

Ah, the glorious days of FORTH: "find if [compile] else literal then"


Sun, 16 Mar 1997 04:42:42 GMT  
 Q: perl vs Tcl: complementary, orthogonal

    HL> Ah, the glorious days of FORTH: "find if [compile] else
    HL> literal then"

Its been years and years since I did serious Forth'ing, but I seem to
remember a bumper sticker that read:

    you forth love if honk then

:-)



Mon, 17 Mar 1997 05:18:50 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Q: perl vs Tcl: complementary, orthogonal or competition?

2. Qs: Perl vs. Lisp

3. embedding tcl vs. perl

4. perl vs tcl (was Re: New version of C-like interpreter available)

5. tcl vs. perl

6. tcl vs. perl

7. perl vs tcl

8. Expect/TCL vs Perl

9. embedding tcl vs. perl

10. System Administration - Perl vs Tcl.

11. Perl and-or-vs TCL

12. TCL Speed vs PERL

 

 
Powered by phpBB® Forum Software