[10099] in Perl-Users-Digest
Perl-Users Digest, Issue: 3693 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 11 14:08:41 1998
Date: Fri, 11 Sep 98 11:01:26 -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 Fri, 11 Sep 1998 Volume: 8 Number: 3693
Today's topics:
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses (Matt Knecht)
Re: Perl & Java - differences and uses bjohnsto_usa_net@my-dejanews.com
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: Perl & Java - differences and uses bjohnsto_usa_net@my-dejanews.com
Re: PERL newbie needs some help <shawn@magma.ca>
Re: Perl Programmer Needed (Mark-Jason Dominus)
Re: Regular expression question (Sean McAfee)
Re: Regular expression question <ajohnson@gpu.srv.ualberta.ca>
Re: Search/Replace but Not under certain conditions. HO (Ilya Zakharevich)
Re: Search/Replace but Not under certain conditions. HO (Ilya Zakharevich)
Searching for a few CGI scripts t-dog98@usa.net
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 11 Sep 1998 16:40:17 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <RncK1.906$E9.3137532@ptah.visi.com>
#1/usr/local/bin/python
import cgi, time;
if __name__=="__main__":
print "Content-type: text/html";
print;
print "<HTML><HEAD><TITLE>Simple CGI</TITLE></HEAD><BODY>";
form = cgi.FieldStorage();
if form.has_key("user"):
print "<H1>"Hi there " + form["user"].value + "</H1>";
print "<P>The current date/time for this server is " +
time.ctime(time.time()) + "</P>";
else:
print "<FORM><H3>What's your name?</H3>";
print "<INPUT NAME=user>";
print "<INPUT TYPE=submit></FORM>";
print "</BODY></HTML>";
If the built-in functions for encapsulating HTML output do not already
exist in python, creating one for python would be trivial. I,
unfortunately, do not work with a lot of CGI in any language (I use
Java servlets). I go back in forth as to whether or not I think it
makes sense to encapsulate HTML output inside functions in the
CGI/servlet language (I have been dealing with this in some Java
libraries I have been writing). There are arguments to be made both
ways. By encapsulating the HTML inside the underlying programming
language, you are making the source code more natural in the metaphor
of that language. On the other hand, by making the HTML code more
plain, you make it easier to see what the HTML output should look like
(and, IMHO, debug).
Nevertheless, either way you lean (and I lean towards the more
minimalist approach), both languages carry the functionality. IMHO,
the Python is much more readable. But I do not think 10 line programs
are the way to test the readability, maintainability, and
extensibility of a language.
In comp.lang.java.programmer Jim Woodgate <jdw@dev.tivoli.com> wrote:
: Since I don't know python, how would you code the following, a simple
: cgi script that does both the front and back end. I left out comments
: and didn't even format it like I normally like to, and I still think
: it is easily readable by most people that have even the slightest
: programming/http/cgi knowledge. (The form is troll-ugly, but I wanted
: to be brief... :)
: Please show me how using python would make this easier...
: #!/usr/bin/perl -w
: #
: use CGI qw/:standard/;
: print header, start_html("Simple CGI");
: if (param) {
: print h1("Hi there ",param('user')),
: p("The current date/time for this server is",
: em(scalar localtime));
: }
: else {
: print start_form, h3("What's your name"), textfield('user'), p,
: submit("Press Me"), end_form;
: }
: print end_html;
--
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: Fri, 11 Sep 1998 16:40:42 GMT
From: hex@voicenet.com (Matt Knecht)
Subject: Re: Perl & Java - differences and uses
Message-Id: <eocK1.97$o72.629461@news3.voicenet.com>
George Reese <borg@imaginary.com> wrote:
>No, my point is that Python and Perl are roughly identical in
>functionality
Agreed. What I don't see in Python, however is complex data structures.
Does Python have a moral equivelant to Perl's references? Can Python
have function/sub/def pointers?
Casual perusal of the language also seems to tell me that it's regular
expressions leave a bit to be desired. Maybe that's a good thing for
Python, sice regular expressions are extremely "line noise like". But
they are also incredibly powerful.
>but that Python produces some of the easiest to maintain
>and extend code on earth while Perl is its polar opposite--some of the
>hardest to maintain and extend code on earth.
This sounds like pure opinion to me. I see no facts *anywhere* from the
web, to dejanews, to your own posts that can even begin to proves this.
Let me give you a quick example. Before I got my current job, I was a C
programmer. I was first introduced to Perl by having to mantain no less
than 5 sepereate individual's code, some of which was written in Perl 4,
which could almost be called a different language! The Perl 5 code I
have maintained and modified quite easily (I have re-written the Perl 4
code to take advantages of things that were not availible to Perl 4. I
don't know if this proves your point or not. However, I would prefer
that the language grows and not stagnates just to keep old code
"current").
>You need to read more carefully, because you have meaningfully
>mis-paraphrased me on both counts and followed it up with a summary of
>something I did not ask.
Meaningfully? No. I may have inferred what was not there, though.
Phrases like "Perl is its polar opposite--some of the >hardest to
maintain and extend code on earth" tend to put me on the defensive (As
I'm sure others have felt). Those are fighting words, pilgrim!
>Thus, if you are not going to argue my points of extensibility and
>maintainability, you need to provide a functional benefit where "all
>things won't be equal".
I don't see what there is to argue with. It seems to me that the burden
of proof lies with you! You make claims, but you don't back them up
with any code examples (As far as I know, the code is the only valid
proof in an argument like this). Again, I place the burden back on you:
Show us why Python is better. A quote that comes to mind
(Unfortunately, I don't know it's author) is "Extraordinary claims
require extraordinary proofs".
>I think you just hit the nail on the head. Your example is line
>noise. The Python example you point out (which has a lot of whitespace
>and comments) is encapsulated in a nice function to make it reusable.
The statement "Your example is line noise" sums up your entire argument.
This is programming. You have to learn the rules of the language. When
you know the rules, it is an extremely elegant piece of code that packs
a lot of meaning into a quickly readable and reproducable statement. I
can't help but think your argument boils down to "Anybody should be able
to look at any code and instantly see what it does without knowledge of
the language". Am I wrong? If so, how?
Again, I counter the line noise argument with: Python looks like
somebody pulled random words from a dictionary and joined them with
excessive whitespace, colons and periods. Both statements are
equivalent.
>I think all I hear constantly from Perl supporters is how few
>keystrokes than can accomplish a task in. Sorry, but I consider that
>a defacto sign of a lack of maintainability.
No, that's is how you interprete what you hear. That sentiment, while
it can express a fun hobby, is not what Perl is. But, it does have a
lot of truth to it. You can express very complex idioms in a small
space. The object isn't to use as few keystrokes as possible. It
should be more correctly read as "Don't use unnesacery logic". Using
Perl, I can can express in a few lines what would take a more primitive
language *pages* of code. The pages may be easy to read, but with a
minimal amount of homework, the few lines are of Perl are just as
easy... in fact, easier because everything is expressed so well!
>And note, both languages are able to perform the task admirably. So
>that is not even a functional difference.
Admirably? You missed my point then. I don't consider the Python
example to be admirable. I consider it to be needlessly complex and
long winded. The onyl thing it proves is that it can be done in Python
through a much greater investment in time, at the expense of future
maintainability.
>: use Text::Tabs;
>: @expanded_lines = expand(@lines_with_tabs);
>
>: It doesn't get much easier than that. A **LOT** can be trivially
>: accomplished in Perl with the use of modules. I invite you to check out
>: your nearest CPAN.
>
>Well, shit, I can do that with Python:
>
>import tabfix;
>
>expanded_lines = tabfix.fixTabs(line_with_tabs);
Don't blow off Perl modules so easily. Chances are if you have a
problem, somebody has built a module for it and it's availible on the
CPAN. The sheer volumne of modules is overwhelming. Perl is by far and
away the language that best captures the OO mantra of software reuse.
As evidence, I invite you to check out your nearest CPAN.
--
Matt Knecht - <hex@voicenet.com>
------------------------------
Date: Fri, 11 Sep 1998 16:58:33 GMT
From: bjohnsto_usa_net@my-dejanews.com
Subject: Re: Perl & Java - differences and uses
Message-Id: <6tbkrp$62$1@nnrp1.dejanews.com>
In article <905466113.40215@thrush.omix.com>,
Zenin <zenin@bawdycaste.org> wrote:
> bjohnsto_usa_net@my-dejanews.com wrote:
> : In article <905295043.652672@thrush.omix.com>,
> : Zenin <zenin@bawdycaste.org> wrote:
>
> For general web sites, I agree with you. For enterprise apps, there
> is no reason to ignore such functionality as presumably a company's
> employees can trust applications written for and by the company,
> regardless of the platform. In such closed systems, the are at
> least no less secure then a full local app.
I agree that for intranet (you said it as enterprise, but I think this goes
for departmental) applications, there is no reason not to trust an internal
applications. However the intranet applications I have built have had no
need for anything outside the sandbox.
> : I use Windows95 at work wide open, and Windows 95 will let anyone do
anything.
> : If I had some choice and did use something decent I would probably still use
a
> : reasonably powerful login.
>
> Some of us can't put our systems at quite such a risk.
Sure, I accept that. I certainly don't want any computer that controls a
nuclear power plant, or my bank account to be running arbitary Java programs.
I feel that those who can run Java applets safely are by far the majority.
>
> : Yes, the database vendors can't make their products/architecture work with
> : many simultaneous users. Pretty pathetic really.
>
> It's not the fault of the database if the application can't scale,
> it's the fault of the designer that used the database incorrectly.
> As I've mentioned, I've got systems in place that handle 3k to 10k
> simultaneous users through as little as 10 Oracle connections. Ford
> can't help it if you connect your big block 400 to the drive chain
> using a bicycle chain.
Given the way that current databases work, an applications which requires each
user to hold a database connection will not scale.
Since this is well known and application which is required to scale should not
be architected this way.
However Database vendors could enable simpler architectures to scale better
by by changing the limitations of their implementations. Instead they have
created requirement to pool connections and diverted some of their potential
revenue to products which provide this service.
> : > lacks the basic primitives (select(), non-blocking IO, file
> : > descriptor passing, etc) to compete for use in writing servers
> : > under Unix (thread all blocking IO my ass...).
> :
> : Not sure I agree. The servers I have written have all been fairly low
volume,
> : and Java would have been fine.
>
> That's the key, low volume. One can easily write low volume inetd
> servers in shell script. If you're only doing low end server work,
> they pretty much any language and/or code design will work.
A common mistake that many involved in a specialized area of computing
science is to assume all other aspect of the trade are simple. People in
real time assume that building batch processes are easy. People in highly
mathematical areas assume that everything else is just shifting data around
by comparitively much simpler rules. People with short deadlines think it is
easy to accomplish any job with more time. People with a requirement for a
large volume of changes with a high level of reliablility assume those with
more static environments have an easy task.
People with a large number of users assume that those with a lower number of
users can get by with any language, like shell script. I have no serious
experience writing large systems in shell script, but I assume that it is not
adapt at solving optimisation problems with linear programming.
> : I guess the Java people just want you to use more threads.
>
> Yes. They are sponsored by the memory and CPU manufactures, I'm
> sure of it. Personally, I feel people should be required to test
> for a competency license before being allowed to use threads. Of
> course, I feel the same way about USENET. :-)
I have no real problem with asking for a bit more memory or CPU at todays
prices if it saves on programmer time.
I agree on threads, however even those competent with threads will create more
bugs by using them. It is important to limit the amount of code which can
potentially have concurrency bugs.
>
> : Maybe now that Sun is looking more towards Java on the server al well as in
a
> : set top box, you will get more of the what you need.
> :
> : Maybe in addition to Personel Java we will get Server Java.
>
> The reason Java lacks the needed primitives I listed before is
> simply because they are not "portable" in the Java sense. Eg, they
> are pretty much impossible to replicate on a Win32 or MacOS
> platform, let alone a WindowsCE toy.
Oracle, and Web servers seems to run OK on NT.
My experience with AIX servers here says they are slower than NT boxes that
cost 1 tenth the price.
I suggest that working within the limitations of a tool, good solutions can be
architected.
>
> : > Even JDBC from
> : > Servlets is worthless with 3k-10k simultaneous users, which is
> : > common for enterprise level applications.
> : Servlets are improving fast.
> : I don't see any major long term issues with the architecture.
>
> For the people thinking it will solve there applet to database
> connectivity issues, they are in for a big supprise. Web server
> cached database connections of any kind scale like mud.
>
> Remember, if you've got 20 httpd children, you've got 20 cached
> database connections.
I take it that the reason you have 20 children is because you don't have
threads.
> Oh, you want to have three different parts
> of the web site (or virtual hosts) use three different database
> logins? You can kick that up to 60 connections. Have a
> "development" "test", and "production" setup? Make that 180 or so.
> Oh, you don't plan to put that much traffic through them? Tough,
> the connections can't be shared across web server children so even
> if you only use the connection once an hour I'm still going to have
> to keep a cached connection per child.
>
> Ever see what the common Oracle server does with 200 connections?
> Let's just say I hope you've got a huge amount of swap space. :-)
You could stick your development, and test boxes on different boxes or on
different ports.
But your point still holds.
>
> Like I said, the design is inherently flawed, regardless if you're
> using Servlets, Apache/DBI cached handles, or Netscape NSAPI
> handlers.
Maybe the Java Web server would do OK.
>
> So why does it work then? Simply because 90% plus of the web
> servers around never have to scale large enough to hit this
> problem. I work in the other < 10% that does need to exceed
> this bottleneck.
Many that exeed the bottleneck solve the problem by buying more hardware.
We could run all our applications on two independent web servers, and no code
would change.
The database is the only limitation.
>
> : > To be honest, Java is pretty darn good for client apps, but
> : > for servers it bites, and without an extra tier or three it
> : > can't scale database access well at all (but then, neither
> : > can anything else, really, for the same reasons).
> : Databases themselves are the limiting factor.
> : They are an order of magnitude slower than any of the web technologies.
>
> How much high end database work have you done?
Please be more precise. I have been working with relational databases for 8
years. I have always found that if I start from the assumption that any
operation which hits a relational database 100000 times more expensive than
getting some data from local memory my applications perform well.
I recently wrote a program which allows users to upload a spreadsheet to a web
server which reads the data in the spreadsheet and updates an oracle database.
A collegue wrote the upload for some spreadsheet templates, I wrote some
others. He is a developer with roughly equal intellect and experience. The
load for the templates that I did access the database less and are massively
faster.
This is because using relational databases is slow.
> Databases can
> more then keep up with the requirements of web and similar
> technologies.
Only if you understand how slow they are and make sure you code around the
performance problems that would otherwise result.
> It's not just a performance issue however, or
> everyone would be running MiniSQL over Oracle. It's a feature
> issue. If you need the kind of features Oracle, Informix, etc
> offer you just can't get it out of web technologies alone. And
> if you try, you'd be many orders of magnitude slower then everything
> else on the planet, in both raw performance and development time.
>
> Again, it's the total system design that's the real problem. Many
> people blame both Perl, Java, Oracle, CORBA, and others for
> being slow, but more often then not if you actually look at the
> code and systems they are using to base such opinions on you'd
> laugh your ass off. It boggles the mind what some people
> actually charge money for these days. The same designs in
> assembly would still be slow as mud.
Perl, Java are fast (C and C++ are very fast).
CORBA I am not sure.
Oracle (like all other relational databases) is slow for many tasks.
I recently had to mulge some data in perl and put it into Oracle.
I have been using perl off and on for less than one year.
I have been using SQL extensively for 8 years and Oracle intensively for 1
year. I have done some DBA work but this database is not one I DBA.
The perl task to mulge the data took 1 minute to code and a few seconds to
run.
The Oracle upload took ten minutes. That is because relations databases
are slow.
>
> If a carpenter can't hammer a nail correctly, it's unlikely
> the hammer or the nail is at fault.
The point is that by choosing a certain set of compromises databases, ORBs
and languages make certain architectures possible. These architectures are
neither the simplest, most productive, or most robust.
> -Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
Brendan Johnston
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Fri, 11 Sep 1998 17:12:10 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <KRcK1.924$E9.3137532@ptah.visi.com>
In comp.lang.java.programmer Matt Knecht <hex@voicenet.com> wrote:
: George Reese <borg@imaginary.com> wrote:
:>No, my point is that Python and Perl are roughly identical in
:>functionality
: Agreed. What I don't see in Python, however is complex data structures.
: Does Python have a moral equivelant to Perl's references? Can Python
: have function/sub/def pointers?
Yes.
Though it's "function pointers" use very different, and, IMHO, more
powerful semantics.
: Casual perusal of the language also seems to tell me that it's regular
: expressions leave a bit to be desired. Maybe that's a good thing for
: Python, sice regular expressions are extremely "line noise like". But
: they are also incredibly powerful.
In my experience, the regular expressions in both languages are
identical in function. The Python version just meshes better into a
the Python semantics. The Perl version, IMHO, seems like a grafting
of line noise into line noise :)
:>but that Python produces some of the easiest to maintain
:>and extend code on earth while Perl is its polar opposite--some of the
:>hardest to maintain and extend code on earth.
: This sounds like pure opinion to me. I see no facts *anywhere* from the
: web, to dejanews, to your own posts that can even begin to proves this.
: Let me give you a quick example. Before I got my current job, I was a C
: programmer. I was first introduced to Perl by having to mantain no less
: than 5 sepereate individual's code, some of which was written in Perl 4,
: which could almost be called a different language! The Perl 5 code I
: have maintained and modified quite easily (I have re-written the Perl 4
: code to take advantages of things that were not availible to Perl 4. I
: don't know if this proves your point or not. However, I would prefer
: that the language grows and not stagnates just to keep old code
: "current").
As a C programmer, you had an advantage--you were used to dealing
with hard to maintain code. Furthermore, my claim comes from
discussing this with people skilled at both perl and python
programming and with experience at getting people who know neither to
learn them. While that is not a formal study, I have quite honestly
never met someone who was experienced with both languages who did not
think the difference in maintainability between the two was like night
and day.
:>You need to read more carefully, because you have meaningfully
:>mis-paraphrased me on both counts and followed it up with a summary of
:>something I did not ask.
: Meaningfully? No. I may have inferred what was not there, though.
: Phrases like "Perl is its polar opposite--some of the >hardest to
: maintain and extend code on earth" tend to put me on the defensive (As
: I'm sure others have felt). Those are fighting words, pilgrim!
On the defensive? Why would you get defensive about a programming
language?
:>Thus, if you are not going to argue my points of extensibility and
:>maintainability, you need to provide a functional benefit where "all
:>things won't be equal".
: I don't see what there is to argue with. It seems to me that the burden
: of proof lies with you! You make claims, but you don't back them up
: with any code examples (As far as I know, the code is the only valid
: proof in an argument like this). Again, I place the burden back on you:
: Show us why Python is better. A quote that comes to mind
: (Unfortunately, I don't know it's author) is "Extraordinary claims
: require extraordinary proofs".
Something that would work for perl developers? I don't think so. But
I do think the degree to which perl is disaparaged foor its
unreadability should be something that strikes you like a neon sign in
the dead of night.
And if you have not heard perl constantly disparaged for its lack of
readability, you are either lying or living on another planet.
:>I think you just hit the nail on the head. Your example is line
:>noise. The Python example you point out (which has a lot of whitespace
:>and comments) is encapsulated in a nice function to make it reusable.
: The statement "Your example is line noise" sums up your entire argument.
: This is programming. You have to learn the rules of the language. When
: you know the rules, it is an extremely elegant piece of code that packs
: a lot of meaning into a quickly readable and reproducable statement. I
: can't help but think your argument boils down to "Anybody should be able
: to look at any code and instantly see what it does without knowledge of
: the language". Am I wrong? If so, how?
You are terribly wrong. A programming language is a construct to
formalize human desires so that they can be translated into a form
understandable by machines. The ideal programming language would be
a human language at a 5th grade reading level. Unfortunately, human
languages are notoriously ambiguous and hard to compute.
: Again, I counter the line noise argument with: Python looks like
: somebody pulled random words from a dictionary and joined them with
: excessive whitespace, colons and periods. Both statements are
: equivalent.
No, it is not. My claim makes sense. Perl is often a string of
non-alphabetic characters that have contextual meaning (often used
without any respect to how we use them in normal discourse) and laced with
implied behaviour. That you cannot deny. And all of those things
renders it hard to read.
Python, on the other hand, cannot be argued with a straight face that
it is random words from a dictionary. The words are gathered in
basically broken English and fit into an OO paradigm. Excessive
whitespace? Only someone who believes in terseness would argue that.
The whitespace clarifies program blocks--you are never in doubt in
python where the program blocks lie. I don't know where you get
periods, but anyone with any programming experience should be able to
see immediately what the colons mean.
:>I think all I hear constantly from Perl supporters is how few
:>keystrokes than can accomplish a task in. Sorry, but I consider that
:>a defacto sign of a lack of maintainability.
: No, that's is how you interprete what you hear. That sentiment, while
: it can express a fun hobby, is not what Perl is. But, it does have a
: lot of truth to it. You can express very complex idioms in a small
: space. The object isn't to use as few keystrokes as possible. It
: should be more correctly read as "Don't use unnesacery logic". Using
: Perl, I can can express in a few lines what would take a more primitive
: language *pages* of code. The pages may be easy to read, but with a
: minimal amount of homework, the few lines are of Perl are just as
: easy... in fact, easier because everything is expressed so well!
If it comes out looking like something only a perl expert could read,
it is no good.
:>And note, both languages are able to perform the task admirably. So
:>that is not even a functional difference.
: Admirably? You missed my point then. I don't consider the Python
: example to be admirable. I consider it to be needlessly complex and
: long winded. The onyl thing it proves is that it can be done in Python
: through a much greater investment in time, at the expense of future
: maintainability.
This is totally false. The python version is only slightly longer
(and, as I pointed out, easier for a non-python/non-perl programmer to
read). If you actually believe that is a meaningful difference, then
I would question your value system.
:>: use Text::Tabs;
:>: @expanded_lines = expand(@lines_with_tabs);
:>
:>: It doesn't get much easier than that. A **LOT** can be trivially
:>: accomplished in Perl with the use of modules. I invite you to check out
:>: your nearest CPAN.
:>
:>Well, shit, I can do that with Python:
:>
:>import tabfix;
:>
:>expanded_lines = tabfix.fixTabs(line_with_tabs);
: Don't blow off Perl modules so easily. Chances are if you have a
: problem, somebody has built a module for it and it's availible on the
: CPAN. The sheer volumne of modules is overwhelming. Perl is by far and
: away the language that best captures the OO mantra of software reuse.
: As evidence, I invite you to check out your nearest CPAN.
Python has tons of modules as well. And software reuse does not make
something OO. Perl IS NOT OO. It just added some OO constructs as an
afterthought. I invite you to check out http://www.python.org.
--
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: Fri, 11 Sep 1998 17:22:36 GMT
From: bjohnsto_usa_net@my-dejanews.com
Subject: Re: Perl & Java - differences and uses
Message-Id: <6tbm8s$2hm$1@nnrp1.dejanews.com>
In article <MmJJ1.591$E9.2050246@ptah.visi.com>,
George Reese <borg@imaginary.com> wrote:
> In comp.lang.java.programmer David Formosa <dformosa@zeta.org.au> wrote:
> : In <tsFJ1.545$E9.1882388@ptah.visi.com> George Reese <borg@imaginary.com>
writes:
>
> :>: Unfortunately, choice of programming language, for many people, is like
> :>: choice of religion. And how many people can discuss religion in a mature
> :>: fashion? :-)
>
> :>This is a fallacy. Religion cannot be discussed rationally because
> :>religious backers tend to fall back on positions outside of logic to
> :>support their claims.
>
> : And how is that diffrent to Language? In most cases the languge argument
> : collapes down to "I like lang X because I think in a style that lang X is
> : able to express well.".
>
> That's a valid comparison.
But was the selection of example motivated by the fact that this is a
representative task, or was it because it supported an emotional investment.
> :> Languages, on the other hand, can be compared on their merits.
>
> : What factors do you think a good language has over a poor one?
>
> It depends on the ends being discussed.
>
> 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
I have always used sub optimal languages because of the quality and diversity
of their implementations.
Brendan Johnston
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
Date: Fri, 11 Sep 1998 15:57:44 GMT
From: Shawn Corey <shawn@magma.ca>
Subject: Re: PERL newbie needs some help
Message-Id: <35F947D8.35569C91@magma.ca>
Duncan Bates wrote:
>
> Umm sorry for being stupid here but i have some code thats really bugging
> me...
>
> a syntax error is reported although i have done everything "to the book"
>
> #!/usr/bin/perl
>
At this stage, %FORM has no values
> $printrun = $FORM{'printrun'};
> $pages = $FORM{'pages'};
> $coverpics = $FORM{'coverpics'};
> $textpics = $FORM{'textpics'};
>
> # Parse the form
> &parse_form;
You call a subroutine but you don't list the definition. It is difficult
to help you without it. Also, this should be called before you set
$printrun, $pages, $coverpics, and $textpics.
>
This looks like the the start of parse_form but you need
sub parse_form
> {
> # Get the input
> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>
> # Split the name-value pairs
> @pairs = split(/&/, $buffer);
>
> foreach $pair (@pairs)
> {
> ($name, $value) = split(/=/, $pair);
>
> # Un-Webify plus signs and %-encoding
> $value =~ tr/+/ /;
> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> $value =~ s/<!--(.|\n)*-->//g;
>
> $FORM{$name} = $value;
> }
> }
>
Put this code with the rest at the top after &parse_form; This is not
required but is a good coding pratice.
> # Check for zero entries
> unless ($printrun == 0) { &html_die; }
>
> # Limit the values
> if ($printrun < 1000 || $printrun > 100000) { &html_die; }
>
> # Work out the cost of printing the report
> $a = (($pages) * ($printrun))
>
> # Work out calculations for cover and textpics
>
> if (($textpics == "0") && ($coverpics == "1")) {
> $b = ($a * 1.25);
> }
> elsif (($textpics == "1") && ($coverpics == "0")) {
> $b = ($a * 1.25);
> }
> elsif (($textpics == "1") && ($coverpics == "1")) {
> $b = ($a * 1.25);
> }
> else (($textpics == "0") && ($coverpics == "0")) {
> $b = ($a * 1.35);
> }
>
> this is supposed to take some figures (printrun) and multiply them with
> another set of figures (pages) then work out the final calcualtion based on
> whether they want cover pics text pics or both or neither...
>
> its really got me stumped i'd appreciate any hints in the right direction
>
> Thanks
>
> Duncan Bates
> duncan.b@marchcom.co.uk
--
Shawn Corey
s @m .c
h a a
a g
w m
n a
------------------------------
Date: 11 Sep 1998 11:57:28 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Perl Programmer Needed
Message-Id: <6tbh98$47b$1@monet.op.net>
In article <FtfJ1.2801$JW5.8419616@news.rdc1.md.home.com>,
Richard <Richard@WowMe.com> wrote:
>Actually, I am still receiving email from interested
>parties. That fact alone proves the point that some people did appreciate
>the post.
That's just what Lawrence Canter said when I emailed him back in 1994
to say that his green card spam was not appropriate for phl.food.
(Not that I would want to characterize this as spam, or imply that yo
uare acting like Lawrence Canter; I just want to caution against the
argument that traffic is appropriate whenever anyone at all is glad to
see it.)
------------------------------
Date: Fri, 11 Sep 1998 15:50:58 GMT
From: mcafee@waits.facilities.med.umich.edu (Sean McAfee)
Subject: Re: Regular expression question
Message-Id: <CFbK1.2260$F7.9273125@news.itd.umich.edu>
In article <35F91061.30F8@jump.net>,
Sherry Coldsmith or Mike Christie <mikec@jump.net> wrote:
>I am new to perl and am trying to write a program to solve cryptograms,
>as an exercise. A cryptogram is an English sentence with a random
>substitution of letters. For example "Hello, there" might be encrypted
>as "Jkpps, mlkqk". The letter relationships remain constant from word
>to word.
>I have a working program, but I would like to speed it up by only
>reading in words from the dictionary I am using that match the target
>words by pattern. I keep an array of candidate words in memory for each
>word in the crypt. For "mlkqk" I don't need all 5 letter words in my
>dictionary in that array; I only need ones with the fifth and third
>letters the same and all the rest different.
>My question is: given an array of all five letter words, and a given
>crypt word like "mlkqk", what is the best way to filter the array down
>to only those words that might match?
This is (probably):
----------------------------------------------------------------------
sub cryptogram ($) {
# Returns a regular expression which will match strings
# following the given pattern
my @pattern = map { lc } split //, shift;
my %seen = ( shift @pattern => 1 );
my ($result, $i, $j) = ("^(.)", 1);
foreach my $letter (@pattern) {
if ($j = $seen{$letter}) {
$result .= "\\$j";
} else {
$result .= "(?!" . join("|", map { "\\$_" } 1 .. $i) . ")(.)";
$seen{$letter} = ++$i;
}
}
$result .= '$';
}
# The pattern returned by cryptogram is anchored at the beginning and end,
# so you don't need to restrict the length of the test words beforehand.
open(DICT, "/usr/dict/words") || die "No words: $!\n";
chomp(@test = <DICT>);
close(DICT);
$regex = cryptogram "mlkqk";
@match = grep { /$regex/o } @test;
----------------------------------------------------------------------
This script produces the following words:
Adele, alibi, Amoco, basis, breve, buses, canon, chili, Clara, crepe,
Crete, Diana, drama, Durer, gases, Ghana, grata, grebe, Habib, Haiti,
Irene, Jesus, juror, koala, Kyoto, Lenin, linen, L'vov, Magog, molal,
Moses, motet, niece, oases, oasis, obese, octet, Omaha, Orono, Osaka,
oxeye, petit, photo, piece, playa, plaza, Scala, scene, siege, sieve,
Steve, Swede, tenon, theme, there, these, where, xenon
--
Sean McAfee | GS d->-- s+++: a26 C++ US+++$ P+++ L++ E- W+ N++ |
| K w--- O? M V-- PS+ PE Y+ PGP?>++ t+() 5++ X+ R+ | mcafee@
| tv+ b++ DI++ D+ G e++>++++ h- r y+>++** | umich.edu
------------------------------
Date: Fri, 11 Sep 1998 10:56:00 -0500
From: Andrew Johnson <ajohnson@gpu.srv.ualberta.ca>
To: Michael Christie <mikec@jump.net>
Subject: Re: Regular expression question
Message-Id: <35F94810.57D01317@gpu.srv.ualberta.ca>
[posted and mailed]
Michael Christie wrote:
>
> The method described below is fast, but when I tested it (and thanks,
> Jonathan, for the help) I discovered that it is incomplete. The problem
> is that the code returns "widow" for "aloha", which is correct, but it
> also returns (for example) "yummy", which is incorrect. "aloha" cannot
> encrypt "yummy", since the "o" and the "h" have to represent two different
> letters. This was the problem I ran into originally--I can match some
> patterns, but I can't see how to avoid matching on failures like this.
>
Here's one you can try out ... it builds a regex using backrefs
and negative look-aheads to create generalized pattern --- could
probably still use some tuning, but it does fail for those cases you
mention. (it also matches, in its present incarnation, the case of a
null-encrytion, ie, 'aloha' matches 'aloha').
enjoy:
#!/usr/bin/perl -w
use strict;
my @dict;
chomp(@dict=<DATA>);
sub match_crypto {
my @crypt = split //,shift;
my (%seen,@matches);
$seen{$crypt[0]}=1;
my $pattern = join('','(.)',
map{$seen{$crypt[$_]}
?"\\$seen{$crypt[$_]}"
:do{
my $p="(?!\\".join("|\\",values %seen).')(.)';
($seen{$crypt[$_]}=$_+1);
$p;
}
}1..$#crypt);
for (@dict){
next unless length($_)==@crypt;
push @matches,$_ if /^$pattern$/o;
}
return @matches;
}
my @test = match_crypto('aloha');
print join("\n",@test),"\n";
__DATA__
yummy
widow
abcde
abcda
aaaaa
abcba
abcca
acaca
aloha
regards
andrew
------------------------------
Date: 11 Sep 1998 17:37:58 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Search/Replace but Not under certain conditions. HOW?
Message-Id: <6tbn5m$5tt$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Larry Rosler
<lr@hpl.hp.com>],
who wrote in article <MPG.1062d1eab5ee1c4989848@nntp.hpl.hp.com>:
> $body =~ s!(http://[^\s@]+)(?=\s|$)!<a href="$1">$1</a>!g;
Negative lookahead is your friend:
http://[^\s@]+(?!\S)
And you do not *need* grouping - if $& slowdown is tolerable.
Ilya
------------------------------
Date: 11 Sep 1998 17:42:18 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: Search/Replace but Not under certain conditions. HOW?
Message-Id: <6tbndq$66g$1@mathserv.mps.ohio-state.edu>
I wrote in article <6tbn5m$5tt$1@mathserv.mps.ohio-state.edu>:
> Negative lookahead is your friend:
>
> http://[^\s@]+(?!\S)
Oups, one needs to backwack the @-sign:
http://[^\s\@]+(?!\S)
Ilya
------------------------------
Date: Fri, 11 Sep 1998 15:50:02 GMT
From: t-dog98@usa.net
Subject: Searching for a few CGI scripts
Message-Id: <6tbgra$qat$1@nnrp1.dejanews.com>
Hi,
I am looking for several scripts which I have seen many times on the web. I
was wondering if they are custom-made scripts or availible for download.
1. A search engine position analyzer. It searches the top search engines for
your URL with keywords which you specify, and return with your rankigs.
2. A link finder. It searches in several search engines for your URL and
returns with the webpages that have linked to you.
3. A Meta tag builder. <-- I bet this one is so simple people just make their
own.
4. A multiple URL submission script. It submits several URL all at once to
the top search engines.
I would greatly appreciate any help.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
------------------------------
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 3693
**************************************
