What ever happened to comp.lang.perl ?

[David K. Wall]

On Fri, Aug 22, Matt Garrish inscribed on the eternal scroll: [....]
It isn't much of a stretch for me to understand why new programmers
trying to get their scripts to run in Apache (simply as an example
that occurs quite frequently), would think it perfectly reasonable
to post to comp.lang.perl.misc to ask other Perl programmers what
the problem might be (without expecting to be flamed). One would
assume that Perl programmers would probably be familiar with
setting up the environment in which to run their scripts, and be
willing to help.

That's where you'd be dead wrong, for many of the serious users of
Perl here. (Myself, for one, excluded... but then, maybe I'm not
serious enough... ;-)

And you can speak for each_and_every person in this group? Do you really
think no "serious" programmer would use it on a www platform???

No, Alan is alluding to the fact that many serious Perl programmers don't
do CGI scripts. Perl existed for many years, and had a strong following,
even before it became popular for CGI scripts. I've been using Perl
extensively for about ten years, but wrote my first CGI script only
about a year and a half ago.

Ambiguity reigns. I thought Alan meant that a Perl programmer may not
necessarily know or care how to set up a web server to use Perl for CGI,
even if he or she frequently uses Perl for CGI programming. But either
way, CGI topics are off-topic for this group even if they are Frequently
Occurring.

 

[Alan J. Flavell]

Very few servers carry out all control messages (especially rmgroups)
automatically because it's too easy to forge them.

But it only needed a news admin to do some relevant housekeeping once
in the last century to get that sorted out...? Otherwise their
server would be awash with derelict groups, I'd have thought.

It's possible to set up a server to use PGP to verify the sender of
PGP-signed control messages,

Indeed. Not being a news admin myself, I must admit I thought that
had become accepted practice by now. Thanks for the clarification.

but many server admins don't go to that trouble.

Newgroup control messages are affected by the same considerations, but at
least if someone using a certain server doesn't see a new group show up
that he's been waiting for, he can ask the server admin to add it,

Which wouldn't help much if their upstream feed didn't carry it?

As with other control messages, in order to be sure a checkgroups is
valid, you need to use PGP.

Indeed, or at least once in every few years to do a manual
verification (which, for the big-8 groups, wouldn't seem to be *such*
a challenging task, or am I being unreasonable?).

But I fear I'm making the mistake of drifing into detailed discussion
of off-topic matters, so please accept my apologies.

 

[Matt Garrish]

And that's likely to be so very different this time around just how?

It was just a hope I had that it might get discussed civilly. Seems everyone
wants to vent about Perl and CGI, which was only tossed out as an example of
why I can understand how those questions wind up here.

Oh, come on: there's been some helpful and constructive discussion in
the past, but the substantive bottom line that I took from it was that
there are very, very few who have the strength of will and patience to
shepherd folks who, for the most part, are new to Usenet as well as
being new to Perl; what's going to happen is that - with maybe a few
honourable exceptions[1] - some relatively clue-impaired
wanna-be-teachers would hold court on the beginners group, while most
of the experts would stay away; but beginners would ask their
questions on the non-beginner group anyway, because they'd know that's
where the experts hang out.

Which is a possible outcome, but certainly not the only. I expect that most
people, especially when new to Usenet, look for the forum most in line with
their skills. As a newbie to language x, I would be inclined to first look
for a learning or beginners group to post a question knowing that it
probably wouldn't be worth wasting the experts time as the problem likely
stems from something simple I've overlooked. Sure not everyone is as
considerate, but I do believe in the goodness of humanity to at least *try*
and find the right place to post.

Speaking now for myself, I'm no expert here: there's a few areas where
I think I know what I'm talking about, but for the most part I come
here as much to learn from those who know better, and to pay some of
that back by sharing the bits I do know. And that's what Usenet is
all about, IMHO.

I'm not going to pretend to be an expert in anything, but as I've said
before, and as you note, I've received some very useful advice here (okay,
never in clpm except through google, but in alt.perl) and my only goal is to
help out anyone I see floundering in the same boat (and hopefully before the
flaimng fingers get to them). It doesn't mean that every posting is
justified and flamings aren't sometimes in order (personally the only people
who irk me are those who post problems in code they didn't write, and who
don't feel they should learn any Perl along the way). I just think that a
different tier group might help the situation (and I don't think PurlGurls
of the world will ever be taken seriously wherever they try to post.)

Some of the problems are ongoing, and have been a feature of Usenet
ever since September (YKWIM, see Abigail's standard dateline). Some
of the proposed solutions are IMHO considerably worse than the
disease. I say let's just try to get along on the basis of fair
shares, and try not to waste too much effort on those who insist on
spoiling the party.

Fair enough. And thanks for staying on topic... : )

Matt

 

