Re: PYTHON VS. PERL VS. TCL

jredford@lehman.com
Tue, 18 Apr 95 10:33:25 -0400

> From: "Steven Miale" <smiale@cs.indiana.edu>
> Subject: Re: PYTHON VS. PERL VS. TCL
>
> In article <9504131455.AA10039@seelebrennt.lehman.com>,
> <jredford@lehman.com> wrote:
> >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.

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

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

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

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

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

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

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

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

> >["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.
jredford@lehman.com       | 5 cans of Scotchguard.