LWN Interviews Larry Wall

dlc writes: "Linux Weekly News interviews Larry Wall. 'Until now, the process of the design of Perl has been evolutionary. It's been done by prototype and modification over time. I talked about becoming stupid, but I've always been stupid. Fortunately I've been just smart enough to realize that I'm stupid.'"

Comments

Re:Is it time to initiate a dialogue on Ruby?

[maraist]

I haven't used it yet (except to download and type out the quick examples). Things I've noticed that I'm not crazy about:

I haven't found a decent debugging mode for it yet. It mimics perl in many ways, but -d isn't the same.

They use "begin / end" instead of the uniform {}. This pisses me off because of lack of emacs / vi matching.

Numbers are all objects, which hints at slower performance. In fact, performance is said to be above that of python, but one can deduce it as being slower than perl.

It is said to have a much more convinient C / C++ API, but that additionally suggests that it'll have additional layers of abstraction, meaning slower interface code (pure speculation). I have the same issue with the Perl6 direction.

It's supports multi-threading even if the OS doesn't, which obviously requires interpreter threads. Depending on how they do this, it could be a negative. (additional checks per ruby-op)

It uses mark-and-sweep memory, which is great for memory leaks, but my initial impression is that it'll be slower than reference counting (since I believe it requires wasteful periodic passes through memory.. Probably through one of it's interpreter threads).

Being a perl advocate, I have no room to speak on this, but some of the syntax seems odd - making use of punctuation marks, etc.

It's heavily OOP, and that isn't always the best solution to problems. Granted, it's useful for things like x.length, but sometimes you want to just length( @{ $some_gloal_name } ) to get the job done. I'll have delve deeper to see how well they copied the TMTOWTDI philosophy.

They made a nice attempt to duplicate perl's interpolating strings through the use of "xxxx #{var_name} xxxxx", which I definately like better than python's c-like method: "xxxxx %s xxxxx" % var_name. Since if I wanted the latter I could just use prints. Still, I can see the extra characters geting annoying. (though there might be a compiler speed-up, since fewer variations need be accounted for).

One of my favorite features of perl is it's code's searchability.. Want to find a function, search on "sub xxxx". Want to find a variable: "$xxx". (Though mangled perl variables can be a pain-sometimes). If nothing else, it's a key for emacs to color on (which remarkably aids reading code). C, Java, Python, and now ruby give this up. (Note: ruby does use $ and @, but only for globals / member-vars, which only has minimal usage. Local's are prefix-less).

I'm definately going to try it out. I dabbled with Python for a while, but couldn't find a compelling reason to move over (poor use of anonymous functions, couldn't find a way to functionalize 'use strict', etc ). I'm expecting a similar final result with ruby, but you never know.

Lastly, I don't believe it's as tried and true as Perl. Ignoring for a moment it's small but growing size 3rd party support compared to CPAN, it was a devil for us to convince our bosses to continue doing web development purely in Perl (as opposed to the more popular but less coder friendly servlets). A good manager would most likely not entrust their clientelle to such a bleeding edge technology. Perl's been on most every platform that I've ever heard of (still waiting for palm). It is the epitomy of robustness as far as I'm concerned. The only times I've ever core'd had to do with c-libraries (which you can _always_ avoid; even if it means resorting to IPC). I'd trust perl-code to c-code any day (assuming you had actual developers on the job). Still ruby's defintaely got future potential.. The trick is how do they differentiate themselves today so that they can grow into tomorrow. They're not defining their own niche, they're piggy-backing existing ones.

What they could do to really bolster acceptance is provide porting scripts fom raw perl. They seem to mimic enough of the rough syntax (like reg-ex, qq(..), etc), so it's bound to be possible. Due to the divergent memory archetectures, it's doubtful that XS code could be ported though. Perhaps if anybody ever used swig, otoh. :)

I saw a lot in Ruby that I heard Larry refer to in Perl6. Namely: OOing the data-types, providing a clean C-interface, consoldating datatypes, etc. So I think it's fair game to steal back from. At least Larry recognizes it; obviously stating his bias. I get the feeling that his cozy job is dependant on the longevity of Perl. If a branch like Ruby could steal the show (considering it is the closest I've ever seen to perl), Larry might be in for some stiff competition.

-Michael

Note: I welcome corrections.. I'm still learning Ruby / Python. Just don't mess with my Perl. ;)

How do you define a finished programming language?

[quickquack]

This bit from Larry's interview stuck out to me.

CL: Now, since Perl 6 is going to be developed under more organized way, do you expect it to live longer? (Of course, I don't mean Perl 5 is dead, though.)
LW: One of the proposals, one of the RFCs was that Perl 6 should be the last version of Perl. The idea is that if we make Perl 6 sufficiently flexible, then there's no need for Perl 7, because you can always bend the full language into whatever you want it to be.

This poses an interesting question. Once the language can do everything in a sense that it was meant to do (everything but operating systems, pretty much) do you discontinue development? Or do you still tweak it for as much speed as possible? What happens if the enviroment of computers changes enough that perl is just not apt to handling it in its latest version?

Flamewars aside, I don't think that perl development will stop. If Larry Wall stops developing it, then the rest of the perl development group will jump on.

I know I'm going to get modded down for this, but I'd like to hear some other's opinions.
------------