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)
Which is why we need to start teaching PERL programming along with English in 4th grade.
I need a TiVo for my car. Pause live traffic now.
I tried looking at your code and translating it to Perl, but I can't for the life of me understand what the heck fj=j+j+p is supposed to do. It's inside a for statement, but that statement uses xj as its inner variable, and you don't ever use the variable xj. Why the heck would you want to add j, j, and p?
Got HTML? Want LaTeX? Try html2latex
It's good to recognize what the dynamic typing versus static typing means to you. It's also valuable to realize that run-time checks will be necessary even in a statically typed language, because there will always be range constraints and user input issues that can't be resolved at compile time. Still, some languages do a lot with pre- and post-condition assertions that you can somewhat build in to your programming abstractions that will do this for you. But they still can't happen till you see what the user typed. :-)
Just a tiny anecdote to add to the discussion...
A few weeks ago, I started a little personal programming project that involved taking an assertive English sentence and converting it into a "why" question (a cool problem, BTW).
I originally started it in Perl. Text processing, right? The fit is ideal. Right tool for the right job, and all that jazz.
Problem was, I wanted to have some fun with it, and Perl made the whole thing just a little too easy. I very quickly lost my motivation, because I realized that I was avoiding all the fun problems that arise during programming. Perl was, in fact, too good a fit for my purposes.
So, I did it in C. It was more work, but it was so much more fun. That was just because it was a personal project, of course. If it had been work, it would have been Perl all the way.
Accountability on the heads of the powerful.
Power in the hands of the accountable.
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.
See http://www.wall.org/~larry/natural.html .
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
$result = myfunc(subject => $first, day => $somevalue, other => "xyz");
or
$result = myfunc({subject => $first, day => $somevalue, other => "xyz"});
The first is good for simple passing, but the second is more flexible and efficient.
Actually, to be perfectly accurate, you could do it the way you first mentioned, but it would require you to use a prototype (which isn't such a bad idea, but maybe you should mention it).
Got HTML? Want LaTeX? Try html2latex
Well, it looks like your complaint about named paramaters was already explained by two other people. So, do you have any other examples of "barriers in the way of 'high-falutin' theory'"?
Got HTML? Want LaTeX? Try html2latex
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.
And as a member of a 'big project' in Perl (nearing 100k lines, ~10 full-time developers), I have to adamantly agree with the original poster.
You are right in saying that there are programming practices that other languages pretty much force you to use that Perl doesn't. This brings me to point #1:
Sometimes peole need "pushes" in the right direction. Not everyone will factor designs as elegantly as you would wish, and there are times when it's too tempting to get out a hack solution. Regardless of what theoretical arguments there are against this, I have seen it happen in practice over and over.
Perl gives a person a lot of control over primitives (strings, hashes, arrays). This is a great benifit in many uses, for example "perl -pi -e", being the most useful implementation of a "read/write grep" I can imagine. However, because it is so easy to pass primitives around, more sophisticated, abstracted types are seldom used. This can be overcome if every developer on the project is a very disciplined OO programmer, but even then Perl's object model is so much harder to use than, say, C++'s. Which brings me to point #2:
There are insurmountable problems in Perl's design that lead to too many things being checked at run-time.
For example, say I want to make a function that only accepts objects of a base type "AdminUser", how can I make sure that an object of type "UnprivilegedUser" doesn't get passed? Perl's answer: Run-time checks.
The simple case is when I wrote an obvious bug and the program will choke upon the first running. The less-simple case is when the code works under most statesduring debugging, but running it in a production environment causes some before-un-thought-of state to surface. Then, we have production code crashing. Or, worse, we have unprivileged users with admin rights in some cases. Suck.
In C++, I would've had a compile(or link)-time error raised explaining to me the situation. I highly question the value of being able to change classes at run-time anyway. Sure, folks like Damien Conway can make some tricky libraries, but beyond that reinventing the object model every time you write a class is a pain.
Please understand that this is *not* a strawman argument, as most of the hours in my day for the last six months have been spent debugging the above problem. It's also why I'm deeming this the last Perl project that I will ever work on.
- Ryan King
I am completely convinced that by version 8 or so, Perl will
Status: Withdrawn
It already has a decent object-oriented system i.e. an optional one (and what it lacks in syntactic sugar can easily be procured from CPAN). Personally, I hardly ever write non OO Perl (and, yes, I'd like to see it graduate from 'decent' to best-of-breed), but there's a bunch of areas - quick'n'dirty CGI, sysadmin scripts, optimizations and general gluing and mucking about - where OO is overkill. Don't forget Perl is a great Unix tool amongst many other things. You can munge the hell out of text with little more than a commandline salvo.
Try version 6.
Er, you mean like Safe, which is as old as Java, offers vastly more control than the Java sandbox (it operates at the opcode level), and which, to my knowledge, has never met a script kiddie yet it couldn't politely but firmly kick to the kerb.
Perl has many fine and dandy features because it promiscuously and 'diagonally' soaks up good ideas (Larry has even been spotted flirting with C# of late). You don't have to be a hypocritical hobgoblin to want to make it finer and dandier: just another perl hacker.
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.
It doesn't have typed parameters. It has "prototypes", but those are really context coercions. Perl isn't strongly typed, which is
:-)
pleasant for some and hateful to others. Here is an example of Perl's named parameters:
$result = foobaz( first => "bob", last => "dole");
sub foobaz {
my %params = @_;
return "My name is $params{first} $params{last}";
}
If by "semantics" you mean "the study of language meaning", Perl's syntax is a wonderful tool for expression. The "line noise" argument falls apart when you realize Perl's syntax is really telling the programer a great deal. If it is "all Greek to you", perhaps a trip to Athens is in order.
Cheers.
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
Seriously, I am looking for a historical perspective on programming languages.
:-)
(Yes, call me lazy now & you'd be right. All I did so far was an extensive search on the net, but I plan to do some more serious research in my CS library at University.)
I mean, Perl, Python, Java etc. surely have a different perspective on development and on what a developer should concentrate on than C had.
What I'm looking for is a historical timeline with an explanation of "inventions" that made software development easier. Maybe a formal classification.
If you know a few book suggestions, I'd be thankful for them.
------------------
------------------
You may like my a cappella music
If you're working on any project with 100 programmers then you need a common set of coding conventions..
Moving back into On-Topic-Land, I'd agree that there is lots of bad perl code around; ultimately thats the fault of the various programmers, not the language itself.
I think Perl has a lot in common with Lisp in that respect - its too simple to start writing bad code that's hard for people to understand and maintain..
Steve
---