Slashdot Mirror

http://modernperlbooks.com/boo...

Perl objects aren't great (it isn't really and OO language)

Efforts are being made to improve them. Have a looke at Modern Perl and what it proposes about objects.

Good stuff on other matters too. I even discovered there a very interesting use of goto to make a tail call elimination, something that's still unavailable in Java. Of course, this being goto, I have a psychological blockade to actually use it, even though I know that Perl's goto is far more sane than BASIC's.

Perl objects aren't great (it isn't really and OO language)

Efforts are being made to improve them. Have a looke at Modern Perl and what it proposes about objects.

Good stuff on other matters too. I even discovered there a very interesting use of goto to make a tail call elimination, something that's still unavailable in Java. Of course, this being goto, I have a psychological blockade to actually use it, even though I know that Perl's goto is far more sane than BASIC's.

The Joel Test: 12 Steps to Better Code by Joel Spolsky

I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. [...] The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

1. 1. Do you use source control?
2. 2. Can you make a build in one step?
3. 3. Do you make daily builds?
4. 4. Do you have a bug database?
5. 5. Do you fix bugs before writing new code?
6. 6. Do you have an up-to-date schedule?
7. 7. Do you have a spec?
8. 8. Do programmers have quiet working conditions?
9. 9. Do you use the best tools money can buy?
10. 10. Do you have testers?
11. 11. Do new candidates write code during their interview?
12. 12. Do you do hallway usability testing?

Perl Shop Maturity Checklist: Technical Concerns by chromatic

• Do you use source control?
• Do you stage deployments? Do you have a defined process for deployment? Do you have a defined process for rolling back a failed deployment?
• Do you have code that "no one knows what it does"?
• Do you have critical business code written more than five years ago that people are afraid to touch?
• Do you have coding standards? Does most of your code follow it?
• Can you tell who wrote each piece of code by its style?
• Do you have a standard technology stack? Across multiple applications?
• If some applications don't meet it, do you have plans to refactor them? Do you refactor at all?
• Do you have a defined process for handling bugs? ... for handling feature requests? ... for scheduling delivery?
• Do you have a training or mentoring process?
• Do you have multiple developers? Can you retain developers for longer than one year? Five years?
• Do you use automated tests? Do your tests all pass? ... before you check in? ... before you deploy?
• Do you have backups? ... for servers? ... for developer workstations? ... and do you test them regularly?
• Are developers their own system administrators?

In short, how predictable is your development process? Can you manage risk? Do you? When surprises happen, how much work is it to recover?

Perl Shop Maturity Checklist: Social Concerns by chromatic

• Do you have a coding competence test when hiring? Does it include real code? Did your developers have a hand in writing it?
• Do you have code reviews? Before deployment? Before merge?
• If you have multiple developers, do they all have access to every piece of code you have?
• Do you pay a prevailing developer wage for your region? ... commensurate with experience?
• Do you have overtime? ... required?
• Do you allow telecommuting? ... part time? ... full time?
• Do you have a training budget? ... for books? ... for travel?
• Do you have well-defined roles? ... technical leadership roles? How do you resolve conflicts?
• Do you have a defined process for scheduling features? ... triaging bugs? ... resolving schedule conflicts?
• How do you handle surprises?

Perl Shop Maturity Checklist

The Joel Test: 12 Steps to Better Code by Joel Spolsky

I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. [...] The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

1. 1. Do you use source control?
2. 2. Can you make a build in one step?
3. 3. Do you make daily builds?
4. 4. Do you have a bug database?
5. 5. Do you fix bugs before writing new code?
6. 6. Do you have an up-to-date schedule?
7. 7. Do you have a spec?
8. 8. Do programmers have quiet working conditions?
9. 9. Do you use the best tools money can buy?
10. 10. Do you have testers?
11. 11. Do new candidates write code during their interview?
12. 12. Do you do hallway usability testing?

Perl Shop Maturity Checklist: Technical Concerns by chromatic

• Do you use source control?
• Do you stage deployments? Do you have a defined process for deployment? Do you have a defined process for rolling back a failed deployment?
• Do you have code that "no one knows what it does"?
• Do you have critical business code written more than five years ago that people are afraid to touch?
• Do you have coding standards? Does most of your code follow it?
• Can you tell who wrote each piece of code by its style?
• Do you have a standard technology stack? Across multiple applications?
• If some applications don't meet it, do you have plans to refactor them? Do you refactor at all?
• Do you have a defined process for handling bugs? ... for handling feature requests? ... for scheduling delivery?
• Do you have a training or mentoring process?
• Do you have multiple developers? Can you retain developers for longer than one year? Five years?
• Do you use automated tests? Do your tests all pass? ... before you check in? ... before you deploy?
• Do you have backups? ... for servers? ... for developer workstations? ... and do you test them regularly?
• Are developers their own system administrators?

In short, how predictable is your development process? Can you manage risk? Do you? When surprises happen, how much work is it to recover?

Perl Shop Maturity Checklist: Social Concerns by chromatic

• Do you have a coding competence test when hiring? Does it include real code? Did your developers have a hand in writing it?
• Do you have code reviews? Before deployment? Before merge?
• If you have multiple developers, do they all have access to every piece of code you have?
• Do you pay a prevailing developer wage for your region? ... commensurate with experience?
• Do you have overtime? ... required?
• Do you allow telecommuting? ... part time? ... full time?
• Do you have a training budget? ... for books? ... for travel?
• Do you have well-defined roles? ... technical leadership roles? How do you resolve conflicts?
• Do you have a defined process for scheduling features? ... triaging bugs? ... resolving schedule conflicts?
• How do you handle surprises?

