Wikipedia:Perl Mediation/OpinionSection

As it seems impossible to get past many of the issues above, I propose a completely different solution. Please take a look at Java_programming_language#Criticism and Java_programming_language#Criticism_2. We could create a Perl#Criticisms and Perl#External_Criticisms, and remove Perl#Opinion completely. Perl#Criticisms would include criticisms of the Perl language and implementation. So, for example, slowness of backtracking in the Regular Expession engine, the OO implementation, Perl's difficult to understand internals, etc., would be perfect for this section. Perl#External_Criticisms would contain links to sound, scholarly criticisms of Perl (as discussed in "The perfect article"). So, the criticisms by Graham, Raymond, Prechelt, and possibly Wall would stay. TIOBE would be out along with the O'Reilly research. Self-published sources and blogs entries, even if they are just external links, will not be allowed as discussed here. The Pro section would not be preserved as the Perl editors have been deemed "pro-Perl" Steve p 17:02, 6 June 2006 (UTC)[reply]

Excellent suggestion. -- RevRagnarok ^{Talk Contrib Reverts} 17:55, 6 June 2006 (UTC)[reply]

Yes, let's do what Steve p says. This is similar to what I did in the Comparative Performance section, and the note I made for that edit [1]. The Pro section is as silly as the rest of the stuff and should be deleted. As I've said before (somewhere), the article shouldn't advocate either side. Scarpia 04:55, 8 June 2006 (UTC)[reply]

This is, by the way, where we were before mediation started, and the same concensus that was previously overruled. Scarpia 05:02, 8 June 2006 (UTC)[reply]

I think you're both in violation of the new arbitration rules, but since this section hasn't been deleted yet, I'll add my side. The content I want to add belongs in the article. I didn't add useless information just to expand unimportant sections. Removal of the opinion section would make me think where else the links and other stuff could go, and don't be surprised if I'd suggest an opinion section for them.

Also remember that this arbitration wasn't initiated my be. I've tried to insert additional issues so a more complete solution can be found for the problems we've had, but under stricter moderation, it's possible that my own concerns would have to be addressed somewhere else. -Barry- 18:16, 6 June 2006 (UTC)[reply]

Can you please elaborate? From a quick scan, Java, C, C++, PHP, COBOL, and ColdFusion have similar structures limiting criticisms to the language. I'm sure others are structured similarly. Steve p 22:10, 6 June 2006 (UTC)[reply]

I think I'll let the mediator control the mediation like he said he'll be doing. -Barry- 22:25, 6 June 2006 (UTC)[reply]

I'd like to see what others think of Steve's idea. I also think a good deal of what would go in criticism belongs explained and explored. I'd love to open this up but Steve hasn't joined the mediation yet. jbolden1517 ^Talk 00:27, 7 June 2006 (UTC)[reply]

I have now. Steve p 13:25, 7 June 2006 (UTC)[reply]

I hope we can keep the opinion section. Barry has stated that we are at an impass, but we may not be. My last remark on the subject was "I want a quote that specifically says 'my opinion of Perl is...'". However, that was somewhat rhetorical. Here's what I think we should have for each item in the Opinion section

An opinion of Perl, explicitly stated or clearly understood
Evidence that someone holds that opinion
A reason why we should care

For example, Perl#Con currently states, "perl is ugly". That is an opinion of Perl. Evidence that someone holds that opinion is a direct quote: Paul Graham thinks Perl is ugly . And why we should care? Click on his name and you find out Paul Graham has written and published on programming, programming languages, and Perl. He started a technology company; now he funds them. He has a PhD in CS. So maybe his opinion is noteworthy.

As it stands, the Opinion section doesn't explicitly make a case that any of the opinions are noteworthy, and it probably shouldn't. For one thing, that would be tedious and pedantic. More importantly, people should be able to see for themselves that the opinions presented are noteworthy. If you have to explain why something is noteworthy, it probably isn't, really. It's like a joke: if you have to explain it, it wasn't funny to begin with.

Barry thinks that the TIOBE data evidences an opinion of Perl. That's certainly possible. For example, we could write, "Perl is boring". Evidence that someone holds this opinion? TIOBE shows references to Perl on the web declining. It used to be interesting; now it's boring. Should we care about this opinion? Maybe we should. The TIOBE data is very broad-based. It aggregates over millions of web pages. If enough people believe something, it becomes notable for that alone.

If "Perl is boring" were added to the opinion section, we could then argue whether the TIOBE data is good enough evidence, and whether millions of random bloggers have a notable opinion. If we kept the item, we would have to decide whether to put it under Pro or Con. Perl hackers would presumably put it under Con, while IT managers--tired of living on the bleeding edge--might count it as a Pro. If we couldn't decide, we could create a Perl#Indifferent sub-head for it. The essential point is that the proposed item, "Perl is boring", begins by expressing an opinion of Perl. Anything that begins by expressing an opinion of Perl is structurally suitable for the Opinion section. Conversely, things that don't express an opinion of Perl aren't.

