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

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

[jeremyp]

vi is the greatest Unix tool ever invented.

vi is the only remotely usable text editor that is guaranteed to be available on any Unix box. It's the lingua franca of Unix text editing.

vi is a bit bizarre for anybody coming from a graphical environment, but once you get used to it, it is as efficient and powerful as any other text editor with the exception of emacs, but life's too short to learn the bits that emacs does that vi doesn't.

Regular Expressions

[Laplace]

I think that you don't really understand the roots of regular expressions. However, you might be familiar with something called a finite state machine.

A finite state machine is essentially a set of rules that operates on a string. Given the current state and the input one travels to a new current state. The theory of finite state machines is integral to the development of computer science and has a very strong mathematical foundation. A computer language that can be represented by a finite state machine is called a regular language.

This is where regular expressions come in. They are essentially user constructed finite state machines. The input is the text, and the state is the curent symbol (or symbol set). If you match the current symbol, you move to the next. If you don't you go back to the beginning. If you reach the end of the symbol set, you have a match.

Regular expressions weren't made up to confound you, they were the implementation of a sound mathematical method that is very useful for text processing. However, regular expressions by themselves are not enough to form a Turing Machine, or even an approximation of a Turing Maching (which is what the computer sitting on your desk is).

Moving to more practical matters; regular expressions are not easy to read. You're working on raw characters, and you have to have lots of escaped to handle everything. They become easier with practice, and are very useful. The biggest problem with them is that every application (Perl, vi, emacs, grep, etc) use their own syntax for them, which means you have to shift gears every time you try to use them in a different application. But that is a problem with the implementation, and not the tool itself.

Re:Not a troll

[Art_XIV]

Well if you follow some rules it shouldn't matter what language you use :) Really though, difficulty reading a language is usually due to

1) lack of commenting (duh!)

2) being unfamiliar with a language

3) lack of organization (formatting code blocks)

I'd add a 4th, though it's related to the first:

4) Meaningless variable names.

I rue the times that I've maintained other people's code that was load with code like this:

temp = foo;

if (temp > = g) {

for (int x = 1; x > rst.length; x++ )
{

if (rst[x] &lt noid) temp -= .05;

}

}

What the????? What is temp? Clearly not the temperature, since this is a financial application. Is it really that freakin' much harder to write something like:

newInterestRate = STANDARD_RATE;

if (interestRate > = cutoffRate) {

for (int x = 1; x < possibleRates.length; x++ )

{

if (possibleRates[x] < THRESHHOLD) newInterestRate -= .05;

}

}

BTW, sorry for using pseudo-java as a ferinstance.

great point

[Preposterous Coward]

I find this especially baffling given that most prolific programmers are also pretty decent typists, so I don't understand why it's so hard to use variable and function names that are a bit longer and more descriptive.

My guess is that many programmers haven't had enough painful experience maintaining crappily-written code. Maybe the first thing that should be taught in CS 101 is not how to write "hello, world", but how to take a poorly documented and convoluted program written by somebody else and fix the bugs. (No flames about how CS is about computer science not programming; you know what I mean here.)

For me personally, the incentive to write more self-documenting code was having to maintain stuff I'd written and deployed in commercial environments for a period of years. I don't care how well you knew the code when you wrote it, when your customer unearths some obscure bug in five years' time you're not going to remember a damn thing. And that is a miserable experience. It taught me to take the time up front to save myself the agony down the line.