What ever happened to comp.lang.perl ?

[Trent Curry]

I know this group (comp.lang.perl, not comp.lang.perl.misc) has been dead
for a long time now, albeit my news server has always carried it, but
seemingly locally to the server since it is always empty but I can still
post to it.

I also noticed that groups.google .com carries comp.lang.perl as well as
comp.lang.perl.misc, so there seems to be the existence of this group still,
yes?

From what I heard a while back, comp.lang.perl simply changed it's name to
comp.lang.perl.misc.

What was the reason for this? Does anyone know?

I have newer understood why the name would be changed instead of just having
two groups. It probably would of lessened the amount of trouble
comp.lang.perl.misc has had in the past years, many of which seemed to lead
to the group name which was very misleading (as most groups with "misc" in
the name suggestion "miscellaneous", yet many regulars would always point
out that it wasn't, though I never actually saw an explanation of what
"misc" was suppose to stand for in this case.)

So I ask, what is the story here? The original control messages only say
that this group has taken over the original. But WHY was this name change
even done in the first place?

 

[Matt Garrish]

From what I heard a while back, comp.lang.perl simply changed it's name to
comp.lang.perl.misc.

What was the reason for this? Does anyone know?

I believe it was to reduce traffic. Someone will undoubtedly correct me if
I'm wrong, but it wasn't just a change in name, but the splitting of clp
into .misc and .moderated.

Matt

 

[Rafael Garcia-Suarez]

Matt Garrish wrote in comp.lang.perl.misc :

I believe it was to reduce traffic. Someone will undoubtedly correct me if
I'm wrong, but it wasn't just a change in name, but the splitting of clp
into .misc and .moderated.

No, .moderated appeared after the other comp.lang.perl.* groups (to
reduce the signal/noise ratio compared to what happens here

 

[Jon Bell]

From what I heard a while back, comp.lang.perl simply changed it's name to
comp.lang.perl.misc.

What was the reason for this? Does anyone know?

For a while, the moderator of news.announce.newgroups strongly preferred
that when a group split, the original group not be left behind in the same
location in the namespace tree. That is, when splitting comp.foo, instead
of ending up with something like

comp.foo
comp.foo.a
comp.foo.b

he preferred

comp.foo.a
comp.foo.b
comp.foo.misc

This was supposed to make it clearer that the a and b stuff doesn't belong
in the (renamed) original group any more. Also, it makes certain
technical aspects of configuring a news server a little bit easier. On
the other hand, it does confuse some people because some servers never get
around to removing the original group (as with comp.lang.perl on your
server), so some people opposed this policy rather strongly.

There were many heated debates in news.groups about this. Finally the
news.announce.newgroups moderator gave up and stopped insisting on
"miscification", so it's not much of an issue any more.

 

[Matt Garrish]

No, .moderated appeared after the other comp.lang.perl.* groups (to
reduce the signal/noise ratio compared to what happens here

I knew I had something not quite right...

I'm not interested in eliciting a hudson-esque reponse, but the inference of
..misc does seem at odds with the willingness of some people to discuss
anything beyond specific code examples (and this is not meant as a critique
of the aim of the group, but simply the appropriateness of the identifier,
as the OP has suggested).

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.

On the other hand, clpm is more of a code-oriented discussion group. If you
don't have a code example, or a specific code question, you're not likely to
get a warm reception. Although I make no bones about how I feel about the
way some people asking general questions get treated, I can also understand
why others feel loathe to help them.

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.

And if you don't have anything constructive to add, please continue on to
some other thread... : )

Matt

 

[Islaw]

I know this group (comp.lang.perl, not comp.lang.perl.misc) has been
dead for a long time now, albeit my news server has always carried
it, but seemingly locally to the server since it is always empty but
I can still post to it.

I also noticed that groups.google .com carries comp.lang.perl as well
as comp.lang.perl.misc, so there seems to be the existence of this
group still, yes?

From what I heard a while back, comp.lang.perl simply changed it's
name to comp.lang.perl.misc.

What was the reason for this? Does anyone know?

Like others had said, they wanted to basically match the naming convention
that the "big 8" groups used.

I have newer understood why the name would be changed instead of just
having two groups. It probably would of lessened the amount of trouble
comp.lang.perl.misc has had in the past years, many of which seemed
to lead to the group name which was very misleading (as most groups
with "misc" in the name suggestion "miscellaneous", yet many regulars
would always point out that it wasn't, though I never actually saw an
explanation of what "misc" was suppose to stand for in this case.)

So I ask, what is the story here? The original control messages only
say that this group has taken over the original. But WHY was this
name change even done in the first place?

Personally I think they should have left it. There are so many groups out
ther havign to do with a certain language, like

comp.lang.c++
comp.lang.c
comp.lang.java
comp.lang.javascript

Some of thosel ike comp.lang.c++ and comp.lang.java have the original group
and a few child groups.

Furthur more, so many times in the past there have been people trying to
push the idea that ".misc" in "comp.lang.perl.misc" dcoesnt stand for
miscellaneous and instead just a very limited discussion of the language. I
agree 100% that ".misc" has been a source of a lot of trouble. For petes
sake, if you are goign to rename a group to include the word or phrase
"misc" in it (espically in a group where popularity was growing at ahealthy
rate) you are going to have a lot people coming there because the name would
lead one to beleive you could ask questions even loosely pertaining to Perl
with any fear of flaming or what not.

Thats my 2cents, canadian

 

[Matt Garrish]

As should be clear from Jon Bell's reply: what *.foo.misc is supposed
to mean on a big-8 group is "anything that would have been on-topic
for *.foo, minus those topics which have their own specific group".

It does *not* mean "anything which is remotely related to foo, no
matter that there might be several other groups where the issue would
be more on-topic".

My intention is not to change clp.misc to anything it isn't already, nor am
I trying to advocate that. I'm simply positing the idea that maybe a
clp.learn would be a useful addition to the hierarchy, as it would fill a
different need.

My impression is that other regulars have seen enough times before
where off-topic questions have got misleading answers, and would wish
to save the questioner from that by nudging them in the direction of a
more-appropriate group. Of course, sometimes the questioner has no
clear idea just where their problem lies, and for sure a degree of
tolerance is then appropriate, but it has to be understood that on a
technical discussion group, technical details are the order of the
day, and warm fuzzies are for a different venue.

Which furthers my point. Diversity is a good thing, and warm and fuzzy group
for beginners would likely: a) keep the discussions in .misc more
technical-based; and b) provide a more obvious and beginner-friendly
discussion group for the newbies of the world.

