I'm snipping a lot of the old stuff since it's getting rather large.

On Mar 6, 2011, at 11:06 , Robert Nesius wrote:

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

See, that's where I disagree though.  I also write C/C++ and (*sob*) C# .NET code professionally and both of those require a fair bit of effort to keep them clean too.  At work, all of the C++ and C# code goes through Style Cop which performs the same functions that Perl Tidy and Perl Critic do.

Ruby and Python aren't exempt from this.  I would argue that while its still a tad bit easier to make nasty code in Perl (if you don't use strict), its as easy in Ruby.  I've seen some... interesting code in Python so that isn't really exempt, but it is a hell of a lot better than Perl.

I think part of Perl's problem is that it is a hackers language, and as such, brings those people to the table.  I know I'm self taught and got my degree years later, and if I look at my Perl before I started school and finally realized the importance of readable code, I can barely read it.

Its easy to knock Perl because it has things like pointer dereferencing and those $, @, and % characters for types which vex newbies so much, but I think more blame lies on the programmer writing the code than the language itself.  In my experiences, there are a lot more crappy programmers out there than there are good ones.

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

Sort of.  IIRC, Ruby was kind of a language that was made just because the author wanted something with the power of Perl but also with the power of Smalltalk.  I believe there was also some animosity between Wall and Matsumoto academically but I don't know the authenticity or details of that.

Python is its own beast, and it was a development of ABC.  Both Perl and Python have tried to emulate one another over the years (Perl is only 2 years older than Python, although Python was first publicly released in 1991).  The big difference with Python was that it was OO and I think that's why it didn't catch on until much later.

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

Yeah, but both Python and Ruby had been around for a while.  Python was pretty much equal to Perl at the time too.  I think it was just good marketing on both Python's and Ruby's part.  Perl 6 was taking too long and both Python and Ruby saw the opportunity.

> 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?

Maturity and CPAN.  I've found both Ruby and Python difficult languages to find good reliable third-party modules/libraries that I feel are good enough to be used in production code.  Python less than Ruby... there are of course exceptions here, there are plenty of great modules for both of those languages.  Its just that CPAN has gotten so mature that its much more difficult to find a bad module out there.

So really, my stance is why wouldn't you use Perl?  Its stable, it finally has releases coming out again, and most of all its mature.  Python and Ruby are almost as old as Perl and still aren't as close to being mature as Perl is.

> 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?  

DBIx::Class is pretty slick these days.  I like the flexibility it offers over ActiveRecord and Django, but I have a colleague who would argue with me to no end saying that the Django model system is better.  Ultimately I think all three of them are as powerful as the other; none of them really shines above the other.

> 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 

Indeed.  I don't believe it covers Moose though, and most OOP code you find these days uses that system.  Its still good to know however so you know how the native OOP stuff works in Perl.

-A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20110306/81af31dd/attachment.html>