[13120] in Perl-Users-Digest
Perl-Users Digest, Issue: 530 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 14 17:17:20 1999
Date: Sat, 14 Aug 1999 14:10:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 14 Aug 1999 Volume: 9 Number: 530
Today's topics:
Re: Why use Perl when we've got Python?! <uri@sysarch.com>
writing an html file into another html file <nicholas@edesigninc.com>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 14 Aug 1999 16:09:48 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <x77lmy3z03.fsf@home.sysarch.com>
>>>>> "JS" == John Stevens <jstevens@bamboo.verinet.com> writes:
JS> On 14 Aug 1999 02:57:08 -0400, Uri Guttman <uri@sysarch.com> wrote:
>>>>>>> "JS" == John Stevens <jstevens@bamboo.verinet.com> writes:
JS> Thank you. I will. Perl cannot be used without manuals.
>>
>> neither can python.
JS> This statement has some validity, but is not entirely true. I can
JS> and do write Python without refering to manuals.
i don't refer to the perl docs on a line by line basis either. BFD. i
know perl. if i want to use a module i haven't used before, i read and
study the docs. that is expected in any large system.
JS> But it is true that you need to have the library reference close
JS> at hand to lookup interface definitions when using some of the
JS> less commonly used library modules.
JS> About 10% of the Python I write uses nothing more than standard
JS> python.
what is standard? perl's core without modules is much larger than
python's. i probably have never used %30 or more of perl's core
functions. i have never used format, rarely needed the getXbyname subs,
etc. but i know they are there if i want them. others use them day in
day out. so how much of a language you use is moot. we all choose the
subset we learn and need to use.
>> this book is not a manual, but a study in how to
>> write OO perl and do all the stuff other OO languages can and more. OO
>> perl can do stuff very few if any other languages can handle.
JS> Yes. As I said, it is powerful. Just confusing, due to its
JS> lack of common key words.
i get the problem you have. it is just you want text token
vs. punctuation tokens. this is a common issue in perl wars. i and many
others find verbose text tokens too hard to scan. this is the perceptual
area you have been hinting at. there is no correct answer for this. look
at the indent religious wars (in languages which allow customized
indenting :-). there is no right way. so tokens vs punctuation is the
same kind of war. you like lots of text, we like concise
expressions. BFD.
that does not make python a better language, just a wordier one. i think
pike's comments on fewer comments is crap too. so i like more comments
which is wordier but not in the code. doesn't make him or me right, just
different views on how we scan and mentally parse code. when i look at
python i see too many tokens which overwhelm my tiny brain. i see long
names for simple operations in perl. you see line noise in perl and
fully declarative named operations in python. neither is more
maintainable than the other. it depends onthe experience and skill of
the coder.
JS> Ada programmers are not allergic to seeing "package" or "module" and
JS> thinking "class", but most people have to take a second look.
??? so the word is different. if you can't translate one term to
another, than you shouldn't be in this business. i see the word class
used perl a lot. just check out some of the module titles in cpan.
JS> My primary complaint re: OO-Perl, is the lack of "expected"
JS> keywords and OO syntax.
>>
>> what is expected keywords?
JS> Almost every OO language uses the word: "class".
oh boy!!! a required keyword that should be required in all
languages. that is a winner.
perl packages are not classes so they shouldn't be named such. they are
namespaces. you can use a package to name a class but they are not the
same. neither is a perl module a class. it is a file of perl code that
can be loaded at compile time. it doesn't have to even have a package
statement in it. a perl class can span multiple files and multiple
classes can be in one file. so there is no need for the keyword class.
>> there are only a couple of things that make
>> perl oo: creating a reference, bless, @ISA for inheritance and the
>> direct method call $obj->method. can't get much simpler syntax that
>> that. don't need no steenkin keywords!
JS> It needs the keywords to communicate intent with the reader.
wrong. the class is defined by its use and not by a keyword. i can say
use FOO ;
and then
FOO::bar( blah ) ;
there is no need to name that a class. but it could be a class method or
just a plain old sub call. perl lets the designer decide and if you read
the docs, you know what it is.
JS> Note: I teach OO programming courses. In the past, I've used
JS> Perl as one of the languages I use to teach OO. After exposing
JS> the class to Python,
JS> I give them an hour to create their first Python class.
JS> They almost all, always, get the assignment done in less than an
JS> hour.
JS> After showing them the Perl way, I let them have a full day.
JS> And, on the average, 1 in 4 cannot finish the assignment
JS> at all.
JS> It is more difficult to learn to do OO in Perl.
have they even learned perl at that point? i wouldn't teach OO perl to
perl newbies. it is not needed for classroom type examples.
and the fact that a language is easier for newbies does not make it
useful. teach vb and you will have lots of tiny crappy little programs
in minutes. wanna unleash those kiddie onto the world. i am glad in some
ways that perl is both easy and hard to learn. it makes easy things easy
and impossible things doable.
>> i have written dozens of programs both OO and not in many
>> languages including assembler. OO is an attitude abotu organizing you
>> data and code.
JS> No. It is not just that. Have you ever had any formal OO training?
i said, i learned it from prof liskov at mit. she is one of the pioneers
of this stuff.
>> it is not a stricture requiring you do use keywords and
>> crap like that.
JS> Keywords are crap?
if they are redundant and not needed.
JS> There is an OO term: polymorphism. It means: the same things
JS> should be said in the same way. An example of polymorphism
JS> is the use of the + keyword to indicate both integer and
JS> floating point addition.
JS> Among other things, good OO design uses appropriate polymorphism.
read OO perl as soon as you can get a copy. perl has polymorphism in
spades. probably better than almost any other language since it is so
dynamic. i wish damian would get in here to show you.
JS> OO describes a system for designing, analyzing, implementing and
JS> maintaining systems, it does not describe languages. Learning an
JS> OO language, does not teach you OO.
so why are you claiming python is so great given that it forces OO on
the coder? and as i have repeatedly, the methodology does not stop
stupid people from designing dumb objects. so it fails on that critical
point. smart people will succeed in any system.
>> so the critical data and queues were
>> hidden from the rest of the code like OO says to do.
JS> Encapsulation is not the sum total of OO. In fact, if all you do
JS> is encapsulation, you are not doing OO. The bare minimum requirement
JS> for OO is encapsulation, inheritance, messaging and support for
JS> subclass responsibility.
bullhockey. you can use any subset you wish. there is no way to
encapsulate the requirements for any system. i can shoose what i need
from what is available. if i want just data encapsulation, i can us perl
closures with no OO. if i want inheritance, i don't have to use
encapsulation, the classes can share the data if they agree to it. you
have too much academic purity in your blood. the real world is more
pragmatic.
JS> Yet the question remains unanswered: what do you use to decide
JS> that OO is waranted, or not waranted.
>> it would be a waste of code and structure
>> for a single standalone program to use OO like that.
JS> Why?
because it was one program file with one purpose that was not even going
to be shared. it had a bunch of well named and not reused global
variables and a mess of subs and it was well documented, ran
beautifully, easily modified and improved, simple to debug, etc. all
because i designed it that way. a good design is a good design in any
methodology.
>> onthe other hand i
>> wrote a simple perl module (only 4 data members) with many methods since
>> it was going to be used by a bunch of small utilities. OO was warranted
>> there as it made the design easier and speed was not an issue.
JS> Ok, so I guess you are saying that OO is unwaranted when speed is
JS> an issue. By that, I am also assuming you are implying that the
JS> speed hit incurred by OO is unacceptably large.
depends on the needs of the project. in this case it didn't matter. in a
large high speed system i might not choose oo because of the speed
hit. that is what warranted is all about. *I* choose the design based on
many factors, not the language.
>> i chose the time and place for oo since i know how to do both. forcing
>> it on newbies is a crime as they will have a hard time going without
>> it.
JS> Excuse? Why would teaching OO to newbies be a crime?
because they will flounder when they have to do non-oo work. they will
not be able to change their thought patterns if they are indoctrinated
with "the one true OO way". can any of them write an rtos in asembler?
will their OO brains be able to grok writing a device driver?
JS> An OO trained programmer will not ask questions like:
JS> "What is a global?". They'll ask: why are you using such a poor design?
globals have their place. youjust have to knwo how to use them
correctly. i wouldn't encourage newbies to use them (look at fortran)
but when a skilled pro uses them, they can be fine. read the tao of
programming.
JS> Again, OO is a paradigm, not a language. You can do
JS> OO in ANSI C.
and in assembler.
JS> It lowers the bar, allowing less talented programmers to design,
JS> write and maintain more complex systems.
>>
>> let's see. cpan is full of modules, many of which use OO perl. it is
>> massive, shared and growing rapdily.
JS> Now, if OO is not an improvement. . . then why introduce OO into
JS> Perl?
it has its uses. that is known. it is not the answer to every design
problem so it is not a direct improvement. you can use it or not is my point.
>> if it is so much more
>> shareable and manageable than why hasn't it developed such a world class
>> library?
JS> What particular part of Python's library is *not* world class?
its size and depth and breadth.
JS> And TC says that Perl encourages stupid people to use it . . .
JS> So, which do you suppose is the truth?
because it is so easy to do simple things in perl and because of its
association wuth cgi. those 2 reasons get more stupid people using perl
than any other language. it is our curse. i wish them all on python.
JS> Perhaps Perl simply attracts people who believe that learning
JS> something that is arbitrarily made difficult than it needs to be
JS> somehow proves that they are more intelligent than the average.
JS> Or maybe it traps users, because after they've spent so much time
JS> becoming competent, they are loathe to waste that time and
JS> fall into the trap of throwing good money after bad.
you are blathering here. no one throws money at perl. i have worked in
many languages which helps my work in perl. i have no problem learning
new things when needed. my perl knowledge would help me in other
areas. nothing is wasted as it all supports my skill set. i won't work
in assembler ever again, but do i regret doing it for several years? no,
it helps me understand what a coputer can really do and it trained me to
be very careful in my coding.
JS> Or maybe it is simpler than that: maybe people are attracted
JS> to Perl because they are more comfortable being part of a
JS> large group, instead of a small group.
??? perl as a social force? you are daft, sir.
>> as for a comparison of the market size, just search for perl vs. python
>> on any jobs site and compare the numbers.
JS> Actually, I hadn't mentioned market size at all.
it is a factor. just look at the job web sites and newsgroups.
>> it is not because perl is
>> a better language or whatever, it is because perl gets the job
>> done.
JS> Your logic is flawed. You have yet to show that Perl's
JS> characteristics have anything at all to do with the number
JS> of people that use it.
most people who use perl professionally (no kiddies involved) have heard
of and seen python, java, etc. they stick with perl because they like to
work in it. look at the size of the perl conferences (and monterey next
week will have 3 perl tracks to one for python). those are not kiddies
going there, but seasoned professionals voting for a language with their
money and time. i bet %99 of the attendees there will know abotu
python. it is not just a critical mass thing. python has been around
almost as long as perl has with a much smaller growth rate. if it were
so great most of the perl hackers would have migrated to it by now. i
love seeing those posts from former perl hackers like you who migrate to
python. it is a trickle down effect and you know how well that worked
for reagan. many time more leanr perl and stay with it than shift over
even when they knwo they could.
JS> An equally good case could be made, from the existing data, that
JS> Perl is so difficult to learn and use, that programmers use it
JS> to protect their jobs.
again with the "i can't do perl well so no one else can"
JS> The point was re: the speed at which systems complexity
JS> has increased in relationship to the speed at which systems
JS> designed to control complexity have been developed.
that is true across the board of software development. documentation is
always lagging the code too. perl has pod which make that easier to
manage and maintain. you can gofrompod to any common format so that make
it more accesible too.
JS> And PL/1 did not support sub-class responsibility (feel free to correct
JS> me if I'm wrong).
JS> Therefore PL/1 did not have language support for OO.
so neeither does c (which you claimed you can do OO in). you can't have
it both ways. either oo needs language support or it is language
independent.
>> so having a language which forces OO is not the
>> answer.
JS> One could make the same argument re: procedural programming.
??? as opposed to prolog? almost all programming languages but a few
(pure oo ones and prolog, etc) support procedural programming. would you
want to work in assembler for the rest of your career? have you ever
worked in assembler or done low level I/O coding?
JS> But, for production use, it is preferable to use a language
JS> that has support for doing OO programming in it.
then why is c so popular?
>> since c has no OO features, teaching and
>> using it in c (as i have on many designs) is more educational than in oo
>> languages.
JS> Yes, it can be quite educational. Especially when you go back and
JS> tell your students: "Now, add in sub-class responsibilty." ;->
who cares. write a subclass to poke bits in an i/o register.
JS> True. But that does not extend to: "Therefore, all tools are
JS> equally good at all jobs".
i never said that.
>> a master craftsman can do wonders with the simplest of tools
>> while an idiot couldn't make a good toothpick with a numerically
>> controlled milling machine.
JS> Correct. But a Master Craftsman will use the right tool for the
JS> right job, rather than forcing a screw driver to act as a chisel.
again, i never said that. given the same set of tools the master will
win out. even with better tools for the dummy, the master will win. so
it is not the tools, but the skill of the master which is important.
>> readibility of code depends on the skill of the coder much more than
>> the language.
JS> No, it does not.
you can write fortran in any language. you cannot force idiots to write
good code by any known methodology. they will out-stupid you each time.
JS> Readability has more to do with designing the language to be
JS> intuitive, than skill of the programmer.
intuitive to whom? to you? or to me? or to them? you don't get what
intuitive means. it is a subjective term as are all coding skills. write
python with one letter variable names. is that intuitive?
JS> The best Perl programmer in the world cannot make Perl readable
JS> to a non-programmer. But well written Cobol can be read even
JS> by people that have never programmed.
than why was cobol such a failure for its intended task, to make it easy
for NON-programmers to use it. they just created a set of job classes
where the designer wrote specs, a coder enter code onto coding sheets
and typists entered the code onto punchcards. did the business guy ever
see or modify the code? no.
>> oo does not make that any easier or harder.
JS> It makes it easier.
JS> Which is easier? Analyzing a program of 10,000 lines, or one
JS> that is 100 lines?
what does that have to do with OO? the unix kernel is a very large
system. i make massive use of it with the shell command 'ls'. is that
OO? no, just a use of a shared resource. i go to a web page and enter a
search query. i make a massive engine do my bidding with aclick of the
mouse. is that OO? what you see is not what is behind the curtain in any
large and shared system.
>> lisp is the simplest language in the
>> world. pure prefix calls. nothing else. guaranteed simple parsers. lisp
>> in lisp in a page of code. it still sux for real world projects (other
>> than for dyed in the wool lispers who are a dying breed). but do you
>> think in parens? do you want to memorize the hundreds of twisty little
>> calls all looking like each other?
JS> Exactly. Perl is the procedural programming equivalent of Lisp.
??? you don't need to know nearly the amount of lisp to function
minimally as you would in perl. perl's hello world is almost the
shortest in any known language.
JS> No, it isn't. You can do procedural programming in Python.
with your array and dictionary objects? doesn't sound procedural to me.
JS> You haven't learned OO yet. Nor have you learned how to control
JS> defect rates. That one statement pretty much explains to me why
JS> Perl coders (if they think like you do) generate more defects, and
JS> why they are so hard to find.
i don't generate many defects and i find them quickly. debugging (and
writing bug free code) is a skill like any other. some are better than
others. i have done debugging it in many languages and it is the same in
each. i just get more work done in less time with perl.
>> just speedier shortcuts for common splice operations. perl's intrinsic
>> array allows multiple well defined operations which can be used to
>> emulate a variety of complex data structures.
JS> Using an array as a stack is an inherent source of defects, and
JS> reduces the maintainability of the program. The interface to
JS> a stack is not the same as an interface to an array, so when
JS> a maintainer inadvertently uses an array operation on a stack:
JS> BOOM! Defect.
no. when i use it as a pure stack, i give it an appropriate
name. BOOM. instant documentation and no defect. if you break the usage
based on the name, it is your burden to bear. having to do tons of
infrastructure coding to enforce those rules is overkill. if the object
were of more complexity and needed more sharing, then an object mught be
warranted. i choose my objects, they don't choose me.
JS> If it's a stack, it should only allow stack operations (push, pop).
so you write a closure to do that and no need for OO for something so
simple.
JS> IOW, the word "push" should not have been used to define this
JS> operation.
it pushes a list of values onto the end of an array. sounds good to me.
JS> Drastically reducing both the readability and maintainability
JS> of the code.
it is a verbose token like you like. append is just longer. and append
makes no sense for a dictionary or hash since there is no ordering there
and append implies order.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: Sat, 14 Aug 1999 15:02:20 -0400
From: "JT Nicholas Tolson" <nicholas@edesigninc.com>
Subject: writing an html file into another html file
Message-Id: <7p4egn$3ms$1@nntp3.atl.mindspring.net>
I've tried to do this with javascript and server-side includes, but because
of the order in which things are processed, this didn't work. Here's my
situation.
What I have is many HTML templates for news articles, and then many html
article files. What I want to do is put in a certain article file into a
certain template on the fly. This way, I just create one template file for
each section, and one article file, then place this article file into
whatever template I need to.
Then, if I want to put the same article in a different template, I don't
have to create another page, I just slap the same article file into a
different template file.
To give you an idea of what I was trying to do, here's the javascript I was
using (disregard any possible syntax errors in this):
function writeSSI() {
searchstr = location.search.substring(1)
include = ('<!--#include virtual=\"/' + searchstr + '.html\"-->')
document.write(include)
}
Then I call this function wherever I want the article to appear, but for the
reason I mentioned earlier, this doesn't work.
Any suggestions? BTW, excuse any ignorance of cgi/perl here, since I am
below novice level.
Thanks in advance.
jtnt
nicholas@edesigninc.com
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
Message-Id: <null>
Administrivia:
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" from
almanac@ruby.oce.orst.edu. The real FAQ, as it appeared last in the
newsgroup, can be retrieved with the request "send perl-users FAQ" from
almanac@ruby.oce.orst.edu. 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" from
almanac@ruby.oce.orst.edu.
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 V9 Issue 530
*************************************
