[10120] in Perl-Users-Digest
Perl-Users Digest, Issue: 3714 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 14 18:07:22 1998
Date: Mon, 14 Sep 98 15:01:23 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 14 Sep 1998 Volume: 8 Number: 3714
Today's topics:
Re: Perl & Java - differences and uses <zenin@bawdycaste.org>
Re: Perl & Java - differences and uses <ajohnson@gpu.srv.ualberta.ca>
Re: Perl & Java - differences and uses <zenin@bawdycaste.org>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: PERL routine using wtmp? <eashton@bbnplanet.com>
Re: Perl Test or Questionare? (Matthew Bafford)
Re: regex help (David A. Black)
Re: regex help <eglamkowski@angelfire.com>
Re: search and replace between values (Craig Berry)
Re: selective split <jdf@pobox.com>
STD I/O for WIN32 Perl (Stephen Elias)
Re: Use of 'exit' in child process (Charles DeRykus)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 14 Sep 1998 20:26:54 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <905804504.149111@thrush.omix.com>
George Reese <borg@imaginary.com> wrote:
: In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
>snip<
: : I'm sure Python has built some of the higher level functionality
: : of Perl pattern matching, but it's not "identical". Not by a
: : long shot.
: How do you know?
Tack on "in my experience". Last I reviewed Python in depth, a
little less then a year ago, its pattern matching abilities still
left much to be desired, and that was before Perl made even more
major advances.
>snip<
: Python patterns are the same damn patterns as perl. You should parse
: the results within an OO framework.
Why? Because an OO framework will solve any and all problems better
then anything else ever thought of? I think not. OO is just
a programming method, and rarely the best method for most tasks at
that.
In some cases, it would make sense to "parse the results within an
OO framework", and in many other cases it would not. Pray tell
why should I be required to create an object and suffer the method
overhead and extra for something as simple as:
my ($foo, $bar) = (
$foobar =~ /match (foo) and (bar) stuff in foobar/
);
How is this so much worse then:
my $regex = new Regexp;
$regex->setPattern ("match (foo) and (bar) stuff in foobar");
$regex->setData ($foobar);
my $foo = $regex->getFirstMatch();
my $bar = $regex->getSecondMatch();
Blagh, no thank you.
: Really? Just because someone maintains a C codebase successfully does
: not mean that task is easy.
This same argument can be applied to any language.
>snip<
: one of the drawbacks of languages like perl, C, and C++ is that
: you have to be experienced to write clear code.
No, you do not, nore have you shown any examples that show
otherwise.
: In Python or Java (moreso Python than Java), you have to intentionally
: set out to write unclear code.
Ditto for Perl.
>snip<
: : I picked up the core of the Java language in a week of reading a
: : book just on my train ride to work. I've been programming Perl
: : for the better part of the decade and still don't know all the
: : power it holds. But guess what, I don't need to know all of it
: : to write good, clean, and productive code. One doesn't even need
: : to know most of it.
:
: You have just made an argument against Perl.
Why? The core Java language is practically useless. To do any
real work you need to know quite a bit about the standard classes,
which are *huge*. The total amount of information you need to
do real work in Java (core language + std classes) is far greater
then the total amout of information you need to do real work
in Perl (very small subset of the core language and no libs).
In any event, the lines at which you divide the information up
is not important. One still needs to learn similar sums of
information to get similar tasks done.
>snip<
: The opposite is true. Just because something is complex does not make
: it in any way more efficient to use.
That should be, "the opposite is *also* true", else you imply my
statement as false, which it isn't.
: : Perl requires more self control then other languages, I'll give
: : you that.
: That is bad.
Why? Just because Perl gives users more flexibility in the way they
code does not mean that it is harder to code cleanly. True you
can code badly with greater ease, *if you choose to*. Take the
same Python habits and apply them to Perl and you'll have equally
as readable code, with *no* greater effort or experience.
>snip<
: You overestimate perl's pervasiveness. Perl's evolution beyond system
: administration is an accident of being in the right place at the right
: time. It is also an accident that is being rectified.
And you underestimate Perl's appeal. With Python, if you don't
agree with Python's idea of "correct", you're wrong, period. With
Perl you are free to decide what is "correct" on your own. Freedom
is *very* appealing, simply because humans almost *never* fully
agree on any particular subject or method.
>snip<
: That is a statement neither you can support nor that I can argue
: against. I have maintained, however, that long time perl programmers
: are not the best judges of perl maintainability and readability.
By the same token, long time Python programmers would not be the
best judge of Python's maintainability and readability, fair?
>snip<
: : "Conciseness is a virtue, when maintaining code at 3am".
: Throwing around cute rhetorical quotes does not make an argument.
It's quite simple. If a thought process can be expressed clearly in
a much shorter amout of code, finding a particular thought within
the block is much, much easier. If one has to scrool through
many pages of code to find the location of a problem it is much
harder to read, understand, and maintain then if the "big picture"
can be seen all at once, or at least within the space of a minimal
set of pages.
>snip<
: If you are comparing python's use of whitespace with that of a
: Makefile, it is you who are evil. They are nothing alike.
They are magic whitespace. Magic whitespace is evil, in
all forms.
: I said the IDEAL language would be human
: language with a disambiguation process so that EVERYONE could read and
: write computer programs. That is clearly not what python is. I have
: nowhere tried to argue that is what python is. I have only argued
: that python is a lot closer to that than perl is.
???
Human speech is *filled* with many, many ways to express the
same idea. "Step on my land and I will kill you" or "I will kill
you if you step on my land", or "Do not step on my land or
I will kill you". Perl, far more then *any* other language in
common use allows these forms of human speech constructs to be
used.
Python takes the direct opposite view infact, believing instead that
there is one true way to say something and be damned anyone that
might disagree that it isn't the best way.
>snip<
: : Quite true. The integration system however, leaves much to be
: : desired. It has nothing even remotely close to the power of
: : PAUSE and CPAN.pm, but then, nothing else on the planet currently
: : comes close to them.
: How do you know? What exactly do these modules do?
PAUSE (Perl Authors Upload Server) isn't a module, it is a system.
CPAN (Comprehensive Perl Archive Network) is both a system and
a module to interface with that system.
To install a module Foo for instance, which has a dependency of Bar,
one just issues the command:
perl -MCPAN -e 'install Foo'
The CPAN module will download the latest Foo from a known CPAN
mirror, check and install any dependencies (Bar) automatically,
check versions, etc of everything, build/compile/whatever Foo,
install it, and register it. The only package management system
that comes close is the FreeBSD "ports" system, and CPAN still
has many advantages over it.
This is just one of many, many features of the system however.
>snip<
: : : And software reuse does not make something OO.
: : Quite correct. The only correct thing I've seen you write, but
: : it is correct. :-)
: : And on the flip side, OO does not make something reusable.
: If it is properly OO, it is very likely to be reusable.
No, if it is designed well it is likely to be reusable. OO did
not invent code reuse, nore does it define it.
: Java is pure OO.
Java has primitive types, therefore by strict OO thinking it
is *not* "pure" OO.
: Python is close enough.
Close enough for what? Perl is as OO as you want it to
be. That's the point, not everyone wants it to be and
with good reason. Because not everything (not even
most things) should be OO.
>snip<
: That is a freedom that has no place in an OO language. You do not
: combine a structured software engineering process with a weak link.
: It is like sticking a pipe with a huge leak inside your plumbing.
: Perl is quite simply no where as OO as python.
As is clear by anyone that actually has taken a good look,
Perl not only is as OO as anyone wants it to be, its model
is very close to Python's (which as far as I remember is where
the design was adopted from).
: Be careful of the examples you choose. In OO circles, C++ is
: considered to be about the worst example of OO available.
In language circles it is considered to be about the worst
example of a programming language available.
:-) <--For the humor impaired
The fact is that it *is* an example, good or bad, of an
OO language, and Perl is at *least* as "OO" as C++.
: That is because OO is 'not simply a tool'. Because of the structured
: nature of the OO software engineering process, you need a language
: that enforces your structure.
Why? Because the programmer is to inept and or stupid to enforce
such practices on there own? Of course, that's it, least we have
people using non-OO code where it makes sense and actually get some
good work done.
: Since I cannot answer the functionality question above, I can only in
: good faith concede that bit of functionality to you based on my
: ignorance (and not necessarily any fact about python). However, it is
: a long way from that one piece of functionality to 'python has a huge
: game of catchup to play'.
It's a *lot* more then "one piece". It's an entire system and
framework. A monument to reusablity, user (not language) enforced
design ethics, and community.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: Mon, 14 Sep 1998 16:02:14 -0500
From: Andrew Johnson <ajohnson@gpu.srv.ualberta.ca>
Subject: Re: Perl & Java - differences and uses
Message-Id: <35FD8456.25185D16@gpu.srv.ualberta.ca>
George Reese wrote:
>
> In comp.lang.java.programmer George Reese <borg@imaginary.com> wrote:
> : In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
> : : Has Python finally developed zero-width lookahead and lookbehind,
> : : assertion, both positive and negative? Interlaced code in both
> : : the search and replace constructs? Subexpressions? Conditional
> : : expressions? Inlined modifiers?
>
> : I could not answer this question fully for either Perl or Python. Hopefully
> : someone else who knows Python well can answer it.
>
> Sorry to followup my own post. The answer is: yes. Python 1.5
> supports all of this.
actually, it seems that answer is *no*: from the RE syntax docs for
python 1.5.1 at:
http://www.python.org/doc/lib/re-syntax.html
it does not appear that lookbehind, interlaced code in
search-pattern, independent subexpressions, or conditional
expressions are supported, perhaps this support is undocumented or
documented elsewhere?
if you are interested in finding out about these features in Perl,
you are welcome to peruse:
http://www.perl.com/CPAN-local/doc/manual/html/pod/perlre.html
regards
andrew
------------------------------
Date: 14 Sep 1998 21:24:13 GMT
From: Zenin <zenin@bawdycaste.org>
Subject: Re: Perl & Java - differences and uses
Message-Id: <905807943.326889@thrush.omix.com>
bjohnsto_usa_net@my-dejanews.com wrote:
: In article <905757998.909140@thrush.omix.com>,
: Zenin <zenin@bawdycaste.org> wrote:
>snip<
: Database vendors offer a variety of communcations protocols now. DecNet, IPX,
: NetBios, TCP/IP, Shared Memory, Named pipes etc.
All of those, save for shared memory (who uses that, BTW?), are
private connection oriented protocols and thus fairly easy to port
provided the system knows how to access them.
: Adding HTTP seems like a small change.
HTTP is an application level protocol built *on top* of protocols
such as you mention above. It's a different layer completely.
If an "HTTP" application level protocol was built, it would likely
be just as slow as anything else unless the database severely cut
back on the amount of access control was allowed.
: Adding a $15,000 per CPU, go on a 2 week course to learn how
: to use it, application server seems like an expensive change.
It depends. Most generic application servers do far, far more
then simply add a buffer to database calls.
: Apart from that the application server I have work with are not that special.
: They seems to sell better to management than anyone who has to use them.
:
: [snip people are being taught to ignore efficiency.]
??? True, badly designed systems using application server can be
inefficient, however in many apps they actually enhance performance
by many, many fold over "standard" access methods.
: > In general I try to architect systems which can scale to anything,
: > up or down. :-)
: Are you optimising programmer time like this?
Yes. Efficient runtime and efficient development do not have to be
at odds. Granted, it takes more still and experience, but for those
that can do it well it's very beneficial. -Remember, if there is
an efficiency problem later you may be required to go in after the
fact to fix it, and in many cases this can require major
architecture changes that cost far more then if they were worked
out before hand.
: I tend to think it is best to
: try to create independant reusable bits and pieces that would fit into any
: overall architecture. The independance seems to make things easier to test.
Agreed. I do not agree however, that this can't be done without
sacrificing efficiency.
: > HotMail. Even Microsoft themselfs couldn't do it, so I question
: > your beliefs here. :-)
: This has more to do with the cost of rearchitecting an existing system than
: with the performance paramters of a particular task.
The particular task being basic mail serving, in a high load
situation. This is something any stock Unix boxes should be able
to handle with little to no changes to the basic mail config.
: If there was a
: substantial requirement for changes in Hotmail which required a rewrite
: anyway, then the rewwrite would most likely occur on NT.
*Only* because they were bought by MS, and for no technical merit
of NT.
: www.microsoft.com is on NT servers.
Microsoft.com is on *rooms* of NT servers. It's huge. It's a
living testimonial that if you throw enough hardware at nearly any
OS you can handle big loads.
: > Unix understands that different people want to do different things
: > in different ways, if only slightly. NT thinks everyone should be
: > happy with the pretty buttons they make and if you don't like
: > it you're just wrong.
: I find the limitations of HTML at the client far more onorous than any at the
: server.
...Huh? How does HTML have anything to do with OS differences?
: If a single NT server is a file server, database server, www server and FTP
: server, then you may need more than one admin.
Last I checked, MS still recommended running no more then one
major service per box.
If ten Unix servers where all running file servers, databases,
web servers, and FTP servers, it's likely that one admin would
be all that's needed.
: Good programmers tend to go for a reasonably efficient design because the best
: design from other perspectives usually is resonably efficient.
Agreed.
: > Which is good, but the above goals and performance issues are not
: > unmixable.
: I certainly hope not. Otherwise we are pretty doomed.
;-)
: > IMHO, there is no "correct" design, just a "good"
: > design. -A reason of many I don't like Python. Part of a good
: > design takes performance into account.
: Don't know python. I assume you are talking about its intrepreted nature, and
: pure OO design.
The interpreted nature isn't a problem; I consider it an asset
actually. It's heavy "OO only" and "one true, correct way" bent is
what I was speeking to.
: However I mostly find that when performance is inadequate it is because of
: excess calls to an external library or resource, not coding inefficiencies.
I envy you in this case. There is quite a bit of OOO (Overly OO)
code around CPAN and the computer world at large, much leading to
highly complex and inefficient code that are monuments to
abstraction gone horribly wrong...
>snip<
: > It's not just that issue. It's also the simple fact that work
: > should be done where the data is.
: This has always been true. 'Client/Server database' tools like VB,
: Powerbuilder, and SQL Windows still put all the code on the client.
One more reason I'll stay on Unix, thanks. :-)
>snip<
: > Simply because the programmers have to actually start to care
: > about performance, something they were not tought in school. ;-)
: Anything which raises the, already high, costs of software development is
: going to be a problem.
That's the thing, it doens't (or shouldn't at least). It can
actually be the other way around. I'm not talking about slaving
away over a hot terminal for hours trying to shave away 3 clock
ticks. I'm just speeking of the difference in fundamental design
when the programmer actually knows what's going on under the hood.
They need to know what happends when a function is called. They
need to know why a method is more expensive then a function. They
need to understand the pros and cons of inlining. They need to
know how expensive string to int conversions really are and why, even
if the language or system (such as Oracle) they are working in makes
the action transparent. They need to understand how data is really
stored in memory and why it is expensive to move it around. They
need to understand context switching, and why 300 children
select()ing or accept()ing on the same descriptor is very
expensive.
Such low level understanding is what separates the good from the
great, and such understanding should not impact the development
time. In many cases, it will shorten it in the long run as
many efficiency problems that would normally need to be fixed later
will simply never happen.
--
-Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
Date: Mon, 14 Sep 1998 21:43:33 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <96gL1.1626$E9.5495820@ptah.visi.com>
In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
: George Reese <borg@imaginary.com> wrote:
: : In comp.lang.java.programmer Zenin <zenin@bawdycaste.org> wrote:
: >snip<
: : : I'm sure Python has built some of the higher level functionality
: : : of Perl pattern matching, but it's not "identical". Not by a
: : : long shot.
: : How do you know?
: Tack on "in my experience". Last I reviewed Python in depth, a
: little less then a year ago, its pattern matching abilities still
: left much to be desired, and that was before Perl made even more
: major advances.
That's a long way from showing any meaningful functional difference.
: : Python patterns are the same damn patterns as perl. You should parse
: : the results within an OO framework.
: Why? Because an OO framework will solve any and all problems better
: then anything else ever thought of? I think not. OO is just
: a programming method, and rarely the best method for most tasks at
: that.
: In some cases, it would make sense to "parse the results within an
: OO framework", and in many other cases it would not. Pray tell
: why should I be required to create an object and suffer the method
: overhead and extra for something as simple as:
: my ($foo, $bar) = (
: $foobar =~ /match (foo) and (bar) stuff in foobar/
: );
: How is this so much worse then:
: my $regex = new Regexp;
: $regex->setPattern ("match (foo) and (bar) stuff in foobar");
: $regex->setData ($foobar);
: my $foo = $regex->getFirstMatch();
: my $bar = $regex->getSecondMatch();
: Blagh, no thank you.
I clearly believe strongly in the OO way of life. You do not. I
believe the results speak for themselves.
: : Really? Just because someone maintains a C codebase successfully does
: : not mean that task is easy.
: This same argument can be applied to any language.
Yes. Unfortunately, you are the one providing anecdotal evidence of
C's maintainability. While I certainly have not provided overwhelming
evidence that Python is more maintainable, at least I have provided a
test by which we can compare maintainability of it and perl.
: >snip<
: : one of the drawbacks of languages like perl, C, and C++ is that
: : you have to be experienced to write clear code.
: No, you do not, nore have you shown any examples that show
: otherwise.
OK, no, I have not. Here is a test though. Get someone who has a
month of experience with each language. Ask each one to accomplish
the same task in their language. I guarantee the perl, C, and C++
code will always come out more obfuscated than the python or Java
code.
: : In Python or Java (moreso Python than Java), you have to intentionally
: : set out to write unclear code.
: Ditto for Perl.
This is totally false.
: >snip<
: : : I picked up the core of the Java language in a week of reading a
: : : book just on my train ride to work. I've been programming Perl
: : : for the better part of the decade and still don't know all the
: : : power it holds. But guess what, I don't need to know all of it
: : : to write good, clean, and productive code. One doesn't even need
: : : to know most of it.
: :
: : You have just made an argument against Perl.
: Why? The core Java language is practically useless. To do any
: real work you need to know quite a bit about the standard classes,
: which are *huge*. The total amount of information you need to
: do real work in Java (core language + std classes) is far greater
: then the total amout of information you need to do real work
: in Perl (very small subset of the core language and no libs).
:
: In any event, the lines at which you divide the information up
: is not important. One still needs to learn similar sums of
: information to get similar tasks done.
This OO breakdown of the language makes it a lot easier to get going
in the language and accomplish what you need. Contrary to what you
have stated, the number of Java classes ou need to know in order to
get started is very low. Need to add database access to your
repertoire? Just worry about java.sql.
: >snip<
: : The opposite is true. Just because something is complex does not make
: : it in any way more efficient to use.
: That should be, "the opposite is *also* true", else you imply my
: statement as false, which it isn't.
I stand corrected.
: : : Perl requires more self control then other languages, I'll give
: : : you that.
: : That is bad.
: Why? Just because Perl gives users more flexibility in the way they
: code does not mean that it is harder to code cleanly. True you
: can code badly with greater ease, *if you choose to*. Take the
: same Python habits and apply them to Perl and you'll have equally
: as readable code, with *no* greater effort or experience.
This contradicts what you stated before. If it is easier to hang
yourself, then that means it is more likely you have to know what you
are doing to avoid pitfalls. And the same bad programming habits will
not create unreadable python code. You have to be an expert at Python
to create unreadable Python code.
: >snip<
: : You overestimate perl's pervasiveness. Perl's evolution beyond system
: : administration is an accident of being in the right place at the right
: : time. It is also an accident that is being rectified.
: And you underestimate Perl's appeal. With Python, if you don't
: agree with Python's idea of "correct", you're wrong, period. With
: Perl you are free to decide what is "correct" on your own. Freedom
: is *very* appealing, simply because humans almost *never* fully
: agree on any particular subject or method.
Freedom has no place in programming. Period.
: >snip<
: : That is a statement neither you can support nor that I can argue
: : against. I have maintained, however, that long time perl programmers
: : are not the best judges of perl maintainability and readability.
: By the same token, long time Python programmers would not be the
: best judge of Python's maintainability and readability, fair?
Correct. And the beauty of this is that I am not a long time Python
programmer. I have slightly more perl experience than python experience.
: >snip<
: : : "Conciseness is a virtue, when maintaining code at 3am".
: : Throwing around cute rhetorical quotes does not make an argument.
: It's quite simple. If a thought process can be expressed clearly in
: a much shorter amout of code, finding a particular thought within
: the block is much, much easier. If one has to scrool through
: many pages of code to find the location of a problem it is much
: harder to read, understand, and maintain then if the "big picture"
: can be seen all at once, or at least within the space of a minimal
: set of pages.
You overestimate the source code size difference between the python
and the perl. My python code ends up coming out in fewer LOC than my
perl code to do the same thing (I know because I ended up rewriting
many of my old perl scripts).
: >snip<
: : If you are comparing python's use of whitespace with that of a
: : Makefile, it is you who are evil. They are nothing alike.
: They are magic whitespace. Magic whitespace is evil, in
: all forms.
It is evil in Makefiles because Makefile distinguish between
whitespace and tabs. Please explain what the issue is with python?
: : I said the IDEAL language would be human
: : language with a disambiguation process so that EVERYONE could read and
: : write computer programs. That is clearly not what python is. I have
: : nowhere tried to argue that is what python is. I have only argued
: : that python is a lot closer to that than perl is.
: ???
: Human speech is *filled* with many, many ways to express the
: same idea. "Step on my land and I will kill you" or "I will kill
: you if you step on my land", or "Do not step on my land or
: I will kill you". Perl, far more then *any* other language in
: common use allows these forms of human speech constructs to be
: used.
: Python takes the direct opposite view infact, believing instead that
: there is one true way to say something and be damned anyone that
: might disagree that it isn't the best way.
This is the second post where you have failed to distinguish between
the ideal and the best we have to offer. The ideal is to use
structured natural language (in other words, to limit expression a bit
so that it is natural language anyone can understand). The reality is
something like python which is expressive in terms common among people
while retaining the structure required for structured programming.
Perl is just chaos.
: >snip<
: : : Quite true. The integration system however, leaves much to be
: : : desired. It has nothing even remotely close to the power of
: : : PAUSE and CPAN.pm, but then, nothing else on the planet currently
: : : comes close to them.
: : How do you know? What exactly do these modules do?
: PAUSE (Perl Authors Upload Server) isn't a module, it is a system.
: CPAN (Comprehensive Perl Archive Network) is both a system and
: a module to interface with that system.
: To install a module Foo for instance, which has a dependency of Bar,
: one just issues the command:
: perl -MCPAN -e 'install Foo'
: The CPAN module will download the latest Foo from a known CPAN
: mirror, check and install any dependencies (Bar) automatically,
: check versions, etc of everything, build/compile/whatever Foo,
: install it, and register it. The only package management system
: that comes close is the FreeBSD "ports" system, and CPAN still
: has many advantages over it.
: This is just one of many, many features of the system however.
This has absolutely nothing to do with the language.
: >snip<
: : : : And software reuse does not make something OO.
: : : Quite correct. The only correct thing I've seen you write, but
: : : it is correct. :-)
: : : And on the flip side, OO does not make something reusable.
: : If it is properly OO, it is very likely to be reusable.
: No, if it is designed well it is likely to be reusable. OO did
: not invent code reuse, nore does it define it.
OO is the single best path to code reuse.
: : Java is pure OO.
: Java has primitive types, therefore by strict OO thinking it
: is *not* "pure" OO.
That has nothing to do with pure OO. Pure OO is defined by data
abstraction, inheritance, polymophism, and encapsulation.
: : Python is close enough.
: Close enough for what? Perl is as OO as you want it to
: be. That's the point, not everyone wants it to be and
: with good reason. Because not everything (not even
: most things) should be OO.
I explained how it is 'close enough'. It exemplifies everything of
pure OO except encapsulation. It only has a weak form of
encapsulation.
Perl, on the other hand, enforces nothing in the object realm. It
simply allows it.
: >snip<
: : That is a freedom that has no place in an OO language. You do not
: : combine a structured software engineering process with a weak link.
: : It is like sticking a pipe with a huge leak inside your plumbing.
: : Perl is quite simply no where as OO as python.
: As is clear by anyone that actually has taken a good look,
: Perl not only is as OO as anyone wants it to be, its model
: is very close to Python's (which as far as I remember is where
: the design was adopted from).
It is not even close.
: : Be careful of the examples you choose. In OO circles, C++ is
: : considered to be about the worst example of OO available.
: In language circles it is considered to be about the worst
: example of a programming language available.
: :-) <--For the humor impaired
: The fact is that it *is* an example, good or bad, of an
: OO language, and Perl is at *least* as "OO" as C++.
And that is not a point worth making since my contention is that perl
is bad OO.
: : That is because OO is 'not simply a tool'. Because of the structured
: : nature of the OO software engineering process, you need a language
: : that enforces your structure.
: Why? Because the programmer is to inept and or stupid to enforce
: such practices on there own? Of course, that's it, least we have
: people using non-OO code where it makes sense and actually get some
: good work done.
It is very convenient to insult everyone not as skilled at you at
programming, but the fact is that the more people you can make
productive in programming, the more work you can get done. And the
more work you can get done, the more money you make.
Therefore, if you can reduce the learning curve for getting involved
in programming, you raise the amount of money you can make.
: : Since I cannot answer the functionality question above, I can only in
: : good faith concede that bit of functionality to you based on my
: : ignorance (and not necessarily any fact about python). However, it is
: : a long way from that one piece of functionality to 'python has a huge
: : game of catchup to play'.
: It's a *lot* more then "one piece". It's an entire system and
: framework. A monument to reusablity, user (not language) enforced
: design ethics, and community.
Actually, I conceded the point to early. Python, as I noted in
another post, has that functionality. So.... where exactly is this
catchup required?
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie."
-Orson Welles
------------------------------
Date: Mon, 14 Sep 1998 20:27:53 GMT
From: Elaine -HappyFunBall- Ashton <eashton@bbnplanet.com>
Subject: Re: PERL routine using wtmp?
Message-Id: <35FD79E8.D17A1514@bbnplanet.com>
Hrmph. Got caught posting while asleep...all I saw were monitoring and
paging. :) Since you are running RedHat, you should have TCPwrappers
already installed. Configure it to wrap telnet or ssh so it will log to
syslog. Then all you have to do is write a fun little script to check
for your user and send email to your pager.
e.
"All of us, all of us, all of us trying to save our immortal souls, some
ways seemingly more round-about and mysterious than others. We're having
a good time here. But hope all will be revealed soon." R. Carver
------------------------------
Date: Mon, 14 Sep 1998 16:12:04 -0400
From: dragons@scescape.net (Matthew Bafford)
Subject: Re: Perl Test or Questionare?
Message-Id: <MPG.10670678d5c2336a989695@news.south-carolina.net>
In article <35FD07BA.77E8C184@fairchildsemi.com> on Mon, 14 Sep
1998 08:10:34 -0400, Christopher Marquis
(Christopher.Marquis@fairchildsemi.com) pounded in the following
text:
=> I am recruitung a new Perl programmer for my team. I'm pretty sure I
=> could spot a good one after a few minutes of talking with them, but I
=> had seen on here a while back that there was a test or a questionare
=> that was floating around. I was wondering if someone had a list of Perl
=> questions that I could give to them before I even went as far as do a
=> face to face. Thanks in advance for the assistance!
=>
=> Chris
=>
How about:
http://www.dejanews.com/getdoc.xp?AN=324248975
Just a thought,
--Matthew :)
------------------------------
Date: Mon, 14 Sep 1998 16:25:54 EDT
From: dblack@saturn.superlink.net (David A. Black)
Subject: Re: regex help
Message-Id: <6tju4i$aho$1@earth.superlink.net>
Hello -
Edward Glamkowski <eglamkowski@angelfire.com> writes:
>I am processing a file containing addresses, and need to remove all
>periods in the file, EXCEPT for those associated with P.O. or U.S.
>I have the following:
> if ($addr1 =~ /(\w+\.)+/) { $addr1 =~ s/(\w+)\./$1 /g; }
>But that obviously doesn't take into account the U.S. or P.O.
>The problem I have is what happens when you run into a line containing
>both U.S. AND a period somewhere else in the line. How do I remove the
>periods from one 'word' and not another?
If you're not afraid of being yelled at by -w:
$addr1 =~ s/(U\.S\.|P\.O\.)|\./$1/g;
and if you are:
$addr1 =~ s/(U\.S\.|P\.O\.)|\./$1?$1:''/ge;
David Black
dblack@saturn.superlink.net
------------------------------
Date: Mon, 14 Sep 1998 20:48:02 GMT
From: Edward Glamkowski <eglamkowski@angelfire.com>
Subject: Re: regex help
Message-Id: <35FD80B7.75FC@angelfire.com>
Matt Knecht wrote:
> Edward Glamkowski <eglamkowski@angelfire.com> wrote:
> >Any pointers would be much appreciated :)
>
> You don't need regex help. You need to decide exactly what you're
> trying to parse first. If you want to preserve certain contrusts
> (Like 'U.S.'), then save them in a hash, and make sure you don't strip
> them.
Actually, I had one suggestion that seems to have worked, using $+
s/(U\.S\.|P\.O\.)|(\w+)\.)/$+/g;
Anybody see any problems with this method?
--
"Have you no sense of decency, sir?
At long last, have you left no sense of decency?"
http://www.angelfire.com/nj/eglamkowski/null.html <-- Null webring
http://www.angelfire.com/nj/eglamkowski/eia.html <-- Eia webring
------------------------------
Date: 14 Sep 1998 20:07:41 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: search and replace between values
Message-Id: <6tjt2d$o8j$1@marina.cinenet.net>
Steve . (syarbrou@ais.net) wrote:
: I have a line like:
:
: http:www.url.com/cgi-bin/hi.cgi/jim.zip?fx=joe.joe.net
:
: I want to delete everything from http through fx= . Problem is the
: jim.zip part changes values on each line. Is there a way to do this?
Presuming that means the rest doesn't change:
s!\Qhttp:www.url.com/cgi-bin/hi.cgi/\E.*?\?fx=!!g;
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "Ripple in still water, when there is no pebble tossed,
nor wind to blow..."
------------------------------
Date: 14 Sep 1998 23:40:17 +0200
From: Jonathan Feinberg <jdf@pobox.com>
To: Oliver Czoske <oczoske@astro.obs-mip.fr>
Subject: Re: selective split
Message-Id: <m3g1dufk5a.fsf@joshua.panix.com>
Oliver Czoske <oczoske@astro.obs-mip.fr> writes:
> this should be a very common problem, but as I'm not used to regexps I
> haven't yet found a solution. What I want to do is to split a database
> entry where the fields are separated by ':'. Now, the fields themselves
> may contain colons which are then masked by a backslash. How do I get
> split to split at colons unless they are preceded by a backslash?
You should consider buying the Friedl book _Mastering Regular
Expressions_, which is full of examples like that. Here's one
approach:
#!/usr/bin/perl -w
while (<DATA>) {
chomp;
my @fields = /((?:\\.|[^:\\])+)/g;
print join("\n",@fields),"\n\n";
}
__DATA__
this colon \: is escaped:that wasn't:nor is this
nothing escaped:here:in:this line:dude
how\:about:these\:\:babies:\:\:here\:man?
yep \::\: man
> Thanks for any help.
^^^^
Heh. The emacs version of :wq
--
Jonathan Feinberg jdf@pobox.com Sunny Brooklyn, NY
http://pobox.com/~jdf
------------------------------
Date: Mon, 14 Sep 1998 20:58:46 GMT
From: steven_elias@ml.com (Stephen Elias)
Subject: STD I/O for WIN32 Perl
Message-Id: <35fd830c.24418822@news.ml.com>
Hello,
Is there any reliable way to perform STD I/O with WIN32 Perl ???
Thanks
example: STDIN / STDOUT
myperl.pl < foo-in.txt > foo-out.txt
------------------------------
Date: Mon, 14 Sep 1998 19:47:12 GMT
From: ced@bcstec.ca.boeing.com (Charles DeRykus)
Subject: Re: Use of 'exit' in child process
Message-Id: <EzAHMo.JAp@news.boeing.com>
In article <35F6EFC6.69C4D184@arm.com>,
Chris N. Hinds <chris.hinds@arm.com> wrote:
>I hope this is a simple one...
>
>In a child process I have an 'exit' as the last
>statement, and I have verified that nothing after
>the exit will execute. In the parent process I have
>a 'sleep 10' (longer than the child) and a test for the
>pid of the child using a 'kill(0, $pid)'. The test returns
>a 1 after the sleep 10, and a 1 again after a 'kill(9, $pid)'!
>
>Why are the outputs of the kill 0 both 1 when the process
>has exited?
>
Is there a wait/waitpid in this scenario? If not, then
even if the child's been zombied, the parent'll still
be able to send a signal 0 successfully.
hth,
--
Charles DeRykus
P.S. - best to show the code in cases like this.
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 3714
**************************************
