Misplaced Pages

Revision as of 02:01, 28 May 2006

Intro

Hi. I'm the mediator taking Misplaced Pages:Mediation Cabal/Cases/2006-05-23 Perl. A little background on neutrality.

1. I've known been programming for about 26 years and professionally involved in the computer field (though not as a developer) for about 13 years.
2. I know Perl and have used it over the last 10 years for a variety of projects.
3. I've noticed Randal is participating on one issue. I should disclose that I did try and hire Randal's company about 7 years ago and was unsuccessful (he was focussed on training and I needed a custom module written). So we have had minor business dealings, OTOH he doesn't seem to be a major participant.
4. I know a wide variety of other languages and I'd say my favorite right now is Haskell.
5. By in large I favor Python for enterprise use and Perl for personal use

So I hope that is neutral enough. Now.... I started this page because the mediation page had turned into a mess very quickly, as is the talk page. I want to keep this page reasonably clean and to the point. So the first rule we have is no discussion of personal bias. Misplaced Pages editors are by and large motivated by passion to write, since they are unpaid. At the same time we attempt institutionally to be dispassionate the way we do this is via. WP:V, WP:NOR, WP:NPOV. I am perfectly OK with why a particular passage is biased I don't want to hear about how an editor is biased.

So now lets address 2 subtopics. Please jump in below jbolden1517 15:38, 27 May 2006 (UTC)

Sorry ... why should anyone care? This is one person, -Barry-, against consensus. This is a waste of time, and I implore everyone to refuse to participate. Pudge 22:06, 27 May 2006 (UTC)

That's fine. So I just indicate refused to participate and take you off the mediation effort? Remember the request was made by User:Revragnarok not Barry. jbolden1517 00:27, 28 May 2006 (UTC)

I'd prefer that we quickly demonstrate that there is consensus and that the edits were made with valid reasons and not vandalism as has been claimed. Steve p 23:05, 27 May 2006 (UTC)

That's better. If you can demonstrate that there is a consensus and that he refused to act in good faith I'll be happy to indicate that in the report and from there you could go for an rfc regarding Barry rather than regarding the issue. But that's going to take some time. This is a process. jbolden1517 00:27, 28 May 2006 (UTC)

The fall in popularity of Perl

This seems to be one of the key issues under debate. Basically has Perl fallen off in terms of popularity as measured by usage, webhits, book sales...? Now what I'd like to determine is (and you all should answer these questions):

1. Am I accurately describing the debate?
2. Now do the facts point to which of the following two statements: For example Cobol is obviously a language in tremendous decline but it is still heavily used, while Java is a language which is increasing usage much more slowly than it was 5 years ago.
   1. Perl's usage is falling off
   2. The increase in Perl's usage has fallen off
3. Does this deserve a paragraph a section or a subsection?

jbolden1517 15:38, 27 May 2006 (UTC)

I don't think you're accurately describing the debate. My issues are with verifiability, not the particular issue at hand. We have no way to measure the statement, and any single measure is certainly to leave out something. Additionally, different measures will show opposite conclusions. This clearly shows that we can't verify the conclusion. There are no facts to support any statement about Perl's popularity either way, so the submissions so far do not meet Misplaced Pages's standards. I don't think that the popularity of anything, Perl included, is encyclopedic. It certainly doesn't change the identity or characteristic of the subject. Should we add a section on popularity of the topic to every page and let people express loosely evidenced opinions on current books, music, political philosphies? Scarpia 17:19, 27 May 2006 (UTC)

OK fair enough. So let me try again. You are arguing that:

1. We don't have good numbers on Perl's popularity
2. Even if we did popularity figures they are not important because we don't generally consider such things?

Is that correct? jbolden1517 20:30, 27 May 2006 (UTC)

Correct, there is no verifiability, and whether Perl's popularity has fallen or not is not criticism of Perl. Even if Perl's popularity has fallen, using it as a reason for criticising Perl is a case of bandwagon fallicy. If there is a valid or verifiable criticism of Perl, it should stay. Criticisms based on specious reasoning are not appropriate, and a consensus of the editors have agreed. Steve p 21:42, 27 May 2006 (UTC)

I'm not sure you are correct here. Things like availability of hires, availability of libraries, 3rd party support... are all functions of popularity. Popularity is of a great deal of importance when choosing a language from a practical standpoint. Right now Perl has publicly available libraries collection second only to Java. On the other hand were usage to fall off by say 90% or so its utility would be diminished substantially. Another 90% from there and directly hiring for the skill sets becomes very difficult. That most certainly does effect language choice. If there genuinely was a consensus on the Perl page not to address issues of popularity that would be very curious since its popularity (and its effects i.e. CPAN and the "everyone knows Perl") more so than any other feature that makes Perl a "safer" choice than Ruby or Python. Purely on the merits its a much more complex choice which comes down to subtle opinions.

So again I'm not here to overturn a consensus but I'd fine it very odd. Perl is one of the most well known languages and is used freely in the way that C++, Java, Cobol, are used not the way Ruby, Lisp and Ada are used. The bandwagon fallacy doesn't apply when an increase in popularity has meaningful effect. Quite simply in choosing a programming in a professional environment popularity matters. How much is an area of debate jbolden1517 01:13, 28 May 2006 (UTC)