You also can't expect someone to be gracious to you when you're
condescending and rude to them (and I don't mean you personally). I've been
reading this group on-and-off for about 3 or 4 years now, and there are some
people who, no matter how many times and how many different people criticize
their lacking manners, seem to believe they have no faults. CLPM is a great
forum for the novice to advanced programmer, but is more often a black hole
for the beginner to novice.

Has anyone considered reading the not-insignificant previous
discussions on that topic area? :-}

They also tend to go nowhere, as they inevitably fall into bickering about
whether clpm is the be-all and end-all of perl groups (which is also why I
put in the concluding comment... : )

I suppose I could have phrased it differently for those who have seen the
question before: is it perhaps time to do something?

Matt

 

[Jürgen Exner]

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).

Except that Apache and Perl have pretty much nothing to do with each other?

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.

Certainly. Just set your path to perl (or perl.exe on Windows) and off you
go.
What does that have to do with Apache? I'm writing Perl programs on and off
for the last 10 years or so. I've never used Apache or any other web server
for that matter.

jue

 

[Luriel]

Hey, relax, Luriel! There was some irony in Alan's post which I
thought was obvious. Seems as if it wasn't that obvious, after all.
;-)

Point well taken ;p
I don't mean to get so worked up over such things.
Sorry about that ;p

 

[Jon Bell]

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.

 

[Luriel]

Except that Apache and Perl have pretty much nothing to do with each
other?

Ever heard of mod_perl? Apache is only one of the largest (web orientated)
platforms where Perl is used! As has been said already, virually any *NIX
distro for the past many years has been coming pre packaged with Apache and
Perl, and in more times then not Perl is already setup to run on it.

Face it, CGI is a huge use of Perl and has been for quite some time. Yes
thye have their own territories but thye also have many overlapping
properties.

Certainly. Just set your path to perl (or perl.exe on Windows) and
off you go.

For that matter there is and has been Win32 versions of Apache too ;p

What does that have to do with Apache? I'm writing Perl programs on
and off for the last 10 years or so. I've never used Apache or any
other web server for that matter.

I've written many web based server management scripts in Perl that run on a
ww server (Apache in my case.) Hell, WEBMIN is written entirely in Perl!

Ok, it doesn't *directly* have anything to do with Apache, but Apache can,
at the same time, be considered a tool to augment Perl.

 

[Sam Holden]

For that matter there is and has been Win32 versions of Apache too ;p


I've written many web based server management scripts in Perl that run on a
ww server (Apache in my case.) Hell, WEBMIN is written entirely in Perl!

Ok, it doesn't *directly* have anything to do with Apache, but Apache can,
at the same time, be considered a tool to augment Perl.

