Slashdot Mirror
Interview With Larry Wall About Perl 6
mholve wrote to us about an interview with Larry Wall [?] regarding Perl 6. Wall is, always, interesting to read. Warning - the text bit is short, most of it is video.
← Back to Stories (view on slashdot.org)
As I watch Perl evolve from version to version, one thing constantly amuses me. Questionable features (or missing features) that are defended strenuously in one version are fixed (or added) in the next. And the same people who argued passionately that the feature was already fine (or completely unnecessary) now passionately support the change.
I am completely convinced that by version 8 or so, Perl will make "$", "%", and "@" optional, will have a decent object-oriented system, will have useful threading, will have a secure sandbox ala Java, etc. etc. And the same people who currently claim that all this is not only unnecessary but outright harmful will embrace it.
Yeah i'd second that.
:)
It's a very nice langauge for developing little scripts in but any big project i've attempted just becomes a mess. Perhaps it doesn't lend itself to my rather random and unplanned programming style.
As for trying to interpret a script you wrote 3 weeks ago, thats hard. But someone elses.... you must be joking
I like Perl that way, because the programmer gets to choose what style he/she wants to program in, and which corners he/she wants to cut. So, if I'm writing this on-the-spot data extraction script to be used on a couple 'o old personal data files, I'd probably cut a lot of corners. OTOH, if I'm writing a script for processing data entry for my boss, I'd make sure my coding style shapes up so that the resulting script is maintainable, in case something goes wrong and I get fired. :-)
Perl is the only language that allows you this kind of freedom without requiring obscene amounts of arcane workarounds. Most other languages, in their efforts to be "more maintainable", basically shoves a particular programming model down your throat. Which isn't necessarily a bad thing, but I prefer the freedom Perl offers.
Of course, on another note, if you're working in a large 100-person software project, each with his/her own programming habits (good and bad), then you don't want Perl unless you have a strict, enforced coding convention. Otherwise you'll end up with 100 different coding styles that don't quite integrate with each other...
My point tho, is that this is a result of the individual programmers' decisions. Perl lets the programmer choose. If this is not a good thing for the problem at hand, look for another language. For personal programming, tho, I like this freedom.
---
mikre he sophia he tou Mikrosophou.
"hard to learn, hard to use well and devillishly difficult to maintain".
All software sucks, and all programming languages suck. PERL sucks. Python sucks. C sucks. C++ sucks++. etc.
The one thing that is possibly different about PERL is that the guy in charge, who's view of the world is shaped by a polymath background, REALISES that his language sucks, and is trying to make it suck less.
For instance "TIMTOWTDI" might seem like a "sucks" thing to you. You might regard having multiple ways to express the same thing as something that makes a language harder.
But Larry Wall, as a linguist, would say it is a characteristic of all natural languages. In English, for instance, there are countless dozens of ways to rephrase "My silly aunt's accountancy course starts next week."
For instance,
"The accountancy course my silly aunt is taking starts next week".
"Next week my aunt's accountancy course starts. She's silly."
Which of these is correct? All of them. And none of them is more correct than the others.
My point is that language features like the ones Larry Wall has put into PERL (I'm thinking for instance of implicit variables), which some people regard as being bad things, are in fact honest and (for some people at least) helpful attempts to suck less.
And this ongoing quest to suck less, not just than the previous versions of PERL, but to suck less than "programming" in general will continue in PERL 6.
I don't think it's Perl's fault that it is any of the above. In fact, I disagree with Mr. Wall that it is hard to learn. I'd have to defer on "use well" since that is subjective. Difficult to maintain? I'd agree, but not because the language is bad, but because I can't think of a single IDE for Perl other than ActiveState's PDK, which is for Windows. I mean, is there anything out there that goes beyond auto-indent macros and color coding? Most of the Perl code I've seen is either kept really really short, heavily .pm-ized (which then obscures the methods and you end up searching man/docs/how-to's just to work with a module-- better than nothing, but efficient, no), or written in very non-modular fashion (such that code snippet reuse from project to project would be painful, if even possible).
I do not have a signature
I mean, Perl, Python, Java etc. surely have a different perspective on development and on what a developer should concentrate on than C had.
:)
The trick here is that there have been lots of programming languages that focused on less low-level stuff than C--languages that have been around for twenty or thirty years--but C has become so dominant in many ways that lots of people don't realize there was anything else.
The original language that tried to abstract away from the hardware was Lisp, from the late 1950s. Right on its heels was Iverson's APL, which was documented in a book published in 1962. In terms of text processing, SNOBOL and Icon were the precursors of Perl. You'd also need to take a good look at Smalltalk and ML. All of these languages were developed before most Slashdotters were even born
Maybe you should look at a few more languages. And think about a few different ways of doing things.
Perl already has a "name these values" system, the builtin hash type, that applies to all its data. If you want to name your paremeters you pass them as a hash, if you want to just use the order you pass a list... what's so hard about that ??
$result = myfunc( $first, $second, $third );
$result = myfunc2 { subject => $first, day => $somevalue, other => "xyz" };
Now, that wasn't so hard was it ??
I think maybe you mean you don't like loose-typing, but it has its place.
Choose the appropriate language for what you're doing, and use it the appropriate way. Don't bitch because your screwdriver is a lousy hammer.
Cheers
Tim
I usually find that the lack of strong typing means that function interfaces are prone to going wrong in discreet and subtle ways.
Then once you've built a whole pile of code on top something somewhere breaks something else and it's often not easy to chase out the bugs.
Yeah i'd second that.
...but any big project i've attempted just becomes a mess. Perhaps it doesn't lend itself to my rather random and unplanned programming style.
:)
I wouldn't.
It's a very nice langauge for developing little scripts in...
Yes it is, and I can throw off tons of 1 to 10 liners to acomplish the task of would-be complex C or Java programs for common tasks as 'glue' between other programs.
As the author of a 'big project' in Perl, I have to adamantly disagree. It's not Perl's fault. There are some languages that cuff you about the head and shoulders with a club and force you out of your 'random and unplanned' style, but not Perl. If you're an undisciplined programmer from the get go, Perl won't help you.
As Larry said: "You can program Perl in the subset you find easy, using the amount of theory you are (or aren't) comfortable with." So, if you are comfortable with disciplined application design, Perl won't stop you. If you aren't comfortable with it, Perl won't chide you. Either way, the ball's in your court.
As for trying to interpret a script you wrote 3 weeks ago, thats hard. But someone elses.... you must be joking
I revisit my scripts and modules all of the time, even (gasp) up to four years in age. I use something called comments and a little documentation system called POD. I would have never gotten my CS degree had I not developed these habits-- the small Indian professor I had for my favorite class used to turn into The Incredible Hulk if my source didn't have at least as many lines of comment as machine readable code. Granted, in a pinch, you can skimp a bit, but you still need to document your work. The time you save now will be paid with interest later.
As for visiting someone else's code, it depends on the someone else. There are plenty of people in the Perl community who write stunningly beautiful and painfully obvious code. It depends on the programmer and the discipline.
But either way, don't blame Perl for the habits you don't have.
Firing up realplay and chunking the following URL into "Open Location" will get you right to the interview:
v ers/09042000/ss00914200.rm?start=00:22:11& end=00:30:23&vidsection=2100114
http://www.zdtv.com/cgi-bin/zdvmod_smi/screensa