9 ms·
Is there a reason to learn Perl these days when we have Python?
by mikevm 11y ago
Is there a reason to learn Perl these days when we have Python?
- webkike 11y agoPerl 6 is extremely cool.
- gricardo99 11y agoThis book is for Perl 5
- awwaiid 11y agoIndeed. But the book is about Perl5. Perl6 is such a different language that someone moving from Perl5->Perl6 will likely be mostly/completely a rewrite. ... unless, I suppose, they are following the practices in Modern Perl ala Moose and some other things. I guess maaayybbeee they could translate across. But it would be touching ever single line, in a transformation that would be on par with switching to Ruby (or Python I suppose).
- somebehemoth 11y agoIt seems disingenuous to imply that moving to Perl 6 from Perl 5 is akin to switching to Ruby or Python (much less "touching every single line"). Perl 6 supports Perl 5 syntax with Inline::Perl5. So, in theory, one could move Perl 5 code directly into a Perl 6 project without changing much at all. Edited: an earlier version of this comment that referred to an outdated FAQ (mentioning a perl 5 to 6 translator).
- chromatic 11y agoThat page looks almost six years out of date. I believe the project to which it refers has bitrotted.
- somebehemoth 11y agoYes, I updated my comment, but my point still stands: Perl 6 supports Perl 5 syntax and migrating is nowhere near as hard as was implied. Sorry for confusion.
- ribasushi 11y agoYour comment is still blatant disinformation. By the same measure Perl6 is also Python and Java and JavaScript, because somebody could make an Inline:: for any of those. You could say that a number of hooks exist to make it easier to write various Inline:: variants, and you would be correct. But claiming that there is a special soft spot for the Perl5 interpreter is factually wrong.
- somebehemoth 11y agoWhat disinformation? Perl 5 is supported when using Perl 6. The comment I replied to states: "Perl6 is such a different language that someone moving from Perl5->Perl6 will likely be mostly/completely a rewrite." Rewriting is not always necessary due to Perl5 support. The comment further states: "I guess maaayybbeee they could translate across. But it would be touching ever single line, in a transformation that would be on par with switching to Ruby (or Python I suppose)." Touching every single line is technically not necessary due to Perl 5 support. To your comment: "But claiming that there is a special soft spot for the Perl5 interpreter is factually wrong." Nowhere in my comments did I make any such claim. I was simply refuting the statement that people with Perl 5 code will have such a difficult time with Perl 6 that it would be just as painful as dropping all their Perl code and switching languages.
- mst 11y agoAlthough to switch to ruby or python you'd likely end up either typing out a lot of things Moo(se) give you or trying to port them (see also the MooseX gem and Elk)
- chromatic 11y agoIn my case, I find the Moose ecosystem much preferable to almost any other OO system I've used. Better multidispatch would put Moose over the top. The last time I looked at Python 3, Perl still had much better Unicode support. In particular, grapheme support in regexes, built-in casefolding, and easy normalization made a 100+ country project much easier. The stability of the language, core libraries, and CPAN modules across major releases really helps with maintenance. Python's 2/3 break was a bummer for a lot of people for a long time that I'm glad to have (mostly) avoided.
- s_kilk 11y agoWhat's your take on Perl6? And do you plan to update the book to cover Perl6 some time in the future?
- chromatic 11y agoI have no plans to use P6. It's probably years away from having the ecosystem sufficient to support what I personally want. I have no plans to update the book to cover P6; I think it does what it needs to do as it is now.
- systems 11y agoI'd bet Perl6 ecosystem will evolve very fast, I don't think you will need to wait several years
- edibleEnergy 11y agoAnything that evolves fast also will have stability issues. Part of the draw of CPAN is the stability that comes from mature codebases.
- s_kilk 11y agoI hope so. It's pretty bare at the moment, but it shouldn't take too much to get it to where, say, Go-lang was when people started to adopt it in earnest.
- oalders 11y agoAt the very least, the fact that we have Python does not make Perl irrelevant.
- cwyers 11y agoNo, but the multiyear period where Perl 5 development stalled waiting on Perl 6 and much of the community moved on might.
- actsasbuffoon 11y agoYeah, fortunately nothing like that is going on with Python. P.S. That was intended as VERY light-hearted ribbing, not as a snide remark.
- s_kilk 11y agoLong-time Python dev here, recently started picking up Perl (both 5 and 6). As with anything, learning another language will give you insight into how things _could_ be done, and you'll pick up a new perspective on programming. More concretely, I've been liking perl because it's much more expressive than python, especially when writing small unix-y programs or scripts to control the machine. And of course, sometimes it's just nice to have a variety of tools in your toolbox. We may as well ask whats the reason for learning Python when $LANGUAGE exists. The answer is always going to be some variant on "just because".
- mattbillenstein 11y ago"more expressive" is often a slippery slope to "I can't read and understand what I wrote 3 months ago" We read code more than we write it, so optimizing for typing time vs reading time is just losing the war to win the battle IMHO.
- DougWebb 11y agoI think you misunderstood what "more expressive" meant. It doesn't mean "more concise", though Perl can excel at that too. It means that expressions can be stated in more meaningful ways. do_the_thing() if $is_ok; warn_the_user() unless $is_ok; The if/unless pair, along with the ability to put conditionals either before or after the statement to execute, is just one example of Perl's ability to be very readable.
- chrisseaton 11y agoIf we're honest with ourselves these discussions are never really about anything more than taste and have almost no technical foundation, but with that said I don't think the trailing conditional is more readable. In the rest of Perl the order in the text of an action normally indicates the sequence of the side effects, but here the first thing to be executed is after the first thing in the text.
- DougWebb 11y ago
- ergothus 11y agoI started as a Perl dev, and I must say that some of the principles I learned there that I still feel are underutilized in other languages even though the syntax could support them. I think the very nature of Perl meant that I had to learn additional tricks to make the code make more sense when I returned 6 months later...tricks that I wish other languages embraced. Having your code not be obscure is the minimum, not the maximum you should be shooting for. Also - I'd still write short scripts (basically glorified one-liners) in Perl vs Python. JS is getting up there, but still isn't as expressive as Perl. Edit: And I say this with full respect for other languages, particularly Python that has done a lot for many areas of development
- ionforce 11y agoWhat are some of these principles that you've learned?
- ergothus 11y agoHmm...hard to put into words. But here are some examples: Perl often gets flak for "There's more than one way to do it", and sometimes that's justified: It's confusing to do things a billion different ways. BUT, sometimes you can use those different ways to be meaningful. So: foo() unless (condition) vs if(!condition){ foo() } They are FUNCTIONALLY the same, but COMMUNICATE differently. If you don't pay attention to the latter, then TIMTOWTDI will be an enemy. If you do, then it can really help. Also: "not", "and", "or" - I wish more languages had these. && and || might seem to be the same thing, but there's no reason to cling to foreign symbols where native (for english speakers) symbols do the same. ! is particularly bad, since it's so small, can easily blend in to an adjacent paren, and yet REVERSES the meaning. Don't get me started on the terrible switch/case syntax that is perpetuated for no reason other than C did it. Moving away from syntax, hashes/dictionaries/associative arrays/Js objects, these guys all have the same basic addressing style. If you're using them in a context where the key will almost always be present, why not use that? instead of addresses[currentAddress] use address_of[current] (or addressOf[current] Instead of building variable names that are 4-5 camelCase words, use the hierarchy of your structures to communicate more clearly. variables are WORDS. Too few words doesn't communicate clearly, but too many is just as obtuse. There are a great many "clean" bits of code out there - nicely structured, nothing wrong, but I'll still have to read the whole to understand a part of it. Similar to the semicolon argument: The reason I object to dropping semicolons is not that the statement needs it - but that I need to read the next statement to retroactively know if the statement needs it. If you can write code so that a reader understands what is happening as they read, rather than understanding the whole and then viewing the parts in that context, your code becomes that much more maintainable.
- MichaelMoser123 11y ago> Is there a reason to learn Perl these days when we have Python? Yes, the GIL - global interpreter lock (in python) is a reason if you are doing multithreaded stuff in a scripting language (which i think is a bad idea by definition because suddenly you are debugging problems in your program as well as the interpreter/runtime) Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.
- bbatha 11y agoLet's not pretend perl threads solve concurrency issues in dynamic languages. The third item in the threads perldoc, after the table of contents and the version, is a big, fat warning about how you shouldn't use them [1]: > The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help. >The use of interpreter-based threads in perl is officially discouraged. > Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example. Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. Also most of the librarys that use perlxs modules aren't thread-safe. [1] http://perldoc.perl.org/threads.html http://perldoc.perl.org/threads.html
- MichaelMoser123 11y ago> Let's not pretend perl threads solve concurrency issues in dynamic languages i didn't 'pretend' that - that's a misstatement; still a big fat lock in the interpreter isn't a concurrency solution at all, instead of running concurrently your threads will be mainly blocked on the lock. Interpreter threads is an approach that does without a global lock, but as i said it is still a pain to debug the result - as you are effectively debugging both your program and the runtime. > Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. threads are not copy on write processes; that is not unique to perl threads. The advantage of threads is that it makes easier to share data - with processes you will need to do a shared memory segment for that. Also it is less costly to create a thread rather than a process.
- yarrel 11y agoYes. I use Python usually but Perl is simply faster at processing large amounts of text. And while Python has made great strides in regex readability since the 90s, Perl's regexes are still more cleanly and flexibly incorporated into the language.
- kafkaesq 11y agoNot really. As in, I wouldn't start from zero and try to learn enough to get a day job at it, at this stage. There are still so many negative tradeoffs in Perl 5 -- especially, and most crucially, for new adopters -- that I don't think it will ever make up the ground it has steadily lost to Python/Ruby/PHP over the last 15 years. P6 has addressed many of P5's most notorious faults, while perpetuating others, and quite likely introducing a whole family of newer, far subtler traps and pitfalls. All while being not particularly fast, poorly document (last I checked -- about a year ago), and like Perl 5, just plain.... zany. That said, there are a lot of incredibly bold -- we might even say, "ahead-of-their-time" ideas in Perl 6 (just as there were in Perl 5, in its time), and I sincerely hope many of these will be carefully studied -- and I won't be surprised if some of them are incorporated to whatever "lingua franca" that ultimately emerges and ends up burying Python, hopefully not too long from now.
- irishcoffee 11y ago> incorporated to whatever "lingua franca" that ends up burying Python, hopefully not too long from now. Sincerely, at this point (Dec 2015) I feel like python is well too far along to be buried. As you state, if something better comes along I too would welcome it, but, and correct me if I'm wrong, python has been around for 20+ years, I don't see it being buried anytime soon.
- krylon 11y agoPersonally, I use Perl for small-ish programs (roughly less than a thousand lines, counting comments and long text constants such as SQL queries) dealing mostly with text, and in that area it is fairly hard to beat. Also, while Python's library ecosystem has grown a lot over the years, in Perl you can find so many modules on CPAN, ranging from very common tasks (like talking to a database / ldap directory / network service) through fairly exotic (at least in my perception: e.g. formatting datetime values in just the right way to feed them to MS SQL Server, figuring out if a given day is a holiday in a given federal state of Germany) to downright silly (but in a clever way: CPAN's ACME::* branch). You think of it, CPAN probably has it. One thing I have grown to appreciate about Perl is its mentality of helping you getting the job done no matter what. Python is a - relatively - clean and simple language, where Perl is not ashamed to be messy, but it's oh-so-useful I just cannot stay mad at it. ;-) Last but not least, the Perl community is awesome, there are so many friendly and helpful people around willing to share insights, code, and words of encouragement. (That is not to say other languages have bad communities, not at all!)
- smonff 11y ago> One thing I have grown to appreciate about Perl is its mentality of helping you getting the job done no matter what. It is incredibly effective at helping prototyping rapidly small ideas. > the Perl community is awesome, there are so many friendly and helpful people around willing to share insights, code, and words of encouragement. And CPAN helps a lot too! It can be considered as an important part of what makes this community so special, it is a very serious repository of modules, I mean not only code: it is incredibly usable, with lots of documentation and a crazy test infrastructure (http://www.cpantesters.org/ http://www.cpantesters.org/) that helps to build quality distributions. The good thing with the Modern Perl book is that, before explaining the language itself, it explains the Perl philosophy. And then it explains about the community and the CPAN. Being modern is also about not writing code and re-using long-tested modules from CPAN with cleans APIs: it helps to compose quality code and make maintenance easier.