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

Difficult climate

[ArcSecond]

And it's the skills to do that -- analysis, design, coding, object orientation, structured programming, design patterns, unit testing, extreme programming, documentation, communication, teamwork, etc. etc. -- that makes someone marketable in today's difficult climate

I suppose he's talking about the post-dot-bomb world we live in, but these are probably important at any time. Funny, though: a majority of programmers I've known--while intelligent and relentless--place less emphasis on the "documentation, communication, teamwork" skills. Of course, that's where technical writers and project managers come in handy... (heh heh)

One thing I've noticed about Perl people is that they are often very open-minded about using other languages to solve a problem. Maybe it's because they are so used to losing the "let's develop in Perl" argument, maybe because they are more naturally inclined to use every tool available, or maybe it's because they want to figure out a way to parse every computer language known to humanity from within a Perl module...

scary code? hope you're not open sourcing

[mattr]

You can be artistic or even create artworks with anything.. although I once found visual basic to be a big impediment.

If you have ever heard of an elegant mathematical proof or an elegant bit of code, this is something like what "artistic" is. It also could mean efficient, clear, etc.

I think you need to differentiate between
- traditional artworks like maybe oil paintings
- artworks which use digital media in some way
- making a statement with/through art
- craftsmanship
- intellectual and visual elegance i.e. of design

Hypercard? Yes, blech. But I hope you think about elegance or craftsmanship at least if you are turning your code out to the public.

We need more elegance in open source code because it tends to 1) make work fun/creative 2) make it run efficiently 3) reduces bugs 4) strong metaphor makes paradigm more powerful/extensible.

Discipline in art is independant of the medium

[Crag]

It's true that individualistic programing styles can slow down a project, and it's true that perl allows almost infinite programming style, or lack of same. However, the two issues are orthogonal, and Perl itself is not bad for cooperation. Just ask the CPAN developers.

Next, 'programming' is not the same as 'coding'. Programming has come to mean all the terms the author of the above post used: Design, Engineering, Requirements, Documentation.

The author of this post is half-right, but missing the big picture. There are folks who develop with maturity and discipline with Perl, and there are folks who write garbage in every language. The freedom to screw ourselves over is necessary for us to learn how not to screw ourselves over.

So no, Perl isn't bad for teams, self-centered programers are bad for teams. I should know, I've been that programmer.

