PYTHON VS. PERL VS. TCL 
Author Message
 PYTHON VS. PERL VS. TCL

How does python compare with Perl and Tcl ? Has anyone compiled an analysis of
pros and cons of the three? Some metrics to be considered are:
1. Learning curve
2. Ease of use
3. Portablility
4. Execution speed
5. Extensibility
6. Development tools such as de{*filter*}s, profilers, code browsers
7. Scalability, i.e. scope of application.
8. Maintainability
9. Built-in Functionality ie. OS interface, GUI toolkits, Networking, etc.
10. Contributed code in the public domain
11. Popularity.
    Not that this implies too much, take m$oft windoze, for e.g ;-)

I just picked up the Python1.2 distribution and I am considering using it for some tools development. I like the OO features :-) .

Sat Nashikkar,
BNR.



Sat, 27 Sep 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

Well, I wasnt going to reply to this because a few quipy answers wasnt
really what was asked for, but I gotta reply to this high-bias piece...

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.

Quote:

> Subject: Re: PYTHON VS. PERL VS. TCL


> >How does python compare with Perl and Tcl ?

> It's better, obviously :-)

Oh yeah.

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

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

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

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

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

Quote:
> >6. Development tools such as de{*filter*}s, profilers, code browsers

> Python has a de{*filter*} (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
de{*filter*} 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.

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

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

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

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

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

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



Mon, 29 Sep 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

[... Stuff deleted...]

Quote:
>In fact, I believe someone has already written a script that takes a
>C header file and automatically generates a Python module that interfaces
>to all those functions.

Could you (or someone) post a site that has this (or other) python
extensions?  Given the modularity of python, these might actually
be useful.

Thanks
David Redish



Thu, 02 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL



read John originial article in

then I advise you do to do so.

I'm just going to answer a couple of points here, hopefully filling
in what John wasn't sure of.  In general, I agree with everything he's
said and respect his experience in these matters.

:> >1. Learning curve

Agreed: If you start with a Unix background, Perl is trivial to learn.
If you don't start with a Unix background, Perl is not trivial to learn.

:> >2. Ease of use

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

No, that's no true.  We're rapidly converging on a network module that
makes it trivial to say (for example):

    require TCP::Client;
    TCP::Client::connect("cs.berkeley.edu", "smtp");

I could give you a simple one of those right now.

I believe it was a darn shame that such things weren't provided
many, many years ago when perl first did networking.

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

No, perl never grafts anything into your name space unless you ask
it to.  e.g.

    require POSIX;
    POSIX::setsid();

But if you really want to, you can say

    use POSIX 'setsid';
    setsid();

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

Quite.

This statement of "Perl is mainly a tool language, and so really doesn't
have much to do outside of UNIX machines" is truly mystifying.  What's
a tools language?  What's a non-tools language?  While it's true that
Perl's been ported to virtually every Unix system in existence, it's also
been ported to Amiga, Atari, LynxOS, Mac, MPE, MS-DOS, MVS, Netware, OS/2,
VMS, Windows-NT, and Xenix.  The number of MS-DOS, OS/2, and NT questions
on comp.lang.perl is going up all the time.  I don't understand why you
think it doesn't apply to non-Unix platforms.

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

Lamentably.

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

Right.  Then again, I don't believe it was designed for that, although
it is used for it.  I'll append an article I wrote about this this morning.

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

If you've been working with the API and MakeMaker folk, they've
been trying hard to make the extension process clearer, both via
interface and documentation.

:> >6. Development tools such as de{*filter*}s, profilers, code browsers
:>
:> Python has a de{*filter*} (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
:de{*filter*} is more powerful than the Python one, for what that matters.

Really?  And you haven't even seen the new (unreleased) stuff.  Cool.

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

Hee. :-)

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

Um, exCUSE me?  OO is nothing vagule resembling a panacea guaranteeing
"scalable" code.  That's just BS that managers believe.  OO doesn't make
good programmers out of bad, and the bad programmers will still manage to
write poorly scalable code whatever paradigm they adopt.  It sickens me to
see how many blindly jump on the OO bandwagon for no good reason, thinking
it guarantees scalability, portability, maintainabilty, or proper design.
It doesn't.  It's still up to the programmer, and the number of bad
programmers in this world so far exceeds the number of good ones that
it's enough to make you want to run an antique book store.

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

Perl5 has real pointers.  And it's arrays and hash tables have always
scaled well.
:> >8. Maintainability
:>
:> Same as above. Python lends itself well to good software engineering IMHO.

Frankly, that's a crock as far as I can see.  Vide supra regarding OO
programming.

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

Good programmer program it in themselves, the rest don't.  And good
programmers are far harder to come by than most folks realize.

Actually, some of the 5.x compiler pragmata, warning-to-fatal promotions,
and module design technology actually do encouraging proper software
engineering, but again, the OO statement I made above still holds.

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

Larry Wall has been known to say he has the biggest software testing
organization in the world, although perhaps Microsoft's is bigger. :-)

Here's the article I posted this morning in which someone asked for speed
comparisons between perl and tcl.  I suspect they also largely hold for
speed comparisons between python and tcl.  Perl and Python speed comparisons
are much less dramatic.

--tom


:Well, I know there's no hard and fast answer to this, but I was wondering
:if there are any reasonable estimates as to how much slower (execution time)
:a typical Perl program might be, as compared to a C program to do the same
:thing.  (If you could, as a bonus, throw in a comparison to tcl, that'd
:be great too!)

Perl code varies in speed considerably.  In my experience, C code will range
from a bit more than 2 to as much as around 50 times faster than perl code
(that's O(e**1) to O(e**4), usually in the 5-10x range on average.  You'll
tend towards the low end of that range if you can spend most of your time
in the perl functions that have been compiled into C, like pattern
matching.  On the other hand, you'll tend towards the high end of the
range if you're spending all your time doing bit or byte compares, or
doing highly recursive function calls like Fibonacci (the latter due to
perl's stack overhead in processing function parameters, something which
is not unfixable).

:P.S. Was tcl derived from Perl, or vice versa?  I've been using Perl for
:quite some time, and only just started looking at tcl, and while there
:are obvious differences, there are some very obvious similarities. (Both
:are about 100 times better than shell programming, so who am I to complain
:about either? :-) )

No, perl and tcl are unrelated.  However, some of the superficial
similarities between tcl and perl are that both support interpolation of
variables into doubly-quoted strings and that in the absence of a return
statement, their functions both return the result of the last thing
evaluated.  While they both appear to be interpreted languages, perl
is actually less of an interpreter than tcl is (vide infra).

In my experience, perl code will on average be about ...

read more »



Thu, 02 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

Steven> In fact, I believe someone has already written a script that takes a
Steven> C header file and automatically generates a Python module that interfaces
Steven> to all those functions.

Has this been done?

Let's say I have a simple database library written in C and I would like
to use it from Python.  Is there a program to automate the glue code
writing?

I took a look at modulator.py which does something similar, but not
quite what I want in this case.

Actually, I made a stab at writing h2pymodule.py myself, but if
somebody has already finished, I'd like to hear about it.

I realize not everything can be made fully automatic, but much
handwork could be avoided in all cases, and simple function calls
could be 'glued' automatically.

Thanks,

Harri
--
==========================================================================



Sat, 04 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

Quote:

> Subject: Re: PYTHON VS. PERL VS. TCL



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

> I do not usually reply to obvious flame bait such as this. Sir, I
> co-implemented a entire system using Tcl as the embedded language,
> before we discovered Python. I have also tried on several occasions
> to learn Perl.

> In short, if you don't know something, you shouldn't insinuate it. This
> is the sign of immaturity, of ignorance, of someone who should be put in
> a KILL file.

Talking about KILL files and not using them is a sign of immaturity.
And telling people who's immature and who isnt is a major sign of
immturity. Bite me.

Quote:
> >Tcl clearly is superior for
> >creating your own simple embeded langauge.

> Strange. I'm working on my fourth system that uses Python as the embedded
> language. (The other two include an IRC client and a WWW browser.) I never
> even considered doing it in Tcl; Python is much nicer in this regard IMHO.

Perhaps if you had considered Tcl you would have chosen differently. I
would likely choose Scheme myself. Tcl makes writing your own langauge
constructs pretty damn easy. Python makes it pretty damn impossible.

Quote:
> >Python's "os-specific modules" are some of the worst things for
> >portability.

> Have you ever heard of os.py? It is an os-independent module that works
> on DOS, Mac, *or* Unix, depending on what system you are running.

Yes. Its Crap. Feel free to recall my email from a year ago on the
topic. The short line is that it is totally useless because you dont
find out your program is going to fail until you get to the os.FOO
where FOO isnt implemented on that system.

If you write a program that imports 'Posix', then you should, at that
moment, have a slim gaurentee that all the Posix calls (in the module)
will work on that platform. Thats the job of the guy making the port.

If you import 'os' then you have to then check its name space
explicitly to make sure that the calls you are gong to use are in
there.

Also 'os' is junk because it has stuff like execvp written in Python,
rather than simply calling the real function on the system, while
execv is in the Posix module. Its discoordinated nonsense.

Quote:
> >Well, I've written non-trivial extensions in all three of these
> >langauges, and Tcl is by far the easiest to extend.

> I haven't done any extensions in Perl, but I did get the opportunity to
> write extensions for both Tcl and Python. Python gives you functions to
> parse the data as you like, and keeps it typed; Tcl gives you a string.
> Python lets you easily create your own data types.

So? The point isnt how useful the language is OVERALL, the point was
how easy it is to write the extension portion.

Quote:
> In fact, I believe someone has already written a script that takes a
> C header file and automatically generates a Python module that interfaces
> to all those functions.

Thrills. Sorry, I dont like "this is probably buggy or wrong" code
generators. It is easier to Cut & Paste by hand than to read though
that stuff for errors.

Quote:
> >Python is not
> >trivial to extend, because the programmer has to manage a lot of GC

> This is contrary to my experience. Very little GC management is required.

Well, clearly your extensions werent as memory oriented. Thats fine.

Quote:
> >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 seriously doubt they are counting interpreter code. And even if they did,
> that's still about 30,000 lines of Python code.

Ok.. Then I guess I was wrong and it dosent exist.

Quote:
> >Besides, I find "big"
> >often means "poor design". Few things really need that much code.

> This statement is quite laughable. I agree that there is some "bloat",
> maybe even a lot, but programs of sufficient complexity will require a
> certain amount of code. There are programs millions of lines long - are
> you insinating that they could be done in, say, 10,000? Do you have any
> proof for this?

What the {*filter*}? I said _few_.. I didnt say none. _YES_ there ARE
programs millions of lines long. I would tend to think of them as
actually being 100+ different cooperating programs, but you can read
it however you want...

The point is that Big, relative to Small is generally a bad thing.
Most designs could be simplified and their size reduced, but people
tend to value the trivial benefit more than the simple, solid code.
They'd rather have big buggy programs than small working ones.

I got yer proof right here, buddy....

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

> Ah, the intellectualist. Care to tell us WHY they... "suck"? (I'm not
> saying that they do not, just that you should try and provide logic to
> go along with your opinions.)

Hmm, I find it hard to define what is is they are lacking which makes
them suck, as I dont know how to change or fix it. I just see that
they are not particularly maintainable, relative to each other or to
other langauges.

Quote:
> >["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".]

> I don't know if the site still exists; that is why I said "used to be."
> You see, if I don't know something, I *state* it. You might pay attention.

Yes, I see you stating things you dont know all the time.

--
John Redford (AKA GArrow) | 3,600 hours of tape.



Sat, 04 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

It just occurred to me that I can delete the polite, calm, humble
insults people are hurtling at each other very easily:  Any message with
the subject: "Re: PYTHON VS. PERL VS. TCL" gets deleted.  If anyone
has something constructive to say please change the subject so the rest
of us notice it.

Thanks for isolating yourselves in a playpen (KILL files,
"bite me", "Yes. Its Crap.", etc.).

-- Mark "x p >= hbar/2" Allman
-- Physics (Stat. Mech.), Univ. of Houston
-- Space Shuttle Ascent Flight Design/Analysis, Rockwell Space Ops. Co.



Sun, 05 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL
After saying some nice and sensible things...

Quote:

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

This could not be more of a mistatement.  If you have any sense
python's namespace scheme is a great advantage in writing reliable
code.  If you are a moron, you can write
   moduleA.classB.methodC = moduleD.instanceE.methodF
and all hell may break loose, but, again, only a moron would do
this for anything other than very special purposes.

That said, I would like to see the ability to "freeze" a namespace
so a module implementer can make abuses like this absolutely
impossible (I did an experiment along these lines).  Please, when
you complain publicly about things like this, include an example
so everyone can see just how obscure your complaint is.         -a.

====
Let's see if I can get Larry's attention here:
  Perl
Hi, Larry!



Sun, 05 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

Quote:

> Subject: Re: PYTHON VS. PERL VS. TCL


> es:

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

> This could not be more of a mistatement.  If you have any sense
> python's namespace scheme is a great advantage in writing reliable
> code.  If you are a moron, you can write
>    moduleA.classB.methodC = moduleD.instanceE.methodF
> and all hell may break loose, but, again, only a moron would do
> this for anything other than very special purposes.

Oh yeah. The safety of a module isnt at all enhanced by having any
control over what is in it. Its really a predictable and secure
langauge that lets the user redefine every data item and function in
any module at a whim. Its a {*filter*}ing benefit.

Only morons write bad code.. only morons try to hack into your python
embedding server by mucking with the namespace of modules on the
fly. Or is hacking your system a "very special purpose"?

Quote:
> That said, I would like to see the ability to "freeze" a namespace
> so a module implementer can make abuses like this absolutely
> impossible (I did an experiment along these lines).  Please, when
> you complain publicly about things like this, include an example
> so everyone can see just how obscure your complaint is.            -a.

Ah yes... Its such a great thing that he wants to be able to get rid
of it. Aaron, your request can be my example. You're obscure enough.

Just WHAT is the "great advantage" part here, Mr. Provide Examples?

--
John Redford (AKA GArrow) | 3,600 hours of tape.



Sun, 05 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL

Quote:

>> I do not usually reply to obvious flame bait such as this....

Well I do.  I do it because it's kinda fun.  I also think its good to
correct what I see as mistakes before they become "conventional
wisdom" (history suggests that unanswered propaganda evolves into
"fact").  You have some good ideas, jredford, but a touch more
diplomacy (and perhaps minimality) might be advised.  A lot of your
concerns are valid, and could be fixed -- especial if you turn down
the decibel level so we can listen without going deaf.

