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.
>Learning curve is influenced by what you already know. If you know C,
>then Perl is trivial to learn.
Really? I had been programming C for over seven years before trying to pick
up Perl. I don't see any similarities at all. Perl has much more in common
with older UNIX scripting languages like Awk.
>If you are capable of thinking simply, then Tcl is easy to learn.
Fascinating. I guess I am not capable of thinking simply :-) since Python
was easier for me to learn.
I teach a class in C++. I am willing to give them printouts of Perl, Tcl,
and Python code, and ask them which one they understand. What language would
you bet on?
>Ah, no wonder I disagree with you people so much.
Perhaps it is because you are always wrong :-)
>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.
>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.
>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.
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.
>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, 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.
>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?
>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.)
>["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.
Steve
-- Steven Miale <http://www.cs.indiana.edu/hyplan/smiale.html>