Damian Conway On Programming, Perl And More

Andrew writes: "My host pair.com has an interview with Damian Conway in which he talks a lot about his upcoming modules, and what skills a Perl programmer needs. I'm personally waiting on Parse::FastDescent." Conway talks about some interesting modules he's working on, Perl 6, and on programming in general, too.

Comments

Conway is a Madman, the proof...

[thelen]

Current projects:

1. "Parse::Perl. Just as the name says, its goal will be to provide a pure Perl parser that parses Perl itself."
   
   
2. "I'll soon be releasing the infamous Lingua::tlhInganHol::yIghun module, so that people will finally be able to program perl in the original Klingon!"
   
   
3. "I often find myself developing right in my editor. In fact, I have a key permanently bound to ":!perl -w %" under vi for just that reason."

Good God, vi?!

Re:Conway is a Madman, the proof...

[yatest5]

vi is the greatest thing on earth. nothing beats the fun factor of typing the 'replace the next 500 characters with' command and watching your fellow developer crap all over his code the next key they press and the ensuing panic. You'd think this would only work once - but ohhhh no.

What's this guy on?

[tunah]

I want to teach it to ... convert adjectives (e.g. "happy" or "good") to adverbs ("happily", "well"), take an adjective (e.g. "happy" or "good") and generate comparative ("happier", "better") and superlative ("happiest", "best") forms, etc., etc.

By which of course he means good, gooder or goodest. Damn intellectuals.

Units

[tunah]

I'm also contemplating a module called Data::Units, which will allow programmers to specify the units for values and variables... So, if you divide a distance by a time, you'd better store the result in a variable whose unit is velocity, otherwise you'll get a run-time exception. That can be a very useful and natural way of error-checking numerical computations.

And if you divide a sibling variable by a knife variable, perl will have none of that mess, you'll have to garbage collect the mess yourself.

Re:Units

[radja]

send it to NASA before they send the next sat to Mars...

//rdj

Re:Software as Art?

[igorwawrzyniak]

According to Larry Wall, it's quite easy to be a good programmer. Here is a quote from The Camel Book:

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.

Re:Because Perl can be tough for teams

[EvlG]

The problem I see with Perl is a management problem. Everyone complains that Perl produces bad code, but in reality, programmers produce bad code. By our very nature as human beings, we all think differently.

I agree Perl provides a lot of freedom to solve problems in the way most suitable to you. However, to use Perl successfully, you still need to set standards for acceptable algorithms, approaches, and documentation. This is exactly what you would do in Java, and exactly what you would do in C++ (i.e., by saying no templates/operator overloading).

I'd argue that such standards are necessary for any significant development effort - its just the nature of the beast, when trying to get multiple people to work together to tackle a problem.

So how do you use Perl effectively in a structured environment with teams of programmers working together? Here's a few ideas:

1) Code reviews. All code written for a team msut be reviewed by the team. This is absolutely essential to keeping the system functioning. If the team rejects it, the code must be fixed.

2) Documentation. Perl provides POD, a simple and standardized way to document the code you write. Enforce a standard that code without *meaningful* POD is not acceptable.

Note that documentation also means you need to document more than the code - you need to document the design decisions, the requirements the code tries to satisfy, and the assumptions made for the system as a whole. Without proper system/process documentation, a development project will fail.

3) Create standards for acceptable approaches to solve the problem. For example, Perl provides eval for exception handling - you could mandate that all external error handling code make use of eval to keep error detection orthogonal to error handling. You could (and should) require team members encapsulate code in modules, and provide documented interfaces to those modules. Code not encapsulated in a module will not be accepted into the tree.

There are only a few examples to illustrate ways to make development in Perl successful for your organization. These are the same problems you tackle in developing a sizeable project in any language with a team of programmers - Perl is no different, and is not a panacea for those problems. However, if standard management and structured development techniques are applied, developing in Perl can (and will) work for large organizations.

Perl is no different from any other technology in this regard. that for a large project, it is essential to set standards

Re:I really don't get it

[Mtgman]

Someone showed me Perl and inside a week I was writting (badly but still writting) a message board. It took me weeks, it was horrid but it worked

CmdrTaco? Is that you?

Steven