I use perl with Solaris. So I should ask all my questions about configuring
Solaris here? It's a tool to augment Perl after all.

I edit my perl scripts in vi. Should I ask here for help on vi commands?

 

[Tad McClellan]

Should I ask here for help on vi commands?

How do I get this durn thing out of "beep mode"?

 

[Jon Bell]

Alan J. Flavell wrote:
On Fri, Aug 22, Matt Garrish inscribed on the eternal scroll:
[...] 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. [Matt was referring specifically to Apache/CGI here]

That's where you'd be dead wrong, for many of the serious users of
Perl here.

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.

WEll, the notion that "serious Perl programmers don't do CGI scripts" is
just plain wrong.

He didn't say that. He (and many of the rest of us) are saying that
*many* serious Perl programmers don't do CGI scripts. It's not that we
don't feel Perl is suitable for CGI scripts, it's just that we don't do
CGI scripts. It isn't our field. The field of Perl programming is much
bigger than just CGI scripts.

And many of the problems that face CGI programmers who use Perl don't
depend on the fact that they're using Perl, but instead on server
configuration, understanding the CGI protocol, etc. People who write CGI
programs in C or C++ or other languages have those problems, too. That's
why there's a group for CGI programming that isn't tied to a specific
language. People who write CGI programs can help each other out there,
with problems that don't depend on the language they're using.

 

[Trent Curry]

TM> How do I get this durn thing out of "beep mode"?

use Emacs ;

uri

Riddle me this: Is it such a crime to ask a question pertaining to vi or
Emaces or apache that would allow you to work with Perl directly? Ok, you
would not ask general vi or Emaces or apache questions in this group, but
there should be no hard in a question that a someone having used Perl might
know, such as, for sake of example, "how do setup perl syntax
checking/highlighting in Emaces?" Editors that you two have named are some
of the most popular editors for UNIX users who write Perl, just like Apache
is very popular for Perl coders who wish to expand their application of Perl
to a web browser.

The point is, such topics have quite commonly been dismissed as off-topic,
when they indeed relate to Perl, more to something more akin to what should
be maybe. YES, it's not language specific, but there are also many things
that people in a vi, or Emaces or apache may not know about Perl (and setup
stuff and the likes) that a seasoned Perl user likely would.

I think it's 100% impossible to have dedicated groups for *every*
possibility and cross subject. If attempted there would most like be at
least an order of magnitude more news groups on public/ISP Usenet servers
then there already are.

Are we just suppose to just out-law anything and everything simply because
it doesn't meet a tight topic criteria?

 

[Uri Guttman]

TC> Riddle me this: Is it such a crime to ask a question pertaining to
TC> vi or Emaces or apache that would allow you to work with Perl
TC> directly? Ok, you would not ask general vi or Emaces or apache
TC> questions in this group, but there should be no hard in a question
TC> that a someone having used Perl might know, such as, for sake of
TC> example, "how do setup perl syntax checking/highlighting in
TC> Emaces?" Editors that you two have named are some of the most
TC> popular editors for UNIX users who write Perl, just like Apache is
TC> very popular for Perl coders who wish to expand their application
TC> of Perl to a web browser.

there is even a autoposted perl in emacs post in this group.

but configuration of emacs is offtopic. configuration of apache is
offtopic. neither involve the perl language or program which is the
topic of this group.

TC> The point is, such topics have quite commonly been dismissed as
TC> off-topic, when they indeed relate to Perl, more to something more
TC> akin to what should be maybe. YES, it's not language specific, but
TC> there are also many things that people in a vi, or Emaces or
TC> apache may not know about Perl (and setup stuff and the likes)
TC> that a seasoned Perl user likely would.

you still have to differentiate whether it is perl specific or
apache/editor/whatever specific. in fact knowing the difference will
lead to a faster solution to the problem for the poster.

so telling someone that it is not a perl problem is actually helping
them. the poster doesn't know enough to tell that for themself.

TC> I think it's 100% impossible to have dedicated groups for *every*
TC> possibility and cross subject. If attempted there would most like
TC> be at least an order of magnitude more news groups on public/ISP
TC> Usenet servers then there already are.

sure 100% is impossible. but 95% is doable and reasonable.

TC> Are we just suppose to just out-law anything and everything simply
TC> because it doesn't meet a tight topic criteria?

to some value of epsilon it is tight enough. and that is true for most
groups.

uri

 

[Alan J. Flavell]

[...] 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?

I'm going to have to suggest some attention to your reading
comprehension. "Many of the serious users" does not even attempt to
speak for "every" person in the group, but as a long-time contributor
here (and editor of part of faq9 where these issues are explored) I do
think I have the approximate temperature of the group, and I can
confidently inform you that there are plenty of serious Perl
programmers who do not write CGI scripts.

