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."
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.
click-clack, front and back. I'm not moving this car otherwise.
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.
putfwd.com - 1GB Free file storage with a twist
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.
Freedom is not increased by mere diminuation of government. Anarchy is freedom for the strong and slavery for the weak.
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.