I have done a lot of work in Python, Perl, and more recently in Tcl,
so I think I have more perspective here than someone who has just
glanced at some code.
> From: "Steven Miale" <smiale@cs.indiana.edu>
> Subject: Re: PYTHON VS. PERL VS. TCL
>
> In article <3megke$ni3@bcarh8ab.bnr.ca>, Sat Nashikkar <snash@bnr.ca> wrote:
> >How does python compare with Perl and Tcl ?
>
> It's better, obviously :-)
Oh yeah.
> >1. Learning curve
>
> Python has one of the smallest learning curves of any language I have
> ever learned, at least for someone with lots of experience with Algol
> derivatives. Perl looks like old UNIX shell languages, and Tcl... well,
> it is best described as taking the worst parts of LISP and COBOL.
Learning curve is influenced by what you already know. If you know C,
then Perl is trivial to learn. If you have a broad ammount of
experience, then Python is pretty trivial. If you are capable of
thinking simply, then Tcl is easy to learn. I found Tcl to have no
curve at all; it just went from 'know nothing' to 'know everything' in
a few minutes.
If you were starting from nothing, then Perl would likely have the
worst learning curve, being close to that for C. Tcl would likely be
the easiest to learn, if only because there was less to learn than in
Python.
> >2. Ease of use
>
> Again, Python wins IMHO. I don't think that I have _ever_ had to sit down
> and think about how to code a particular problem in Python. It just comes
> naturally.
Ah, no wonder I disagree with you people so much. Let's hope that
someone learning a language takes the time to stop and think about
what they are doing.
Ease of use depend on what you are doing.. If you want to write
networking code, then Python is BY FAR the easiest to use. Perl makes
this about as hard as C would. I havent tried it in Tcl, but I suspect
it is simply impossible.
On the other hand, if you want to write a piece of reliable code,
Python is your worst enemy. Python's practice of throwing around
namespaces in the interpreted langauge makes it _inheriently_
untrustworthy. Tcl restricts this type of game to the extension API,
and Perl dosent do it noticably at all.
Also, for generating reports, or doing system-related tasks perl
clearly is the best langauge for the task. Tcl clearly is superior for
creating your own simple embeded langauge.
> >3. Portablility
>
> Don't really think this matters; all three languages have been ported to
> a variety of systems. Perl is mainly a tool language, and so really doesn't
> have much to do outside of UNIX machines. Python has been ported to all,
> and also has OS-specific modules for each platform (UNIX, DOS, etc.)
These single minded replies.... The issue of where the interpreters
have been ported is a simple one. If it has been ported to your
platform, you can consider it, if not, then not. Case closed.
The far more interesting issue of the portability of the code written
in the langauge. Here perl is clearly superior because of the number
of operations gaurenteed to exist on multiple platforms. I dont see
why you feel perl is a Unix-mainly thing, or why a 'tool langauge'
would be.
Python's "os-specific modules" are some of the worst things for
portability. There is no gaurentee that any operations will exist on
all platforms, or even that operations will exist on any platform. You
just get lists of what IS available, which is an impractical subset.
The Perl strategy of providing a POSIX interface, and trying to
provide all of the POSIX calls is a much better plan.
Tcl just dosent come close in any of this, Tcl code is as portable as
the extentions you use with it. Raw Tcl is portable because its dull.
> >4. Execution speed
>
> Tcl is pretty slow. I don't know what the speed difference between Python
> and Perl is, though.
Well I'll let ya know. Tcl is durn slow. Python is reasonable fast,
and Perl is very fast.
The only one this is an issue for is Tcl, which is just too slow to do
a lot of work in directly.
> >5. Extensibility
>
> Python. Writing a C module is trivial; all the examples and helper functions
> that you could ever want have been provided.
Well, I've written non-trivial extensions in all three of these
langauges, and Tcl is by far the easiest to extend. Thats its claim to
fame after all. Python and Perl are roughly equal. Python is not
trivial to extend, because the programmer has to manage a lot of GC
and thread issues in really crude and ugly ways. Perl is just slightly
cryptic, but it is not terribly complex.
> >6. Development tools such as debuggers, profilers, code browsers
>
> Python has a debugger (pdb) and a profiler (profile); I don't know if it
> has a code browser yet, but that should be easy to implement. Dunno about
> Perl or Tcl.
Well Perl and Python might be tied for 'what they have', but the Perl
debugger is more powerful than the Python one, for what that matters.
Tcl has no tools that _I_ know of, which means little, but I have
found it impossible to write anything that needs tools to understand
in Tcl. I'd think trying to profile Tcl means you're using the wrong
language; seek speed elsewhere.
> >7. Scalability, i.e. scope of application.
>
> Very; having OO and modules is a big win. I forgot what the largest Python
> program is, but I believe it's well over 10,000 lines of code.
Well, i have seen mention, even years ago, of 70,000+ like python
applications. Perhaps they were counting the code for the interpreter.
Who knows. I have not conducted a survey, so I dont know what size you
can find for each langauge, and even then you wouldnt know if these
systems work well, or just happen to exist. Besides, I find "big"
often means "poor design". Few things really need that much code.
Tcl is quickly nonscalable for the reason of speed. Perl dosent scale
too well to very large data sets (though that may not be true now with
perl5). Python is as scalable as you can get, with real pointers for
memory handling and with reasonable speed.
OO is fine, but none of these langauges have anything like a pure
object model, so most of it is just hype, and you can do better with
C. Python's painful discontinuity between interpreter objects and API
objects is a huge limit on the usefulness of OO in it.
Perl and Python both have modules, and Perl's are slightly better
thought out. Personally I think that Modules without Interfaces is
a waste of time anyway.
> >8. Maintainability
>
> Same as above. Python lends itself well to good software engineering IMHO.
All of these langauges lend themselves to good software engineering,
and they are all more or less equally maintainable. That is, they all
kinda suck.
> >9. Built-in Functionality ie. OS interface, GUI toolkits, Networking, etc.
>
> All three languages have Tk support now. Python (in addition) has modules
> for SUIT and stdwin (portable GUIs), as well as X. It also has interfaces
> for OS calls and a socket library. Checking Contrib/, there are demos
> for RPC, POP and SMTP mail clients, etc.
Yes, well this isnt answering the question. Perl wins hands-down on
built-in functionality, as it has a huge number of system calls built
into it (for historical reasons). In the 'Standard Library' you get
with each of these, Python is somewhat ahead.
These are all issues of what you happen to get with the distribution.
What you CAN get is the next question...
> >10. Contributed code in the public domain
>
> Quite a bit - a lot of demo code comes with the standard distribution,
> and quite a bit of code is posted here. There used to be a contrib FTP
> site.
Tcl has 'very very good' Tk support for obvious reason. Tk is a fine
thing for the other languages to hook into. SUIT and stdwin both are
more than a little pathetic, and relative to Tk, are quite dead. A raw
X interface is like a disease you dont talk about in public, more so
when it dosent interface seamlessly with the Tk interface.
Tcl has some number of extentions which I dont know about, but for
both Perl and Python one can trivially name dozens of them.
["There used to be a contrib FTP site.".. Yeah, thats a good sign. You
could phrase that as "We lost the only site for contributed code".]
> >11. Popularity.
> > Not that this implies too much, take m$oft windoze, for e.g ;-)
>
> It's the least popular of the three, unfortunately. I don't think that
> this is a concern, though.
Oh certainly.. on the scale from Most to Least, it seems to be:
Perl...................Tcl....................................Python.
I suspect that if peopel realize that they can get Tk w/o Tcl, it
might become:
Perl.................................Python......................Tcl.
Popularity means a heck of a lot by the way. The popular langauges
get extensions written for them. The popular langauges have a much
larger base of "testing by doing" going on and more people to provide
fixed code. Popular langauges are learned by people before you hire
them.
> >I just picked up the Python1.2 distribution and I am considering using it for
> >some tools development. I like the OO features :-) .
>
> Have fun. Feel free to ask questions.
Certainly.
-- John Redford (AKA GArrow) | 3,600 hours of tape. jredford@lehman.com | 5 cans of Scotchguard.