Do you really think no "serious" programmer would use it on a www
platform???

Now you're really drifing into fantasy, I'm afraid.

No offense instended Flavell, but I think on this note is "where you'd be
dead wrong".

If I had said what you appear to believe I had said, then I would
indeed be wrong. But I didn't, and I think the record shows that.

 

[Jürgen Exner]

Ever heard of mod_perl?

If you have a question about how to use mod_perl then I think nobody will
yell at you, although maybe CLP.modules might even be a better place to ask.

Apache is only one of the largest (web
orientated) platforms where Perl is used!

Sure. As is Linux and FreeBSD and Windows9x and Windows2k and Mac and
Solaris and .... for non-web oriented.
Does that make any question about how to configure Linux, FreeBSD,
Windows9x, Windows2k, Mac, Solaris, .... an appropriate topic for this
group?
If the answer would be "Well, you do it exactly the same way as you would do
it for Fortran or C or Basic or Lisp or ...." then obviously it has nothing
to do with Perl.

As has been said already,
virually any *NIX distro for the past many years has been coming pre
packaged with Apache and Perl, and in more times then not Perl is
already setup to run on it.

Face it, CGI is a huge use of Perl and has been for quite some time.
Yes thye have their own territories but thye also have many
overlapping properties.

Sure. Just as Perl has a large followship among Unix adminstrators or
managers of large programming projects even on Windows. Does that make any
Unix administration question on topic here? Or any question about manage a
multi-million line programming project?

For that matter there is and has been Win32 versions of Apache too ;p

I've written many web based server management scripts in Perl that
run on a ww server (Apache in my case.) Hell, WEBMIN is written
entirely in Perl!

Ok, it doesn't *directly* have anything to do with Apache, but Apache
can, at the same time, be considered a tool to augment Perl.

As is Notepad or vi or emacs or even DOS. Yes, DOS: if you are using Windows
then you still need some place to run your Perl script. Does that make any
DOS question on topic here?
If the question is related to Perl, then probably yes. Heck, there is even
an FAQ entry about that DOS quotes are different from Unix quotes or about
the infamous differences in line end characters.
But let's say "How do I set my path in DOS so that I can call Perl"? Well,
you do it exactly the same way you would add any other directory to your
path.
"How do open a new window when a user clicks a button?" Well, you do it
exactly the same way as you would do it in C or Haskell or Cobol (assuming
you are asking about a CGI script; most often people don't even mention that
little, minor detail and you wonder if they are talking about Perl::Tk or
Win32::API or what).

jue

 

[Jon Bell]

Well, that is an accident of history. The rmgroup for comp.lang.perl
was properly issued, but for whatever reason it wasn't actioned
everywhere

It's as simple as the fact that the moderator of news.announce.newgroups
can't hold a gun to every news server administrator's head and tell
him/her, "remove that group or I pull the trigger."

Very few servers carry out all control messages (especially rmgroups)
automatically because it's too easy to forge them. It's possible to set
up a server to use PGP to verify the sender of PGP-signed control
messages, 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, and
usually it will be done. I doubt that many people would take the trouble
to ask their admins to remove a "bogus" group that they know about.

Conversely, comp.infosystems.www.authoring.stylesheets was properly
created, but for many years a significant proportion of servers failed
to honour its existence, which was annoying for the participants.

A perfect example. This sort of thing is probably the biggest factor that
led the new team of n.a.n moderators last year to impose a moratorium on
converting unmoderated groups to moderated ones. It's confusing when some
servers carry a group as moderated and others carry it as unmoderated.

What's odd to me is that big-8 chkgroups messages are sent at
intervals, which are supposed to facilitate synchronisation of the
newsgroup names, but it seems that some servers don't honour those
either.

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

 

[Jon Bell]

[...]. The field of Perl programming is much
bigger than just CGI scripts.

And many of the problems that face CGI programmers who use Perl don't
depend on the fact that they're using Perl, but instead on server
configuration, understanding the CGI protocol, etc.

At the risk of creating a greasy spot on the pavement where a horse used
to be, here's a parallel example.

The projects that *I* do in Perl usually have to do with processing e-mail
and newsgroup messages. For example, the moderation software for
news.newusers.questions. If I had questions about the fine points of
Net::NNTP and Net::SMTP (all praise to their authors), I'd feel free to
ask them in one of the comp.lang.perl.* groups. If I had problems with
setting up my news server to accept the messages that Net::NNTP is trying
to post, or questions about what information should be in which headers of
the postings that I'm feeding to Net::NNTP, I wouldn't think of asking
them here; I'd go over to news.software.nntp.