Interview With Larry Wall About Perl 6 55
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.
This discussion has been archived.
No new comments can be posted.
Interview With Larry Wall About Perl 6
Related Links Top of the: day, week, month.
The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford
Re:Warning: I'm not a programmer, ok:) ? (Score:1)
Re:Classification of programming languages(?) (Score:1)
This is a comprehensive survey of just about every programming language under the sun. It covers some of their history as well as the syntax and sematics of the languages themselves. It should prove to be a useful starting point for intensive research on language topics.
Re:Perl is "devilishly difficult to maintain"... (Score:2)
Re:Warning: I'm not a programmer, ok:) ? (Score:2)
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?
Re:Perl is "devilishly difficult to maintain"... (Score:1)
Which article are you quoting? Or are you just trolling?
Chris
Re:Perl is "devilishly difficult to maintain"... (Score:2)
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. :-)
Re:Warning: I'm not a programmer, ok:) ? (Score:1)
#foo is the character/pattern you want to split long string on... typically, comma, colon or spaces (\s+ meaning 1 or more whitespace characters, covers tab-delimited output from spreadsheets
@split_strings = split
Now you can refer to each $split_strings[$i] individually.
Another way is to explicitly set up an 'array' of scalar variables that the long string will be split into:
($street_addr, $city, $state, $zip) = split
for example, which will turn a long address with comma-separated segments into 4 scalar variables... If the $full_address has more fields, the rest gets thrown out. If it has less fields, you get null written to the latter variables.
Of course, TIMTOWTDI, but that's how I do it...
Eric
Oh, fuck TMTOWTDI (Score:1)
Reading Perl zealots, one gets the impression that Larry Wall is right up there with Noam Chomsky. God, like every other sentence is "Larry Wall is a linguist". When was the last fucking time Wall worked with linguistics? 1979?
Anyway, the argument is pure bullshit. First of all, it assumes you want programming languages to be like natural languages, which is a questionable assumption in itself. Second, it is not an argument at all-- it is just the bald assertion that pearl is like a natural language because Wall says so, and Wall is a linguist, and Wall would never lie to us, so it must be true. Never mind that noone's ever given an actual argument supporting Wall's BS.
Face it, Perl is no more like natural language than any other language.
In English, for instance, there are countless dozens of ways to rephrase "My silly aunt's accountancy course starts next week."
And most of them are considerably longer, or, more importantly, don't quite mean the same thing. So?
This thing about Perl being "like a natural language" is self-serving BS spread by Wall; he abuses his title to give it credibility. Only monolingual pearl zealot g**ks who have never tried their hand at actually learning a natural language swallow it. If pearl actuallt were like a natural language, you'd have a miserable time learning it, your programs would all do something different than what you thought they did, and you'd never get the prepositions right.
Yes, you can have too much of a good thing (Score:2)
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.
Re:Off-the-Wall's Newest Work? (Score:1)
It came out at TPC 4.0 this summer. There'll be a Slashdot review soon, I promise. (Hey, even *I* deserve a vacation.)
--
Re:Foolish consistency: the hobgoblin of little mi (Score:1)
2. Decent? No. Awkward and primitive.
3. Sure, but I can recall discussions as recently as a couple years ago where the Perl glitterati argued vociferously that threading inside the language wasn't useful at all.
4. You've got be kidding. "Safe" is a collection of low-level primitives that I suppose, with massive effort, could be used to implement a secure system. It's hardly compares to Java's.
But, of course, all this just validates my original point. In the beginning OO wasn't useful. Now it's useful, but we can get by with a primitive system. By version 8, it will have all the bells and whistles. The same people will defend each version.
Ditto for threading. A few years ago, threading was something that that OS should do---adding it to the language wouldn't be useful. Then it was worth a tack-on. Now the next version will be based on threads.
Ditto for security. First, it's up to the OS: it has no business in the language. Next, it's worth an add-on hack. Finally (v8 or so) we'll have a full-blown system. The same people will defend each version to the death. Until it changes.
Look: I'm not putting down Perl. I just think this is amusing.
It was good to actually... (Score:1)
Yeah, the interview wasn't conducted perfectly, but still in all it was cool
Simon Sez
Foolish consistency: the hobgoblin of little minds (Score:3)
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.
Programming Language Pragmatics (Score:1)
Re:Yes, you can have too much of a good thing (Score:1)
I'm not contradicting what you said, I'm just adding to it: it's great when you come to the realization with a language that the simple problems are too easy. You never get paid to solve a simple problem. :-) By making the simple problems easy, it frees you up to concentrate on the difficult problems, a.k.a. the reasons why you are really developing software. I first had this experience with Java of all things, but have since had it with Perl as well.
--jbRe:Annoying Interviewer (Score:1)
No kidding. And did you hear what his next topic was going to be? "How to keep your images safe" from "web pick-pockets".
After thanking Larry for giving away such a great gift to the world, he wants to talk about dumb ways to disable right-clicking using javascript or something. How crass.
It's a pity you can't really expect more fromm ZDNet.
---
exactly. (Score:1)
Re:Classification of programming languages(?) (Score:1)
Re:Oh, fuck TMTOWTDI (Score:2)
Before ZDTV, There Was Wired (Score:1)
Larry was onboard, as were Tom Christiansen, Randal Schwartz, Lincoln Stein, Andreas Koenig, Uri Guttman, "Ziggy" Turoff, and many other Perl luminaries familiar to readers here. It was an amazing week.
The story is on the newsstands now, and will be online at wired.com in a couple of weeks.
Re:Perl is "devilishly difficult to maintain"... (Score:3)
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
Re:Perl is "devilishly difficult to maintain"... (Score:3)
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.
---
Annoying Interviewer (Score:1)
Just let him talk! Larry's the smart guy, not you. Obviously.
Re:Perl is "devilishly difficult to maintain"... (Score:5)
"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.
Warning: I'm not a programmer, ok:) ? (Score:1)
I'm just trying to write a thing:
What I'm trying to do is take a string, split it into several strings, and assing a variable to each of the split strings... It doesn't seem to be working :(:( Now, I'm not a programmer. I would never consider programming professionally. I just downloaded Python yesterday after I read the /. article. I'm thinking of downloading Perl next. How would you do this in Perl? Here is what I've written. I don't understand why it isn't working.
import os
h='/'
j=os.listdir(h)
print j
p=list(j)
for xj in j:
fj=j+j+p
list(fj)
for kv in fj:
fj=j
Re:Perl is "devilishly difficult to maintain"... (Score:3)
Re:Perl is "devilishly difficult to maintain"... (Score:1)
I've wondered this about Perl programming: Why continue doing something you know is bad?
This applies to any language. If you are working for a company that is producing code that is hard to maintain, the problem lies within the company, not the tools. If the company makes it possible to produce bad code, the only solution to the problem is to change the way the company produces code.
--
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
Re:Perl is "devilishly difficult to maintain"... (Score:1)
I recently cooked up a small internal web-site with a few interactive screens and a database for my development team. I spent all of a day
Using any "real language" that would have taken at least a week and never been done.
We also use Perl for some administrative tools in our product with great result.
Would I create a large heavy use system in Perl? Probably not.
But don't knock it it's a great language and will be around!
How do you want your perl today? (Score:1)
Re:Perl is "devilishly difficult to maintain"... (Score:1)
I've been coding perl for a couple years now, and I've never had this problem, except maybe in my most newbie-ish first month or two.
But then, I also document my interfaces.
I've started learning C (and liking it for what it is, not hating it for what it isn't *ahem*) and I can see how a person could get used to letting the compiler catch that. But, really, if you're watching what you're doing, it's just not an issue.
Re:Classification of programming languages(?) (Score:3)
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
Re:Perl, the Doner Kebab of Languages (Score:4)
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
Re:Perl, the Doner Kebab of Languages (Score:2)
$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).
Re:Perl is "devilishly difficult to maintain"... (Score:1)
Code commenting (Score:1)
That sounds like over-commenting to me. Comments that are redundant with the code are worthless.
The code should be sufficient to describe what's going on; the names of variables and functions should go a long way toward explaining the why's behind the what's; comments are for any why's left over.
Re:Warning: I'm not a programmer, ok:) ? (Score:1)
Hehe. I told you I'm not a programmer!! Yes, the HTML messed it up. I used "IDLE" which automatically puts the lines in the right place (usually after a ":" the next line is one tab-space to the right).
All I'm trying to do is take a list of files (As a string) , and split that into sub strings, and then assign a variable to each of those sub strings so that I can use them later in the program.would? (Score:1)
Re:Perl is "devilishly difficult to maintain"... (Score:1)
Don't get me wrong: perl gives me warm fuzzies like the next guy. But comparing Perl to natural languages as an argument in its favor is not the way to go.
Regards,
Jason.
Re:Perl, the Doner Kebab of Languages (Score:2)
when do I get shorthand of sub mysub($arg1, $arg2) (Score:1)
I not saying that should be changed.
Merely that a more sane shorthand should be allowed:
sub mysub($arg1, $arg2)
{
doit();
}
should be equivilant to:
sub mysub
{
my($arg1, $arg2) = @_;
doit();
}
If a million other poeple suggested this already, oh well.
Re:Perl is "devilishly difficult to maintain"... (Score:1)
Yes, and all these things sadden me to some degree. I cut my teeth on Perl, and it's unfortunate for me to have to look back on the language of my youth as a "toy-language". I'll always use it as a day-to-day tool, but I must say that this project forever cured me of using any predominantly dynamically typed language for a lorge project.
I understand that Perl's purpose was never to be like C++ or Java, but I get the feeling that the perl interpreter is too busy trying to "please", accepting whatever I give it. Twistng Larry's quote about false laziness and such, I consider it "false postmodernism".
I certainly don't mean to say my $user = new UnprivilegedUser; $user->destroyTheWholeSystem(), and I would like some help from the interpreter to remind me when I try. Unless some sort of "use TypeCheck" pragma could be introduced, I see this whole thing as a death toll for Perl's use on a large/multi-developer project in exchange for a little niftiness in a few obscure situations.
Oy.
Re:Perl is "devilishly difficult to maintain"... (Score:2)
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
Re:Perl is "devilishly difficult to maintain"... (Score:1)
This is the full quote: "Perl is an ungainly hodgepodge of a language that is hard to learn, hard to use well, and devilishly difficult to maintain."
I have very little experience with Perl, but the quote seems reasonable to me. The language seems very confused and confusing.
I'm honestly interested. I'm trying to decide if I should put time into learning Perl, or is Python really better, or something else.
This seems to be a case where the moderation system failed. My comment is scored at 0, but the replies to my comment have perhaps a total of 15 points. The result is that the very useful replies are hidden unless the reader changes his or her threshold from the default of 1 to 0.
Re:Perl, the Doner Kebab of Languages (Score:1)
Try taking a C++ program and re-writing it in Prolog (or vice-versa), to quote a Larry Wall-ism "the trick is to use the strengths of a tool, not its weaknesses". Quote also Stroustrup on people implementing SmallTalk like classes in C++: "if you want to use SmallTalk, please do so; don't try and re-write it in C++". If you give me time I can probably find quotes to support the similar attitiude by Kernighan, Stallman, Torvalds et al.
My motto used to be "Never attribute to malice what is explained by ignorance", but its now "Never attribute to stupidity what is explained by a different, but internally consistent, value system".
Not so snappy, but it makes for great dinner party conversations
Tim
Re:Foolish consistency: the hobgoblin of little mi (Score:1)
Re:Foolish consistency: the hobgoblin of little mi (Score:2)
I am completely convinced that by version 8 or so, Perl will
Status: Withdrawn [perl.org]
It already has a decent object-oriented system i.e. an optional one (and what it lacks in syntactic sugar [cpan.org] can easily be procured from CPAN [cpan.org]). 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 [slug.org.au].
Try version 6 [perl.org].
Er, you mean like Safe [cpan.org], which is as old [cpan.org] as Java [sun.com], 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 [webreview.com]' 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.
doh !! (Score:1)
can't believe it. all I needed to do was use "list".
Re:Perl is "devilishly difficult to maintain"... (Score:4)
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.
Re:Perl is "devilishly difficult to maintain"... (Score:5)
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.
Perl has named parameters (Score:2)
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.
URL (Score:3)
http://www.zdtv.com/cgi-bin/zdvmod_smi/screensa
Classification of programming languages(?) (Score:2)
(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.
------------------
Perl, the Doner Kebab of Languages (Score:1)
-
But if you run into a harder problem where you need a more powerful language, Perl will support you in that. Unlike many other computer languages, Perl supports all the high-falutin' theory without forcing it down your throat. You get to pick your own cultural context. Perl is kind of postmodern that way.
Bollocks. I have never come across a language that put more barriers in the way of "high-falutin' theory" than Perl. For God's sake, it doesn't even have named parameters. Perl is kind of sub-lambda calculus that way.Perl: all syntax and no semantics. I weep.
Re:Annoying Interviewer (Score:1)
Re:Perl is "devilishly difficult to maintain"... (Score:2)
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
---