Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Perl Programming

Is Perl Better Than a Randomly Generated Programming Language? 538

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."
This discussion has been archived. No new comments can be posted.

Is Perl Better Than a Randomly Generated Programming Language?

Comments Filter:
  • Better? (Score:5, Funny)

    by Hognoxious ( 631665 ) on Thursday October 27, 2011 @04:06PM (#37861404) Homepage Journal

    Better? How about we start with distinguishable?

    • Re:Better? (Score:5, Funny)

      by Chris Burke ( 6130 ) on Thursday October 27, 2011 @04:14PM (#37861486) Homepage

      Indeed. This is the reason why the Obfuscated Perl Contest is run by the Department of Redundancy Department.

    • Re:Better? (Score:5, Informative)

      by Smallpond ( 221300 ) on Thursday October 27, 2011 @04:23PM (#37861578) Homepage Journal

      Yet another ridiculous summary. The study wasn't which language was better, it was in which language can first-time users write a program more accurately. My guess is that Cobol would beat any of the three - it is designed from the ground up to be readable.

      • My guess is that Cobol would beat any of the three - it is designed from the ground up to be readable.

        So are Pascal and Python. In fact, Quorum looked a lot like Pascal from what I saw in the PDF.

        • by h4rr4r ( 612664 ) on Thursday October 27, 2011 @04:33PM (#37861696)

          Languages that consider whitespace need to die.

          • by narcc ( 412956 ) on Thursday October 27, 2011 @04:45PM (#37861852) Journal

            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?

            • by Radres ( 776901 )

              Because in practice, the automated code cleaner results in almost every line of code in the file to have a difference highlighted by my company's source code repository diff generator. This obfuscates the true nature of the change to the logic in the code I am making in order to fix a bug or implement a feature. In turn, that makes it harder for people responsible for maintaining the code to determine what exactly changed from version to version.

              • by rthille ( 8526 )

                I've always felt that version control systems should store syntax trees, but have never had the time to do the work to do that.

            • No-one is saying that Python is good because it forces you to indent. Quite the opposite: all sane people indent their code anyway, whatever the language, so why not use that to indicate program structure?

              • Because not everyone uses the same indentation as everyone else. If indentation rules need to be worked out before starting a project, you're wasting more time than a language where indentation has no meaning.

            • Oh the fucking irony of it. I was trying to post the following using pre and code tags without success and just ended proving your point:

              Sure. Because

              def function(): if condition: while ok: do_something() end while end if end def Is much more readable than: def function(): if condition: while ok: do_something()

          • Re: (Score:3, Insightful)

            Languages that consider whitespace need to die.

            Most languages consider whitespace. In most programming languages where both of the following are valid, they will have different semantics:

            1: foo bar
            2: foobar

            Quite a lot of languages even distinguish between different types of whitespace, e.g., C where the following two constructs are different, despite differing only in which particular kind of whitespace:

            1:
            foo(); //
            bar();

            2:
            foo(); // bar();

            Python may be unusual in which differences in whitespace it considers

        • Quorum looked a lot like BASIC to me. Only the keywords were different. The headline for the article is horrible (as usual). The headline (and summary) neglect to mention that this test was given to people who had no experience in programming.

          We compared novices that were programming for the first time using each of these languages, testing how accurately they could write simple programs using common program constructs (e.g., loops, conditionals, functions, variables, parameters).

          My takeaway from this "research" is that Perl is not a good language for beginners. If you already know the general concepts of programming, Perl is fairly easy to pick up.

      • by mwvdlee ( 775178 )

        COBOL is designed to be readable, but it's hardly writable.
        (roughly 10 years of experience developing COBOL code).

      • by Junta ( 36770 )

        Indeed. vim is impossible for a first-time user. That does not mean it is a terrible editor. Over-emphasizing day 1 productivity is a bad thing when most of your days will not be 'day 1'.

    • You know, the "study" (which I didn't read, this being slashdot 8-) probably involved exposing the languages in question a hugely diverse and wide ranging number of College Undergrads That Fancy Themselves Programmers. As such, the fact that the quality of the code was not distinguishable despite the language chosen indites the programmers more than the languages.

      The problem with most studies is that College Freshmen already know everything so any attempt to test them is doomed to fail.

  • How does C++ fair? LOL

    • by Halo1 ( 136547 ) on Thursday October 27, 2011 @04:15PM (#37861498)

      How does C++ fair?

      Farely average.

      • by Weezul ( 52464 )

        I know C++ fairly well, trust me, it's the most pointlessly complex language on the planet. And the boilerplate goes on forever.

        C++ might have developed sanely if they'd introduced it's major features in reverse order, i.e. lambdas way back in 1983, templates a bit later, and class methods only during the last decade. As it stands, there are basically two types of C++ code : code that badly emulates functional programming styles, and code consisting entirely of calls to simple wrappers around extern "C" f

        • Unfortunately, C++ remains the only language with a full-featured yet concise RAII, which is its main advantage when compared to C. And templates, while messy, are also extremely efficient in terms of generated code - more so than similar mechanism (generics etc) in pretty much any other language I know of.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      How does C++ fair? LOL

      #%@$&#@^UGSOWDYRO&F@#L(EGFGP*$TW

      This Script written in Perl computes the answer.

    • In a productivity study of experienced users, perl & python were best and C++ worst in both time to finish and lines of code.

      http://www.connellybarnes.com/documents/language_productivity.pdf [connellybarnes.com]

      • Cool, but I'd be curious how the languages fared in other metrics as well. For example:
        1. Errors per line of code at initial run/compile, as appropriate;
        2. Time to debug;
        3. Number of times run/compiled until the program has been debugged;
        4. Time to modify when the software requirements change; and
        5. Number of new errors introduced when the software requirements changed.

        I've used Python, and Perl is my "goto" language (sorry, bad pun) so I tend to suspect they would do better than C/C++ in these areas too, but

      • Re: (Score:3, Informative)

        by increment1 ( 1722312 )

        The study cited has several biases in favor of the scripted languages that are acknowledge by the author in the references of your supplied link.

        Primarily:
        - The non-scripted languages (C, C++, Java) were tested under formal conditions in 1997 / 1998 (Java 1.1 I assume), the script programmers wrote their programs at home and self reported their times (and in most cases spent several days thinking about the problem before starting work, time which was not included).
        - The script programmers were told that the

  • by MrEricSir ( 398214 ) on Thursday October 27, 2011 @04:14PM (#37861474) Homepage

    I always thought Perl was a randomly generated programming language.

  • Perl Is way better (Score:5, Informative)

    by PerlJedi ( 2406408 ) Works for Slashdot on Thursday October 27, 2011 @04:15PM (#37861494) Homepage Journal
    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.
    • by Tridus ( 79566 ) on Thursday October 27, 2011 @04:19PM (#37861536) Homepage

      "Its syntax is very forgiving, and there are lots of ways to do most things"

      That's probably why it's so commonly known as a write-only language. "Forgiving syntax" in particular usually leads to someone sitting around later trying to figure out WTF is going on.

      It's possible to write bad unreadable code in anything, but it's just so much easier in Perl that I shudder anytime I get asked to look at someone elses Perl code. That has NEVER been a good experience.

      • Sounds more like an issue of EBCAK.

        You can make a program that's illegible, blaming Perl for the incompetence or sloth of the people that are writing the code is hardly a fair. What about all those C programs where code is being run from random other files without concern for organization or maintainability?

      • by jedidiah ( 1196 )

        Yeah but wasn't this supposed to be measuring the efforts of "first time users".

        Maintaining someone else's code is an entirely different problem.

        Trying to sort out someone else's code is generally a scary experience across the board. You can make spaghetti out of any language.

        • by anss123 ( 985305 )

          Trying to sort out someone else's code is generally a scary experience across the board. You can make spaghetti out of any language.

          IME it's easier to read Java code, even decompiled java code, than just about anything. C# sharp can be easy too, but a lot more regx use, linq and such ugliness drag it down.

      • by mvar ( 1386987 )
        I use perl for my daily tasks (scripts etc) at work and this "forgiving syntax" has been a time saver.. imho perl is (or should be) just an administrator's tool, nothing more. And yes, its true that reading someone else's code is usually a bad experience and you probably end up writing the program yourself from scratch
      • by gold23 ( 44621 ) <org...slashdot...2@@@oolong...com> on Thursday October 27, 2011 @04:36PM (#37861756) Homepage

        I would suggest that perhaps Perl is particularly effective in separating good from bad programmers. In other languages, restrictions allow bad programmers to write code that *looks* good.

        But if you see readable, understandable Perl code, you know you've got a keeper.

        • One of these days that may happen to me.

        • I would suggest that perhaps Perl is particularly effective in separating good from bad programmers. In other languages, restrictions allow bad programmers to write code that *looks* good.

          But if you see readable, understandable Perl code, you know you've got a keeper.

          I've looked at Perl like I look at English. It's possible to write really well done English that uses some obscure structures for emphasis, or to increase clarity. It is however more likely that someone will piece together the most incoherent confusing material into an English essay, and you will have difficulty following it.

          Illegible code in Perl is not a fault of the language, but rather a fault of the programmer. Whether the matter of Perl letting people write so hideously is a good or bad thing, it must

        • by eriks ( 31863 ) on Thursday October 27, 2011 @05:17PM (#37862210)

          This!

          Perl is a "beautiful" language -- in the same way some people talk about certain human languages (e.g. romance languages, Russian, or Sanskrit) being beautiful, as opposed to merely functional. Other people will disparage those same languages as being too this, or not enough that... the same kind of debate we see with programming languages, particularly with Perl, which is kind of interesting.

          And for some of those human languages, you'll also hear people lament how horribly some non-native speakers butcher them, perhaps because those non-native speakers are using them merely as a "functional" language, rather than grasping the full depth of expression that is possible.

          This analogy has at least some merit I think, since Perl is a language that was designed "linguistically" at least in some sense, in that it has the same kinds of patterns that natural languages have and is chock full of idioms and expressions, that some programmers (myself included) find not only useful from a functional perspective, but actually enhance the creative process that happens when one writes code. I think part of that is due to Larry Wall's now venerable "Programming Perl" -- which is one of the few truly valuable programming books that's also actually fun to read -- especially if you're one of those people that thinks at least a little like Larry, and enjoys a dry wit.

          Anyway, so yes, I totally agree, programmers that need "restrictions" in a scripting language to have their code be readable are definitely a certain "kind" of programmer. Not that they are better or worse programmers, they just don't embrace the TMTOWTDI philosophy, which is something that the society at-large doesn't generally embrace, so it's no surprise that there seem to be a lot of people that shit all over Perl.

          I've seen (in my own code and in others) truly beautiful and elegant Perl code that reads like a story, and also the "line noise" code people complain about. Which is really all about regular expressions. Some people really love 'em, perhaps a little too much. Though as has been pointed out probably a billion times, there's nothing wrong with one-off throwaway code that looks like line noise, but if you're building a giant system, then your code should be all pretty and commented and generally sociable.

          It's both unfortunate (and I still hope... a mixed-blessing) that Perl 6 has taken so long to come about. In that PHP went and pretty much took over it's niche as a web-development and "glue" language. Though the Perl community is still strong, if small, and I have no doubt that it will remain a living language for a long time to come, if for no other reason than the fact that CPAN is awesome, and there are zillions of lines of code written in Perl that a lot of people depend on every day, and that when Perl6 matures, I think it will enjoy a resurgence, within the Perl community, and perhaps much further, simply because of the simple and powerful philosophies that it encodes.

          Easy things should be easy and hard things possible.

      • by arth1 ( 260657 )

        Comments are supposed to tell you what's going on. In fact, Perl has a built-in self-documentation system that makes it a breeze to document and find the documentation you want.

        You don't maintain perl code by trying to understand it and tweak it. You maintain it by replacing lines or blocks of code with better written code.
        And if you're not man enough to write better code, wtf are you doing trying to maintain it in the first place?

        • Comments are supposed to tell you what's going on.
          I certainly hope not. Whenever i see comments in C++ or Java code i'm thinking "why did you not write this to be more ovious way in the first place, wtf needs explanations here".
          There a few cases where code needs comments IMO, and class-level and function-level docs are perfectly OK. But comments within source are a sign of
          a) something incredibly clever being done
          b) sloppy design or poorly written code that needs explanation on whats going on
          In 99% of
          • Re: (Score:3, Insightful)

            You are dangerous, incompetent and unprofessional. I sincerely hope that you never work on any system that could even remotely threaten anyone's well being, either physical, mental or economic. There is no such thing as self documenting code. That idea was disproved with COBOL. You have no idea what you are talking about.

            Despite some of the ill founded comments in this discussion, natural language is not comparable to computer language. Programming is closer to mathematics then human language. In the same

            • Agreed. I am a PhD mathematics student and I can attest its extremely difficult to understand equations without context and written explanation. Im also a programmer (for my job) and I write my code to be very readable with proper formatting and self-explanatory variables/classes (as much as they can be), however even when I look at my OWN code from the distant past I need comments to sort out the macro-structure of it as well as to explain a complicated line quickly. If you don't remember what some class o
      • by grcumb ( 781340 ) on Thursday October 27, 2011 @04:49PM (#37861902) Homepage Journal

        "Its syntax is very forgiving, and there are lots of ways to do most things"

        That's probably why it's so commonly known as a write-only language. "Forgiving syntax" in particular usually leads to someone sitting around later trying to figure out WTF is going on.

        One could - quite validly - say the same about the English Language.

        Now, I'll grant programming and spoken/written languages don't overlap perfectly with one another. That's why languages like LISP have such elegance; what they're designed to express is something far more abstracted and formalised in nature. It's possible to conceive of a complex structure and accompanying set of behaviours and properties simply by scanning a screenful of LISP, but English is narrative in nature. You don't scan across; you scan from top to bottom.

        It's possible to write bad unreadable code in anything, but it's just so much easier in Perl that I shudder anytime I get asked to look at someone elses Perl code. That has NEVER been a good experience.

        Perl can be difficult to grok, but it can be elegant as well. I've experienced revulsion looking at Perl code before, but never so consistently as with ASP and PHP. These are languages (and I use that term loosely) that simply cannot be made pretty.

        In the right hands, Perl can be as elegant and expressive (and opaque, and efficient) as Shakespearean English. Argue however you like, the same is not true of many other languages. Python has clarity and simplicity. It's truly an engineer's language. LISP, as I've said, is beautiful in the same way architecture can be beautiful: taken as a whole, rather than a story. I didn't understand the appeal of Ruby until I learned that its inventor is Japanese. Then it all became clear. What seemed like awkward, nearly backward syntactical constructions suddenly made sense.

        In other words, horses for courses. But arguing that Perl is not readable in its very nature is like arguing that English in incomprehensible based entirely on watching Jersey Shore.

  • Who taught them Perl? Where did they learn to call subroutines with an ampersand? A Perl 4 manual?

    OK they're novices but even I didn't write loops using C-style loops as a novice Perl coder because I was reading that it was more readable to do for($a..$b) instead.

    • by finnw ( 415539 ) on Thursday October 27, 2011 @04:30PM (#37861666) Homepage

      Yes it was Perl 4 [perl.org], which is one of the flaws in this study.

    • That's sort of the the point. I'm not a good programmer, but when I code, I tend to use Perl, I focus on making the code legible and typically don't take on much with it. Perl works well with that, but there's plenty of folks that use Perl for things that it's not really intended for and don't have any idea what maintainable code should look like.

      Ultimately GIGO, you need more than a study like this to determine whether or not Perl is better than a randomly generated programming language. Ultimately, I woul

    • by Smallpond ( 221300 ) on Thursday October 27, 2011 @04:56PM (#37861970) Homepage Journal

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

  • Not so fast.... (Score:5, Informative)

    by Ardeaem ( 625311 ) on Thursday October 27, 2011 @04:23PM (#37861586)
    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 [wikipedia.org] 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.
    • Also... (Score:5, Insightful)

      by Ardeaem ( 625311 ) on Thursday October 27, 2011 @04:33PM (#37861714)
      They also say that

      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 [wikipedia.org] 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.

      • ...of what a p value [wikipedia.org] means in statistical inference. The p value is not, and should not be interpreted as, [perl's divergence in] accurate performance." The p value is the chance, given that there is no difference, of obtaining a difference as large or larger.

        And they say English can't be obfuscated like programming languages.

      • If p is the chance, given no difference, of obtaining a result that is larger, what would you interpret (1-p) to mean?

  • by medv4380 ( 1604309 ) on Thursday October 27, 2011 @04:25PM (#37861602)
    Are they telling me that Quorum is better then a randomly generated language at teaching and that Perl makes bad programmers? This sounds more like someone setting up a study and trying to rig it so that their horse (quorum) gets taught in the class room. Personally I stick Perl in the same bucket as VB and most scripts. They may have their uses but new programmers need to be beaten with languages like C and C++ first. Otherwise they learn bad habits. Perl only starts getting good when you use strict so that it has been given permission to beat the programmer for any little mistake.
  • But for now... If I were a Samurai, I would not start newbies with a live sharp sword. And Modern Perl is so, so very sharp...

    I keep reading the full paper (+points for publishing the whole thing!) and have yet to hit upon the definition of the word "accurate" they are using to measure the results. Apparently that is contained inside their previous paper with no direct link. On page 3 though, Perl is described as "A well-known commercial programming language". Really? C# is a commercial language, Perl
  • The participants didn't know the languages before. If anything, the study only proved that Perl has a steep learning curve.

  • by sprior ( 249994 )

    Didn't APL prove this a long time ago?

  • Well written Perl (Score:4, Interesting)

    by danbuter ( 2019760 ) on Thursday October 27, 2011 @04:45PM (#37861854)
    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.
    • by arth1 ( 260657 )

      Not each line. Only lines that need to be separated. There's no need for a semicolon if the next line is a closing curly, for example.

      Some insert them anyhow, and I can see the rationale for doing so. But unfortunately, that also encourages cut/paste programming, which is especially bad for perl. I remove superfluous semicolons precisely so I will have to stop and think before doing a cut/paste job.

  • It's something of an injustice to credit "Southern Illinois University" researchers for this. The unmodified SIU is in Carbondale, while these researchers were in the Edwardsville branch.
  • While it is important for adoption how fast one can learn a language, the long term benefits are much more important. I also needed time to get used to Perl but is now a programmable languages very dear to me: it is reliable, has a great culture, is fast, does evolve only slowly and can be extremely powerful. This is similar to LaTeX, which needs first some efforts to learned but after a while runs circles around any other text processing system. Other programming languages or text processors might be easie
  • by knarf ( 34928 ) on Thursday October 27, 2011 @05:03PM (#37862050)

    Perl is a language, just like Dutch, Swedish, English, German and most of the others. In just about any language there is, to paraphrase a well-known Perl motto, more than one way to say something. That is in many ways a good thing, especially when it comes to using the language creatively as a novelist or poet or similar type of wordsmith does.

    It is true that this quality does tend to make Perl programs somewhat hard to grasp for the uninitiated in the programmers style of writing. That is another quality the Perl language shares with those other languages mentioned above - did you understand all of Finnegans Wake the first time you read it?

    In other words, Perl is a writers' language. It is not an editors' language. Once you get into the right mood, Perl flows like your native language does. Done right, this can lead to great things. It can also lead to the sort of notes you made when attending those lectures you did not care about in the first place, and did not understand in the second. Use Perl for things you care about, and it will provide you the means to express yourself in just the right way (for you).

Never test for an error condition you don't know how to handle. -- Steinbach

Working...