I think you missed my point. My point is not that popularity doesn't matter when selecting a language. Popularity, however, is not a valid criticism of a language. For example, "Language A is more popular than language B; therefore, language A is better". The popularity arguments have nothing to do with the criticism of Perl, the language. My personal opinion is that the RFCs for Perl 6 are a much more valid criticism of Perl. Those are the real gripes that Perl programmers have had with the language. Steve p 02:01, 28 May 2006 (UTC)

This is the page I'm getting the popularity ratings from.

OK that's a piece of data. Its being questioned. Do you have any other independent data which supports the relative positions? Also you didn't answer my questions above, could you answer those? jbolden1517 01:13, 28 May 2006 (UTC)

Barry we get into either attack or defending those numbers I want to address the more general questions. Popularity of programming languages is not an obscure topic we have a variety of ways of measuring it. Right now the question is about whether popularity figures should be used at all. jbolden1517 01:13, 28 May 2006 (UTC)

Randal L. Schwartz, co-author of several Perl books published by O'Reilly, has said that OSCON's organizers are openly hostile to Perl, and that Perl isn't interesting to O'Reilly anymore.

Another piece of evidence. But do remember this is an off the record comment. Its substantially weaker than an official statement but still definitely something to show falling interest. jbolden1517 01:13, 28 May 2006 (UTC)

In the article Comparison of programming languages, at this time, the Tiobe data is there (last two columns of the top chart) under the headings Serp Rank and Serp Rank Change. I'd like it to remain there. (I'll post in the Benchmarking section later)-Barry- 00:14, 28 May 2006 (UTC)

Those seem like reasonable facts for that chart. I'll see if other's object. jbolden1517 01:13, 28 May 2006 (UTC)

Benchmarking

Benchmarking any language is very complicated. However discussions about problems with benchmarking that are not specific to Perl belong in Benchmark (computing) not in a Perl article. Obviously we need to include some benchmarks for Perl and some discussion of how to benchmark Perl. Perl has been optimized far more than most "interpreted" languages, it has been studied on this issue for decade or more. So what I want is a strategy for addressing this issue. I'd like the participants in the benchmarking debate to propose one. jbolden1517 15:38, 27 May 2006 (UTC)

The Misplaced Pages article on a programming language is not its documentation. We don't need to explain how to do anything. Misplaced Pages is not a HOWTO. I don't see that its obvious that we need to include benchmarking information, or what purpose it would serve. We can include discussion about design trade-offs that gives insight into the architecture and inner-workings of the language, but simply throwing numbers around does not inform the reader. Scarpia 17:24, 27 May 2006 (UTC)

Again. Let me just make sure I understand. You are arguing that knowing how fast a language is at various tasks is not important to be people considering / evaluating a language? jbolden1517 20:32, 27 May 2006 (UTC)

A language itself doesn't do anything at any speed, just as the english language doesn't tell a story or make a poem. People can write programs to do tasks, and we can time those programs. That's only timing the programs that somebody wrote, and the speed only measures that particular implementation. Another programmer (e.g. one with more skill) may write a program in the same language to do the same thing faster (and I've been on both sides of that many times, as have most practicing programmers probably). The execution speed, even if we could measure it, is only a tiny portion of the utility and reason to use a language, and to focus on it gives it undue importance. If everyone wanted really fast programs (i.e. cared about execution speed), they'd be programming in machine language. Since there are concerns more important to them (time to market, how much time they have, return on investment, total programmer time, portability, and so on), elevating a single concern to stand above all others adds bias, even if the numbers favor Perl.

It's not of particular importance to Perl specifically, but may be appropriate in an article about dynamic languages in general. I addressed some of these concerns in my last edits to the "Comparative Performance" section by relating the claims to the design of Perl and linking to two significant discussions of the impact of Perl's implementation to its performance.

Knowing how to benchmark something is certainly interesting to users, but as I said before, Misplaced Pages is not a HOWTO. Scarpia 22:12, 27 May 2006 (UTC)

Benchmarking is an appropriate thing to consider when choosing a language. It is not appropriate, however, to provide benchmark results as they may not be at all relevant as a criticism to a programming language in all cases. There are too many variables to consider (differences in CPU, memory, file systems, bus speed, etc.) that make a single set of benchmark results unusable when not comparing identical system. Benchmark results involving Perl and other interpreted languages can also be slanted through differences in C compilers used to compile the interpreter, optimization levels, and other compiler options. Using benchmark comparisons between languages is also often a slanted argument. I'm sure most programmers will concede that Assembly Language is faster in almost every task than any other language. However, this would certainly be specious reasoning if you are using this alone to select a programming language or using it as a criticism against another language. I am highly suspect of adding benchmark information for any computer language as it can provide an editor a way to add a positive or negative point of view.

As for how to benchmark Perl, its not to much different than any other statistical experiment. Set up a base case with a measured level of expected error. Experiment with and measure an opposing case. If you cannot prove the opposing case is statically significant from the base, you cannot say that the opposing case is any different from the base. Knowing how to benchmark has little to do with Perl. It requires a basic understanding of statistical inference and an ability to be dispassionate about the results. Steve p 22:52, 27 May 2006 (UTC)