Perl Shop Maturity Checklist

The Joel Test: 12 Steps to Better Code by Joel Spolsky

I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. [...] The bummer about The Joel Test is that you really shouldn't use it to make sure that your nuclear power plant software is safe.

1. 1. Do you use source control?
2. 2. Can you make a build in one step?
3. 3. Do you make daily builds?
4. 4. Do you have a bug database?
5. 5. Do you fix bugs before writing new code?
6. 6. Do you have an up-to-date schedule?
7. 7. Do you have a spec?
8. 8. Do programmers have quiet working conditions?
9. 9. Do you use the best tools money can buy?
10. 10. Do you have testers?
11. 11. Do new candidates write code during their interview?
12. 12. Do you do hallway usability testing?

Perl Shop Maturity Checklist: Technical Concerns by chromatic

• Do you use source control?
• Do you stage deployments? Do you have a defined process for deployment? Do you have a defined process for rolling back a failed deployment?
• Do you have code that "no one knows what it does"?
• Do you have critical business code written more than five years ago that people are afraid to touch?
• Do you have coding standards? Does most of your code follow it?
• Can you tell who wrote each piece of code by its style?
• Do you have a standard technology stack? Across multiple applications?
• If some applications don't meet it, do you have plans to refactor them? Do you refactor at all?
• Do you have a defined process for handling bugs? ... for handling feature requests? ... for scheduling delivery?
• Do you have a training or mentoring process?
• Do you have multiple developers? Can you retain developers for longer than one year? Five years?
• Do you use automated tests? Do your tests all pass? ... before you check in? ... before you deploy?
• Do you have backups? ... for servers? ... for developer workstations? ... and do you test them regularly?
• Are developers their own system administrators?

In short, how predictable is your development process? Can you manage risk? Do you? When surprises happen, how much work is it to recover?

Perl Shop Maturity Checklist: Social Concerns by chromatic

• Do you have a coding competence test when hiring? Does it include real code? Did your developers have a hand in writing it?
• Do you have code reviews? Before deployment? Before merge?
• If you have multiple developers, do they all have access to every piece of code you have?
• Do you pay a prevailing developer wage for your region? ... commensurate with experience?
• Do you have overtime? ... required?
• Do you allow telecommuting? ... part time? ... full time?
• Do you have a training budget? ... for books? ... for travel?
• Do you have well-defined roles? ... technical leadership roles? How do you resolve conflicts?
• Do you have a defined process for scheduling features? ... triaging bugs? ... resolving schedule conflicts?
• How do you handle surprises?

Perl Shop Maturity Checklist

So, um, why are you manually decoding query parametres in URLs in Perl? Have you not heard of CGI.pm or any of the dozen frameworks that do the thing for you?

Yes, I know it's fun to quote a regexp and the $_ convenience variable when trying to highlight Perl's potential illegibility, but let's see that code segment in Ruby:

def decode_query_string (query)
  query.tr!('+', ' ')
  query.gsub!(/%(..)/) { |s| [ $1.to_i(16) ].pack("c") }
  return query
end

Much clearer, no? How is that written in Python?

May I recommend you read Modern Perl, the (free) book, that succinctly describes the language?

Can some /.er point me down the path toward modern Perl learning?

I have a bias, but I've had many positive responses to Modern Perl: The Book.

Perl 6 is still being worked on, but it's more of a proving ground for new features and new ideas. It'll be ready when it's ready. Meanwhile, many of the good ideas from Perl 6 have made their way into Perl 5 releases. Useful things such as Moose, smart matching, and other things. Hopefully others will reply with more details.

But has there really been that much real effort in the PERL community?

Yes:

http://www.modernperlbooks.com/
http://perl-begin.org/tutorials/modern-perl/

"I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent."

It's a shame that this 'Osborne effect' has hung over Perl for the last decade. I wonder how Perl 5 would now be perceived if Perl 6 had been given a different name and announced as a research project into language development, rather than the next version of Perl? With better PR, Perl 5.10 could easily have been 'Perl 6'.

All this tends to obscure the quet evolution of Perl 5 programming into what 'chromatic' and others are calling 'Modern Perl', using an idiomatic style that takes full advantage of recent language features (some borrowed from Perl 6) and CPAN to write efficient and maintainable code:

http://www.modernperlbooks.com/
http://onyxneon.com/books/modern_perl/

As always, a lot of the most active development is happening outside the core language. Anyone interested in some of the directions Perl 5 is going in today ought to check out projects like these:

http://www.iinteractive.com/moose/
http://plackperl.org/
http://www.catalystframework.org/
http://mojolicio.us/

If you want to explore a new language and don't mind getting your hands dirty (and for the next several releases, reporting a few bugs), Perl 6 can be great fun.

If you have a project in mind you want to deliver as soon as possible, Perl 5 is a powerful, capable language especially if you take advantage of the CPAN.

Hopefully my camel book will be sufficient to learn both from a basic level.

The most recent Camel is ten years old. Rakudo Star comes with a book on Perl 6. You can also read my Modern Perl draft book for an introduction to the current versions of Perl 5.

... if Perl did not have such sclerotic leadership as to fritter an entire decade away on linguistic games with themselves.

I trade most milestones in the Perl renaissance directly to Perl 6.

(Sclerotic? If that's the word you intended, the metaphor is... difficult.)