(If I felt like invoking flame-mode, I'd suggest that perhaps the poster is coming from an academic or corporate background where individualism is bad for the hierarchy... :)

Perls Idiom NOT Perl Specific Pattern

[Anonymous Coward]

"Perl Specific Patterns"

I would call that a "Perl Idiom"

It is not a pattern.

Patterns are CONCEPTS not IMPLEMENTATIONS

I really don't get it

[Christianfreak]

I make my living as a perl programmer

I do not understand why a majority of people on /. are so quick to flame Perl. If you don't like it don't use it but don't flame people who do. I love Perl. As far is being hard to read or understand well I think that's people who have never tried. When I started coding Perl I was a complete newbie. I'd done a little C and a bit of Basic and I wanted to learn how to right CGI scripts. 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. I know very few people who can do that in any other language. In fact it was Perl that got me to move away from the darkside of Windows (this was before ActiveState made Perl on Windows a more manageable beast).

Try it before you knock it. Give it a chance. If you don't like it then use the tool you like but don't keep spreading flames and lies about it. Saying its only good for 500 line programs or that its always unmaintainable or it can't be used by teams simply isn't true. And ANY language can have all of those attributes.

Perl also has a great community that I've not seen in other languages. Don't know how to do something, ask Perlmonks. Those guys are even one of the few places where newbies can come. Very rarely do I even see someone screaming RTFM at them. Most of the time you just get your question answered and answered fast. There are other places that aren't so kind.

Perl is great. Long live Perl

Re:language preference

[caranmir]

Oh, c'mon. You can code badly in any language.

Given Damian's reputation, the fact that the Perl community is raising money to get him to focus on Perl, and the fact that he seems to know what he's doing, wouldn't you think that the fact he chooses to work with Perl says something potentially interesting about the language?

When someone I respect praises (or consistently uses) a tool that I don't like, I try to question my opinion and find out what they know that I don't.

I disagree.

[Anonymous Coward]

I work for a Major Automotive Manufacturer's ITM department, and Perl has saved our lives.

We have a large number of very large and complicated projects done in Perl, plus literally thousands of minor, single-use programs. There have been no maintainence issues to speak of.

Perl, like any other language, can be written in such a way as to only be comprehensible by the authour. But if you optimise the code for *LEGIBILITY* - ie, no use of "$_" or the "implied $_" then Perl has spectacular legibility. Much better than C, C++, or (especially) Java.

In fact, the projects that meet or beat deadlines are usually written in Perl. Those that miss deadlines, drag on for ages, and prove impossible to maintain once complete are written in Java.

That's the real beauty of Perl, from a large-project-maintainence point of view. Perl's "there's more than one way to do it" idiom means you can write code such that it is much easier to maintain than a "bondage and discipline" language that only has One True Way to code in. Java's syntax is optimised for the language designer's preferences and tastes, where Perl allows you to optimise for the needs of the project.

Y'know, the anti-Perl sentiment that runs through a sub-population of Slashdot reminds me very much of Medival England, back when French was the language of the Royal Court. French was considered the language of nobility, and English was the language of commoners. English was gauche, ugly, and messy.

But (and I'm a fluent French speaker, so I know whereof I speak here) English is a far more flexible and adaptable language than French is. You can write some really horrible, incomprehensible stuff in English, if you want to. But you can also write Shakespere. French - even the French of Voltaire and Hugo - is still pretty much French.

In the Darwinism of languages, French (once the lingua franca of the world - note the irony in the term?) has been relegated to second-fiddle status and is on the decline, where English is now the closest thing to a global language we've got, and is on the incline.

So too is Perl.

Because Perl can be tough for teams

[jabbo]

I write Perl too. I write Perl professionally and I do a professional job of it -- my code is organized into object-oriented modules that could pass for Java if it wasn't for the pointies and easier string manipulation. The documentation is Javadoc-style POD and it's kept up to date. Same thing goes for my PHP code, my C code, etc... I don't write Java code professionally anymore but that's where I picked up some of my documentation and OO habits, since I learned C++ as a scientific (computational) language. Anyways, discipline will see you through if you want it to. It's always more productive to just design and write the damn code than to hold meetings over which language to do it in.

However, Perl is really a language that I find more suited to "glue" than use on a continuing basis by teams of programmers. The vast majority of Perl (and a LOT of C++ for that matter) code I have seen used by teams was phased out MUCH faster than the equivalent PHP+C, Java, or Python code. Now with Inline.pm perhaps the horrible problems of using XS or Swig for wrapping "real" code are gone, but the fact remains, without a LOT of discipline and some bitter years of experience, Perl offers more chances for a programmer to take shortcuts. Again, great for quick glue jobs, but bad for long-lived projects. For what it's worth, the C++ code that got shitcanned was big on templates, gratuitous operator overloading, and all the other Perl-like shit that I hate in C++... if there's one good thing I can say about Java it's that it isn't C++.

But I *hate* the current Java platform with a seething passion. I don't really like C, and I can't hire a bunch of Common Lisp or Python programmers off the street. Ada? Probably, but who wants to deal with DoD curmudgeons? So every approach that I can see is a compromise in some respect or another. All the "good" ways to write code have their problems. Perl's problem is that it offers lazy programmers (oops, that was redundant) many, many ways to churn out spaghetti that "works"... for a while.

As un-fond as I am of fuddy-duddy computer scientists, their focus on formal correctness, proofs, and mathematical solutions to problems is really where it's at when you are solving a problem that hasn't been attacked before. If you're just re-inventing the wheel, Perl (or any other language) is fine, but if you need to parallelize development of some fast, bug-free innards code, it isn't what you want to release in.

I use Perl on a daily basis for configuration, scripts, etc. because it's the best tool for those jobs. Right now I am the only programmer on my team. When that changes again, I'm going to have to go back to a more easily maintained solution, which looks like it'll be PHP+C for most of my tasks. (did I mention that I hate Java with a seething passion? Too much work for too little payoff) This isn't too tough since PHP and Perl have equivalent means of using extension classes, etc. and PHP is actually easier than Perl to integrate directly with C (across-the-board, not just using Inline.pm, which I admit rules). Work with a large team doing development with some custom extension code, etc. and I'll bet dollars to donuts that you, too, will one day shrug your shoulders and admit that Perl is not right for all types of work. It's also a bit baroque and the syntax can be frustrating for people who aren't from a Unix background. I started out sharing your perspective years ago because Perl is SO very wonderful when you're working all by yourself. But it isn't so great when you're with a team. Especially if you are working on code that is inter-dependent with other programmers, it's important to be using the same or similar approaches to solving problems, and this is anathema to the TMTOWTDI credo at the heart of Perl. I'm not going to hedge on this claim -- I, too, make a LOT of money writing Perl and other code, I've done so for years, I appreciate the CPAN and Perl community, and I try to give back -- but I refuse to be a simp and just crow about how great Perl is for EVERY situation, when I have seen so much evidence to the contrary.

(It is still the greatest string manipulation and glue language known to mankind, though. And many of the one-offs I wrote in Perl have made my company tens of thousands of dollars. So the fundamental truth, "Use the right tool for the job" still holds!)