Slashdot Mirror
Is Perl Better Than a Randomly Generated Programming Language?
First time accepted submitter QuantumMist writes "Researchers from Southern Illinois University have published a paper comparing Perl to Quorum(PDF) (their own statistically informed programming language) and Randomo (a programming language whose syntax is partially randomly generated). From the paper: 'Perl users were unable to write programs more accurately than those using a language designed by chance.' Reactions have been enthusiastic, and the authors have responded."
Better? How about we start with distinguishable?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I always thought Perl was a randomly generated programming language.
There's no -1 for "I don't get it."
I'd have to say PERL is better than a lot of purposefully crafted languages. Its syntax is very forgiving, and there are lots of ways to do most things. Those two components are likely the reason this study came to that conclusion. This in no way means that PERL is not a good language. It does mean that many people can write PERL badly, but many people speak English badly and that doesn't reflect poorly on the language. PERL is, IMO, and should always be: Easy to do, but impossible to do "perfectly". But then I'm not sure that anything can truely be done "perfectly". Things may be done poorly, well, very well, or nearly perfectly, but to claim perfection is to deny the possibility of improvement.
How does C++ fair?
Farely average.
Donate free food here
They claim that Perl is not significantly better than Randomo, but that's just due to the test they chose. Looking at their figure, Perl programmers outperformed Randomo programmers in 6/6 tasks (that is, their means were greater). Using a simple sign test on the differences between the means, the two tailed p value is about 0.03, and the one-tailed p value (I think we're justified here having having a directional hypothesis...) is about 0.015. Both of these numbers are less than 0.05; we are justified in saying that Perl programmers performed significantly better than Randomo programmers, in spite of what the paper says.
Yes it was Perl 4, which is one of the flaws in this study.
Is Betteridge's Law of Headlines Correct?
Languages that consider whitespace need to die.
While Perl has never had a particular reputation for clarity, the fact that our data shows that there is only a 55.2 % (1 - p) chance that Perl affords more accurate performance amongst novices than Randomo, a language that even we, as the designers, nd excruciatingly difcult to understand, was very surprising.
This is a complete misunderstanding of what a p value means in statistical inference. The p value is not, and should not be interpreted as, the chance that "Perl affords more [or less] accurate performance." The p value is the chance, given that there is no difference, of obtaining a difference as large or larger. This is covered in first-year statistics.
Well said.
If you want your code properly indented, just indent it. It's like the Python apologists are incapable of formatting their code properly unless the language forces its particular version of "properly" on you.
Before the trolls fire back: In the case of code written by others, run it through a pretty-printer. Problem solved. Oh, as a bonus, you can use that same tool to format code the way you prefer, and switch it back to whatever style your company requires at the press of a button. Why is this a bad thing?
Required reading for internet skeptics
When Perl is well written, including indents and not jamming multiple lines all together on one line, it looks very similar to Python, but with a semicolon at the end at each line.
If those punctuation marks (or keywords) make the code more readable, then they're not gratuitous are they? I, for one, find brace-less languages fantastically hard to read, Python especially.
"we did not train participants on what each line of syntax actually did in the computer programs. Instead, participants attempted to derive the meaning of the computer code on their own."
They were not trained. They were just shown code samples with no explanation. The code samples had 1-letter variable names and no comments. The Perl sample uses $_[0} for getting the first sub argument instead of shift, and "for ($i = $a; $i = $b; $i++)" to do a for loop instead of "foreach $i ($a .. $b)", so it is deliberately obfuscated Perl.
Fortran (at least, IV and earlier) totally ignored white space, even in the middle of an identifier. Of course, this led to problems like
DO 10 I = 1.10
meaning "assign the floating point number 1.10 to variable DO10I", when the programmer meant to type
DO 10 I = 1,10
meaning "loop from here to label 10 varying I from 1 to 10".
An error something like this caused the Mariner II probe to Venus to go off course at launch and the Range Safety Officer hit the destruct.
-- Alastair
Fortran is interesting, theologically - it considers God to be real unless declared integer.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I dunno. Since it's a comment on Perl, starting with a # would seem to be entirely accurate according to the syntax.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
If those punctuation marks (or keywords) make the code more readable, then they're not gratuitous are they? I, for one, find brace-less languages fantastically hard to read, Python especially.
I LUUUUURV Python so much that if it was legal I would marry it, but I completely agree. Curly braces to denote block starts and stops make the code easier to read and manage. I should not have to wonder whether a function or block continues past the bottom of the current screen's worth of code when it ends with a few lines of whitespace because I have to know the indentation level of the next line of code to know if it's in a different block context than the last line of code on the current page. I also should never have to wonder if I re-indented code correctly when cut/pasting or adding/removing a level of block nesting.
I don't care if Python wants to keep the indentation requirements. Forcing the code of awful programmers to be more readable in this way is a good thing. Forcing all code to be less readable in another way is a bad trade-off. Just add in the damn braces! Then I can use tools to auto-indent for additional readability.
The enemies of Democracy are
It in fact has three disadvantages: it bypasses any prototype coercions, it passes @_ unmodified by default, and it's unidiomatic.
All of these fencepost errors I've fixed argue otherwise.
how to invest, a novice's guide
Personally, I find that curly braces make code easier to read on top of perfect indentation. In truth, though, it's not so much the braces, as it is the nearly-empty lines of code that are spend to put those braces (note: this specifically applies to ANSI-style brace layout only, not K&R style). It creates a kind of a visual box, clearly delimited, with body of the block in it - more so than plain indentation does by itself.
That said, I wouldn't call Python "fantastically hard to read", quite the opposite - it tends to be one of the easiest languages to read. Not because of indentation, but because its basic syntax is rather clean.