11 ms·
I'm a relatively new programmer. Been programming for around 4 years. I tried Perl, but felt like the world had moved on, so I never really committed to it. Wi
by AlexanderDhoore 13y ago
I'm a relatively new programmer. Been programming for around 4 years. I tried Perl, but felt like the world had moved on, so I never really committed to it.
With PHP, Python, Ruby and Javascript... space seems tight for another scripting language. Languages like Lua have something special. What's special about Perl?
Edit: I don't want to be hateful. The more the merrier obviously.
- phpnode 13y agoI'm not a perl coder, but the library support does seem pretty fantastic - http://www.cpan.org/ http://www.cpan.org/
- untothebreach 13y agoI would say "pretty fantastic" is an understatement...CPAN is the gold standard of library support
- danellis 13y agoMaybe, for the modules that build and actually have useful documentation. That seemed to me to be depressingly uncommon.
- chromatic 13y agoSee CPAN Testers: http://www.cpantesters.org/ http://www.cpantesters.org/
- SwellJoe 13y agoWhat platform are you on? I can't remember the last time I tried to install a module on a modern Linux distribution and had problems with it. Docs might be weaker than I'd like in some cases, mostly because of not enough examples (the curse of most documentation, IMHO). I don't develop on Windows or Mac, since I work on server-side software, so I might just be blissfully ignorant of a serious problem.
- danellis 13y agoLinux. I think the most recent example (by which I mean about two years ago; I don't use Perl much) was trying to get the XML Signature modules to build. I gave up in the end. The documentation for those was poor. I remember the documentation for Moose being poor, as well as the documentation for Catalyst being especially bad.
- __david__ 13y agoMy experience is that the Perl community documents better than any other scripting language community. Most everything is perldoc (which gets installed as man pages when install a cpan package) with clear examples right up front where you can see them. And that's not even talking about the built-in documentation. Even in 1994-5 when I first learned Perl, I learned it completely from the Perl man pages and not from a book. The man pages are comprehensive, easy to read, and organized well for reference. Ruby, Python, PHP and Node really need to get their act together and follow Perl's lead in this area.
- virtualsue 13y agoThere is, in fact, all the space in the world.
- collyw 13y agoI moved from Perl to Python 3 years ago. Its true. Perl feels like a very powerful base language, moving to Python felt like you were taking a bit away (I know in reality you can probably achieve much the same things). Python on the other hand doesn't require you to implement your own basic functions (max, min , trim / strip ) as they are included already. Python stops me from shooting myself in the foot as often, by not allowing me to do stuff that is too clever too early. I do miss being able to reference / deference variables explicitly though. Other great things are, CPAN, regular expression support (that never feels as nice in Python), one liners for doing stuff quickly on the command line. I even quite like the sigils, as an easy way to recognize the types of variable you are dealing with (though it is confusing at first). Working with strings feels a lot more natural in Perl than Python.
- mxey 13y agomax and min are part of List::Util, a library that comes with Perl
- eCa 13y agoLink for the lazy: https://metacpan.org/pod/List::Util https://metacpan.org/pod/List::Util Or even better, just use List::AllUtils - https://metacpan.org/pod/List::AllUtils https://metacpan.org/pod/List::AllUtils
- berntb 13y ago>> max, min [etc] Perl has a minimal std library, to teach people to use CPAN I guess. But even Perl has util modules for trivial help functions in the std install (at least those which aren't one line of code to define). The strongest argument for Perl today is CPAN and CPAN Testers, still the gold standard. But all the scripting languages are really similar, there is no reason to learn another if you already know one. Edit: You might want to check out the Modern Perl book, free online. Perl evolves quite fast.
- collyw 13y agoDjango was the reason I switched. I gave Catalyst a go, but the ability to swap out almost every component left me wondering what the framework actually was. The documentation was significantly easier (for a newbie to web frameworks) to get something going. And the Django admin gave me a large chunk of what I wanted for very little effort.
- nailer 13y agoPerl's older than most of those. The original killer feature of Perl was regexs - these existed before, but Perl's implementation destroyed all others, and 'PCRE' (Perl compatible regular expressions) became the default - most modern languages use PCREs for their regexs. There was some bad stuff that happened with this too - people used regexs for ghetto, half-assed versions of tree structures like HTML and XML - but for the task of chewing through Unix config files, up until around 2005 Perl was unbeatable because of the awesome regex support (and because it's history meant, at the time, perl was installed on all Unix boxes).
- garrettdreyfus 13y agoI first looked at perl last week and also shared your sentiment. At first when I saw perl I was aghast. The "ugly" $%@ syntax seemed pointless and unreadable. Then I decided to take a look at a non-beginner book, Intermediate Perl http://it-ebooks.info/book/879/ http://it-ebooks.info/book/879/. I was surprised and excited 50 pages in because I realized that Perl had a wealth of tricks , and that that "ugly" $%@ syntax actually had some cool repercussions. The other thing I noticed was that Perl's flexibility led to the ability to write code that was closer to how I would structure the command grammatically, for instance, "print x if x>5." I'm looking forward to learning perl further.
- Mithaldu 13y agoLet me point out http://perl-tutorial.org http://perl-tutorial.org because most books you'll find by simply googling are terribly outdated and teach, plainly put, how to write shitty perl. Modern Perl and Ovid's Beginning Perl (not the older Beginning Perl) are excellent books to learn from. Also a note about the sigil: Get a decent syntax highlighting set up for your editor and you'll quickly realize how nice it is to have functions, variables and different variable types colored differently.
- bonemachine 13y agoUnfortunately -- and this is one of the many "banana peels" in Perl 5 -- even a simple statement like print x if x > 5 is problematic in p5 for a whole bunch of reasons: (1) At a bare minimum, what you really need to say is: print "$x\n" if $x > 5; That extra "\n" is a definite turn-off to a lot of people when the get their very first look at Perl. Really, the default these days should be more "say"-like. Of course, "say" is there as of 5.10 if you know where to look for it, and you go out of your way to enable it: use feature 'say'; say $x if $x > 5; (2) In "modern", better practice, production-quality Perl you pretty much have to either hedge every comparison op with a check for defined-ness: use feature 'say'; say $x if defined $x && $x > 5; in order to head off an unsightly warning about $x not being initialized: Use of uninitialized value $x in numeric gt (>) at print-if.pl line 5. or add even more boilerplate to suppress the warning: use feature 'say'; { no warnings 'uninitialized'; print $x if $x > 5; } or be very attentive about how $x can mutate once it's gotten passed whatever validations you're imposing on it before it enters your scope -- via e.g. Params::Validate, Method::Signatures, provided you know these tools exist and are up to speed and hip as to how to use them effectively. (Yes, I know that in some contexts, the warning on 'uninitialized' can be very useful. But my point is, most of the time, and especially for novices, it's more of a misfeature). (3) We shouldn't gloss over the fact that the magical pseudo-grammatical construction the "infix" if syntax provides is itself problematic in many ways. In the current example, it simply isn't clear -- until you've become very comfortable with the language! -- if the original statement say $x if $x > 5; is or is not equivalent to the very similar construction $foo = $x if $x > 5; say $foo This is because it is by no means obvious as to which of the more "active" parts of the original expression -- either the "verb" (print) or the conditional (if) -- takes precedence. And unfortunately, it's not only possible, but terribly easy to "whip up" fare more volatile constructions like this in Perl 5. Various on this theme -- gotchas about print, conditionals, and complex "if/unless" constructions -- were of course given ample treatment in Perl Better Practices, to the point where (I believe) that Damian pretty much eschews "trailing" if/unless constructions altogether. (4) Lastly, it's sad to say that for all the complains of Python having too many safety belts and what not, it completely nails the hidden complexity management issues embedded in such a simple construct like Perl's "print-if" idiom. In Python, basically the only sensible way to achieve the original desired result is to do this: if x > 5: print x Perfectly clear, completely unambiguous, and basically impossible to screw up.
- ef47d35620c1 13y agoOld Unix sys admins made Perl special. Before Perl, they had to chain a bunch of sed, awk, grep, etc commands together or try to solve their problem in C. Both approaches were doable, but neither were ideal for the task. Perl was perfect for Unix scripting and sys admin tasks. From there, the rest is history.
- dded 13y agoOne of Perl's strengths, actually, was (is?) how well it was supported on many different types of systems. Today's world is largely Linux/Windows/Mac, but that was far less true in the 90s. I started using Perl on VMS, where there was no sed, (g)awk was new, no grep ("search" did not handle regular expressions, "find" did but arrived very late); and the command language, while sane, was very slow. Perl's system integration on VMS was excellent.
- loudmax 13y agoWhen I started working at AOL in 2002, I was given a list of commands and jobs to run manually on a Stratus VOS mainframe: http://en.wikipedia.org/wiki/Stratus_VOS http://en.wikipedia.org/wiki/Stratus_VOS It was tedious and lame (not necessarily Stratus' fault). But then I discovered that someone had ported Perl to VOS! And I was able to script my daily routine away.
- petercooper 13y agoPerl was my #1 language 1996-2004 and my answer for the period would be.. CPAN. It's easy to find great libraries for almost any language with traction nowadays, but back in, say, 2000, library availability and packaging was piss poor in languages like Python or Ruby. CPAN was full of great stuff, all reasonably well documented, and, the kicker, a lot of it had tests too.
- DougWebb 13y agoWith PHP, Python, Ruby and Javascript... space seems tight for another scripting language. That's an ironic statement, since Perl came first and was absolutely dominant in the domains which PHP, Python, Ruby, and Javascript now occupy. When they were young, it would have been reasonable to say that space seems tight for another scripting language because we had Perl. Languages like Lua have something special. What's special about Perl? What's special about Lua? That's a four-word question that could require a huge response. Lua's a nice little embeddable scripting language, but that's a niche that Perl has occupied too. It's got fantastic support for both being embedded (callable from other languages) and embedding (able to call other languages). You might say that Lua's better because it's smaller and cleaner and simpler, but that's only true until you run into Lua not being powerful enough for something you want to do. If you used Perl as your embedded scripting language instead, you probably wouldn't have that problem. (Other problems, maybe, but not a lack of power.)
- deleted 13y ago[deleted]