[Hudson]

I would suggest:

comp.lang.perl - pure perl (no modules)
comp.lang.perl.cgi - all things cgi in perl
comp.lang.perl.nix - perl on unix

etc...

 

[Helgi Briem]

My question is: has anyone considered a c.l.learn.perl group? (Or anything
similar?) I'm aware that learn.perl.org has mailing lists, but I suspect
that much of the unwanted posting in this group would be more quickly
diverted were posters presented the option of posting to .learn.perl or
.perl.misc when looking for a group.

Newcomers wanting to learn are more than welcome on
comp.lang.perl,misc and are uniformly warmly treated.

What is unwelcomes is questions about CGI, Unix, sendmail,
shell scripting, awk, Javascript, web server configuration,
yada yada yada.

Oh, and top-posting.

 

[Jonathan Stowe]

I would suggest:

comp.lang.perl - pure perl (no modules)

To cater for all the particular restrictions people might want to place
on their code might I suggest more granularity:

comp.lang.perl.no-modules
comp.lang.perl.no-strict
comp.lang.perl.no-foreach
comp.lang.perl.four

and so forth.

comp.lang.perl.cgi - all things cgi in perl

I would suggest also

comp.lang.perl.munging-energis-cdrs-for-billing-purposes
comp.lang.perl.parsing-biztalk-xml-data
comp.lang.perl.managing-foundry-switch-configuration

Which are things I do with Perl more frequently than applications that use
the CGI.

comp.lang.perl.nix - perl on unix

Actually I think that:

comp.lang.perl.aix
comp.lang.perl.amiga
comp.lang.perl.apollo
comp.lang.perl.beos
comp.lang.perl.bs2000
comp.lang.perl.ce
comp.lang.perl.cygwin
comp.lang.perl.dgux
comp.lang.perl.dos
comp.lang.perl.epoc
comp.lang.perl.freebsd
comp.lang.perl.hpux
comp.lang.perl.hurd
comp.lang.perl.irix
comp.lang.perl.machten
comp.lang.perl.macos
comp.lang.perl.micro
comp.lang.perl.mint
comp.lang.perl.mpeix
comp.lang.perl.netware
comp.lang.perl.os2
comp.lang.perl.os390
comp.lang.perl.os400
comp.lang.perl.plan9
comp.lang.perl.qnx
comp.lang.perl.solaris
comp.lang.perl.tru64
comp.lang.perl.uts
comp.lang.perl.vmesa
comp.lang.perl.vms
comp.lang.perl.vos
comp.lang.perl.win32

would be better if one was going to take that to it's logical conclusion.

I mean we wouldn't want anyone in particular to feel excluded.

I think you might want to get started on the RFDs now.

/J\

 

[Islaw]

Newcomers wanting to learn are more than welcome on
comp.lang.perl,misc and are uniformly warmly treated.

What is unwelcomes is questions about CGI, Unix, sendmail,
shell scripting, awk, Javascript, web server configuration,
yada yada yada.

Oh, and top-posting.

Some things never change...

 

[Islaw]

comp.lang.perl.cgi - all things cgi in perl

It never ceases to amaze me how quick some people are to dismiss this group.
Such a group actually exeists as de.comp.lang.perl.cgi and other foreign
language hierarchies. Just what the hell is so dismally wrong with wanting
such a group?

comp.lang.perl.aix
comp.lang.perl.amiga
comp.lang.perl.apollo
comp.lang.perl.beos
comp.lang.perl.bs2000
comp.lang.perl.ce
comp.lang.perl.cygwin
comp.lang.perl.dgux
comp.lang.perl.dos
comp.lang.perl.epoc
comp.lang.perl.freebsd
comp.lang.perl.hpux
comp.lang.perl.hurd
comp.lang.perl.irix
comp.lang.perl.machten
comp.lang.perl.macos
comp.lang.perl.micro
comp.lang.perl.mint
comp.lang.perl.mpeix
comp.lang.perl.netware
comp.lang.perl.os2
comp.lang.perl.os390
comp.lang.perl.os400
comp.lang.perl.plan9
comp.lang.perl.qnx
comp.lang.perl.solaris
comp.lang.perl.tru64
comp.lang.perl.uts
comp.lang.perl.vmesa
comp.lang.perl.vms
comp.lang.perl.vos
comp.lang.perl.win32

Actually there are many hierarchies that are like this. Hell, look at
comp.unix.*, comp.os.*, comp.lang.* for starters. There are so many large
spamming hierarchies, what is do damn wrong with expanding the Perl
hierarchy?

What you just listed above might actually make the most sense, though could
benefit from a little redundancy reduction. Too bad you only meant it as a
smart ass comment.

A proper suggestive hierarchy could go like this possibly:

