Article 3847 of comp.lang.python: Newsgroups: comp.lang.tcl,comp.lang.python From: danj@netcom.com (Dan Janowski) Subject: Opinions? Tcl Python Perl, Virtues/failings Message-ID: Summary: Looking for opinions about virtues/failings of these languages Keywords: Tcl, Python, Perl Sender: danj@netcom2.netcom.com Organization: NETCOM On-line Communication Services (408 261-4700 guest) Date: Thu, 30 Mar 1995 06:12:15 GMT Lines: 34 Xref: nef.ens.fr comp.lang.tcl:17673 comp.lang.python:3847 I almost hate to pose this question because of the possible flaming thread that it may produce, but alas, I must. Simply, it has been asserted that the fact that Tcl is 'typeless' is a 'problem', mostly for reasons of speed, and that it has some syntactic failings (no a=1, $ to use variables, and such). Interp speed, although theoretically significant, has not bit me in any way that I couldn't take care of with a C binding. The lack of a=1 syntax attests to the regularity of the languange, every evaluated 'line' begins with a command, like 'set'. The non Tcl packages have Tk 'ports' but it somehow seems contrived. Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It looks like a language of regexps, seems messy, hard to read. Python, seemingly new in the fray, is interesting but has a wierd indention scheme for block definitions (while, for, if, etc). Both of them seem to suffer from many 'implied' operations and results. From a coding standpoint, the word basis of Tcl operations, as opposed to %^@: characters, means that the code is actually readable. Having named commands that do operations is a GOOD thing, as opposed to relying on non-alpha characters. My opinion is that all of these interps are for prototyping and growth applications that may become partially or completely compiled at some point. Fast, easy to remeber, english coding means less time is spent on being clever and more on the idea. Tcl seems to fit this notion more than Perl or Python. Opinions? -- danj@netcom.com | Dan Janowski | :-(insert witty comment here) New York, NY | Article 3855 of comp.lang.python: Newsgroups: comp.lang.tcl,comp.lang.python Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!usc!news.cerf.net!netlabs!lwall From: lwall@netlabs.com (Larry Wall) Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Message-ID: <1995Mar30.173753.19064@netlabs.com> Keywords: Tcl, Python, Perl Organization: NetLabs, Inc., Los Altos, California. References: Date: Thu, 30 Mar 1995 17:37:53 GMT Lines: 13 Xref: nef.ens.fr comp.lang.tcl:17696 comp.lang.python:3855 In article , Dan Janowski wrote: : My opinion is that all of these interps are for prototyping and growth : applications that may become partially or completely compiled at some : point. Fast, easy to remeber, english coding means less time is spent : on being clever and more on the idea. Tcl seems to fit this notion more : than Perl or Python. : : Opinions? Yes, those are opinions. :-) Larry Wall lwall@netlabs.com Article 3854 of comp.lang.python: Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!news.cac.psu.edu!news.pop.psu.edu!hudson.lm.com!godot.cc.duq.edu!toads.pgh.pa.us!news.pgh.net!newsfeed.pitt.edu!uunet!dove.nist.gov!usenet From: klm@nist.gov (Kenneth Manheimer) Newsgroups: comp.lang.tcl,comp.lang.python Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Date: 30 Mar 1995 12:41:23 -0500 Organization: National Institute of Standards and Technology Lines: 169 Message-ID: References: Reply-To: ken.manheimer@nist.gov NNTP-Posting-Host: coil.nist.gov In-reply-to: danj@netcom.com's message of Thu, 30 Mar 1995 06:12:15 GMT To: danj@netcom.com (Dan Janowski) X-Newsreader: (ding) Gnus v0.40 Xref: nef.ens.fr comp.lang.tcl:17695 comp.lang.python:3854 [Whoops, i initially responded to this via the python mailing list, which means it didn't get crossposted to comp.lang.tcl. I'm resending, including both newsgroups in the distribution. ken.] Dan Janowski (danj@netcom.com, message id ) wrote: > I almost hate to pose this question because of the possible flaming > thread that it may produce, but alas, I must. Well, i have a sick day here, and the topic is a dear one to my heart, so i'd like to take a few moments to address it. The relative virtues of these languages is an important question. Also, certainly, it is a complex one, difficult to address because it is so much easier to get a focus on the more superficial issues - syntax, simplicity of trivial programs, speed - than on the deeper, more stuctural issues - semantic power, data abstraction, management of complexity - that the dialogue can quickly become meaningless. The real question, in my view, is, which languages provide the biggest payoffs for effort invested? "Payoff" has different components for different people. However, one component that is always important for me, and one that i think transcends most application boundaries, is integratibility. When you build a system or a tool, will you be able to use it for more than just a single application? Will you be able to use all your tools together, gaining more leverage as you go, or are you always starting from scratch? Will you be able to go back and directly use, or indirectly adapt, code you have already developed for other purposes? I think python is the big winner in this regard. (I happen to think it is the big winner, in the scripting/extension domain, in most regards, but that's a whole nother story.) > Simply, it has been asserted that the fact that Tcl is 'typeless' is a > 'problem', mostly for reasons of speed, and that it has some syntactic Tcl's "typelessness" is a serious issue, and issues of speed are the most extremely superficial ramifications of it. The real problem has to do with data abstraction - tcl does not adequately provide it unless you create your own special extension data types, and then you sacrifice the integration benefits that come with native data types. When i explored tcl, i tried some substantial programming in it - a dns domain cataloguer - and i found myself needing a simple nested data structure. The problem is, i could *not* directly construct it in a manageable way. Ie, as best i recall, i had to use indirection through variable names, because eg nesting an array within an array is really just putting a string within a string, and the boundaries can be lost depending on the data. This is NOT NOT NOT adequate. Of course, you *can* create your own extension data types in tcl, to accomplish this kind of thing. However, this sacrifices the generality of powerful data types that are native to the language. Either you build extensions to implement your own fundamental structuring mechanisms, inventing extrinsic rudiments that ought to be intrinsic. Or you make disparate extension structures for each system you develop, and arrive at type-discrepancies that prevent good integration of the systems with eachother. In either case you sacrifice the ease and cleanliness of well-reconciled, native data structuring mechanisms, something which python offers to a profound degree. In my opinion, the lack of simple but sophisticated native data structures is one of the main impediments to building clean, large systems with tcl. That, together with the excessively rudimentary scoping mechanisms, convinced me that the effort necessary to do substantial things with the language would not nearly pay off in the integratibility i need from my tools. People say it is a simple language, i suggest it is simplistic, the distinction being that it is handy for doing very simple things, and not handy for doing less than simple things. > The non Tcl packages have Tk 'ports' but it somehow seems contrived. That's about as vague a criticism as i could imagine. I mean, the ports **are** contrived - contrived to implement the tk functions in the other languages. Question is, were the contrivances successful? I've only been fooled with, not done any substantial things, with tk and tkinter. (I have done very little with perl, in general.) I have the impression that they're both very effective, with tkinter having the benefit, in my perspective, of being python... > Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It > looks like a language of regexps, seems messy, hard to read. Python, As i said above, i have done very little with perl. When i first looked at it (twice, really, once during perl 3 and once during perl 4, i think), i was very daunted by the complexity of the language, and the difficulties in nesting data structures. (I have a feeble memory, in some ways, and the apparent burden on the programmer of using different operations to accomplish the same thing, depending on the object data types, was very daunting.) Evidently, perl 5 addresses the nesting problem, but still seems overly complex to me. Even supposing the complexity to be a misperception on my part, the reknowned difficulty in reading and adjusting established perl code, even your own code, betrays my integratibility criterion... > seemingly new in the fray, is interesting but has a wierd indention > scheme for block definitions (while, for, if, etc). Both of them seem Have you tried the language's indentation scheme, for any substantial purposes? It certainly is different. You may find it to be an improvement, as most people do who give it a real try. > scheme for block definitions (while, for, if, etc). Both of them seem > to suffer from many 'implied' operations and results. From a coding Not certain what you mean here by "implied operations and results", but i do know that you need to be well acquainted with python class object's intrinsic special disciplines (__init__, __add__, __del__, etc) before you can be confident using these objects. However, there's a ton of stuff you can do with python without even touching class objects, that i consider to be extremely simple and straightforward. And when you're ready for the class objects, the effort invested to understand the disciplines will pay off big time. > standpoint, the word basis of Tcl operations, as opposed to %^@: > characters, means that the code is actually readable. Having named > commands that do operations is a GOOD thing, as opposed to relying on > non-alpha characters. The "word basis" of tcl operations breaks down pretty quick. What about: [expr {($hostsNoticed > 1) ? "s" : ""}] The string-nature of the native types in tcl drives me *crazy*, when it comes to distingushing structure from syntax. Granted, this doesn't come up with simple structures holding simple data. But it is a real world problem when it comes to real tasks and real world data. (I also happen to be uncomfortable with a lot of C's syntax, which shows up more or less in all these scripting languages, but i'm probably in the minority on this in the Unix world. Sigh.) > My opinion is that all of these interps are for prototyping and growth > applications that may become partially or completely compiled at some Actually, i think the relative prominence of compiled languages will be decreasing as we continue into the network age, where passing code across the wire increasingly makes the network the computation (to warp a phrase:). > point. Fast, easy to remeber, english coding means less time is spent > on being clever and more on the idea. Tcl seems to fit this notion more > than Perl or Python. I see nothing "english" about tcl coding. It uses words, but so do most natural languages. Tcl's phrase structure is almost non- existent, in marked contrast to any modern spoken language. Most importantly, the structure is simplistic, in ways that become unwieldy when the ideas you are trying to express - the algorithms - are anything more than extremely simple. This is not a virtue. I realize that the simplicity of tcl *is* a real virtue for some applications. Have you tried doing some substantial things with each of the languages? If not, i would be interested to hear what your opinion is once you have gotten a feel for their relative versatility... Thanks for your indulgence, ken ken.manheimer@nist.gov, 301 975-3539 Article 3858 of comp.lang.python: Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!cs.utexas.edu!news.sprintlink.net!uunet!in1.uu.net!nntp.cac.washington.edu!donn From: donn@u.washington.edu (Donn Cave) Newsgroups: comp.lang.tcl,comp.lang.python Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Date: 30 Mar 1995 18:55:21 GMT Organization: University of Washington Lines: 12 Message-ID: <3leuqp$loh@nntp3.u.washington.edu> References: NNTP-Posting-Host: news.u.washington.edu Keywords: Tcl, Python, Perl Xref: nef.ens.fr comp.lang.tcl:17701 comp.lang.python:3858 If you're happy with Tcl, what's the problem? If someone else you work with is pushing in python's direction, he or she may have a different perspective on the role these languages play. You see Tcl as a tool for quick and dirty prototypes, others may see Python as a tool for serious finished applications. Without the perfect specification, you don't know if you have the perfect tool. It's a mistake to see Python and Tcl as comparable just because either can be embedded in a C program. Donn Cave, University Computing Services, University of Washington donn@cac.washington.edu Article 3863 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: jredford@lehman.com Subject: Re: Opinions? Tcl Python Perl, Virtues/failings In-Reply-To: Your message of "30 Mar 95 12:41:23 EST." Message-ID: <9503302028.AA27714@seelebrennt.lehman.com> Sender: root@cwi.nl (The Daemons of the Dark) X-Newsgroups: comp.lang.tcl,comp.lang.python Organization: CWI, Amsterdam References: Date: Thu, 30 Mar 1995 20:28:05 GMT Lines: 249 > From: klm@nist.gov (Kenneth Manheimer) > Subject: Re: Opinions? Tcl Python Perl, Virtues/failings > > Dan Janowski (danj@netcom.com, message id ) wrote: > > > I almost hate to pose this question because of the possible flaming > > thread that it may produce, but alas, I must. > > Well, i have a sick day here, and the topic is a dear one to my heart, > so i'd like to take a few moments to address it. The same but healthy, and more than a few moments. > The relative virtues of these languages is an important question. Also, > certainly, it is a complex one, difficult to address because it is so much > easier to get a focus on the more superficial issues - syntax, simplicity > of trivial programs, speed - than on the deeper, more stuctural issues - > semantic power, data abstraction, management of complexity - that the > dialogue can quickly become meaningless. > > The real question, in my view, is, which languages provide the biggest > payoffs for effort invested? "Payoff" has different components for > different people. However, one component that is always important for > me, and one that i think transcends most application boundaries, is > integratibility. When you build a system or a tool, will you be able > to use it for more than just a single application? Well, I have to point out that these paragraphs are fluffy & just serve to desmonstrate the author's bias in relief. Why? Well.. Syntax is just as valid as any other criteria, and is one of Python's seeming weaknesses. Speed is certainly as valid as anything else, and is another relative failing of Python. Payoff is generally defined as the return on effort invested, btw. Payoff is also not always an important factor. Certain problem domains need certain features, and the incidental cost isnt a part of the choice. For example, people who want to write truely universal tools (still) have to write them in K&R C. Despite the many failings of this dialect & langauge, it can deliver more total result than other langauges with might have better learning curves or "bug incidence":"lines of code" ratios. Lastly.. the relative virtues of these langauges isnt even vaguely important. There is no pressing need to unify these langauges, and so there is little need to throw any out in favour of others. Every individual is free to choose whcih one they think will be best, based on the langauges AND their knowledge of them. This said, its amusing to pretend its important.... > Will you be able to use all your tools together, gaining more leverage > as you go, or are you always starting from scratch? Will you be able > to go back and directly use, or indirectly adapt, code you have > already developed for other purposes? I think python is the big > winner in this regard. (I happen to think it is the big winner, in > the scripting/extension domain, in most regards, but that's a whole > nother story.) Well.. any langauge that allows modular programming will do you here. As any C++ programmer will tell you, it merley takes god-like willpower and diety inspired designs to write reusable code. > > Simply, it has been asserted that the fact that Tcl is 'typeless' is a > > 'problem', mostly for reasons of speed, and that it has some syntactic > > Tcl's "typelessness" is a serious issue, and issues of speed are the > most extremely superficial ramifications of it. The real problem has > to do with data abstraction - tcl does not adequately provide it > unless you create your own special extension data types, and then you > sacrifice the integration benefits that come with native data types. Here the author gets into explaining why Tcl kinda sucks, and does a good job of it. [...] > People say it is a simple language, i suggest it is simplistic, the > distinction being that it is handy for doing very simple things, and > not handy for doing less than simple things. This is a tad glib. My current work is "complex" and "Tcl". Tcl does just fine. > > The non Tcl packages have Tk 'ports' but it somehow seems contrived. I strongly agree. Tk isnt bad though, and I dont see any reason to not treat it as a kind of vague informal standard for graphical descriptions. Before the Tk-standard, everyone had their own thing, and while it wasnt contrived, it was often dumb. At least now its consistant & not too dumb. > > Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It > > looks like a language of regexps, seems messy, hard to read. Python, > > As i said above, i have done very little with perl. Well, I have used perl a lot.... Certainly the lineage is there, though usually I think of the lineage as being C, not the other things mentioned. The regexps part of perl is very good, but I have written many a perl program that dosent use any of them. > When i first looked at it (twice, really, once during perl 3 and once > during perl 4, i think), i was very daunted by the complexity of the > language, and the difficulties in nesting data structures. (I have a > feeble memory, in some ways, and the apparent burden on the programmer > of using different operations to accomplish the same thing, depending > on the object data types, was very daunting.) Evidently, perl 5 > addresses the nesting problem, but still seems overly complex to me. > > Even supposing the complexity to be a misperception on my part, the > reknowned difficulty in reading and adjusting established perl code, > even your own code, betrays my integratibility criterion... Reknowned? Perhaps rumoured. I have not had this trouble with my own perl code. Just this week I took a lexer written in perl (not by me) & modified the internals by hand to perform differently. I found it pretty easy to do, even though it involved huge ammounts of regexps & crypticly named variables. No, there is nothing about the langauge that causes the code to be unreadable, just poor coders, which plague any langauge. Anything 'odd' makes code unreadable. Python's funky indentation confuses the heck out of me now that I dont see it often. M3's CAPITAL LETTERS always takes a bit of time to adjust to. Perl's $fetish _for $bonus non-/[a-zA-Z]/ characters takes time to adjust to as well. After you adjust, it is very handy to have little $ & @ & % characters there telling you what something is. This is just the argument between short func names and foo_reallyLongFunctionNamesWithSpecialPrefixes. > > seemingly new in the fray, is interesting but has a wierd indention > > scheme for block definitions (while, for, if, etc). Both of them seem > > Have you tried the language's indentation scheme, for any substantial > purposes? It certainly is different. You may find it to be an > improvement, as most people do who give it a real try. I gave it a real try. I'm the person who originally hacked python-mode to parse #END tokens. I think its very readable, once you get used to it, but I dont think it is safe or good. > > scheme for block definitions (while, for, if, etc). Both of them seem > > to suffer from many 'implied' operations and results. From a coding Very true. I personally never make use of $_ in perl code. @_ is somewhat unavoidable, but one can quickly assign it to something with a real name. Python does this a lot less, but it shares a prediliction for having functions have side effects on arbitrary stack-frames with Tcl. > Not certain what you mean here by "implied operations and results", > but i do know that you need to be well acquainted with python class > object's intrinsic special disciplines (__init__, __add__, __del__, > etc) before you can be confident using these objects. However, > there's a ton of stuff you can do with python without even touching > class objects, that i consider to be extremely simple and > straightforward. And when you're ready for the class objects, the > effort invested to understand the disciplines will pay off big time. Simple & straightforward? From the guy who dismissed 'simplicity of trivial programs' as criteria? Yes, Im sure python makes a fine calculator. Yes, having written several Python classes I can tell you its paid off big-time for me. Oh yeah. Yawn. > > standpoint, the word basis of Tcl operations, as opposed to %^@: > > characters, means that the code is actually readable. Having named > > commands that do operations is a GOOD thing, as opposed to relying on > > non-alpha characters. I generally agree, as I despise operator AND FUNCTION overloading. But this 'word' thing is just downright ugly. I can enjoy a good perl with tons of weird characters around. It isnt the job of the langauge to be readable to one's boss. The COBOL thing has been done. > The "word basis" of tcl operations breaks down pretty quick. What > about: > > [expr {($hostsNoticed > 1) ? "s" : ""}] > > The string-nature of the native types in tcl drives me *crazy*, when > it comes to distingushing structure from syntax. Granted, this > doesn't come up with simple structures holding simple data. But it is > a real world problem when it comes to real tasks and real world data. This wasnt what was refered to, but yes, the string-thing generally sucks. Perl does this type of thing as well though, in the right places for it to help w/o being too much of a pain. > (I also happen to be uncomfortable with a lot of C's syntax, which > shows up more or less in all these scripting languages, but i'm > probably in the minority on this in the Unix world. Sigh.) Highly so, yes. You prefer...? > > My opinion is that all of these interps are for prototyping and growth > > applications that may become partially or completely compiled at some > > Actually, i think the relative prominence of compiled languages will > be decreasing as we continue into the network age, where passing code > across the wire increasingly makes the network the computation (to > warp a phrase:). Well, the former opinion is more right than the latter. There is a lot to be said for a good compile, and having a product that can 'eventually' compile arbitrary parts of itself is a good thing. Python is easilly the worst in this regard, with its split object model between Python objects and Python C-API objects. Tcl is probably the best, but at the cost of making it be In Your Face even when you dont care. > > point. Fast, easy to remeber, english coding means less time is spent > > on being clever and more on the idea. Tcl seems to fit this notion more > > than Perl or Python. Bah. Screw english. As for cleverness.. nothing wrong with letting some people be clever. The more time you spend 'on the idea' the more code you'll throw away when someone thinks of a clever way of doing it. Depends on what your constraints are. > I see nothing "english" about tcl coding. It uses words, but so do > most natural languages. Tcl's phrase structure is almost non- > existent, in marked contrast to any modern spoken language. Most > importantly, the structure is simplistic, in ways that become unwieldy > when the ideas you are trying to express - the algorithms - are > anything more than extremely simple. This is not a virtue. This is very true. And over & above this, English is a stupid goal for a computer langauge. Let's try to pretend we think programmers are skilled professionals, not people with degrees in English and a lot of free time. > I realize that the simplicity of tcl *is* a real virtue for some > applications. Have you tried doing some substantial things with each > of the languages? If not, i would be interested to hear what your > opinion is once you have gotten a feel for their relative > versatility... I've done substantial work with Python, Perl, & STk. I'm writing a Scheme interpreter (with a difference) and using Tcl a great deal now. Scheme is by far the best of the lot, followed by perl, followed by nothing. Tcl and Python are not better than (Scheme|Perl) at anything I have ever thought to do. -- John Redford (AKA GArrow) | 3,600 hours of tape. jredford@lehman.com | 5 cans of Scotchguard. Article 3867 of comp.lang.python: Path: nef.ens.fr!jussieu.fr!news.univ-angers.fr!news.univ-rennes1.fr!irisa.fr!news2.EUnet.fr!EU.net!howland.reston.ans.net!news2.near.net!das-news2.harvard.edu!cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!in22+ From: Ian S Nelson Newsgroups: comp.lang.tcl,comp.lang.python Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Date: Thu, 30 Mar 1995 23:22:30 -0500 Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA Lines: 50 Message-ID: <0jSsC6S00WBOI_z1BY@andrew.cmu.edu> References: NNTP-Posting-Host: andrew.cmu.edu In-Reply-To: Xref: nef.ens.fr comp.lang.tcl:17716 comp.lang.python:3867 Excerpts from netnews.comp.lang.python: 30-Mar-95 Opinions? Tcl Python Perl, .. by Dan Janowski@netcom.com > I almost hate to pose this question because of the possible flaming > thread that it may produce, but alas, I must. > > Simply, it has been asserted that the fact that Tcl is 'typeless' is a > 'problem', mostly for reasons of speed, and that it has some syntactic > failings (no a=1, $ to use variables, and such). Interp speed, [...etc...] Well my feeling on the subject is this: I'm not terribly fond of perl, it's kind of neat and it does some great things for people, but it's not my cup of tea. TCL is pretty cool, it's on just about everthing, you can even do gui stuff on a lot of machines (not OS/2 yet...) Byte and the other rags are billing it as a key piece of "agents" and the 411-interstate... I would definitely keep an eye on it. Python is really cool in my book. It's just like C, at least to me it is; and that's a very good thing, C and I have been together ever since pop bought MS C 2.0 for that ancient XT back in the glory days. Python picked up really well. It is also well suited for objects, OOP/D is one of my favorite things and it makes life really easy. There is also a large number of tools in the library which makes it that much more attractive. It doesn't have tha fame of TCL, but it's really cool. The OS/2 support isn't the greatest, but it's not too bad. Pretty good for prototyping and stuff like that. Then there is REXX and Java. I've always been bothered by the small amount of ligt REXX is given, it's a really powerful language for scripting, complete with new object ready versions and IBM supports it left and right. Java is Sun's brand new thing that I've been hearing about everywhere. It sounds like it's going to be big, but only time will tell... I could go on... The biggest problem with Perl, TCL, Python, etc. is that there are so many interpreted languages that are supposed to fit that "prototyping/batch/scripting" role. They all have a lot of things in there favor and a lot of them have huge weaknesses (I looked at this one perl for about half an hour, it was only 30-40 lines and I couldn't figure out how it was working.) My advice is this, they are all fairly simple to learn and use; find one you like, use it, if it becomes obsolete or something learn a new one. If you are starting a project that is long term and fairly important, I think you might be better off with a compiler and some good ANSI C++ or Ada or something. If you are just doing simple/small stuff, then jsut use what you like. -- Ian S. Nelson finger for PGP key Carnegie Mellon Computer Science/Math Home Page:http://www.contrib.andrew.cmu.edu/usr/in22/ian.html My opinions are not the school's, although they should be! Article 3864 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: mlutz@KaPRE.COM (Mark Lutz) Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Message-ID: <9503302126.AA15420@whitetaileddeer.KaPRE.COM> X-Sun-Charset: US-ASCII Sender: root@cwi.nl (The Daemons of the Dark) Organization: CWI, Amsterdam Date: Thu, 30 Mar 1995 07:26:16 GMT Content-Length: 4617 Lines: 135 This is one of those hopeless religious arguments that always come down to a matter of taste. But since you asked (and since I've got way too much time on my hands waiting for C++ builds! ;-), here's a few opinions from a Python perspective. All IMHO of course: - READABILITY. Python's easier to write and read. It has a simple statement-based, procedural syntax. Here's an example which intersects 2 sequences: def intersect(item1, item2): result = [] for x in item1: if x in item2: result.append(x) return result Here, item1 and item2 can be any sequence data type (lists, strings, user-defined classes, C extension types,..). - SEMANTIC POWER. Python's also usually considered more powerful than TCL, yet applicable to the same problem domains -- extension-language work, shell scripts, prototyping, etc. It's a step-up from TCL as a language, but still has great interfaces to/from C (dynamic loading, C modules act just like Python ones,..). Python's an object-oriented language, and has powerful built-in data and program structuring tools -- lists, dictionaries, modules, classes, exceptions,... For instance, if 'intersect' above were a class's method, we could overload the '&' operator to run it; we could also speed it up by using dictionaries, make it more generic... Here's a more relevant example: a simple Tk program in Python which puts up a window with a single button [this could be more compact]: from Tkinter import * # get the Tk module class Hello(Frame): # subclass our app def __init__(self, master=None): Frame.__init__(self, master) self.pack() self.make_widgets() def make_widgets(self): self.hello = Button(self, {'text': 'Hello GUI world!', 'command' : self.quit}) self.hello.pack({'side': 'left'}) Hello().mainloop() - TRY IT, YOU'LL LIKE IT... Have you ever tried Python? For instance, indentation syntax turns out to be pretty handy in a rapid-development language, and is an implicit quality-control feature (whatever that means :-). Because of its features and readability, Python can be better than TCL for non-trivial tasks. Like all dynamic languages, Python may not be the best tool for delivery of large, static components. But it's great for 'front-end' type tasks in mixed/hybrid systems, as a prototyping tool, etc. For example, I'm currently using it as an extension language for on-site customization of C++ binaries. But examples beat words: I've tacked-on another example below, from a module that redirects standard input/output streams to instances of classes that simulate files; probably not the best example, but enough to illustrate some distinctions between TCL and Python. Again, YMMV on all of this. And to be fair, Python's borrowed the Tk tool-kit, a TCL-land invention. But I'd encourage you to have a look at Python before closing-the-book. Mark Lutz lutz@kapre.com ------------------------------------------------------------------------ # file (module) redirect.py # part of an example that redirects i/o streams to objects import sys # load a module (python or C) class FakeStream: # a class def def close(self): # its methods pass def flush(self): pass def isatty(self): return 0 class Input(FakeStream): def __init__(self, input): # plus readline,... self.text = input def read(self, *size): if not size: result, self.text = self.text, '' else: bytes = size[0] result, self.text = self.text[:bytes], self.text[bytes:] return result class Output(FakeStream): def __init__(self): self.text = '' def write(self, string): self.text = self.text + string def writelines(self, lines): for line in lines: self.write(line) def testfunc(input, function, args): # a function def save_stdio = sys.stdin, sys.stdout sys.stdin = Input(input) # make instances sys.stdout = Output() try: # catch errors here apply(function, args) # run the function except: sys.stderr.write('error during function!\n') result = sys.stdout.text sys.stdin, sys.stdout = save_stdio return result # output as a string ------------------------------------------------------------------------ Article 3856 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!oleane!pipex!howland.reston.ans.net!news.sprintlink.net!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: Ken Manheimer Subject: Re: Opinions? Tcl Python Perl, Virtues/failings In-Reply-To: Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Sender: root@cwi.nl (The Daemons of the Dark) Content-Transfer-Encoding: 7BIT Organization: CWI, Amsterdam Mime-Version: 1.0 Date: Thu, 30 Mar 1995 17:29:54 GMT Content-Length: 8120 Lines: 167 Dan Janowski (danj@netcom.com) wrote: > I almost hate to pose this question because of the possible flaming > thread that it may produce, but alas, I must. Well, i have a sick day here, and the topic is a dear one to my heart, so i'd like to take a few moments to address it. The relative virtues of these languages is an important question. Also, certainly, it is a complex one, difficult to address because it is so much easier to get a focus on the more superficial issues - syntax, simplicity of trivial programs, speed - than on the deeper, more stuctural issues - semantic power, data abstraction, management of complexity - that the dialogue can quickly become meaningless. The real question, in my view, is, which languages provide the biggest payoffs for effort invested? The issue of payoffs has different components for different people. However, one component that is always important for me, and one that i think transcends most application boundaries, is integratibility. When you build a system or a tool, will you be able to use it for more than just a single application? Will you be able to use all your tools together, gaining more leverage as you go, or are you always starting from scratch? Will you be able to go back and directly use, or indirectly adapt, code you have already developed for other purposes? I think python is the big winner in this regard. (I happen to think it is the big winner, in the scripting/extension domain, in most regards, but that's a whole nother story.) > Simply, it has been asserted that the fact that Tcl is 'typeless' is a > 'problem', mostly for reasons of speed, and that it has some syntactic Tcl's "typelessness" is a serious issue, and issues of speed are the most extremely superficial ramifications of it. The real problem has to do with data abstraction - tcl does not adequately provide it unless you create your own special extension data types, and then you sacrifice the integration benefits that come with native data types. When i explored tcl, i tried some substantial programming in it - a dns domain cataloguer - and i found myself needing a simple nested data structure. The problem is, i could *not* directly construct it in a manageable way. Ie, as best i recall, i had to use indirection through variable names, because eg nesting an array within an array is really just putting a string within a string, and the boundaries can be lost depending on the data. This is NOT NOT NOT adequate. Of course, you *can* create your own extension data types in tcl, to accomplish this kind of thing. However, this sacrifices the generality of powerful data types that are native to the language. Either you build extensions to implement your own fundamental structuring mechanisms, inventing extrinsic rudiments that ought to be intrinsic. Or you make disparate extension structures for each system you develop, and arrive at type-discrepancies that prevent good integration of the systems with eachother. In either case you sacrifice the ease and cleanliness of well-reconciled, native data structuring mechanisms, something which python offers to a profound degree. In my opinion, the lack of simple but sophisticated native data structures is one of the main impediments to building clean, large systems with tcl. That, together with the excessively rudimentary scoping mechanisms, convinced me that the effort necessary to do substantial things with the language would not nearly pay off in the integratibility i need from my tools. People say it is a simple language, i suggest it is simplistic, the distinction being that it is handy for doing very simple things, and not handy for doing less than simple things. > The non Tcl packages have Tk 'ports' but it somehow seems contrived. That's about as vague a criticism as i could imagine. I mean, the ports **are** contrived - contrived to implement the tk functions in the other languages. Question is, were the contrivances successful? I've only been fooled with, not done any substantial things, with tk and tkinter. (I have done very little with perl, in general.) I have the impression that they're both very effective, with tkinter having the benefit, in my perspective, of being python... > Perl shows its lineage of replacing /bin/sh, awk, sed, and so on. It > looks like a language of regexps, seems messy, hard to read. Python, As i said above, i have done very little with perl. When i first looked at it (twice, really, once during perl 3 and once during perl 4, i think), i was very daunted by the complexity of the language, and the difficulties in nesting data structures. (I have a feeble memory, in some ways, and the apparent burden on the programmer of using different operations to accomplish the same thing, depending on the object data types, was very daunting.) Evidently, perl 5 addresses the nesting problem, but still seems overly complex to me. Even supposing the complexity to be a misperception on my part, the reknowned difficulty in reading and adjusting established perl code, even your own code, betrays my integratibility criterion... > seemingly new in the fray, is interesting but has a wierd indention > scheme for block definitions (while, for, if, etc). Both of them seem Have you tried the language's indentation scheme, for any substantial purposes? It certainly is different. You may find it to be an improvement, as most people do who give it a real try. > scheme for block definitions (while, for, if, etc). Both of them seem > to suffer from many 'implied' operations and results. From a coding Not certain what you mean here by "implied operations and results", but i do know that you need to be well acquainted with python class object's intrinsic special disciplines (__init__, __add__, __del__, etc) before you can be confident using these objects. However, there's a ton of stuff you can do with python without even touching class objects, that i consider to be extremely simple and straightforward. > standpoint, the word basis of Tcl operations, as opposed to %^@: > characters, means that the code is actually readable. Having named > commands that do operations is a GOOD thing, as opposed to relying on > non-alpha characters. The "word basis" of tcl operations breaks down pretty quick. What about: [expr {($hostsNoticed > 1) ? "s" : ""}] The string-nature of the native types in tcl drives me *crazy*, when it comes to distingushing structure from syntax. Granted, this doesn't come up with simple structures holding simple data. But it is a real world problem when it comes to real tasks and real world data. (I also happen to be uncomfortable with a lot of C's syntax, which shows up more or less in all these scripting languages, but i'm probably in the minority on this in the Unix world. Sigh.) > My opinion is that all of these interps are for prototyping and growth > applications that may become partially or completely compiled at some Actually, i think the relative prominence of compiled languages will be decreasing as we continue into the network age, where passing code across the wire increasingly makes the network the computation (to warp a phrase:). > point. Fast, easy to remeber, english coding means less time is spent > on being clever and more on the idea. Tcl seems to fit this notion more > than Perl or Python. I see nothing "english" about tcl coding. It uses words, but so do most natural languages. Tcl's phrase structure is almost non- existent, in marked contrast to any modern spoken language. Most importantly, the structure is simplistic, in ways that become unwieldy when the ideas you are trying to express - the algorithms - are anything more than extremely simple. This is not a virtue. I realize that the simplicity of tcl *is* a real virtue for some applications. Have you tried doing some substantial things with each of the languages? If not, i would be interested to hear what your opinion is once you have gotten a feel for their relative versatility... Thanks for your indulgence, ken ken.manheimer@nist.gov, 301 975-3539 Article 3859 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!howland.reston.ans.net!Germany.EU.net!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: mjc4y@server.cs.Virginia.EDU Subject: Re: Opinions? Tcl Python Perl, Virtues/failings In-Reply-To: Message-ID: <9503301907.AA20236@cobra.cs.Virginia.EDU> Posted-Date: Thu, 30 Mar 1995 14:07:04 -0500 Sender: root@cwi.nl (The Daemons of the Dark) Reply-To: conway@uvacs.cs.virginia.edu Organization: CWI, Amsterdam References: Date: Thu, 30 Mar 1995 19:07:04 GMT Return-Path: Lines: 16 I forwarded Ken's mail off to wayne@icemcfd.com who keeps a pretty interesting collection of articles on this subject, that many of you might already know about: http://icemcfd.com/tcl/comparison.html Perhaps if this thread turns into something long lived, we can condense them all into a single submission to this page? ---------------------------------------------------------------------------- Matthew Conway University of Virginia Dept. of Computer Science Charlottesville, VA 22901 conway@Virginia.EDU http://uvacs.cs.virginia.edu/~mjc4y ---------------------------------------------------------------------------- Article 3865 of comp.lang.python: Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!uwm.edu!news.alpha.net!news.mathworks.com!zombie.ncsc.mil!gmi!msunews!harbinger.cc.monash.edu.au!newshost.anu.edu.au!newsmaster From: graham.matthews@maths.anu.edu.au Newsgroups: comp.lang.python Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Date: 30 Mar 1995 23:17:17 GMT Organization: Australian National University Lines: 20 Message-ID: <3lfe5t$hnk@manuel.anu.edu.au> References: NNTP-Posting-Host: 150.203.33.48 Ken Manheimer writes: >Tcl's "typelessness" is a serious issue, and issues of speed are the >most extremely superficial ramifications of it. The real problem has >to do with data abstraction - tcl does not adequately provide it >unless you create your own special extension data types, and then you >sacrifice the integration benefits that come with native data types. I agree that Python's data abstraction mechanisms are better than Tcl's. However there is one small thing I would like to see in Python (which maybe you can do?), and it would boost the integratedness of Python. And this thing is to be able to inherit from inbuilt classes. I wanted to make a sub-class of a file object, but could not it seems. graham -- Je suis pour le communisme Je suis pour le socialisme Je suis pour le capitalisme Parce que je suis opportuniste Article 3860 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!math.ohio-state.edu!cs.utexas.edu!news.sprintlink.net!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: "Steven D. Majewski" Subject: Re: Opinions? Tcl Python Perl, Virtues/failings In-Reply-To: <9503301907.AA20236@cobra.cs.Virginia.EDU> X-Sender: sdm7g@elvis.med.Virginia.EDU Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Sender: root@cwi.nl (The Daemons of the Dark) Organization: CWI, Amsterdam Mime-Version: 1.0 Date: Thu, 30 Mar 1995 19:33:27 GMT Lines: 39 On Thu, 30 Mar 1995 mjc4y@server.cs.virginia.edu wrote: > > I forwarded Ken's mail off to wayne@icemcfd.com who keeps a pretty > interesting collection of articles on this subject, that many of you > might already know about: > > http://icemcfd.com/tcl/comparison.html Now that you've mentioned it: Adam Sah has a revised version of his "Tcl Considered Harmful" at: ( The original was part of the Stallman "Why you should not use Tcl" gnu.misc.discuss thread. ) I have some links to that, Wayne Christopher's comparisons, Adam Sah's online papers, and a few other bits of that argument ( or was it a "negation" ? ) at: ... Which is part of the Programming Language Critiques page at : ... Which I haven't widely advertised until now, as I'm trying to squeeze in time to finish construction of that page and clean up and reorganize some of the "agents" stuff on my WWW-server. ---| Steven D. Majewski (804-982-0831) |--- ---| Computer Systems Engineer University of Virginia |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| Box 449 Health Science Center Charlottesville,VA 22908 |--- Article 3869 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!oleane!pipex!howland.reston.ans.net!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: danj@netcom.com (Dan Janowski) Subject: Re: Opinions? Tcl Python Perl, Virtues/failings Message-ID: <199503310549.VAA18893@netcom13.netcom.com> Sender: root@cwi.nl (The Daemons of the Dark) Organization: CWI, Amsterdam Date: Fri, 31 Mar 1995 05:49:11 GMT Lines: 31 Thanks for your response. It was exactly what I was looking for. I am considering learning yet another language, Python, and I was looking for your well formed comparison. > Will you be able to use all your tools together, gaining more leverage > as you go, or are you always starting from scratch? Will you be able This is one of the issues that I hold to be very important. Tcl has given me a reasonable amount of re-use, but not as much as I suspect that I can get. The more I use itcl (OO extensions) to make classes, the more I re-use. So I started wondering if there wasn't another system that has a better library mgmt scheme and a better, and built in, OO scheme. Python seems to have both. > unless you create your own special extension data types, and then you > sacrifice the integration benefits that come with native data types. I have hit this. Compiling invariably works against the extensibility and portability of code. > ken > ken.manheimer@nist.gov, 301 975-3539 Thanks again. Dan -- Dan Janowski danj@netcom.com New York, NY Article 3861 of comp.lang.python: Newsgroups: comp.lang.python Path: nef.ens.fr!jussieu.fr!news.univ-angers.fr!news.univ-rennes1.fr!irisa.fr!news2.EUnet.fr!EU.net!sun4nl!cwi.nl!cwi.nl!python-list-request From: "Steven D. Majewski" Subject: Re: Opinions? Tcl Python Perl, Virtues/failings (fwd) X-Sender: sdm7g@elvis.med.Virginia.EDU Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Sender: root@cwi.nl (The Daemons of the Dark) Organization: CWI, Amsterdam Mime-Version: 1.0 Date: Thu, 30 Mar 1995 19:48:35 GMT Lines: 84 [ As I was answering from the python mailing list and not the newsgroup, I also didn't include comp.lang.tcl and comp.lang.perl, however, rather that crossposting the discussion everywhere, I'll just forward the previous message, with some additional comments included to comp.lang.misc. ( If we're going to have another "language war", let's not clutter up the all the relevant comp.lang groups. ) ] Anyway, the most relevant quote from John Ousterhout himself is: | I didn't design Tcl for building huge programs with 10's or 100's of | thousands of lines of Tcl, and I've been pretty surprised that people | have used it for huge programs. What's even more surprising to me is | that in some cases the resulting applications appear to be manageable. | This certainly isn't what I intended the language for, but the | results haven't been as bad as I would have guessed. In my opinion, not "as bad as I would have guessed" is not good enough. That's why I haven't particularly objected to safe-tcl for enabled-mail applications, where the scripts are typically going to be in that < 100 lines range, but I am frightened at the intent to turn it into a general purpose distributed programming language. ( The fact that Sun is also promoting another (almost Python-like ;-) language - Java - for distributed applications, shows that they are also aware of Tcl's limitations. ) ---| Steven D. Majewski (804-982-0831) |--- ---| Computer Systems Engineer University of Virginia |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| Box 449 Health Science Center Charlottesville,VA 22908 |--- ---------- Forwarded message ---------- Date: Thu, 30 Mar 1995 14:33:27 -0500 (EST) From: Steven D. Majewski To: conway@server.cs.virginia.edu Cc: python-list@cwi.nl Subject: Re: Opinions? Tcl Python Perl, Virtues/failings On Thu, 30 Mar 1995 mjc4y@server.cs.virginia.edu wrote: > > I forwarded Ken's mail off to wayne@icemcfd.com who keeps a pretty > interesting collection of articles on this subject, that many of you > might already know about: > > http://icemcfd.com/tcl/comparison.html Now that you've mentioned it: Adam Sah has a revised version of his "Tcl Considered Harmful" at: ( The original was part of the Stallman "Why you should not use Tcl" gnu.misc.discuss thread. ) I have some links to that, Wayne Christopher's comparisons, Adam Sah's online papers, and a few other bits of that argument ( or was it a "negation" ? ) at: ... Which is part of the Programming Language Critiques page at : ... Which I haven't widely advertised until now, as I'm trying to squeeze in time to finish construction of that page and clean up and reorganize some of the "agents" stuff on my WWW-server. ---| Steven D. Majewski (804-982-0831) |--- ---| Computer Systems Engineer University of Virginia |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| Box 449 Health Science Center Charlottesville,VA 22908 |---