6 ms·

It is still... A language for the quick hack, but not for the reader (or author) to understand a day or even an hour after the writing.

• mhd 11y ago
  It's an Algol-based language. I never quite got what people "got wrong" with Perl code. Yes, I've seen bad examples, but those would've looked pretty much the same in C, Pascal or Python (deep nesting, bad names, overuse of regexps). Back in the days one argument was using "grep" or "map" instead of explicit for-loops, but in this day of functional programming, that would seem a weird criticism. Is it the type glyphs? ($%@) References are a bit unnecessary, yes.
  • hugs 11y ago
    Yes, it's the type glyphs. (For me, at least.) Back when I was a DBA writing database back-up scripts in Perl, I could never remember how to dereference a value in an array or hash properly. (It reminded me of my problem with pointer notation syntax in C). When I first saw Python, I thought "Wow, it's like Perl, but without the confusing notation." I rewrote the scripts in Python and never looked back.
    • raiph 11y ago
      > I could never remember how to dereference a value in an array or hash properly. I too struggled with that and came to hate it. Perl 6 directly addressed this and some related problems. First, sigils are now invariant - they're just a part of the name that signals which of the three data structure types a particular variable is. Second, there's no need for a `->` dereferencing op. my @array = 1,2,3; # `@` sigil means indexable var say @array[1]; # prints 2 It might be interesting to look at an example. Perhaps you could share an example of code in Python that illustrates some data structuring code that would be confusing in Perl 5 syntax, I'll try show what the Perl 6 equivalent would be, and we can see if Perl 6 really does clean this part of the language up.
    • collyw 11y ago
      Nested arrays are a pain on the arse in Python. Do I use extend or append? Then strings are treated as character arrays. I far preferred Perl's approach where you would reference or dereference variables instead.
• realusername 11y ago
  That's the number one reason I don't code in Perl, I can't even read my own code 6 months later... Perl is not a programming language, it's closer to real languages and you can sort of invent stuff and it works...
  • dozzie 11y ago
    Then you're doing it wrong. Do you write in the same manner in other languages, too?
    • lmm 11y ago
      I can write readable Perl by writing it as if it were Python, adding extra braces where required, a couple of use declarations at the top, and wrapping some system functions with clearer names. But if that's what you want then it's easier to just write Python. Perl's USPs like regex literals and $_ rely on you writing in an unreadable style.
      • Mithaldu 11y ago
        Got some examples of your Perl?
        • lmm 11y ago
          Afraid not - I only ever wrote Perl for employers, for my personal projects I used Python.
      • dozzie 11y ago
        So, Python regexps are suddenly more readable, even though they need additional layer of backslashes? $_ does not rely on unreadable style. First, it's a common idiom, so it's in no way less comprehensible than list comprehension in Python. You just need to understand what it means. Second, it's not an obligation to use $_. I often avoid it if it doesn't make my code reflecting my intentions better. Funny thing, I do the same in Python, C, and Erlang. And I hear about $_ and regexp literals as unique selling points (if I read your acronym correctly) only from people that don't really write in Perl.
• kqr 11y ago
  This is because it was invented to be possible to use as an interactive shell. When you're working with an interactive shell, you want its language to be (at least somewhat) optimised for writeability, which by necessity means a lack of optimisation for readability. (Explicitness and some level of redundancy aid readability but hurt writeability.)
  • dalke 11y ago
    I believe Perl was meant as a replacement for shell scripts, as well as sed and awk script. It wasn't designed as a interactive shell. For example, the original perl man page says (quoting from http://history.perl.org/PerlTimeline.html http://history.perl.org/PerlTimeline.html ): Perl is a interpreted language optimized for scanning arbi- trary text files, extracting information from those text files, and printing reports based on that information. It's also a good language for many system management tasks. The language is intended to be practical (easy to use, effi- cient, complete) rather than beautiful (tiny, elegant, minimal). It combines (in the author's opinion, anyway) some of the best features of C, sed, awk, and sh, so people familiar with those languages should have little difficulty with it. The closest that perl had to an interactive shell was with the "-d" debugger. See for example this synopsis from 2007 at http://archive.oreilly.com/pub/post/writing_a_modern_perl_repl.html http://archive.oreilly.com/pub/post/writing_a_modern_perl_re... : > One area in which Perl falls behind other languages is in its lack of a usable Read-Evaluate-Print-Loop. (perl -de 0 just isn't enough for me.) I've used Ruby's irb and a handful of Python shells, and I'm starting to become a fan of ghci, but I fall back on perl -e far too often for my sanity. An interactive shell should, in my opinion, support more than a REPL. It should also implement job control, like suspending a job or starting jobs in the background. Perl definitely was not invented for that purpose.
• collyw 11y ago
  I have seen just as much crappy unreadable Python in the wild.