comp.lang.perl (or comp.lang.perl.misc - already exists)
comp.lang.perl.cgi
comp.lang.perl.unix (or comp.lang.perl.linux or comp.lang.perl.unix_linux)
comp.lang.perl.win32
comp.lang.perl.os2 (not sure if theres a very big base for this)
comp.lang.perl.mac
comp.lang.perl.networking
comp.lang.perl.modules (already exists)

It's no wonder nothign like this hasn't been done already. It's my
understanding that to start a new big-8 group you need so decent backing.
This will never happen while those who proclaim themselves to be higher up
continuely shoot down these idea, most of the time for no real good reason.

 

[Randal L. Schwartz]

Islaw> It never ceases to amaze me how quick some people are to
Islaw> dismiss this group. Such a group actually exeists as
Islaw> de.comp.lang.perl.cgi and other foreign language
Islaw> hierarchies. Just what the hell is so dismally wrong with
Islaw> wanting such a group?

Because most CGI problems involving Perl are much more about CGI than
they are about Perl, and the cross-breeding in CIWAC is already the
right place to post. CIWAC works very effectively for this. Don't
add a new Perl group to fix something that isn't yet broken.

print "Just another Perl hacker,"

CIWAC = comp.infosystems.www.authoring.cgi - the "CGI group"

 

[Jonathan Stowe]

It never ceases to amaze me how quick some people are to dismiss this group.
Such a group actually exeists as de.comp.lang.perl.cgi and other foreign
language hierarchies. Just what the hell is so dismally wrong with wanting
such a group?

Well because either people have a question about Perl in which case they
post here or they have a problem with the CGI in which case they can post
in c.i.w.a.c - there is no need for another group. Just because people
who write programs using the CGI seem to think it is somehow different, it
doesn't make it different from any other application area - you either have
a question about the interface or application area or you have a question
about the programming language. I don't think I have ever seen anyone ever
suggest comp.lang.c++.cgi ....

Actually there are many hierarchies that are like this. Hell, look at
comp.unix.*, comp.os.*, comp.lang.* for starters. There are so many large
spamming hierarchies, what is do damn wrong with expanding the Perl
hierarchy?

Because people apparently have too much difficulty knowing where to post
as things stand, adding a few extra groups is not going to help matters.

What you just listed above might actually make the most sense, though could
benefit from a little redundancy reduction. Too bad you only meant it as a
smart ass comment.

A proper suggestive hierarchy could go like this possibly:

comp.lang.perl (or comp.lang.perl.misc - already exists)
comp.lang.perl.cgi
comp.lang.perl.unix (or comp.lang.perl.linux or comp.lang.perl.unix_linux)
comp.lang.perl.win32
comp.lang.perl.os2 (not sure if theres a very big base for this)
comp.lang.perl.mac
comp.lang.perl.networking
comp.lang.perl.modules (already exists)

So having set a partial OS hierarchy where do people who are using Perl on
OS/400 post their questions? I don't think that anyone has ever objected
to answering OS specific questions about Perl here, they might of course
object to OS specific questions which are nothing to do with Perl.

/J\

 

[Tassilo v. Parseval]

Also sprach Randal L. Schwartz:

Islaw> It never ceases to amaze me how quick some people are to
Islaw> dismiss this group. Such a group actually exeists as
Islaw> de.comp.lang.perl.cgi and other foreign language
Islaw> hierarchies. Just what the hell is so dismally wrong with
Islaw> wanting such a group?

Because most CGI problems involving Perl are much more about CGI than
they are about Perl, and the cross-breeding in CIWAC is already the
right place to post. CIWAC works very effectively for this. Don't
add a new Perl group to fix something that isn't yet broken.

For the de. hierarchy however, this distinction into .misc and .cgi
works very well. Hardly any CGI-related posts to .misc and the large
majority of postings to .cgi are in fact Perl-related.

Thus I'd say that the above premises against clp.misc and clp.cgi are
wrong. OTOH, I am not subscribed to CIWAC and therefore don't know how
much redundancy clp.cgi would infer.

Tassilo

 

[Randal L. Schwartz]

Tassilo> Thus I'd say that the above premises against clp.misc and clp.cgi are
Tassilo> wrong. OTOH, I am not subscribed to CIWAC and therefore don't know how
Tassilo> much redundancy clp.cgi would infer.

Well, you need to subscribe to CIWAC then. There's a lot of Perl
discussed there. There's no need for a *second* place to discuss the
intersection of Perl and CGI (in English), because the Perl traffic
there does not warrant a breakout group.

 

[Tassilo v. Parseval]

Also sprach Randal L. Schwartz:

Tassilo> Thus I'd say that the above premises against clp.misc and clp.cgi are
Tassilo> wrong. OTOH, I am not subscribed to CIWAC and therefore don't know how
Tassilo> much redundancy clp.cgi would infer.

