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

Not a troll

[pubjames]

Why has this been modded as a troll? What he's saying makes absolute sense.

The fact of the matter is that anyone who is involved in professional web site development will know that Perl is becoming less and less important as a scripting language, I believe precisely because of its design and philosophy.

Unfortuately, "Perl gurus" like to write programs which are as short and "clever" as possible. That type of programming is not compatible with large, professional software development projects.

Of course this opinion will probably be modded as a troll as well by those very same "perl gurus".

Ach du Lieber

[jkujawa]

* For me, Perl syntax hits the sweet spot between too much order (e.g. Pascal, Ada, Python) and too much chaos (e.g. Lisp, APL, Forth). It "fits my brain" better than any other language I've used.
* Perl's TMTOWTDI philosophy extends past its syntax and into its semantics, and that allows me to craft the precise compromise I want between code size, maintainability, efficiency, and complexity.
* Perl lets me to program in a style that suits me, rather than enforcing a style that some language designer thought would be best for me.
* It's an "instant gratification" language. Because Perl provides acceptable execution speed with no separate compilation step, 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.
* It can be quick-and-dirty when I feel the need for speed, but it can also be clean-and-careful when I need robustness. And it can be both in the same program, which lets me prototype new features quickly without compromising the integrity of the existing code.
* Perl is multi-paradigm: I can write code that's procedural, or object-oriented, or functional, or declarative; whatever solves my problem best. I can even mix styles when the optimal solution calls for that.
* Perl's built-in types (i.e. nestable arrays and hashes) cover the vast majority of my needs without requiring me to drag in libraries or jump through memory management hoops.

None of these are good reasons to use Perl. None! These are all reasons that Perl is a maintenance nightmare, and not at all suitable for programs in excess of five hundred lines, or programs that will ever have to be modified.
Even good Perl is some of the worst code I've ever seen.
Just say no.