[30185] in Perl-Users-Digest
Perl-Users Digest, Issue: 1428 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Apr 7 03:14:13 2008
Date: Mon, 7 Apr 2008 00:14:06 -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 Mon, 7 Apr 2008 Volume: 11 Number: 1428
Today's topics:
Re: perl should be improved and perl6 <jm@nospam.fr>
Re: perl should be improved and perl6 <get@bentsys.com>
Re: perl should be improved and perl6 <get@bentsys.com>
Re: perl should be improved and perl6 <get@bentsys.com>
Re: perl should be improved and perl6 <uri@stemsystems.com>
Re: perl should be improved and perl6 <tadmc@seesig.invalid>
Re: perl should be improved and perl6 <tadmc@seesig.invalid>
Re: perl should be improved and perl6 <uri@stemsystems.com>
Re: perl should be improved and perl6 <uri@stemsystems.com>
Re: perl should be improved and perl6 <devnull4711@web.de>
Re: perl should be improved and perl6 <get@bentsys.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 07 Apr 2008 00:26:21 +0200
From: jm <jm@nospam.fr>
Subject: Re: perl should be improved and perl6
Message-Id: <47f94e0d$0$21144$7a628cd7@news.club-internet.fr>
Uri Guttman a écrit :
>>>>>> "j" == jm <jm@nospam.fr> writes:
>
> j> perl provides good things and bad ones.
> j> In the good thing, such as:
> j> * it is adapted for text processing
> j> * it is poorly typed
>
> me thinks you don't understand typing well. perl actually has stronger
> typing than many langs. it just types on the variable type (scalar vs
> array vs hash) instead of the data type.
When passing a parameter to a function, in Perl, I do not know any way
to say that the type of the parameter is a hash table which associate
strings to integer, for example.
When in a language such as java (or Java) you can say it is a
HashMap<String, Integer>
In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
and; optionals.
For the rest, I believe type is not checked at function call, but at
data use.
> j> * it is enough powerful with unicode
> j> * provide arrays and hash and reference (and objects)
> j> * transparently manage any kind of numbers.
> j> * is C interfacable
> j> * has basic network and IPC possibilities
>
> basic??? cpan has modules for almost every protocol out there and IPC
> support is all done too. you don't know perl well if you say this is basic.
I used basic to mean low level.
It is clear than when you have enough good low-level functions, you can
use them to provide higher level functions (such as those protocols)
> j> * pack/unpack
>
> that is a major part of perl? it is used but not that often by most
> coders.
It is one practical way to access binary data.
And binary is not so uncommon.
> j> In the bad things, such as:
> j> * bytes/unicode confusion
> j> * stack overflow within bad regular expression
>
> huh?? then don't write bad regexes. most likely if it blows up in perl
> it will do worse in other langs.
I have yet read that Perl regexs are best than every other ones.
What I mean here is there is no way (I know) to check a coder did not
write bad regexes.
When Perl 5 encourages use of regexs,
But I need to read some Perl 6 rules documentation.
> j> * memory consumption (might be an issue when energy will be more expensive?)
> what?? you are smoking very strange stuff. ram is cheap and always
> getting cheaper. cpu speed is the power hog.
According to some web sites (1),
1 Gbytes memory might "smoke" 60 watts, when
Pentium 4 3.2 Ghz version E might "smoke" 75 watts.
But I do not know if those figures are good.
Also, I read that in developed countries, data center energy consumption
is greater than 1% of (electrical?) energy. When energy is not less
and less expensive (2).
I do not know this subject, so you might be right, waste of energy might
be not related to memory.
> j> * insufficient typing
>
> again, you don't know what you are talking about.
I explained the way I consider this upper.
> j> * some portability issue, notably with function «system».
>
> proof of the last comment. system is the way to call external
> programs. how could that POSSIBLY BE PORTABLE if the external programs
> vary from box to box?
I assume that what you call the external program is the shell.
In my opinion, call to external programs should be done based on one of
the two following ideas:
idea 1/ A function which provides pipes for stdin, stdout, stderr and
(if possible) portable access to exit values.
idea 2/ Some minishell embedded within Perl, in order to interpret pipes
and redirections from to files.
I prefer idea 1 to idea 2.
> j> * some $@% issues.
>
> no, you have some issues.
Yes this is the point.
In Perl 5, some coders might be confused by sigils ($@%).
It seams I have read they will be modified in Perl 6 to improve this issue.
> j> * pack limitation: cannot just modify one byte.
>
> huh??? pack doesn't modify anything. pack converts a list of values to a
> single buffer string. and the C format can pack a single byte.
Yes, thats what pack/unpack does.
In C, some coders access binary data with struct/union.
I do not like this because it is not portable.
I do not like the way Java access binary data, because bytes are signed.
At first, the pack/unpack looks pleasant to me, an elegant way, based on
a format string to separate low level bytes from upper level data.
But one day, I just wanted to modify just one single byte.
> j> perl6 looks like a cleanup of perl, but I am wondering:
>
> j> how will memory be handled in perl6?
>
> just find with true gc.
Does this mean an effort will be done to reduce memory consumption?
> j> how will bytes be handled in perl6?
>
> with stone tablets.
What a pity. This mean it will be not improved.
> j> why perl6 encourages complex regex (as x become standard)?
>
> wtf are you babbling about? perl6 has grammars and rules which blow away
> all current regex engines. you need to read up on them. in fact you can
> use a bunch of it in perl5 now with cpan modules.
I did not yet understand how works rules in Perl 6.
Might be it gives a way to simplify the following expression from perlfaq6:
s{
/\* ## Start of /* ... */ comment
[^*]*\*+ ## Non-* followed by 1-or-more *’s
(
[^/*][^*]*\*+
)* ## 0-or-more things which don’t start with /
## but do end with ’*’
/ ## End of /* ... */ comment
| ## OR various things which aren’t comments:
(
" ## Start of " ... " string
(
\\. ## Escaped char
| ## OR
[^"\\] ## Non "\
)*
" ## End of " ... " string
| ## OR
’ ## Start of ’ ... ’ string
(
\\. ## Escaped char
| ## OR
[^’\\] ## Non ’\
)*
’ ## End of ’ ... ’ string
| ## OR
. ## Anything other char
[^/"’\\]* ## Chars which doesn’t start a comment,
string or escape
)
}{defined $2 ? $2 : ""}gxse;
> j> how will perl6 address portability issues?
>
> what issues?
There was so much portability issues in Perl 5 than the first question
is probably bad.
> j> how will perl6 address IPC issues?
>
> again, what issues? there are no IPC issues, other than your
> delusions. perl has fine IPC.
A function which provides pipes for stdin, stdout, stderr and (if
possible) portable access to exit values.
When I tried to do IPC, what I was missing was a function similar to
system, but which
allow managing every pipes (stdin, stdout, stderr) and any kind of
return vale (exit code, signal).
I did not find this in perlfunc.
> uri
1/
http://www.ginjfo.com/Publics/Actualites/Act1-84-Evaluation-de-la-consommation-electrique-d-un-PC.html
2/
«dans les pays développés, la consommation énergétique des data centers
dépasse largement 1% de la consommation globale.
Or, la tendance n'est pas franchement à la baisse du coût de l'énergie.»
http://www.guideinformatique.com/fiche-consommation_electrique_des_data_centers-846.htm
------------------------------
Date: Sun, 6 Apr 2008 15:34:20 -0700
From: "Gordon Etly" <get@bentsys.com>
Subject: Re: perl should be improved and perl6
Message-Id: <65t1feF2h92v9U1@mid.individual.net>
Andrew DeFaria wrote:
> Gordon Etly wrote:
>> John Bokma wrote:
>>> Andrew DeFaria <Andrew@DeFaria.com> wrote:
>>>
>>>> Attachment decoded: text-html-3
>>> Oops, you just lost any credebility :-D
>> While on UseNet you generally do not post HTML,
> No, when on Usenet *you* generally do not post HTML. I do.
>
>> since you have pointed out there is plain-text version,
> Did I? Or did you mean John?
I think you misunderstood me. I was just pointing out that your posts
are multipart messages (a section for "Content-Type: text/plain;" and
another for "Content-Type: text/html;") and that people who wish to read
only in plain-text should be seeing just the plain-text section, if the
reader works in such a sensible way. Those who do not mind html will
likely view that part. This was all I meant. And this is why I don't
feel it should be a much of a problem as some people make it out to be.
What part one sees by default should be as par one's preferences.
--
G.Etly
------------------------------
Date: Sun, 6 Apr 2008 16:52:18 -0700
From: "Gordon Etly" <get@bentsys.com>
Subject: Re: perl should be improved and perl6
Message-Id: <65t61kF2hamqlU1@mid.individual.net>
David Formosa (aka ? the Platypus) wrote:
> On Sun, 6 Apr 2008 09:25:02 -0700, Gordon Etly <get@bentsys.com>
> wrote:
>> David Formosa (aka ? the Platypus) wrote:
>
> [...]
>
>>> Because reading the FAQ, paying attention to detail and
>>> understanding what people tell them are aspects of knowing how to
>>> program in Perl.
>>
>> No, you can judge someone purely on grounds like that.
>
> And we don't. We also judge people on how they respond to being
> corrected.
Well, given 'perldoc perl'/'man perl', stating near the top,
"perl - Practical Extraction and Report Language",
it is perfectly valid to use "perl" or "PERL", as that abbreviates the
above.
So the attempting to "correct" someone for using "perl" or "PERL"
contradicts Perl's own documentation. The "regulars" are always saying
to read perldoc, amongst other things, yet conveniently forget about the
main document.
Since it's in Perl's own docs, using the acronym of, or in full,
"Practical Extraction and Report Language" is fair game.
> [...]
>
>>> You will find that people don't care about the spelling of random
>>> words, its only when people start talking about Perl specific words
>>> does it start to mattor.
>>
>> Yes, but "PERL" and "Practical Extraction and Report Language" come
>> fro mthe man/perldoc page for "perl", how can one get more official
>> then something's own man page?
>
> The all cap sequence is a side effect of man.
>
>> Are you saying the FAQ for this group, a user
>> contributed document, as valvuable as it may be, carries more weight
>> then Perl's own man page?
>
> man perlfaq
>
> They carry the same waight as perl's own man page because perl's man
> page incorperates the FAQ for this group.
That may be, but how does that change the fact that the main document,
'perdoc perl'/'man perl', completely contradicts those attempting to
impose such corrections on people who use "perl" or "PERL"?
--
G.Etly
------------------------------
Date: Sun, 6 Apr 2008 17:00:01 -0700
From: "Gordon Etly" <get@bentsys.com>
Subject: Re: perl should be improved and perl6
Message-Id: <65t6g3F2huv6jU1@mid.individual.net>
Frank Seitz wrote:
> Gordon Etly wrote:
>>
>> There you go again, completely ignoring what 'man perl' and 'perldoc
>> perl' say:
>>
>> I would think a good programmer would also have read Perl's own
>> documentation, which validates the usage of Perl as an acronym:
>>
>> $ perldoc perl | head -n 10
>> PERL(1) User Contributed Perl Documentation PERL(1)
>>
>>
>> NAME
>> perl - Practical Extraction and Report Language
>> ^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Even http://perldoc.perl.org/perl.html says:
>> "perl - Practical Extraction and Report Language"
>
> Another (better?) citation: http://tinyurl.com/o6ll4
Perhaps.
"Randal Schwartz capitalised the language's name to
make it stand out better when typeset. This convention
was adopted by the community"
Ok.
"You may or may not choose to follow this usage"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alright.
"But never write "PERL", because perl is not an acronym,
apocryphal folklore and post-facto expansions
notwithstanding."
This last quote is contradicted by the main Perl document, that gives
the "NAME" of the language as:
"perl - Practical Extraction and Report Language"
Which IS an acronym. Or at the very least allows one to write "perl" or
"PERL" to abbreviate that. Again, you just cannot ignore the main
document.
--
G.Etly
------------------------------
Date: Mon, 07 Apr 2008 01:23:55 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: perl should be improved and perl6
Message-Id: <x7fxtyfoes.fsf@mail.sysarch.com>
>>>>> "j" == jm <jm@nospam.fr> writes:
j> Uri Guttman a écrit :
>>>>>>> "j" == jm <jm@nospam.fr> writes:
>>
j> perl provides good things and bad ones.
j> In the good thing, such as:
j> * it is adapted for text processing
j> * it is poorly typed
>>
>> me thinks you don't understand typing well. perl actually has stronger
>> typing than many langs. it just types on the variable type (scalar vs
>> array vs hash) instead of the data type.
j> When passing a parameter to a function, in Perl, I do not know any way
j> to say that the type of the parameter is a hash table which associate
j> strings to integer, for example.
why do you need such a beast? you name the variable according to its
use. if you use it incorrectly, that then is your fault. that sort of
typing is anal to an extreme. what if there is no class type for the
hash you want? what if different members of the hash have different
value types (as in a structure)? you can't prename hash types for all
possible types so why even bother?
j> When in a language such as java (or Java) you can say it is a
j> HashMap<String, Integer>
useless information as it should be in the variable name.
j> In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
j> and; optionals.
those are prototypes and you have it wrong. besides, prototypes in perl
are not a good thing and no experienced hacker uses them.
j> For the rest, I believe type is not checked at function call, but at
j> data use.
correct. and that is stronger than compile time checking as you can fake
out compile time with all sorts of tricks in most langs.
j> * it is enough powerful with unicode
j> * provide arrays and hash and reference (and objects)
j> * transparently manage any kind of numbers.
j> * is C interfacable
j> * has basic network and IPC possibilities
>>
>> basic??? cpan has modules for almost every protocol out there and IPC
>> support is all done too. you don't know perl well if you say this is basic.
j> I used basic to mean low level.
and what high level IPC do you mean and what is missing? you don't know
IPC if you claim that about perl.
j> It is clear than when you have enough good low-level functions, you can
j> use them to provide higher level functions (such as those protocols)
j> * pack/unpack
>>
>> that is a major part of perl? it is used but not that often by most
>> coders.
j> It is one practical way to access binary data.
j> And binary is not so uncommon.
it isn't used in most perl programs. as someone who is a professional
perl code reviewer i don't see pack nor binary used in perl nearly as
much as text. that isn't to say pack/binary aren't important but it
isn't a major part of perl as such. and even for many binary things,
there are modules that handle it for you. cpan is your friend.
j> In the bad things, such as:
j> * bytes/unicode confusion
j> * stack overflow within bad regular expression
>>
>> huh?? then don't write bad regexes. most likely if it blows up in perl
>> it will do worse in other langs.
j> I have yet read that Perl regexs are best than every other ones.
huh? ever heard the expression 'perl compatible regular expressions'?
every other language claims that (check out 'pcre' and you will
see). they all want to have perl's regexes. and none of them really do.
j> * memory consumption (might be an issue when energy will be more expensive?)
>> what?? you are smoking very strange stuff. ram is cheap and always
>> getting cheaper. cpu speed is the power hog.
j> According to some web sites (1),
j> 1 Gbytes memory might "smoke" 60 watts, when
j> Pentium 4 3.2 Ghz version E might "smoke" 75 watts.
this makes no sense. the whole motherboard 'smokes' even more. disk
drives smoke the most. where did you learn how to smoke?
j> I do not know this subject, so you might be right, waste of energy might
j> be not related to memory.
that is ram in the cpu, not ram used in the program. they are different
beasts.
j> * some portability issue, notably with function «system».
>>
>> proof of the last comment. system is the way to call external
>> programs. how could that POSSIBLY BE PORTABLE if the external programs
>> vary from box to box?
j> I assume that what you call the external program is the shell.
no, you can call directly to any external program bypassing the
shell. learn more about qx, system and exec from the docs.
j> In my opinion, call to external programs should be done based on one of
j> the two following ideas:
j> idea 1/ A function which provides pipes for stdin, stdout, stderr and
j> (if possible) portable access to exit values.
and perl has those in IPC::Run and many other modules. hmm, IPC modules!
j> idea 2/ Some minishell embedded within Perl, in order to interpret pipes
j> and redirections from to files.
huh??? perl doesn't need pipes internally as you don't have processes
inside perl. you need to learn more about this.
j> * some $@% issues.
>>
>> no, you have some issues.
j> Yes this is the point.
j> In Perl 5, some coders might be confused by sigils ($@%).
maybe you but most seem to learn it just fine.
j> * pack limitation: cannot just modify one byte.
>>
>> huh??? pack doesn't modify anything. pack converts a list of values to a
>> single buffer string. and the C format can pack a single byte.
j> Yes, thats what pack/unpack does.
but your statement about modifying one byte made no sense. i sense a
pattern here.
j> In C, some coders access binary data with struct/union.
j> I do not like this because it is not portable.
huh?? you can make c structs portable. the issues are more with
endianess.
j> At first, the pack/unpack looks pleasant to me, an elegant way, based on
j> a format string to separate low level bytes from upper level data.
j> But one day, I just wanted to modify just one single byte.
and you couldn't? why? show your code.
j> perl6 looks like a cleanup of perl, but I am wondering:
>>
j> how will memory be handled in perl6?
>>
>> just find with true gc.
j> Does this mean an effort will be done to reduce memory consumption?
that doesn't compute. ram usage and gc are not related.
j> how will bytes be handled in perl6?
>>
>> with stone tablets.
j> What a pity. This mean it will be not improved.
perl6 has very sharp chisels!
j> why perl6 encourages complex regex (as x become standard)?
>>
>> wtf are you babbling about? perl6 has grammars and rules which blow away
>> all current regex engines. you need to read up on them. in fact you can
>> use a bunch of it in perl5 now with cpan modules.
j> I did not yet understand how works rules in Perl 6.
so don't denigrate them. you seem to have a habit of bitching about
stuff which you don't understand well.
j> Might be it gives a way to simplify the following expression from perlfaq6:
sure it does. but i won't translate it. this regex is an example just to
show how something CAN be done. and it is a very tricky problem
involving c style comments and strings. perl6 rules will be able to
parse nested complex stuff in a very high level way with libraries
(called grammars) of reusable rules.
j> how will perl6 address IPC issues?
>>
>> again, what issues? there are no IPC issues, other than your
>> delusions. perl has fine IPC.
j> A function which provides pipes for stdin, stdout, stderr and (if
j> possible) portable access to exit values.
you don't understand IPC at all it seems. perl5 has full access (both
high and low level) to all IPC features. you just don't see them.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Sun, 6 Apr 2008 21:28:09 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: perl should be improved and perl6
Message-Id: <slrnfvj1lp.vp8.tadmc@tadmc30.sbcglobal.net>
Gordon Etly <get@bentsys.com> wrote:
> John Bokma wrote:
>> Andrew DeFaria <Andrew@DeFaria.com> wrote:
>>
>>> Attachment decoded: text-html-3
>>
>> Oops, you just lost any credebility :-D
>
> While on UseNet you generally do not post HTML, since you have pointed
> out there is plain-text version, should not a sensible news reader use
> only that part if all you want is plain-text, just as any sensible mail
> reader does? This is how mine behaves. Surely what ever reader you have
> could do the same?
>
> With that said, it would be nice to keep everything in plain-text only,
> though in this day and age, I don't think it should be so surprising to
> see messages in multiple formats?
I find HTML attachments on Usenet postings to be useful to me.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Sun, 6 Apr 2008 21:26:35 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: perl should be improved and perl6
Message-Id: <slrnfvj1ir.vp8.tadmc@tadmc30.sbcglobal.net>
David Formosa (aka ? the Platypus) <dformosa@usyd.edu.au> wrote:
> On Sun, 6 Apr 2008 09:25:02 -0700, Gordon Etly <get@bentsys.com> wrote:
>> Are you saying the FAQ for this group, a user
>> contributed document, as valvuable as it may be, carries more weight
>> then Perl's own man page?
>
> man perlfaq
>
> They carry the same waight as perl's own man page because perl's man
> page incorperates the FAQ for this group.
There is no FAQ for this newsgroup.
There is a FAQ for Perl, that ships with perl (but not with PERL).
So there is a FAQ for the topic of this newsgroup rather than
a FAQ for this newsgroup.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 07 Apr 2008 04:12:47 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: perl should be improved and perl6
Message-Id: <x7hceecngg.fsf@mail.sysarch.com>
>>>>> "AD" == Andrew DeFaria <Andrew@DeFaria.com> writes:
AD> Uri Guttman wrote:
j> When passing a parameter to a function, in Perl, I do not know any way
j> to say that the type of the parameter is a hash table which associate
j> strings to integer, for example.
AD> why do you need such a beast? you name the variable according
AD> to its use. if you use it incorrectly, that then is your
AD> fault.
AD> Ah... to cut down the the number of "well it's your fault" type
AD> errors. Humans make mistakes (like the constant mistake you keep
AD> making by not properly capitalizing letters).
mistake? i lost my caps lock key!! it is now control which is where it
should be.
j> When in a language such as java (or Java) you can say it is a
j> HashMap<String, Integer>
AD> useless information as it should be in the variable name.
AD> Just because you can't understand it does not mean it's useless.
huh?? i understand more code before 6am than you do in a year!
j> In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
j> and; optionals.
AD> those are prototypes and you have it wrong. besides,
AD> prototypes in perl are not a good thing and no experienced
AD> hacker uses them.
AD> Yes, script kiddies don't. Experienced professional programmers on
AD> the other hand...
huh? show me one serious perl hacker that uses and likes prototypes?
they have about one useful purpose (can you name it?). otherwise even
larry wall says they were a mistake. they aren't even prototypes as
other langs use the term.
j> For the rest, I believe type is not checked at function call, but at
j> data use.
AD> correct. and that is stronger than compile time checking as you can fake
AD> out compile time with all sorts of tricks in most langs.
AD> Yes so let's all rely on the weakest form of enforcement -
AD> convention of the names of variables...
you seem to be contrarian with no actual defense of your position. oh
well, off with your head!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 07 Apr 2008 04:44:39 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: perl should be improved and perl6
Message-Id: <x71w5iclzd.fsf@mail.sysarch.com>
>>>>> "AD" == Andrew DeFaria <Andrew@DeFaria.com> writes:
AD> Uri Guttman wrote:
AD> Ah... to cut down the the number of "well it's your fault" type
AD> errors. Humans make mistakes (like the constant mistake you keep
AD> making by not properly capitalizing letters).
AD> mistake? i lost my caps lock key!! it is now control which is where it
AD> should be.
AD> I'll personally donate a new caps lock key if you promise to use it! Deal?
AD> Oh and BTW all you need is a fucking shift key. You're a punk -
AD> admit it! A rebel for no good cause nor clue...
oh, i now see what i am. i owe you a great debt!! see if you can cash it
in.
j> When in a language such as java (or Java) you can say it is a
j> HashMap<String, Integer>
AD> useless information as it should be in the variable name.
AD> Just because you can't understand it does not mean it's useless.
AD> huh?? i understand more code before 6am than you do in a year!
AD> You keep believing that bro as you apparently need it to have
AD> some semblance of
AD> self esteem. Personally at 6 AM I'm sleeping...
nah, you just need to know when you were punked. (see i must be a punk!)
j> In Perl, I know a $ parameter is a scalar, a %, a hash, a @, a table,
j> and; optionals.
AD> those are prototypes and you have it wrong. besides,
AD> prototypes in perl are not a good thing and no experienced
AD> hacker uses them.
AD> Yes, script kiddies don't. Experienced professional programmers on
AD> the other hand...
AD> huh? show me one serious perl hacker that uses and likes prototypes?
AD> Hackers? You mean as opposed to serious, professional programmers?
AD> Give me a fucking break!
haha. and your cpan id is? if you denigrate the term perl hacker, you
are neither a perl coder nor a hacker. sorry but you are not allowed
into the clubhouse.
AD> you seem to be contrarian with no actual defense of your
AD> position. oh well, off with your head!
AD> You should talk. Let's see you off my head there buddy. You can't
AD> even fucking quote right! My statement stands. Your tack is to us
AD> the buddy system of hackers. Hackers unite! We will take over the
AD> world, even though we can't get laid! I bow to the obvious
AD> superiority of such a position!
me quote right? emacs does it fine. the other poster has quoting
issues.
AD> Still spilling my beer from this fucking funny shit!
all over your nice perl code. how sweet. go back to coding in java
please.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 07 Apr 2008 08:43:07 +0200
From: Frank Seitz <devnull4711@web.de>
Subject: Re: perl should be improved and perl6
Message-Id: <65tu3rF2h8lnrU1@mid.individual.net>
Uri Guttman wrote:
>>>>>>"j" == jm <jm@nospam.fr> writes:
>
> j> perl provides good things and bad ones.
> j> In the good thing, such as:
> j> * it is adapted for text processing
> j> * it is poorly typed
>
> me thinks you don't understand typing well. perl actually has stronger
> typing than many langs. it just types on the variable type (scalar vs
> array vs hash) instead of the data type.
This is only true for the built-in types, not for
user-defined types (classes).
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
------------------------------
Date: Sun, 6 Apr 2008 23:47:00 -0700
From: "Gordon Etly" <get@bentsys.com>
Subject: Re: perl should be improved and perl6
Message-Id: <65tub6F2g6o1cU1@mid.individual.net>
Tad J McClellan wrote:
> David Formosa (aka ? the Platypus) <dformosa@usyd.edu.au> wrote:
>> On Sun, 6 Apr 2008 09:25:02 -0700, Gordon Etly <get@bentsys.com>
>> wrote:
>
>>> Are you saying the FAQ for this group, a user
>>> contributed document, as valvuable as it may be, carries more weight
>>> then Perl's own man page?
>>
>> man perlfaq
>>
>> They carry the same waight as perl's own man page because perl's man
>> page incorperates the FAQ for this group.
> There is a FAQ for Perl, that ships with perl (but not with PERL).
According to perldoc (which we encouraged to use according to the clpm
guidelines, right?), perl/PERL/Perl are one and the same:
$ perldoc perl | head -n 6
PERL(1) User Contributed Perl Documentation PERL(1)
NAME
perl - Practical Extraction and Report Language
If this is one of the first documents one reads when starting out with
Perl, then why is it of any surprise that some people use "PERL",
"perl", and "Perl" interchangeably? It spells it out in the NAME line
that it is an acronym, and acronyms can be written in all lowercase,
uppercase, or even mixed-case.
> So there is a FAQ for the topic of this newsgroup rather than
> a FAQ for this newsgroup.
True, and a small part of it pertaining to the usage of the term
"perl"/"Perl" and not using "PERL" would seem to be in error according
to the main Perl document/man-page.
--
G.Etly
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
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.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
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.
#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 V11 Issue 1428
***************************************