Quote:
>Perhaps if you had considered Tcl you would have chosen differently. I
>would likely choose Scheme myself. Tcl makes writing your own langauge
>constructs pretty damn easy. Python makes it pretty damn impossible.

If you want to write your own language within a language, try Common
Lisp's macro facility.  Here a programmer can build his/her own idioms
and constructs which no other programmer in the world will ever
understand, possibly including 'self' 6 months later (believe me, I
know).  It's lots of fun, but probably not a good idea.  You'd be
surprised how much you can do without resorting to building your own
constructs -- object encapsulation and procedural abstraction go a
long way.

[BTW: if you want to interpret another language in Python, I have
 a parser-generator you might be interested in.  It doesn't scream,
 but it's not as slow as you might think!]

I liked your suggestion that Python should have earlier bindings,
so that an undefined os-specific function is detected at load time
and not in the middle of a computation.  At present this would suggest
that one should use

   import neat_function from os_specific_module

(to get an error on load) in place of

   import * from os_specific_module

or

   import os_specific_module
   ...
       os_specific_module.neat_function(...)

and that implementations should never use errors such as

   # os_specific_module for itty-bitty-machines
   def neat_function(...):
       raise SystemError, "not implemented on this itty-bitty-machine"

In the long term, I think it might be nice if Python could do more early
module/function bindings at load time.  This would prevent some abuses
(which, unfortunately, can sometimes be useful) and have the added
benefit of making Python run faster.            -a.
====
In the long term, we're all dead.               -Keynes



Mon, 06 Oct 1997 03:00:00 GMT  
 PYTHON VS. PERL VS. TCL


Quote:
>I'm not Dan, but I have the impression that Java will really take off
>because the WWW is such a huge success.  From what I gather, Netscape,
>who dominates the WWW scene, is working with Sun on future WWW based
>products.  I would guess that Java is the language they will use as
>the base language.  Right now, about 60% of the browsers out there are
>NetScape and the number is climbing.  So, in the future, if the number
>of browsers out there that uses Java as the base agent language is 70%
>(a guess based on the combined strength of Netscape and Sun), then not
>many people are going to have access to all those cool Python
>agents/programs unless Python compiles to JavaVM (assuming that the
>browsers will accept programs/applets/agents or
>whatever-they-will-be-call in compiled form). . .

Well, I looked at the Java Web page and it seemed I couldn't do
anything interesting there because I needed Java (free for my own use,
fork out big bucks otherwise) to do anything.  If Sun's plan is to
sell all WWW providers a Java license and have every WWW browser
running Java, I doubt this will take off (although I'm not sure I have
my facts completely straight -- I gave up after about 5 minutes -- hey,
I'm a busy guy).

In my blissful ignorance I see two problems with compiling to JavaVM:
  1) Licensing.
  2) I'm dubious as to whether JavaVM can be interfaced nicely
     to C extensions to python, particularly if it uses a different
     memory management scheme.  If we can't use Python C extensions
     then all we've got is "brain dead python" and who cares?
     (For the same reason I don't think Stallman's vision of Python
     compiling to Scheme will ever materialize either.)