I think there is a place on the Perl page for items like these. I think they are encyclopedic (interesting, informative, relevant) and verifiable (as to the existence and notability of the stated opinions.) See Talk:Perl#Opinion_is_not_advocacy for further discussion. I originally titled the section "Opinion", because that seemed simple and direct. However, the title has become problematic. For one thing, there is a small but steady stream of edits by people who think that opinion is advocacy, and act accordingly. Also, everyone may not agree on what constitiutes or expresses an opinion. Maybe the "Opinion" title should attach to some other section, or be dropped entirely. Then we'd have to pick a new title for this section--maybe we could call it "Responsible opposing viewpoints" :) Swmcd 00:44, 7 June 2006 (UTC)[reply]

I see the "Pro" and "Con" sections less weasel-y than "Opinion" - it clearly states the objective of that section. It clearly tells you, "here comes a (referenced but not necessarily unbiased or verifiable) [cheerleading|gripe] session." I cannot quantify it, but something about the clearer heading to me would allow a little more wiggle room for the editor, while giving the reader an extra grain of salt. -- RevRagnarok ^{Talk Contrib Reverts} 01:34, 7 June 2006 (UTC)[reply]

I have a feeling nobody would give me that kind of wiggle room in a pro and con section that's not in an opinion section. They'd want verifiable good and bad things more than in an opinion section, and I'd tend to too, though I wouldn't be strict about it. I think:

"In some academic literature, TIOBE's search engine polling data is used to indicate popularity trends of programming languages. TIOBE's data indicates that as of May 2006, Perl's popularity was at its lowest since June, 2001."

which was rejected, is fine for Opinion > Con, but it can be reworded with "readers of...may conclude...because the data indicates..." if it pleases someone to do so. I tried to end that discussion because whether we were at a definite impass or not, I preferred to have arbitrators handle it than to waste more time...[self edited].

I don't think "Perl is boring" would be a reasonable thing to put in the article based on the Tiobe data. You're...um...I mean, that's stretching it. -Barry- 03:04, 7 June 2006 (UTC)[reply]

I wasn't suggesting it (not seriously :) I wrote it to illustrate what an item based on the TIOBE data would look like: it would start by expressing an opinion of Perl. Swmcd 03:42, 7 June 2006 (UTC)[reply]

Jbolden wrote "I also think a good deal of what would go in criticism belongs explained and explored." I tried suggested that here where I said:

"How about if we create an analysis or similar section after Pro and Con where you can say how bad it is to rely on search engine results for this? Or make an analysis section, or an analysis subsection for pro and con. Or just name the whole thing criticism and responses. The responses could come from us if they're facts, or others if they're opinions. You could mention that anyone can create a website with many references to a particular programming language. Go on and on with the criticism if you want." -Barry- 04:05, 7 June 2006 (UTC)[reply]

I believe that one of the goals of the mediation is to improve the overall Perl article. Let's stop fighting over specific links. This is not a turf war. My proposal is to make Perl more like the language articles. Yes, it might be nice to have an Opinion section, but not if the people editing the article could do it without deliberately antagonizing each other. That seems highly unlikely right now. Let's shoot for a more reasonable goal of improving the page, providing factual and critical points against Perl. I would think that discussing the disadvantages of Perl's OO model factually and critically would sway someone more against Perl, than the quote, "Perl is ugly." Steve p 13:25, 7 June 2006 (UTC)[reply]

Eliminating the Opinion section would cause more problems because we'd have to find other sections to put the content that I want added, and if the argument becomes "there's no appropriate section any more" then I'd want the opinion section back.

