On Sun, Mar 6, 2011 at 8:21 AM, Adam Morris <adam.morris at redstargaming.net>wrote: > On Mar 6, 2011, at 0:07 , Robert Nesius wrote: > > > > On Sun, Mar 6, 2011 at 12:01 AM, r j <ronsmailbox5 at gmail.com> wrote: > >> I am really enjoying learning Perl right now and I love the array and list >> operators. >> After using python for a while I am finding its not so hard to say there >> is more than one way to do it. >> The ease in making a list of elements is cool (1...100); >> and using @ to make a list @giant = 1...1e5; >> The generate word list it nice as well gw< this list of words > >> Cool :D >> What are some of your favourite language elements to get work done ? >> ,Ron >> >> > Hi Ron, > > On the one hand I applaud your ability to step outside of Python and > appreciate something different. On the other hand here's what a friend of > mine had to say about Perl after developing in it for 10+ years and then > finally moving to Python. > > "Ten years of Perl man. That shit rots your brain." > > As someone who also spent 10 years+ maintaining perl distros and debuggin > legacy perl scripts, I have no option but to agree. > > Enjoy your time with Perl, but .... don't deploy anything into production > if you don't have to. Those who come after you and maintain your code will > thank you for it. > > -Rob (who is migrating from Perl to Ruby, with an eye on Python as a > possible end-game beyond Ruby). > > > As someone who writes production both Perl and Python code professionally > (10+ years), this is one of the biggest things I see and disagree with on a > normal basis. You *can* make very clean looking Perl code. Perl Tidy > helps with this a lot, and forcing people to use a post-modern object system > like Moose provides helps even more. Add in a requirement that everyone > runs perltidy and perlcritic before they perform a check-in and you've got > some code that you can show to Mom. I've actually seen cleaner Perl code > than Python code on a frequent basis. > > That said, Perl makes it a *lot* easier to make really ugly looking code. > There are many Perl programmers I've met over the years who seem to think > they know more than Chronic and Conway when it comes to best practices and > that's both frustrating and unprofessional. In my experiences Legacy code > is riddled with this, but running it through perltidy usually helps when > you've got to maintain something. > Adam nailed it, and everything he said is true. There is a bit of subjectivity here, but really it comes down to how you look at it. Adam looks at the above points - and concludes "Perl's a reasonable language to work in." For some people that's true, but I think those preconditions he listed point to a lot of risk. * Everyone runs perltidy. * Everyone runs perlcritic * Warnings on? * Use strict on? * Do you know the idiomatic best practices? Add to that some other considerations... * Object oriented functionality was bolted onto perl after the fact * Scalar vs. array-context considerations can cause a lot of unexpected things to happen * I never enjoyed de-referencing pointers in perl. Anyway, take all of the above and Andy is saying "See. You can get there." And my point is "Look at everything you need to do to get there. While you can write atrocious code in Ruby or Python, it's not as easy to do as it is in Perl, and conversely it takes more effort in Perl to get to elegant, clean code." That's really what it boils down to for me. My (possibly incorrect) view of Ruby and Python is they are refactorings of Perl. Both languages stepped back to the language design phase and tried to make a better dynamically typed interpreted language with object-oriented programming paradigms integrated from the ground up and I think they both are improvements. When I first started going to OSCON back when it was still the "Recently Renamed Perl Conference", Perl ruled the day. There were 15 bajillion books on perl, and nearly all of the conference talks about "cool stuff I did" were perl modules. On top of that Damien Conway is not just a "God of Perl", he's a "God of Presentations" and watching him do a talk makes you think "If I could get to his level, I could build my own light sabre.... in Perl!" :) But O'Reilly book sales figures tell the tale.... Perl book sales - drastically down. Python and Ruby book sales - dramatically up. Perl 6 is partly to blame for that, imho. It was announced with much fanfare, never arrived, and people got tired of waiting for the Perl Gods to deliver a better a perl because someone did it faster by delivering Python and Ruby. It really boils down to the standards and practices you or your company > implements. If you're using Perl for system administration tasks only, well > I think all bets are off unless you police yourself. If you're using it for > an actual application using a framework like Catalyst though, I know from > experience its easy to make the code clean and readable. > I think it takes far more effort and expertise to write "good, maintainable Perl code" and given the other improvements in the design of Ruby and Perl - why bother? > Back to Ron's question. My favorite element of Perl is CPAN and the > maturity of the packages these days. You can find some excellent modules > out there, such as the Moose Post-Modern Object System, Catalyst, and pretty > much anything else you'll ever need. > CPAN is pretty awesome. I'd also point any budding programmer to the Data::Dumper module, which will help you visualize your arrays of hashes of hashes and figure out where you're messing them up. Because you will mess them up. Btw, you better like #'s, $'s, and {}'s, and @'s because you're going to overdose on them. And that... is the brain-rot factor for me. :) I don't know what ORDM's look like in Perl these days? Are they as nice as ActiveRecord or Python's equivalent? > > Also, get a copy of Perl Best Practices now and read through it. It'll > help you out a lot in the long run. > I've also heard Damien Conway's "Object Oriented Perl" book is exceptionally well written and a worth-while read for both perl and non-perl programmers. -Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20110306/6a9b5e5b/attachment-0001.html>