Quote:
>I think many of the ideas in S. Majewski's WWW page should be
>considered now for future versions of Python.  First, reference
>counting should be eliminated in favor of garbage collection which
>sets the anchor to other enhancements.  

Someone please jump in and point out that I'm being stupid, if I am.
(I'm no expert on this.)

One of the really nice things about Python is that it peacefully
coexists with C libraries with very few complications.  For example,
a C library can keep a pointer to a Python object, with no extra
overhead (such as registering the pointer in a table somewhere),
and there will be no problems whatsoever so long as the refcount
was incremented correctly.  Now, under a more intrusive GC strategy
such pointers must be either disallowed, or they must be registered
with the garbage collector, so that when the collector decides to
move the object, it will know to change the pointer too.  Bug city. Yuck.

Also, I imagine, the heap space would need to be managed in some complicated
way so that the C libraries can have "normal" heap behavior and python
can have fancy garbage collection.  If the scheme is to run fast, this
might involve using system dependant features on different platforms,
making portability much more complicated, no?

The main problems I see with the current scheme are
  1) once in a while circular references are useful (eg, for TkInter)
  2) the law of entropy suggests that if a Python process is active
     enough for long enough the memory will eventually grow to an
     arbitrary size with lots of tiny objects evenly distributed therein.
These are a concern, but please don't throw out portability and ease
of extension to solve them.  Other than that I don't understand your
assertion that GC would be the "anchor to other enhancements".
Please explain.         -a.

=====
If you feel like being cruel, ask a 6 year old if he can
count to 1000.  Then ask him to prove it.

Unfortunately the really smart ones will pull the
 "one, two, skip a few, a thousand"
trick.  This is irritating, but it ABSOLUTELY DOES
NOT JUSTIFY {*filter*}!



Tue, 07 Oct 1997 03:00:00 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Python Binding [Was: Re: PYTHON VS. PERL VS. TCL ]

2. jredford's flames and criticism (was: PYTHON VS. PERL VS. TCL )

3. THANKS: RE: PYTHON VS PERL VS TCL

4. Forth vs Python vs Perl

5. perl vs python vs icon

6. Newbie question: tcl vs perl and tkMotif vs tkX

7. Tcl/Tk vs. Perl and Python

8. Perl vs TCL (was: Execution speed of Perl?)

9. Tcl vs Python vs Java :: Apologies

10. Python vs Tcl vs Perl5

11. python vs java (vs tcl?) benchmarks

12. Tcl vs Python vs Java :: Apologies

 

 
Powered by phpBB® Forum Software