tcl vs. perl
John F Nielsen
Because the webserver I am now using uses embedded tcl, I have started to
learn it. Typically, I program w/perl 5. Perhaps I haven't played enough
w/it yet, but tcl seems cruder than perl. I'm tempted to use tcl
only is cases where speed really matters (since it's embedded), and
switch to perl for everything else.
(As a side note, w/regards to speed, with the perl5 database package I wrote,
it's more than 10 times slower than using embdeed tcl. So, for serious
database work, tcl has an advantage).
Can anything think of a case, where a problem is solved much eaiser using tcl
than perl. What advantages does tcl have over perl as a scripting language?
john
Tom Christiansen
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
jnie...@magnus.acs.ohio-state.edu (John F Nielsen) writes:
:Because the webserver I am now using uses embedded tcl, I have started to
:learn it. Typically, I program w/perl 5. Perhaps I haven't played enough
:w/it yet, but tcl seems cruder than perl. I'm tempted to use tcl
:only is cases where speed really matters (since it's embedded), and
:switch to perl for everything else.
You can have embedded perl as well, you know. The Apache server
has it, as does O'Reilly's.
:(As a side note, w/regards to speed, with the perl5 database package I wrote,
:it's more than 10 times slower than using embdeed tcl. So, for serious
:database work, tcl has an advantage).
That's pretty crazy. Typically perl is about 5x to 50x faster than tcl,
both because perl is byte-compiled and tcl is only interpreted, and also
because of better data structure and regexp support in perl. You must be
doing something abysmally wrong. You haven't explained how much is in C,
how much in perl, how much in tcl, so it's hard to judge what's really
happening.
:Can anything think of a case, where a problem is solved much eaiser using tcl
:than perl. What advantages does tcl have over perl as a scripting language?
Tcl has the advantage that as a minimalist metalanguage, it allows you to
make new languages by its very redefining syntax on the fly. For good and
for bad and maybe even for evil, this is because tcl is really little more
than csh + lisp + cpp. Tcl shines brightest when you're using it for its
intended purpose as a glue language, much like the shell, but often bombs
when you try to do full applications programming in it. One of tcl's cute
points is that John managed to finally get people to (nearly) always put
braces where God and Dennis intended. :-)
On the other hand, perl is a more traditional programming language with
more intuitive evaluation rules and the full support you'd expect from a
"real" programming language. For a variety of reasons, it is far better
suited to general-purpose programming than is tcl. Perl has an underlying
foundation that's surprisingly sophisticated and carefully designed, much
more so than is readily apparent to the casual observer. It's one of the
few "scripting" languages (whatever the heck that means) that doesn't bomb
out on you early as your appplication grows, which means that your
prototype doesn't have to be rewritten in C. Contrasted with tcl, perl
makes few attempts at minimalism. Since big programming languages often
make little programs, and little programming languages make big programs,
perl tries to apply the DWIMmer and dweomer approach so you can write
small programs and get home to see your kids before they've moved away.
--tom
--
Tom Christiansen Perl Consultant, Gamer, Hiker tch...@mox.perl.com
"With a PC, I always felt limited by the software available.
On Unix, I am limited only by my own knowledge." --Peter J. Schoenster
Eric Palmer
Well like usual Tom has sparked my interest.
So what is
DWIMmer and dweomer?
Nate Patwardhan
John,
: Can anything think of a case, where a problem is solved much eaiser using tcl
: than perl. What advantages does tcl have over perl as a scripting language?
The only advantage of using tcl/tk over Perl would be in terms of
embedding tcl code in C, where Perl is a bit tougher. In terms of
everything else, well, Perl's Tk extension is really good, and Perl's
syntax is much more reasonable than most of the tcl 'prefix-isms.'
Don't get me wrong, I think tcl is an extremely clever language that
works very well with C, but the syntax is herendous. Kind of reminds
me of the (first) C-based scripting language I wrote, which now
precedes party jokes that begin with "so a dog walks up to a bar ...
and set .var(x) 20 ..." You get the picture.
Perl's parsing capabilities are far easier than tcl's from what I can
tell, and Perl emcompasses (for the better) many other C-isms that I
wish would appear in tcl.
Buh-bye.
Nate
n...@nfic.com
John F Nielsen
In article <4pkam5$9...@csnews.cs.colorado.edu>,
Tom Christiansen <tch...@mox.perl.com> wrote:
> [courtesy cc of this posting sent to cited author via email]
>
>In comp.lang.perl.misc,
> jnie...@magnus.acs.ohio-state.edu (John F Nielsen) writes:
>:Because the webserver I am now using uses embedded tcl, I have started to
>:learn it. Typically, I program w/perl 5. Perhaps I haven't played enough
>:w/it yet, but tcl seems cruder than perl. I'm tempted to use tcl
>:only is cases where speed really matters (since it's embedded), and
>:switch to perl for everything else.
>
>You can have embedded perl as well, you know. The Apache server
>has it, as does O'Reilly's.
>
>:(As a side note, w/regards to speed, with the perl5 database package I wrote,
>:it's more than 10 times slower than using embdeed tcl. So, for serious
>:database work, tcl has an advantage).
>
>That's pretty crazy. Typically perl is about 5x to 50x faster than tcl,
>both because perl is byte-compiled and tcl is only interpreted, and also
>because of better data structure and regexp support in perl. You must be
>doing something abysmally wrong. You haven't explained how much is in C,
>how much in perl, how much in tcl, so it's hard to judge what's really
>happening.
>
>:than perl. What advantages does tcl have over perl as a scripting language?
>
>make new languages by its very redefining syntax on the fly. For good and
>for bad and maybe even for evil, this is because tcl is really little more
>than csh + lisp + cpp. Tcl shines brightest when you're using it for its
>intended purpose as a glue language, much like the shell, but often bombs
>when you try to do full applications programming in it. One of tcl's cute
>points is that John managed to finally get people to (nearly) always put
>braces where God and Dennis intended. :-)
>
>On the other hand, perl is a more traditional programming language with
>more intuitive evaluation rules and the full support you'd expect from a
>"real" programming language. For a variety of reasons, it is far better
>suited to general-purpose programming than is tcl. Perl has an underlying
>foundation that's surprisingly sophisticated and carefully designed, much
>more so than is readily apparent to the casual observer. It's one of the
>few "scripting" languages (whatever the heck that means) that doesn't bomb
>out on you early as your appplication grows, which means that your
>prototype doesn't have to be rewritten in C. Contrasted with tcl, perl
>make little programs, and little programming languages make big programs,
>perl tries to apply the DWIMmer and dweomer approach so you can write
>small programs and get home to see your kids before they've moved away.
>
Cameron Laird
In article <4pkam5$9...@csnews.cs.colorado.edu>,
Tom Christiansen <tch...@mox.perl.com> wrote:
> [courtesy cc of this posting sent to cited author via email]
>
>In comp.lang.perl.misc,
> jnie...@magnus.acs.ohio-state.edu (John F Nielsen) writes:
>:Because the webserver I am now using uses embedded tcl, I have started to
>:learn it. Typically, I program w/perl 5. Perhaps I haven't played enough
.
.
>You can have embedded perl as well, you know. The Apache server
>has it, as does O'Reilly's.
>
>:(As a side note, w/regards to speed, with the perl5 database package I wrote,
>:it's more than 10 times slower than using embdeed tcl. So, for serious
>:database work, tcl has an advantage).
>
>That's pretty crazy. Typically perl is about 5x to 50x faster than tcl,
a Tcl embedding with forked Perl processes. He seems to
understand this isn't "fair", but wasn't aware of the
technology for embedding Perl.
.
['bit of overkill
on performance is-
sues]
.
.
>:Can anything think of a case, where a problem is solved much eaiser using tcl
>:than perl. What advantages does tcl have over perl as a scripting language?
>
>Tcl has the advantage that as a minimalist metalanguage, it allows you to
>make new languages by its very redefining syntax on the fly. For good and
>for bad and maybe even for evil, this is because tcl is really little more
>than csh + lisp + cpp. Tcl shines brightest when you're using it for its
>intended purpose as a glue language, much like the shell, but often bombs
>when you try to do full applications programming in it. One of tcl's cute
Mr. Nielsen, please understand that there are
small European principalities devoted to de-
bating "Tcl vs. Perl" as a tourist attraction.
Well, that's perhaps an exaggeration, but cer-
tainly it's a topic that has been done before
<URL:http://www.perl.com/perl/versus/asherman-
on-tcl.html>. Explanation of the highlights
has been refined to the point that Tom can
probably write this stuff in his sleep. The
nice thing is that he writes accurately.
I'll express some of the same points just a
bit differently: use Tcl if
1. you think of yourself binding the
"scripting" (and Tom is utterly
correct when he quotes that word)
part of your application closely
with C codings;
2. you like the LISP attitude of
writing a domain-specific language
for every application (but then,
why not use scsh? That's a differ-
ent question);
3. through historical accident you're
more comfortable with Tcl; and/or
4. Tcl happens to have extensions that
fit your problem better than the
corresponding ones for Perl (example:
there's no engineering reason not to
build a great SNMP application with
Perl, but Scotty <URL:http://star
base.neosoft.com/~claird/comp.lang.
tcl/scotty.html> already exists.
Peter da Silva emphasizes that Tcl promotes the
program-data duality. In fact, it's also
straightforward to write Perl applications that
act on Perl scripts, but I agree that Tcl has
at least an attitudinal edge.
That's about it. For everything else that comes
to my mind, Perl is about the same as Tcl, or
superior.
Myself, I mostly use Tcl this year.
.
.
.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 623 8000 #227
+1 713 996 8546 FAX
Steve Simmons
Tom Christiansen <tch...@mox.perl.com> writes a lot of stuff I generally
agree with. However . . .
>On the other hand, perl is a more traditional programming language with
>more intuitive evaluation rules and the full support you'd expect from a
>"real" programming language.
`more intuitive evaluation rules'? Cough, gasp, *wheeze* :-). Sure,
if you cut your teeth on awk, sed, C and sh (as I did, and as Tom did,
and as Larry did). But for the average non-programmer who has to do the
odd bit of scripting, tcl/tk is a much more approachable language.
Without sarcasm, I'd say that tcl is the BASIC of scripting languages
while perl is the C++. Both are useful tools, both have their places.
I'd hate to give up either one, and refuse to get into any silly debates
over which one to use exclusively. As someone said recently over in
comp.org.usenix, Real Programmers programs in whatever language is
appropriate for the job. Toms piece did a good job of talking about when
tcl is appropriate and where perl is appropriate.
Donal K. Fellows
In article <4pkghb$e...@bill-graham.nfic.com>,
Nate Patwardhan <n...@bill-graham.nfic.com> wrote:
> Perl's parsing capabilities are far easier than tcl's from what I can
> tell, and Perl emcompasses (for the better) many other C-isms that I
> wish would appear in tcl.
As long as you are not parsing something coming out of Tcl. Unless
I've missed a way of scanning a string in perl for a character in a
set (which doesn't involve regexps, which have been really awful in
some performance tests I've run). If you have output from Tcl, it is
much easier to stick with using Tcl to process it if you can.
Perl's references are rather neat though (I use them a lot)
Donal.
--
Donal K. Fellows, (at work) | Donal K. Fellows, (at home)
Dept. of Computer Science, | 6, Randall Place, Heaton,
University of Manchester | Bradford, BD9 4AE
U.K. Tel: ++44-161-275-6137 | U.K. Tel: ++44-1274-401017
fell...@cs.man.ac.uk (preferred) | do...@ugglan.demon.co.uk (if you must)
--------------------------------------------------------------------------
<http://r8h.cs.man.ac.uk:8000/> for my home page
Larry W. Virden
For that matter, a new version f nvi that I've been playing with
even has perl 5 embedded, but then, I suspect that at least one of you
out there know that, cause I think he was the one who added it...
--
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
Tom Christiansen
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
fell...@cs.man.ac.uk (Donal K. Fellows) writes:
:As long as you are not parsing something coming out of Tcl. Unless
:I've missed a way of scanning a string in perl for a character in a
:set (which doesn't involve regexps, which have been really awful in
:some performance tests I've run).
It's not Perl -- it's your tests. Regexps are fast. Show me the code,
and I'll speed it up by an order of magnitude or so.
Mike Heins
. (t...@best.com) wrote:
: In article <4pk7j3$a...@charm.magnus.acs.ohio-state.edu> jnie...@magnus.acs.ohio-st
:
: Because the webserver I am now using uses embedded tcl, I have started to
: learn it. Typically, I program w/perl 5. Perhaps I haven't played enough
: only is cases where speed really matters (since it's embedded), and
: switch to perl for everything else.
: (Both Tcl and Perl can be embedded.)
:
: For anything complex or large, I strongly recommend staying away from
: Perl. Perl has some really serious design flaws that make it
: difficult to write large programs that are reasonably robust:
: basically, instead of giving you a runtime error when you do something
: wrong, it tries to do something it considers "reasonable" instead (you
: can turn on extra error checking via "use strict;", but the result is
: such strict checking that you might as well not use a scripting
: language at all, and many of the complaints that result from that are
: plain wrong).
[rest of diatribe deleted]
So, do you have any concrete examples of this? I do all my code
under 'use strict', and don't find it so onerous.
I hear lots of sweeping statements, and no examples to back them up.
--
Regards,
Mike Heins [mailed and posted] http://www.iac.net/~mikeh ___ ___
Internet Robotics |_ _|____ |_ _|
Few blame themselves until they 131 Willow Lane, Floor 2 | || _ \ | |
have exhausted all other Oxford, OH 45056 | || |_) || |
possibilities. |___| _ <|___|
-- anonymous mi...@iac.net 513.523.5028 |_| \_\
Mike Heins
. (t...@best.com) wrote:
: In article <4q0cvq$o...@vixen.cso.uiuc.edu> mhe...@prairienet.org (Mike Heins) writes:
:
: [rest of diatribe deleted]
:
: So, do you have any concrete examples of this? I do all my code
: under 'use strict', and don't find it so onerous.
:
: I hear lots of sweeping statements, and no examples to back them up.
: As I was saying: anybody coming to this fresh and considering using
: Perl should take a look at the Perl5 on-line manual first, in
: particular, the "Common Mistakes" section in perldesc, but also
: perlref, perllol, perlobj, perltie, perltrap, and perlbot, to see what
: kind of mess they are getting into. They should also try to
: experiment with "use strict;" and Perl's idea of "exception handling"
: from the start to see whether they suit them; on larger projects, you
: can't live without them (but you may not be able to live with them
: either).
:
As I was saying: do you have any concrete examples to back this
up?
: Beyond that, I related my practical experience using both Perl and
: Python on larger projects (annotating Web proxy server, workflow
: system, various database related projects, etc.), and my experience is
: that Perl code is much harder to get working reliably than Python and
: considerably more difficult to maintain. By its very nature,
: robustness on large projects isn't something that can be demonstrated
: by example, but I can relate my experience. Also, I didn't say "you
: can't use Perl for large projects", but simply that I have found it to
: be worse and that I recommend avoiding it for such applications when
: possible. Do _you_ have extensive experience in _both_ languages to
: be able to make a comparison?
No, but I have extensive experience in other languages besides Perl (C,
Bourne Shell, Pascal, and [ugh]BASIC) and I don't see where the maintainability
suffers in comparison. I admit that reading Perl can be a bit tough
at times if the programmer is heavily into multiple operations on the
same line, but well-written Perl I have not found to be bad.
I don't know from Python -- and I am not making any claims about it --
but I want to see YOUR examples.
None of the references you make pertain to the beginning Perl
programmer -- they would be at the "Learning Perl" or "Programming Perl"
level to begin with, then seque into those man pages you refer to. It
took me some time to become facile with all of those, but once I did,
I found that maintainability was greatly IMPROVED. I could reliably
re-use previously coded routines and catalog them so they made sense.
Again, I am not slamming any other language, so don't take it that I
am. I understand that Python is very highly thought of, and don't wish
to take away from it.
I also know that Perl is very highly thought of, and want to respond
to any sweeping slams against it. Perhaps you had a bad experience at
one time? Could you relate it?
--
Regards,
Mike Heins http://www.iac.net/~mikeh ___ ___
Mike Heins
. (t...@best.com) wrote:
: In article <4q0kgt$s...@vixen.cso.uiuc.edu> mhe...@prairienet.org (Mike Heins) writes:
:
: None of the references you make pertain to the beginning Perl
: programmer -- they would be at the "Learning Perl" or "Programming Perl"
: level to begin with, then seque into those man pages you refer to.
: Perl is perfectly fine for simple, small awk-like scripts. That is
: exactly why I recommend that people look at what awaits them and
: aren't taken in by the initial simplicity. By the time people people
: discover they need the more complex Perl features and how tricky they
: are to use, they may already have wasted a lot of time learning a
: language that will prove a hassle later on (and they may exhibit
: exactly your attitude: "oh, Perl seems fine, why even look at anything
: else?").
:
I haven't seen any other scripting language with the rich library
and application support of Perl. And I don't think it exists for Python,
which whould cause a problem for me. I like to leverage off of previous
efforts, and find that easy to do with Perl.
: In any case, the very fact that you have to recommend that beginners
: don't look at features like lists of lists indicates that there is
: something wrong in the design of Perl. Lists of lists are not an
: advanced programming concept, or at least shouldn't be.
:
Arrays are not introduced until chapter 7 or so of most C books
I have seen. Advanced is a relative concept -- is there a book on
Python? When does it introduce arrays?
: The Perl manual pages and their list of pitfalls and gotchas are an
: excellent resource demonstrating why people may not want to use Perl
: for complex scripting applications. Look at them before embarking on
: "Learning Perl".
:
: Perhaps you had a bad experience at one time? Could you relate it?
:
: I didn't have "a" bad experience. I have found frequently, in my
: code, in Perl code that is distributed over the net, and in Perl code
: that other people I have worked with have written, that Perl's lack of
: a formal exception handling mechanism, its tricky support for nested
: data structures (and the attendant silly syntax), its grafted-on
: object system, and the plethora of DWIM defaults it supplies cause
: bugs and problems. In comparison, I have found similar Python
: programs to be considerably easier to develop, debug, and maintain. I
: also have observed people learning either language, and it seems that
: they generally have a much easier time with Python.
:
Does anyone have any idea how many Python users are there compared to
Perl users? I must confess I have never personally met a Python user, but
have met many who have and do user Perl.
: Again, I have been using Perl for many years and on large projects, so
: it isn't like I'm speaking from ignorance or a brief look at the
: documentation. Take the advice or leave it... I don't have anything
: to prove.
:
It sounds to me as if you had all that experience with Perl 4, then were
not happy with the new Perl 5 features and migrated to Python. Have you done
much with Perl 5?
As this is becoming a two-way conversation, I will wait to post again
until I hear other input.
Felix Gallo
t...@best.com (.) writes:
>For anything complex or large, I strongly recommend staying away from
>Perl. [...]
>BTW, my diatribe against Perl is based on lots of practical
>experience: I have written lots of Perl code in the past and continue
>to write lots of Perl code on various projects I'm working on.
Other people's experiences may differ. I've written natural language
processing systems, editors, a small language, and a truly massive
web site environment in perl -- that last as a highly successful commercial
effort in conjunction with several other perl programmers of various
skill levels and stylistic preferences. And as a side note, the only
useful program I've ever seen written in python was quickly rewritten
in perl.
In both your case and my case, anecdotes only serve to illustrate that
there are extremes of possibility in this environment; and I believe
you'll find that that's true with every computing environment, be it perl,
python or prolog.
I hope that the python camp has the sense to stop being aggressive and
ill-considered in their posts about perl; although many of us perl folken
giggle at python's straitjacket syntax, it's clear that python is
sufficiently interesting that it's worth having it around on one's hard
drive. The same is, of course, true for perl.
So let's save the needless comparisons and vitriol for the truly silly
or horrifically implemented languages which actually deserve scorn and
pity, such as anything coming from Sun. :)
Just another Perl hacker who liberally steals ideas from Python code,
Felix
--
tick tick tick
Nate Patwardhan
. (t...@best.com) wrote:
: In article <4q0kgt$s...@vixen.cso.uiuc.edu> mhe...@prairienet.org (Mike Heins) writes:
: Perl is perfectly fine for simple, small awk-like scripts. That is
: exactly why I recommend that people look at what awaits them and
: aren't taken in by the initial simplicity. By the time people people
: discover they need the more complex Perl features and how tricky they
: are to use, they may already have wasted a lot of time learning a
: language that will prove a hassle later on (and they may exhibit
[snip]
Whaaat?!?!?! If you think Perl is nothing more than a parser, or
batch programming language, you are sorely mistaken. Perl does MUCH
more than that. You wrote that Perl might be a hassle --- well,
that's kind of silly, because MANY inexperienced "programmers," web
developers, and others use Perl because (1) its syntax is similar to
C, Pascal (sub), (2) it is very strong at a system level, (3) it has a
nice learning curve, and (4) pointers are not a mainstay for things
like list processing (Perl already has list functions).
Nate
n...@nfic.com
Christopher D Dukes
In article <TMB.96Ju...@best.best.com>, . <t...@best.com> wrote:
>In article <4q0kgt$s...@vixen.cso.uiuc.edu> mhe...@prairienet.org (Mike Heins) writes:
>a formal exception handling mechanism, its tricky support for nested
The Viscount of Voyeurism
In article <31bdbb53....@news.mindspring.com>,
Eric Palmer <e...@etechinc.com> wrote:
>Well like usual Tom has sparked my interest.
>
>So what is
>
> DWIMmer and dweomer?
`DWIM' is `Do What I Mean'. The DWIMmer is the part of Perl that
figures out what you mean and then does it.
`Dweomer' is an Old English word for magic or sorcery.
--
Mark-Jason Dominus m...@plover.com
Mark Daku
OK Simple question.
Does Python have the same power in regexp that perl does? I'm asking
because I have never even tried Python. In my opinion this is
probably perl's strongest ability. When ever you are building a
system where a user has to input data you have to be able to address
all of the possible ways a user can input the data. With out a very
strong regexp system I find this impossible to do.
On the other points it looks like Python and Perl are tied. However
I will remain a perl programmer for quite awhile since it is easy
portable and most of the other programers around me use perl. I
don't enjoy porting code from language to language.
At home maybe I'll play with Python.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Mark Daku NORTEL Ltd. |
| mailto:da...@bnr.ca P.O. Box 3511, Station C |
| W: (613) 763-9790 Ottawa, Ontario |
| K1Y 4H7 |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Aaron Watters
Felix Gallo wrote:
>
> t...@best.com (.) writes:
>
> I hope that the python camp has the sense to stop being aggressive and
> ill-considered in their posts about perl; although many of us perl folken
> giggle at python's straitjacket syntax, it's clear that python is
> sufficiently interesting that it's worth having it around on one's hard
> drive. The same is, of course, true for perl.
Well it's probably just my stupidity
(and that of everyone else who works here) but I've got about 50 Perl
scripts that do god knows what, and the people who wrote them left,
and we are experiencing excruciating pain. Just my personal experience.
I know that this is all due to some genetic disorder, or perhaps
some lead in the local water supply, so it probably doesn't apply to
the rest of the world. For me, life's just too short for this. Sorry.
-- Aaron Watters.
===
Be careful with road kills, since they may still be alive and
may bite and scratch you. It's best to leave them there for several
days before cooking.
Christoph Badura
In <31C565...@big.att.com> Aaron Watters <a...@big.att.com> writes:
>Well it's probably just my stupidity
>(and that of everyone else who works here) but I've got about 50 Perl
>scripts that do god knows what, and the people who wrote them left,
>and we are experiencing excruciating pain. Just my personal experience.
And you think that some programming language can save you from this?
Boy, are you in for a surprise.
The only thing that bugs me about this is that the customers are usually
willing to pay you for dumbing down perfectly readable code (probably not
what Mr. Watters has to deal with) to their level of programming
experience -- it just takes longer -- but not enough to compensate the pain.
--
Christoph Badura
O'Reilly/International Thomson Verlag
Kirk Haines
> Well it's probably just my stupidity
> (and that of everyone else who works here) but I've got about 50 Perl
> scripts that do god knows what, and the people who wrote them left,
> and we are experiencing excruciating pain. Just my personal experience.
> some lead in the local water supply, so it probably doesn't apply to
> the rest of the world. For me, life's just too short for this. Sorry.
And that is not a situation in the least bit related to Perl. That is the
fault of whoever wrote those scripts for writing obfusicated, uncommented
code. It is probably also the fault of whoever that person's manager or
supervisor or (insert title X here) was for not taking the time to verify
that what this person was doing could be covered in the event that the
person was no longer around. The fact that the obfusicated code was
written in Perl is fairly irrelevant to the fact that you don't knpw what
the programs do.
Kirk Haines
OSH Consulting
Felix Gallo
Aaron Watters <a...@big.att.com> writes:
>Well it's probably just my stupidity
>(and that of everyone else who works here)
everyone else at AT&T? :)
>but I've got about 50 Perl
>scripts that do god knows what, and the people who wrote them left,
>and we are experiencing excruciating pain.
That sucks. On the other hand, might I suggest that that is an
organizational problem related to managing a software project
rather than a feature of the perl language?
By the by, if you choose to resolve your problem, there are several
thousand perl contractors, many of whom read these newsgroups, who
might be able to help you out with the reverse engineering issue.
Though it's little consolation, that's one of the advantages of
writing in a mainstream language.
Just another perl hacker,
Conrad Minshall
In article <TMB.96Ju...@best.best.com>, t...@best.com (.) wrote:
> However, languages also have an influence on the quality, maintainability,
> and readability of code that people produce.
I have found it very hard to distinguish cause and effect in this regard.
I mean, yes, most code I've seen in "anything-goes" languages is harder to
read, but is that due to the language itself? Or is it that these
languages are more likely to be chosen by programmers who write code
without regard for its later readability? Or is it that such languages
are inherently more likely to be applied to problems which are at the time
thought to need only short-term solutions? Hard to tell...
> In fact, one way management can bring about good coding styles without
> examining each and every line of code is by choosing tools and
> languages that enforce some aspects of good coding styles. Perl isn't
> one of those languages. Perl has written on its banner to be an
> "anything goes" and "you can write it a million ways" kind of
> language.
Bear in mind that I'm still very new to Python, but IMHO this Perl vs
Python dialogue looks like an argument between a pot and a kettle. Does
it really matter that Perl is more black? If my goal were to encourage
good coding styles via choice of langauge then I'd stay away from Perl,
Python, APL, Forth :-) Maybe I'd instead choose Eiffel, or some other
language that encourages adherence to good design principles. (Eiffel for
instance encourages tightly defined interfaces via type checking and
precondition/postcondition assertions.)
I'm enjoying learning Python - the above was not intended as a criticism
of Python (or of any other language mentioned.)
--
Conrad Minshall con...@apple.com
Aaron Watters
Aaron Watters wrote:
crap deleted.
I've been properly scolded for my post. It was a mistake and
all the scolders were correct.
I do believe that certain tools tend to make clean modularity and
clear programs easy and others make it hard or encourage
obscurity. Back in the old days I used to write the most
beautiful and transparent PDP11 assembly code you can imagine :).
If I still had it and if it wasn't extremely valuable proprietary
stuff :) I'd post it all here to all these newsgroups and more,
and you'd all see what I mean. Nevertheless, for programmers less
skilled than I :) they are far more likely to write clear and
maintainable code in Python than in PDP11 assembly.
I apologize in advance for fans of of PDP11 assembly and I
know that intelligent people can disagree on this point.
-- Aaron Watters
===
If I could live life over again, I'd definitely join a fraternity.
Jay Allen
Aaron Watters wrote:
> Well it's probably just my stupidity
> (and that of everyone else who works here) but I've got about 50 Perl
> scripts that do god knows what, and the people who wrote them left,
> and we are experiencing excruciating pain.
I'd hate to know what you'd be experiencing if they had left behind
C code.
-J-
--
This message does not necessarily reflect the opinions of
Eastman Kodak Company.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT/L d?(!) s+:+ a-- C+++ USLBH+++$>++++ P+++ L+++>++++ E>++
W+++(--)$ N++ o-- K>--- w(---) M+ V-- PGP>+++ t@ 5(-) X- tv+(--)
b+++>++++ DI+++>++++ D-- G>+++ e* h---- y?
-----END GEEK CODE BLOCK-----
Mike Stok
In article <31C7F3...@kodak.com>, Jay Allen <jaya...@kodak.com> wrote:
>Aaron Watters wrote:
>
>> Well it's probably just my stupidity
>> (and that of everyone else who works here) but I've got about 50 Perl
>> scripts that do god knows what, and the people who wrote them left,
>> and we are experiencing excruciating pain.
>
>I'd hate to know what you'd be experiencing if they had left behind
>C code.
I hold the opinion that the readability and maintainability of code is
more a reflection of the coder's maturity and ability than of the
language. This is usually compounded by the project management policies
in place (or not) which can be used to make sure that there is supporting
documentation and a consistent "house" style for projects which are
considered to be of any importance.
Some languages encourage people to make a first pass at a problem and
then hack away until it works OK - especially those which are interpreted
or are supported by a fast turnaround environment (in the good old days
when you had to submit a deck to be run some time in the next few days
and pick up the output later there was an incentive to get things right
first time, but kids today...)
HArd to maintain programs are probably a social problem which can't be
solved by "better" languages or technology alone - the same environments
which I suggest encourage a "hack & slay" approach to coding are
amazingly useful to people with some discipline and probably help them
generate more "good" code per day.
Just a few thoughts,
Mike
...now, let the language wars resume, or failing that "I love vi, all
other editors are useless" :-)
--
mi...@stok.co.uk | The "`Stok' disclaimers" apply.
http://www.stok.co.uk/~mike/ | PGP fingerprint FE 56 4D 7D 42 1A 4A 9C
http://www.cybercom.net/~mike/ | 65 F3 3F 1D 27 22 B7 41
st...@pencom.com | Pencom Systems Administration (work)
John Shen
In article <31C565...@big.att.com> Aaron Watters <a...@big.att.com> writes:
> From: Aaron Watters <a...@big.att.com>
> Newsgroups: comp.lang.perl.misc,comp.lang.tcl,comp.lang.perl.tk,comp.lang.python
> Date: Mon, 17 Jun 1996 10:04:11 -0400
> Organization: AT&T
>
> Well it's probably just my stupidity
> (and that of everyone else who works here) but I've got about 50 Perl
> scripts that do god knows what, and the people who wrote them left,
> and we are experiencing excruciating pain. Just my personal experience.
> I know that this is all due to some genetic disorder, or perhaps
> some lead in the local water supply, so it probably doesn't apply to
> the rest of the world. For me, life's just too short for this. Sorry.
> -- Aaron Watters.
this could happen with things written in any language. code in any
language could cause this sort of problems, esp. if those who are left
are not familiar with the language or the style of the original
author. the solution would be either to train someone to read perl
code, or find someone who can.
this is more a matter of code management and maintenance.
--john
Larry W. Virden
Are you suggesting that there exists some programming language in which it
is fundamentally impossible to write software that cannot be understood?
By someone who doesn't know the language?
Tell us more - I have yet to see that language, and have looked at
probably 50-100 languages in the past 23 years.
Mike Heins
. (t...@best.com) wrote:
: In article <4qc2ic$k...@srv13s4.cas.org> lw...@cas.org (Larry W. Virden) writes:
:
: Are you suggesting that there exists some programming language in which it
: is fundamentally impossible to write software that cannot be understood?
: No, but he is suggesting, rightfully, that some languages make it
: harder to get reusable, readable, maintainable code out of a
: programming team than other languages. Perl is trivially and clearly
: worse in this regard than Python. To make up for those deficiencies,
: you have to invest more heavily in training and management. Given
: that people aren't wedded to Perl, a random hack and recent blip
: on the language radar screen, there is little reason for accepting
: this additional expense.
:
The vitriol keeps flying -- I am killfiling you. A pity -- you seem
to be quite knowledgeable.
Random hack, indeed!
Larry W. Virden
According to . <t...@best.com>:
:In article <4qc2ic$k...@srv13s4.cas.org> lw...@cas.org (Larry W. Virden) writes:
:
: Are you suggesting that there exists some programming language in which it
: is fundamentally impossible to write software that cannot be understood?
:
:No, but he is suggesting, rightfully, that some languages make it
:harder to get reusable, readable, maintainable code out of a
I have yet to find such a language that is, intrinsicly, of such a nature.
A co-worker came here from an environment where their business apps were all
written in APL. Shrug.
:programming team than other languages. Perl is trivially and clearly
:worse in this regard than Python. To make up for those deficiencies,
While that's _your_ opinion, it certainly isn't a proven fact in general.
Given that the public CPAN environment is a 'programming team' of several
dozen, or more, individuals, all writing code which works together, in
a manner that is maintainable and readable by someone who reads Perl. I
have taken a look at the 'golden bullet' of Python and find it just
as cryptic as any other language which I have not taken the time to read.
And, it becomes more readable, and maintainable, as I learn more about
it. The same was true of IBM BAL, IBM PL/1, DEC PDP 11 assembler, C,
C++, Bourne/Korn shell, awk, etc.
:you have to invest more heavily in training and management. Given
:that people aren't wedded to Perl, a random hack and recent blip
:on the language radar screen, there is little reason for accepting
:this additional expense.
There is always going to be some expense. What we have found in a
production maintenance environment, is that the benefits of getting code
working quickly by using perl, and the smaller amount of code that is needed,
results in an quicker response time and less maintenance, since there is
less code for one to maintain.
Bill Thater
>>>>> "Thomas" == <t...@best.com> writes:
In article <TMB.96Ju...@best.best.com> t...@best.com (.) writes:
Thomas> Of course it is _related_ to Perl. Yes, you can write better
Thomas> or worse Perl code. Yes, managers are responsible for
Thomas> ensuring that programmers produce readable code. However,
Thomas> languages also have an influence on the quality,
Thomas> maintainability, and readability of code that people produce.
any language that provides a means of including comments [is there one
that doesn't?] puts a burden on a *good* programmer to use them to
explain and describe the programs and procedures. my
$1.98. [inflation ya know. ;-)]
--
_
( )
- -
( (0___
| 7
\ (")===========================================================
/ \ \ |
( ) | Witch's Bear | While Eeyore frets... |
| \__/ Bill Thater, KiTA, BOfH | and Piglet hesitates... |
| | bi...@npac.syr.edu | and Rabbit calculates... |
| / | and Owl pontificates... |
( / Alt.Cuddle's resident | Pooh just is. |
\ / CuddleNinja | |
) /(_ | _The Tao of Pooh_ |
| (___) | |
\___)=============================================================
Jeffrey Hobbs
In article <4pnuo6$e...@hawk.branch.com>, Steve Simmons <s...@iti.org> wrote:
>>On the other hand, perl is a more traditional programming language with
>>more intuitive evaluation rules and the full support you'd expect from a
>>"real" programming language.
>
>`more intuitive evaluation rules'? Cough, gasp, *wheeze* :-). Sure,
OK, we can all choke on this thread for a while, but I'll get in my $.02.
AFAIK, there is only one true head-to-head test of language hack value out
there - the Duke Internet Programming Contest. Like the ACM Programming
Contest, except open to everyone and everything (I hate the
single-mindedness of the ACM programming contest: C or Pascal, but what do
you expect from a contest owned by Microsquash?).
So, a contest with real bent on getting the best language for the job.
What are the results? Curious myself (I only participated once, many
years ago), I found the best page for answers was:
http://www.ug.cs.dal.ca/~xke/internet.prog.contest.html
It even had languages used per problem. The winner? Hands down C, with
Perl a distant third (after Pascal). However, if you look at the %ages
of attempts versus correct answers, Perl wins in any language used in more
than 5 attempts. Tcl wasn't used.
Sure, it's not necessarily a good representation of the best large app
programming language, but that didn't seem to be the argument...
--
Jeffrey Hobbs Office: 541/346-3998
Univ of Oregon CIS GRF email: jho...@cs.uoregon.edu
URL: http://www.cs.uoregon.edu/~jhobbs/
Felix Gallo
t...@best.com (.) writes:
> [ Larry Virden writes ]
> There is always going to be some expense. What we have found in a
> production maintenance environment, is that the benefits of getting
> code working quickly by using perl, and the smaller amount of code
> that is needed, results in an quicker response time and less
> maintenance, since there is less code for one to maintain.
>And what I have found is that Python is better than Perl for some
>applications (larger scripts, applications where robustness counts
>more) and slightly worse for others (smaller scripts). Where is the
>contradiction?
You're starting to sound like a broken record, Thomas. Your experience
with perl is negative; fine. That doesn't make perl bad or useless;
a vast majority of other evidence demonstrates the opposite. Your posts
are only serving to make perl users wonder what's wrong with python
that it produces such vociferous, repetitive and negative advocates.
Never thought I'd have to use a killfile against comp.lang.perl.misc
until now.
just another perl hacker,
Larry W. Virden
According to . <t...@best.com>:
:In article <4qe41i$1...@srv13s4.cas.org> lw...@cas.org (Larry W. Virden) writes:
:
:So, why bother even with Perl? C is much more mature, has more
As I said, because with Perl, folk here are finding they are more productive
than with C. Your postings seem to come across as if you feel that one should
only use one language. Right now, we use Perl, C, assember, Fortran, PL/1,
Tcl, Shell, and a variety of other languages - each one to get done what
the programmer feels s/he can do best, in the least amount of time spent
in either learning , programming , documenting, or maintaining.
:And what I have found is that Python is better than Perl for some
:applications (larger scripts, applications where robustness counts
:more) and slightly worse for others (smaller scripts). Where is the
:contradiction?
I didn't mean to indicate that Python might not, in some cases, be a good
language to use in certain cases, for certain people, on certain projects,
under certain domains. Shrug - whose to say? I am sure that the use of
a hammer in frying eggs might make sense in a certain context. I do believe
that programming languages have areas in which they are more developed and
less developed.
I myself can't imagine trying to use Python/Perl/Slang/C/etc. as a
configuration file language that would be used by a user group base which
are computer-phobic. A natural language interface, or at least a minimalistic
one, seems more effective.
I am sure that others can envision other places where particular languages
don't seem to work most effectively.
Evan Kirshenbaum
In article <4qe41i$1...@srv13s4.cas.org>,
>:
>: Are you suggesting that there exists some programming language in which it
>: is fundamentally impossible to write software that cannot be understood?
>:
>:No, but he is suggesting, rightfully, that some languages make it
>:harder to get reusable, readable, maintainable code out of a
>
>I have yet to find such a language that is, intrinsicly, of such a nature.
>A co-worker came here from an environment where their business apps were all
>written in APL. Shrug.
You didn't get a chance to program in TECO, did you? :-) Here's an
excerpt from a sample program (this is intended to be good code):
! detab routine - ts at 4 or 8 spaces depending upon EZ&4 !
@^UD]8UTEZ&4"N4UT'0J<:@S/ /;.UA0LQA-.UBQB/QT*QTUCQB-QCUCQAJ-D@I/ /
QC"NQT-QC<@I/ />'>]@^UX/0JHXRHEQHK1XQ ZJ543HZPRHKG#/QZ&512"NMX0J'
0uz
(Yes, those are escape characters at the end.)
@^UD] define a command in q-register 'D' through the next ']'
8UT assign 8 to q-register 'T'
EZ&4"N if current tab stops are every four columns
4UT assign 4 to q-register 'T'
' end
0J move to beginning of buffer
< begin iteration
:@S/ / search forward for tab
; break if not found
.UA set q-register 'A' to the current position
0L move to end of line
QA-.UB set q-register 'B' to difference of 'A' and current
position
QB/QT*QTUC c = (b/t)*t (to lose the remainder)
QB-QCUC c = b-c
QAJ-D move to position A and delete
@I/ / insert a space
QC"N if c != 0
QT-QC< while (qt-qc >= 0)
@I/ / insert a space
> end
' end
> end
] end
The rest of the excerpt is left as an exercise for the reader. :-)
Oh, yeah. The original version of emacs was written in TECO.
----
Evan Kirshenbaum +------------------------------------
HP Laboratories |"Revolution" has many definitions.
1501 Page Mill Road, Building 1U |From the looks of this, I'd say
Palo Alto, CA 94304 |"going around in circles" comes
|closest to applying...
kirsh...@hpl.hp.com | Richard M. Hartman
(415)857-7572
Dan Connolly
Sorry for the length, but I felt inspired tonight...
In article <TMB.96Ju...@best.best.com> t...@best.com (.) writes:
>
> In article <Pine.SUN.3.93.96061...@blackhole.dimensional.com> Kirk Haines <oshc...@dimensional.com> writes:
>
> > Well it's probably just my stupidity
> > (and that of everyone else who works here) but I've got about 50 Perl
> > scripts that do god knows what, and the people who wrote them left,
> > and we are experiencing excruciating pain.
>
> And that is not a situation in the least bit related to Perl. That is the
> fault of whoever wrote those scripts [...]
> Of course it is _related_ to Perl. Yes, you can write better or worse
> Perl code.
> In fact, one way management can bring about good coding styles without
> examining each and every line of code is by choosing tools and
> languages that enforce some aspects of good coding styles. Perl isn't
> one of those languages.
Short form: (1) there's a tension between early detection of faults
and rapid prototyping, and perl and python are at very different
points on the spectrum. (2) it's more the community around a language
than the language itself that influences code quality.
(3) For my purposes, perl will continue to be a work-horse tool, but
I'll be using Java more for things that I would have used python or
Modula-3 for, and I hope the industry uses Java for things that
it has been using C++ for.
Long form:
(1) Traditional perl programming is a black art, but a darned useful
craft as well. The semantics are very powerful, and the syntactic
features combine in amazingly powerful ways. But you definitely have
enough rope to hang yourself; not enough to hang the machine or crash
all the time, like the way you can corrupt the runtime in C by writing
past the end of an array or calling free() twice. But like C, you can
introduce subtle logic bugs by using = where you meant ==. And
failing to check return values results in a program that nearly always
reports successful completion, whether it really succeeded or not.
I like studying and learning programming languages, and I found it
more difficult to build the necessary intuitions to read and write
traditional perl programs than to build intuitions for any language
I leaned previously, and nearly every language I learned since.
I learned perl "from a master" -- Tom Christiansen was in the next
office, and he painstakingly (if not patiently :-) answered my many
frustrated questions. Previous to learning perl, I had learned a dozen
or so languages without much difficulty (here in roughly the order
I learned them):
Extended BASIC (Radio Shack Color Computer)
learned from a book, disassembled the interpreter
6809 assembler
learned from a book with a friend, and from
disassembling LOTS of stuff
Basic09
learned from the manuals, with help from BBS folks
Logo
learned in a store one afternoon, reading a book
Pascal
learned one summer from a college professor
C
read a book one weekend
COBOL
learned at a summer job
shell
misc. hacking in school
LISP
read some books, hacked on TI lisp machine in a class
prolog
programming languages course
Modula-2
programming languages course
Ada
programming languages course
Learning assembly after basic was tough: "Where are the variables?
Geez.. rebooting the machine all the time is a pain. I wish this thing
had automatic string handling." And I'm not sure I ever grokked Ada's
rendezvous stuff completely. And I learned COBOL in a strictly
monkey-see-monkey-do manner. It was months before I found a manual.
None of those were particularly unexpected difficulties. But after
an intial taste of perl, it looked really easy and powerful, and
I was frustrated when the first few real programs I tried to write
had bugs that I just could not figure out at all.
Really learning to use regexps was well worth the effort, but things
like "surprise! <FILE> works completely different in an array
context!" was an experience I don't care to repeat. I can't remember
the exact program that drove me batty, but it was related to:
$x = <FILE>; # reads one line
@x = <FILE>; # reads whole file, split into lines
but the idiom I used that created an array context wasn't as transparent
as @x -- it was something like grep() or chop(). Ah yes, I think
it was chop(). Who would have guessed that
chop(<XXX>);
would read thew whole file?
Perl is full of short-hand idioms that are so useful that
knowledgeable perl programmer's would feel awkward writing them out
long-hand, and yet they can throw newbies for a loop. For example, the
work-horse idiom:
while(<>){
...;
}
is short for:
while( ($_ = <STDIN>) gt ''){
...;
}
roughly speaking; that is, ignoring the tremendously useful
feature of <> which processes files mentioned on the command line
(aka @ARGV) ala traditional unix filters, which would take me
about 10 or 20 lines to write out longhand, and about an hour
to get just right. Ah! and I forgot to mention that <XXX> is
an idiom for reading one line from a file... and lines are
delimited by the magic $/, and ...
The point is that even as of several years ago, perl is a
highly-evolved, highly idiomatic language and tool, based on zillions
of person-years of use in unix system administration. The vast
majority of text-processing/system management tasks that folks might
want to hack up a script to tackle can be developed quickly, expressed
succincly, and run efficiently in perl.
The first crack usually looks like:
while(<>){
if(/X-Diagnostic: (.*)/){
print "diagnostic: $1\n";
}
}
and it usually works great the first time you try it. Then
you add a few wrinkles, and before you know it, the task you
set out to do is solved.
Taking that piece of code that solves a particular problem, and
software-engineering it usually takes about 10x longer than it took
to develop in the first place (as these tasks are often personal
and transient, it's rarely worth the trouble anyway).
The author of the hack is generally in a position to restrict
the inputs to reasonable stuff (eliminating the need to deal with
corner cases) and check the output by hand (eliminating the need
to document and report errors in typical engineering fashion).
This is very much in contrast with other languages, where the
cost of solving the immediate problem may be significantly higher,
but the result is much more likely to have good software engineering
characteristics, such that it's useful to other folks or other
projects with little added effort.
For example, Olin Shivers described his experience writing ML
programs: they are a royal pain to get through the type checker, but
once they compile, they are often bug-free.
Python isn't that far along the quick-and-dirty vs. slow-and-clean
spectrum, but it's in that direction.
Contrast the work-horse example above with a loose translation to
python:
import sys
while 1:
line = sys.stdin.readline()
if not line: break
...
incorporating the @ARGV parts of <> would expand it to something like:
import sys
for f in sys.argv[1:]:
in = open(f)
while 1:
line = sys.stdin.readline()
if not line: break
...
Python doesn't have special syntax for this sort of thing. So the
python code is more verbose and less idiomatic -- easier to grok for
the newbie, but harder to "pattern match," or recognize as a common
idiom for the seasoned programmer.
For an example of the stylistic slants of the two languages, consider
error/exception conditions. As a rule, in perl, errors are reported as
particular return values, whereas in python, they signal
exceptions. So in the error case, a perl code fragment will run
merrily along, while a python code fragment will trap out. In many
text-processing tasks, running merrily along is just what you
want. But when you hand that code to your friend, and he presents it
with some input that you never considered, python is a lot more likely
to let your friend know that the program needs to be enhanced to
handle the new situation.
I've seen exception idioms in perl, but they involve die and EVAL.
The runtime libraries don't die on errors, as a rule, and EVAL
is a pretty hairy way to do something as mundane as error handling.
Next, consider naming and scope. By default, perl variables are
global, so you almost never have to declare them. Local variables have
dynamic scope by default (ala early lisp systems) and traditional
statically scoped variables are a perl5 innovation.
On the flip side, python variables are local by default, so you almost
never have to worry about the variable clobbering problem. (python
has some semantic gotchas of its own here for the folks who have
intuitions about traditional static scoping)
So far, I have discussed mostly the intrinsic aspects of a language
that vary along the quick-and-dirty vs. slow-and-clean spectrum.
But the point of this article is that:
(2) The comunity around a language -- i.e. the conventional wisdom,
history, documentation, and available source code -- has a lot
more influence of the quality of code developed in a given language
than the intrinsic aspects of the language itself.
For example, it's perfectly possible to write clean, well structured
programs in Fortran. But the bulk of traditional fortran has no
comments or indentation, and lots of GOTOs, global variables, and
aliased variables. The mindset behind fortran was that
hand-optimization was superior to machine-optimization -- a mindset
left over from assembler, and popularized by bad compilers.
COBOL has some really bad features (e.g. lack of local variables) that
make writing good programs hard, but don't come close to explaining
the astoundinly uninspired programming techniques I've seen employed
in some business/database apps I've seen. Stuff like writing 12
paragraphs (subroutines, or functions to the modern world) -- one for
each month of the year, with 12 sets of variables jan-X, jan-Y, feb-X,
feb-Y, etc., rather than using loops and arrays, which DO exist in
COBOL.
Perl, as a language, is evolving faster than the perl development
community. Perl5 in strict mode a reasonable modern object-oriented
programming language. But there are ZILLIONs of perl programmers, and
from what I can see, about 2% of them bought into the new
facilities. The rest of them are still happily getting their jobs done
writing perl4 code -- myself included.
Perl was useful and widely deployed before the OOP "paradigm-shift"
hit the industry. And a community with that much momentum doesn't
turn on a dime.
In contrast, python started from scratch after some earlier languages,
and had the benefit of looking back at REXX, icon, and perl, as well
as C++ and -- most importantly -- Modula-3. So documentation
encouraged some pretty modern concepts like objects and modules while
the python development community was still young.
As a result, consider the namespace of functions in the two systems:
the languages have roughly equivalent support: python has modules,
and perl has packages. But you might not know that from looking at
most of the code you see on the net: traditional perl folks rarely
use the $package`var stuff, while python folks use it routinely.
The perl5 movement is quickly changing this, but until recently,
perl programmers use the vast majority of perl's facilities without
ever considering packages, while python programmers run into the
concept of modules in the early tutorials.
For me, the bottom line is that I do a lot of quick-and-dirty stuff,
and I'm comfortable with perl4's idioms, so I use it a lot. I have
dabbled in perl5, but I'm not yet comfortable with it's OOP idioms.
I prefer the feel and syntax of python, but the "strictness" often
gets in the way, and I end up switching to perl in order to finish the
task before leaving for the day.
When I want to write "correct" programs, neither is good enough. I
want lots more help from the machine, like static typechecking. And
sad to say, when I want to write code that other folks will use, I
choose C.
As much as the industry adopted C++, I find it frightening. It
requires all the priestly knowledge and incantations of perl with none
of the rapid-prototyping benefits, gives no more safety guarantees
than C, and has never been specified to my satisfaction.
Modual-3 was more fun to learn than I had had in years. The precision,
simplicity, and discipline employed in the design of the language and
libraries is refreshing and results in a system with amazing
complexity management characteristics.
I have high hopes for Java. I will miss a few of Modula-3's really
novel features. The way interfaces, generics, exceptions, partial
revelations, structural typing + brands come together is fantastic.
But Java has threads, exceptions, and garbage collection, combined
with more hype than C++ ever had.
I'm afraid that the portion of the space of problems for which I might
have looked to python and Modula-3 has been covered -- by perl for
quick-and-dirty tasks, and by Java for more engineered stuff. And both
perl and Java seem more economical than python and Modula-3.
Dan
--
Daniel W. Connolly "We believe in the interconnectedness of all things"
Research Scientist, MIT/W3C PGP: EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21
<conn...@w3.org> http://www.w3.org/pub/WWW/People/Connolly/
Aaron Watters
>
> As I said, because with Perl, folk here are finding they are more productive
> than with C. Your postings seem to come across as if you feel that one should
> only use one language. Right now, we use Perl, C, assember, Fortran, PL/1,
> Tcl, Shell, and a variety of other languages - each one to get done what
> the programmer feels s/he can do best, in the least amount of time spent
> in either learning , programming , documenting, or maintaining.
Yes, and with respect I suggest that this is a mistake. Six months from now
he/she will be gone and you'll have snippets in 17 different languages to maintain.
It would be better to choose the language with the greatest flexibility and
power and simplicity, and use that language only -- extending it when necessary
with foreign api interfaces or embedding it in other programs when appropriate
or adding new base types to the languages where performance demands require it.
Then when you get a completely new staff they will only have to learn one language
and it will take them a single day, verses 21 days times 17 languages.
Sorry to folks who want this thread closed off, I think this needed to be
said. I do speak from experience.
-- Aaron Watters.
===
You think you're so illustrious, you call yourself intense. -- the Cars
(huh?)
Dan Connolly
>
> Sorry for the length, but I felt inspired tonight...
> Short form: (1) there's a tension between early detection of faults
> and rapid prototyping, and perl and python are at very different
I'm afraid I'm breaking more rules by following up to my own post. But
a few people sent encouraging replies, and I think I'll take this
opportunity to invite folks to participate in another forum where
interesting issues will be discussed: Web Programmer.
I've been invited by SIGS (publisher of stuff like the Smalltalk Report)
to edit a magazine for the web development community.
I realize there are many of them, but I feel I have a unique
contribution to make, and I hope to attract and build a useful
community of readers (and writers!).
For details, please see:
http://www.w3.org/pub/WWW/People/Connolly/WebProgrammer/
Aaron Watters
Dan Connolly wrote:
>
> Sorry for the length, but I felt inspired tonight...
python version of while (line=<>) {...} or whatever...
> import sys
>
> for f in sys.argv[1:]:
> in = open(f)
> while 1:
> line = sys.stdin.readline()
> if not line: break
> ...
>
> Python doesn't have special syntax for this sort of thing. So the
> python code is more verbose and less idiomatic -- easier to grok for
> the newbie, but harder to "pattern match," or recognize as a common
> idiom for the seasoned programmer.
There is no need to repeat a common idiom like this, as Jim Fulton
also pointed out. Instead, implement this exactly once:
import sys
class FilesReader:
def __init__(self, list_of_files=sys.argv[1:]):
self.list = list_of_files
self.thefile = open(list_of_files[0])
def __getitem__(self, ignore):
line = self.thefile.readline()
if line: return line
else:
self.thefile.close()
self.list = self.list[1:]
try:
self.thefile = open(self.list[0])
except IndexError:
raise IndexError, "no more lines"
else:
return self.__getitem__(ignore)
# and use it as many times as you please like this:
if __name__=="__main__":
for line in FilesReader():
sys.stdout.write(line) # or whatever you want...
I can't think of any reason to ever repeat an idiom in Python code
at the moment, but I'm not trying too hard either... :)
-- Aaron Watters
===
You mean to say: life isn't a fountain? -- stupid punch line.