Well, you need to subscribe to CIWAC then. There's a lot of Perl
discussed there. There's no need for a *second* place to discuss the
intersection of Perl and CGI (in English), because the Perl traffic
there does not warrant a breakout group.

Bah, since I'd hate to subscribe to a CGI-only-related group, I rather
believe you on that. In that case we wont need clp.cgi (even though I'd
love to see the word CGI banned in this group;-).

Tassilo

 

[Tassilo v. Parseval]

Also sprach Greg Schmidt:

Believing that the world in general, and typical AOL subscribers in
particular, are as good as the average German at following organized and
logical thought processes in determining where to post is akin to
believing that the government of the USA is the organization best suited
to finding a peaceful solution to the Middle East problem.

I think the US and Germany have more things in common than you'd think:
We do have AOL subscribers as well (although not to this extent
arguably). And as for the competence of a government, Germany has long
ago reached American standards. ;-)

Anyway, Randal somehow convinced me that the current structure will do.

Tassilo

 

[Helgi Briem]

Thus I'd say that the above premises against clp.misc and clp.cgi are
wrong. OTOH, I am not subscribed to CIWAC and therefore don't know how
much redundancy clp.cgi would infer.

Approximately 100%.

 

[Trent Curry]

It would be nice if they would jsut change sometimes.

Well, for anything to change it'll take an effort from a great many people
in the group.

 

[Trent Curry]

On Fri, Aug 22, Matt Garrish inscribed on the eternal scroll:

wanna-be-teachers would hold court on the beginners group, while most
but beginners would ask their questions on the non-beginner group
anyway, because they'd know that's where the experts hang out.

Well why is it that this group is mentioned in the top Perl books, like the
camel/llama books, books that you'd expect a beginner to pick up. This is
just one of the way such beginner have been lured here over the years. Then
everyone wonders why they come here. They have often been ridiculed becasue
they did not check the FAQs or go to news.newuser, when it should be
plainally obvious that beginners would probably not even know of the news.*
groups, unless they were from they grew up a decade earlier and had unix
surroundings in their upringing.

The fact is, if you were just getting into computers around the mid 90's,
chances are they wouldnt know much of usenet or the "old way"s that have
been around, yet they were expected to know all the rules. I know some jsut
wanted "a quick and dirty" script, and some had better reasons then others,
but when in the end it all resulted in a flame war, it realy served no one,
and in fact hurt this group, as well as others out there (it doesn't just
apply to this group, saddly.)

[1] my admiration goes out to those who hang out on
news.newusers.questions to do just that (hi Jon); it's not
a task that I could cope with, to be fran^W candid.

Speaking now for myself, I'm no expert here: there's a few areas where
I think I know what I'm talking about, but for the most part I come
here as much to learn from those who know better, and to pay some of
that back by sharing the bits I do know. And that's what Usenet is
all about, IMHO.

is it perhaps time to do something?

Some of the problems are ongoing, and have been a feature of Usenet
ever since September (YKWIM, see Abigail's standard dateline). Some
of the proposed solutions are IMHO considerably worse than the
disease. I say let's just try to get along on the basis of fair
shares, and try not to waste too much effort on those who insist on
spoiling the party.

While most of this is true, the last bit I must comment on: you assume that
everytime some "came into" the "party", that it was their intention to spoil
it? I think part of the problem has ben the constant assuming that someone
was lazy, or didnt do any outside research, or didnt look at the FAQ. Many
people seem to beleive that the FAQ and Perldoc are the be all, end all, and
that every single person who reads them will understand them, or how to use
them (in the case of Perldoc), no matter how good a doc each may be (which
they are.)

As I seen posted many times in the days of yore, sometimes it's better to
simply ignore or go on to the next thread if that particular if you find one
to be so distateful and just no worth it.

all the best

One can only hope.

 

[Tad McClellan]

Trent Curry, Islaw, krakle, MJ Owens, Cpt Fredo, Manny Wilco, Robin Givens
and a cast of thousands wrote:

been around, yet they were expected to know all the rules. I know some jsut

^^^^
^^^^

 

[Tad McClellan]

^^^^
^^^^

I say, I say, I say, that was a joke son!

Well, for anything to change it'll take an effort from a great many people
in the group.

Yeah, they'd all have to check the FAQs before posting and ask a
question that was about Perl.

Never happen.

 

[Helgi Briem]

Trent Curry, Islaw, krakle, MJ Owens, Cpt Fredo,

know all the rules. I know some jsut
^^^^

This joker must be a glutton for punishment.

Why does he keep coming back?

What does he want?

Strangely, if we just killfiled everybody who mistypes
just j-s-u-t, we'd probably get rid of this moron forever
at only a tiny cost. It might be worth it.