Developer Spotlight: Damian Conway

An anonymous reader writes "Builder AU interview Perl guru Damian Conway to talk about Perl 6, his reasons for choosing Perl over other languages, PHP, Model-driven development and the first Open Source Developers Conference held this week in Melbourne, Australia."

Comments

Perl Vs. Java

[justanyone]

From the Article:

why not say, Java?
Leaving aside the uniqueness of the Perl community, from a purely technical perspective Java is far too restrictive for the kind of work I do. And it's far too demanding on the programmer. Sure, it has a lot of great libraries that make it easy to get particular things done, but I didn't want to do those particular things. And certainly not in the ways Java would require me to do them.

This makes a wonderful point about Perl "There's More Than One Way To Do It" == TMTOWTDI. This is good and bad (like most powerful tools) in that writing hard-to-read code is certainly easy. However, the loose-type is great for projects that don't really need to differentiate between long and integer and float. Hey, it's a number, that's good enough. We read it in, we do stuff with it, we write it out. If it doesn't break when we get a different type coming through than we expected, great.

Yes, Java is demanding. I don't mind demanding. I do mind it being private. And, Java isn't open source. Perl is by nature open source - you CAN'T hide the source if you distribute code to someone. That's the beauty of it.

Re:Perl Vs. Java

[IpalindromeI]

No, not even then.

Language agnosticism needs to be preached more...

[Roman_(ajvvs)]

Balanced words from a sensible man. But I do sense some conflict in his views on languages.
For example, his explanation of the many layered concepts required of a java program. Many of those concepts, while visible in java, also exist in other languages, so I don't necessarily agree that java is as "conceptually overloaded" as he suggests. The structure of any program even in its most basic form requires understanding of programming concepts. Many programming concepts are language agnostic (procedures ~ functions ~ methods) and only differ in their implementation.

Never having used PERL, I can't really comment on relative merits, but having used various languages such as Scheme, Java, .NET, C/C++, I do find that to write a solid program in any language there is a required minimum of understanding of basic programming concepts and the how they fit in the design of the language you're using. I agree with him with regards to the danger of language specialization for this very reason. Recursiveness in Scheme is highly appropriate and key to efficient execution. As it happens the same concept is highly useful when traversing trees (which I wrote a few weeks ago using a recursive function in .NET). If I had never used scheme and understood what works and what doesn't in that language I don't think my tree traversal would have been as efficient in its implementation. I didn't replicate any code or structure from Scheme, I simply applied the concept in what best suited the language and the situation.

A good interview, overall.

Re:Language agnosticism needs to be preached more.

[PghFox]

Perl is not an acronym; There is no such thing as "PERL." It's either "Perl," or "perl," depending on whether you're referring to the language or the implementation/interpreter. :-)

See: http://www.perldoc.com/perl5.8.4/pod/perlfaq1.html #What's-the-difference-between--perl--and--Perl--

Good stuff

[lux55]

I especially like the quote at the end of the article, I'll have to remember that one.

Damian's insights on programming languages (the same with computers in general) as tools not in competition is spot on, as well as his comments regarding the (impossibility of) perfection of programming languages. He has a refreshingly simple way of putting it too -- he's a natural teacher.

His comments also provide a strong validation of why there's always room for one more (ie. Perl 6) that pretty much nullifies the nay-sayers.

The interesting thing (for me) is how his comments pertain to other non-mainstream languages (ie. Lisp, Haskell, etc.) and their place within the whole of computer programming. Even if Perl 6 is never widely accepted, it will still sufficiently *influence* the mainstream of programming to help shape better tools down the road (ie. Perl 6's regular expressions are downright sci-fi, but will be very useful once they're ready).

So the Lisp-ers who are worried their language has fallen by the wayside should take comfort instead of getting upset about the influences of Lisp on mainstream languages. That's what it was meant to do, ultimately.

Re:Language agnosticism needs to be preached more.