A piece of information such as that book that I quoted calling the Tiobe search engine stats "popularity" ranks, and using them as such, and the fact that Tiobe says the numbers indicate popularity and the fact that Tiobe is a popular website (Google PageRank of 7) clearly indicate that the author of the book (and authors of other scholarly publications I've linked to), some of its readers, and some visitors to Tiobe's website who've seen the Perl data (which is hard to miss because there are only 20 languages in the top chart) believe Perl's popularity is declining. And if they think of it as only web popularity because search engines are used, that's still a form of popularity, and the consequences of a drop in such popularity would be reduced but not eliminated. A decline in popularity is clearly a con for the fairly obvious reasons that I've mentioned (which should be included in the article just to make sure).

If every entry in the Opinion > Con has to start with "X believes..." I don't think that would read well, but I don't mind. Just figure out how to word it to please yourselves and put it in. Nothing would be accomplished by changing the structure of the article so that there's less of a clear place for this information, and using that as justification for omitting it. -Barry- 14:44, 7 June 2006 (UTC)[reply]

Are you saying that getting your specific changes in are more important than working together on improving the article?

For example, you've already added a good beginning for the Perl#Criticisms section. -Barry-, you were very much on the mark with what you put down about CPAN and what Scarpia and I expanded on. People on systems with an installed Perl and no C compiler are in a world of hurt. There are binary packages for people on these environments, but no solution includes all possible CPAN modules. Among the many reasons are liscensing and portability. This would be what the Perl#Criticisms section would be for. Again, that is a far stronger criticism of Perl than any of the links you posted. Steve p 15:08, 7 June 2006 (UTC)[reply]

If we're going to use other articles as models, I've proposed this article because of its Criticisms and responses section. Then you can express valid concerns.

Criticism may sound better than opinion to some people, but I don't think the things I want to add would no longer fit. If there's policy, such as [2], prohibiting what I want to add, be specific about the content you're claiming it applies to.

Steve asked me "Are you saying that getting your specific changes in are more important than working together on improving the article?" We're analyzing proposed changes together, and I've made some compromises. I can't say too much more on my feelings about "working together" because of the rules, but you already know that I'd rather have administrators make these decisions.

The problem I mentioned with the modules written in C doesn't seem like a clear con to me because I don't know whether there are so many modules that it applies to that the number of modules left would be fewer than those of competing languages when they used to number more. This is similar to the reasoning I used with the benchmark issue - if you find a problem that makes something better or worse, that doesn't necessarily mean it's now better or worse than the competitors. The module issue is a kind of limitation, but it doesn't necessarily take anything away from Perl when choosing a language, except for the fact that the total number of Perl modules listed could be misleading. -Barry- 22:53, 7 June 2006 (UTC)[reply]

Unfortunately, Perl is not part of the paranormal. Its a programming language. Let's stay on topic. Do you plan on working with the other editors to improve the page? Steve p 02:41, 8 June 2006 (UTC)[reply]

That paranormal article might be a better place to look for help than other programming articles because we're dealing with different viewpoints, which it's more common to find in controversial articles than programming articles. The paranormal article dealt with them by allowing different views in the article and labeling them as such rather than as fact, and there was a place for responses. Such a response section could contain analysis, fact checking, etc. The Perl article was already half way there by having an opinion section, but rather than having it solve problems by providing an outlet for controversial opinions, it's only provided the appearance of allowing all sides, and it's actually caused problems when I tried to use it as it should be used. Open it up to material like I want to add, and I'll support a response section, and I'll even help you write one. That's one way I'm willing to work with the other editors to improve the page. -Barry- 03:23, 8 June 2006 (UTC)[reply]

As I said, the Perl#Criticisms section will be limited to criticisms of the Perl language and implementation. Otherwise, it opens the page to the POV pushing that you are concerned about. [3] Can you please answer my previously question? Are you saying that getting your specific changes in is more important than working together on improving the article? Steve p 09:51, 8 June 2006 (UTC)[reply]

It's not POV pushing (at least not improper POV pushing) when you give both sides in a properly labeled section. That wouldn't concern me. It's what I want and what's expected in an opinion section with pro and con subsections. A drop in popularity, which is supported by the scholarly material that I've cited, the Tiobe data, Randall's comments about O'Reilly, and book sales and O'Reilly's comments about their significance, is relevant to the article, and whether those things are "criticisms of the Perl language and implementation" or not, they belong in the article.

To answer your question, fixing the article is what I'm working with you on. Yes, you can call that improving it, I guess. Getting my original specific changes are one way to fix it. I've also offered compromises in responce to other editors' concerns, which I consider working together.

There are six things I want added to the opinion section, or other sections if the opinion section is replaced with one that doesn't fit what I want to add. Maybe we should deal with each item individually. -Barry- 16:08, 8 June 2006 (UTC)[reply]

Other editors [[Talk:Perl#Pro_vs._Con here] indicated why the Pro section is POV-pushing and solutions for fixing it. The general lack of disagreement there and the general agreement with it seems to confirm that feeling. As external editors have agreed the article is pro-Perl, removing the Pro section seems a good first step.

However, let's stick to the discussion of the Perl#Criticism as a section for "criticisms of the Perl language and implementation" and the complete removal of the Perl#Opinion section. Here's a yes or no question. Will you work with us to improve the page without adding the opinions you want? Steve p 16:31, 8 June 2006 (UTC)[reply]

Since I want the additions that I've mentioned unless I'm convinced otherwise (and please attempt to do so here, not with other people's words on some other page), I think we should keep the opinion section because it would allow editors in disagreement to voice that disagreement to some extent. Where do you propose to put the things I want to add if there's no opinion section? If you can't think of a place, I'll propose one, but with no opinion section and with the restrictions you'd put on a criticism section, there will be more problems.

I won't give you yes or no answers if I don't want to. I don't foresee spending any more time working with the Perl editors than is necessary to remove the pro-Perl bias currently in the article, and even to accomplish that I'd prefer to leave it to administrators. This dispute is based on my edits (which arguably aren't all opinions), and that's what I'm here to discuss. I don't know what kind of improvements you have in mind, so I can't say whether I'd work with you on them. -Barry- 18:54, 8 June 2006 (UTC)[reply]

Here's some example criticisms of Perl that would go into the Perl#Criticisms section. Please feel free to suggest more. As I mentioned before and as other languages have done, the purpose is come up with criticisms of the language or implementation. I actually quite like PHP#Criticism's opening statement regarding scripting programming languages and dynamic typing.

"There's more than one way to do it." makes Perl too complex.
Object Oriented programming with Perl isn't very Object Oriented/good/? (can someone suggest better wording here).
All the sigils and operators make Perl hard to read.
The Perl internals are too complex.

Steve p 19:29, 8 June 2006 (UTC)[reply]