[A beautiful mind]

Perl stands for "Practical Extraction and Report Language"
How is this NOT an acronym? Not to nitpick, but to correct. Your statement about the differences between Perl vs. perl is correct.

Re:His arguments against Java are a bit spurious I

[brpr]

He states that Java (and by implication other C style languages) are over complex syntactically and cognitively. Sorry , thats wrong. Sure , for the mickey mouse "hello world" example he has a point but Java isn't designed for 1 line hello world programs , its syntax (we'll ignore the horrid JVMs) is designed for large scale complex systems and for large scale complex systems you need complex data structure abilities and flow of control.

Java doesn't provide for complex data structures or complex control flow. It has only one kind of complex data type (sum types, i.e. classes) and, limited polymorhpism aside, only the standard block-structured control flow constructs (loops, branches, etc.) which have been around in pretty much the same form since the 1960s. OK, it has exceptions, but they're pretty limited compared to what some other languages offer.

For complex control flow, you need higher order functions (anonymous classes are a poor subsitute), an exception system which supports restarts, and various other abstraction features. For example, macros in Lisp or laziness in Haskell (which allows you to build pretty much any control structure using higher order functions).

Rigid structure does not help to manage complexity. Complexity is often the result of trying to force a program into the structure dictated by rigid languages like Java and C. Abstraction is the key to reducing complexity, and Java/C do not support it very well.

Perl can't compete with Haskell/Lisp/ML as far as abstraction is concerned, but it comes pretty close and it has a big community and lots of library support. It's probably a better candidate for writing a complex system than C or Java, overall.

memories, misty watercolour memories

[dankelley]

I've used a whack of languages (I once loved APL, to put a date-stamp on this), but only one passes the memory test, and that's C.

What I mean is that I don't have to look in a manual to write C code. C is simple enough that I can just open a window and start typing. (I've been known to use cat to write simple C programs.)

I do, however, have to look in a manual to write Perl. What the heck is the order of the arguments to split? How the heck does perl do else-if? Am I supposed to use a $ or a @ here? I am pretty sure that Perl is hard to remember because of the "many ways" aspect; all of those ways get blended together in memory. If there were fewer ways, then the mind might better remember the path to take.

Being hard to remember is a flaw, for a language that is so well suited to quick, one-off, applications. Too bad Perl 6 is introducing yet more ways to do "hello world". Seriously, do we need this new say when we already have print? Now users have to remember which one takes the newlines. Very little extra functionality, at the cost of more details to keep in mind.

Having said all of this, of course I'll use Perl for my next 3-liner. But it won't be perl 6.

Re:memories, misty watercolour memories

[Tanktalus]

The "memory test" is somewhat flaky, IMO. I can write C++, C, Perl, and shell scripts without looking at a manual, and have a pretty good chance of getting stuff to compile ("no syntactic errors") on the first try, and still a reasonable chance of getting it to work on that first try, too. I'm not saying that I'm a guru in these languages, only that I've used them all quite a bit, so I now remember them. I was getting to the same point with Java, then I stopped using it, and now I need to look up a fair bit of stuff (especially APIs).

This memory test is simply what you're used to. Use a tool for long enough, and you'll feel comfortable with it, even if it's an otherwisely awkward tool (e.g., what could be more awkward than awk?).

Two days down, one to go

[ynotds]

It's been pretty impressive for a first attempt, even to somebody like me who has had the privilege of sitting in on the preparations for OSDC and who has been there and done that in another life time.

Damian's participation is certainly an asset, and he is far from the only open source notable for whom it's a home town show, not that we have been short of visitors from afar either.

In two days, we have had no no shows on the speaker front, no doubt reflecting the efforts of the papers committee which also produced a 325 page book of proceedings with all papers reviewed or refereed. All sessions across the three parallel streams have also run very close to schedule.

Highlights are way too many to mention but if you want to know more, or want to check back later to see our plans for 2005, visit OSDC's website.