Exegesis 2: Damian Conway On Perl6

sumengen writes: "Damian's writing a series of articles parallel to Larry's Apocalypses. These 'Exegesis' articles will show full perl6 programs, with commentary exlaining the new features. The first Exegesis (numbered 2, to keep in sync with Larry) shows a perl6 version of a binary tree program from the Perl Cookbook. Get excited to see things like:
my int ($pre, $in, $post) are constant = (0..2);"

Comments

"are constant" that's retarded...

[Anonymous Coward]

"are constant" that's retarded...

for perl anyways, is this supposed to be some COBOL style shit or a language that has syntax like "s/\/=[ab]//" etc type crap...

Perl has always been nasty syntactically and the people who learned it and know how to use it like it that way. Regexs, $_, and all the other assorted funky magic stuff. Let's not try to throw in some stuff that looks like semi-english just to stop the weenies from switching learning python.

I don't like Perl

[Anonymous Coward]

I don't like Perl because it sucks. Why does it suck? It sucks because Larry Wall is not a computer scientist so he designed an ugly mish-mash of a language that is write-only. It is almost impossible to decipher a Perl script 6 months after it has been written.

What is even more ironic is that Larry fancies himself some sort of "linguist" or "English" major. He went to college and read a couple books on Shakespeare so now he thinks he is some kind of language expert. Well it doesn't work that way.

Take a look at Perl. Does it look like it was designed by anyone who knew anything about the English language? No, it doesn't. It honest-to-God looks like it was designed by someone who was an Egyptian hieroglyphics major who spent all his free time watching Star Trek -- in other words, someone completely disconnected with reality.

So you can see why Perl sucks. Not to worry; there are other better languages to use. Try Python or Ruby, or gosh darn it -- Korn Shell. Any of these is better than Perl, a "language" which should be relegated to set decoration for Raiders of the Lost Ark.

Re:I don't like Perl

[ianezz]

The usefulness of a language [is determined] by the speed at which you can make something out of it that you can actually use.

Uhm, that's a little bit narrow-minded IMHO. At least, you should throw in also the ability for people other than the original author to quickly understand what the code does, how it does it and change its behaviour according to the new requirements. Requirements usually aren't written in stone, and even if Perl allows you to be extremely quick at producing new working code from zero, having to almost refactor everything at every change request which can't be done by the original author doesn't sound too well to me.

You can say: "but there are comments for this! There is literate programming!", but in the end the final word is always said by code itself, not by the comments (do you expect all programmers to write meaningful and exahustive comments explaining the exact behaviour and side effects of a piece of code? I've given up expecting this some years ago...).

I may be wrong, of course, and honestly I hope I am. I recognize that Perl programmers have better things to do that writing code which is difficult to read, but I wouldn't like to have to say one day "Inside Perl there is a little nifty language..." as it has been said over and over for C++.

If this is going to be the case, expect a Language-X to Perl translator really soon, and Perl being relegated to be the new assembly language of the third millenium (btw, IIRC, this is one of Larry's proposals: using Perl as a cross-platform VM with translators on the top of it from several languages -- after all, this is the current trend).

Re:I don't like Perl

[ianezz]

Do you really mean that it is not possible to write readable code in perl???

I was talking about languages in general. All languages suck more or less from this point of view (this is why you have many of them - otherwise we'd be all using only the One True Language - which is not the case).

That said, i fear Perl is going in the direction of the creeping featurism that affected C++ some time ago, and IMHO it would be really a pity. Introducing constructs that to save a line or two affects how the code is interpreted 1200 lines below, and then saying "you should use them locally" adds to the list of things that an average developer could get wrong or overlook.

A language with an anal-retentive syntax is definitively not the answer, but nor is trying to support every conceivable programming style (in the sense of the amount of syntax sugar thrown in) in a single language.

So, to answer your question: it is definitively possible to write perfectly readable Perl, exactly in the same manner it is possible to write perfectly readable assembly or C. But people won't write readable code just because it's possible.

Re:I don't like Perl

[James Lanfear]

What is even more ironic is that Larry fancies himself some sort of "linguist" or "English" major. He went to college and read a couple books on Shakespeare so now he thinks he is some kind of language expert. Well it doesn't work that way.

I know you're a troll, but from O'Reilly

Wall's education has included a B.A. in natural and artifical languages from Seattle Pacific University, and graduate level training in linguistics at the University of California at Berkeley and the University of California at Los Angeles.

Re:I don't like Perl

[koolB]

You're dead on here. *Sometimes* I dont give a flying f*ck about how readable it is, as I usually do a complete rewrite on each visit to a function/procudure. Sometimes I want to do it my way with my current knowledge. Of course, as you learn more, you can modify to do things smarter and faster...

Re:I don't like Perl

[ultrabot]

If you don't get Perl, it's probably because your head is full of BASIC trauma.

Or LISP trauma. Perl strives to avoid orthogonality at all costs.

Re:I don't like Perl

[GroovBird]

The usefulness of a language is not determined by the ease of the syntax, but by the speed at which you can make something out of it that you can actually use.

If you don't get Perl, it's probably because your head is full of BASIC trauma.

Re:I don't like Perl

[sumengen]

>Uhm, that's a little bit narrow-minded IMHO.
>At least, you should throw in also the ability
>for people other than the original author to
>quickly understand what the code does, how it
>does it and change its behaviour according to
>the new requirements.

Do you really mean that it is not possible to write readable code in perl??? I think that is a bit narrow minded.

Re:I don't like Perl

[sumengen]

I guess the problem might be that there are multiple levels of perl knowledge. Perl is huge, so most people don't learn half of perl offers. (In C, you mostly need to know 90% of C before starting to code) It is understandable that they won't understand code written by true perl hackers using all the fancy features available in Perl. And it applies the way around in an opposite way as you noted.

Re:I don't like Perl

[Magumbo]

With the exception of the stuff out of an obfuscated perl contest, there hasn't been a single scrap of perl code I haven't been able to understand pretty quickly. In fact, given a chunk of code in perl and the same basic thing in some other language, I would bet my yearly salary that a perl hacker would be able to grok the perl code more quickly than languageX hacker would with the languageX implementation. And I'm not talking about using ready-rolled libraries or modules either. I'd also be willing to bet that these well-seasoned hackers would fare the same if you threw totally different coding styles at 'em.

At least that's been my experience.

--
"Fuck your mama."

Perl ? Mmmmm.........

[Anonymous Coward]

This is off topic, but what the hell - everyone else does it !

Over the last couple of weeks, I've been doing some stuff in Perl. It's the first time I've used it, and I must say that it has, without a doubt, one of the most tortuous and confusing syntax of any language I've ever used.

I *HATE* all this stuff with preceding variable with $'s and %'s and stuff - it reminds me of the old BASIC days of 15 years ago.

In the latest Perl book, there's a couple of paragraphs that try and defend all this $ and % stuff. It basically says that if you don't like it you're missing the point and that you really ought to go back to school.

Well, Mr. Wall, YOU ARE WRONG ! This sort of crappy syntax should not be necessary. There is simply no reason for it at all.

It is INCREDIBLY difficult to just pass a variable about the place and actually get it to pop out at the other side in the same format as it was at the start. Or, more correctly, it's incredibly difficult to contrive some weird reference syntax (with the appropriate $ or % or whatever) in both the call to a function and the extraction of the variable out of that bloody stupid $_ thing within the function.

I agree with an earlier post - it is a jumbled mess. C++ is often criticized for being confusing and having weird syntax. This may well be a valid complaint, but at least once you know how to do it, it's consistent !

I don't doubt for a moment that someone will read this and think "idiot - he doesn't know what he's doing". The thing it, it shouldn't be difficult - it should be easy to do easy things.

I've often seen the following description of Perl.....

"It makes difficult things easy and it makes impossible things possible."

Added to this ought to be the phrase "it makes easy things UNBELIEVABLY difficult and contrived".

That brings me nicely to a general problem with the Perl book (and indeed most of the available Perl documentation) - why are the examples so crap ?

example (this is lifted straight out of the book)......

The 'while' loop..........

while ($tickets_sold ;
chomp($purchase);
$tickets_sold += $purchase;
}

This isn't actually that good an example of what my gripe is, but look at it !!! I mean, what's wrong with a READABLE example like.....

my ($blob) = 0;
while ($blob 10)
{
print "$blob\n";
}

In other words, stick to the topic in hand - why start introducing stuff about file input and stuff when all you want to know is "what does a while loop do ?", and "how do I write it ?".

This sort of crappy, over engineered, example is typical of what you get in the documentation.

Plus, the examples are often incomplete - they assume that variables are defined (OK, I know you don't need to do this), and they often assume that you've done lots of other stuff. Until you realize this, you tap in the example and find it won't even bloody compile !!!!!!

I HATE Perl !!!!!

OK, rant over.

Re:Perl ? Mmmmm.........

[Anonymous Coward]

Now rewrite slashdot in Mercury, functional programming language freak.

Of course a functional language like Mercury, ML, Haskell, etc, is going to eat up a binary tree for breakfast. In my experience getting a functional language to do anything more than a small example of code is nearly impossible, although I have seen that people have coded raytracers, etc, in ML. Speed demon is not the word to describe these things though.

The usefulness of a language these days is scored by the number of libraries available for it to do things. Perl wins here, C wins here.

Anyway, Perl is easy in my opinion. Regular expressions are great once you know about them, and really powerful. Sure, Perl has some idiosyncracies that need to be sorted out, which is what Perl 6 should be aiming to do.

I like the $, %, @, etc. They show me the type of a variable at a glance. Look at C variables - most people (should) use hungarian notation, and just look at the horrible result of that.

Just because BASIC did the same kind of thing doesn't mean it is a bad idea. However, BASIC was much more limited. I mean $ for scaler, % for hashes, @ for lists, etc is easy with Perl.

And CPAN rules.

New Sig: If you think a C geek is bad, wait 'til you see an ML freak.

Re:Perl ? Mmmmm.........

[Piers Cawley]

Note too that an awful lot of what is claimed to be good about the language in question is projected for Perl 6. Larry just hasn't got to that part yet.

Okay, so you'll still have @$% and friends, but so what? Personally I /like/ the easy interpolation into strings that that gives me.

Re:Perl ? Mmmmm.........

[jCaT]

I had a really nice response to this that would have been extremely helpful, but the guys at slashdot seem to think perl code is random characters:

Lameness filter encountered. Post aborted.

Reason: Junk character post.

Kind of funny, since it's all written in perl. Kudos, rob- you've managed to stifle any discussion about perl code. :)

Re:Perl ? Mmmmm.........

[LunaticLeo]

Perl is easy to learn if you are coming from a Unix background. All the good stuff in built into the language (grep, sort, hashes, arrays). It has got the best from awk, sed, C, and shell.

For the Children of Windows (much like Children of the Corn), you are screwed. If you want an easy-to-use/familliar programming language try Logo. A more serious suggestion is Rexx from OS/2.

Has anybody noticed that all these Python/KDE/PHP/GUI loving and Unix whining posters come from User IDs over 200,000 ? What you people want in Windows 2000. Go get it from a warez site and call it Freeware.

Re:Perl ? Mmmmm.........

[LunaticLeo]

I DO come from a UNIX background !

You come from a unix background. That is nice.

Are you standing in support of the claim Perl is hard to learn?

So you've used sed, awk, bourne-shell, cut, sort, and grep alot...right? You know that bourne-shell uses backticks for sub shelled output? You know that '/' is called slash and '\' is called back-slash? (inverting this distinction is a big child-of-windows give away.) You've programmed in C...so you know argc, argv and envp right?

All these things translate one-for-one into PERL and you find it hard to understand PERL?

If you didn't understant all the above unix references, you aren't from a unix background. You are a cage-monkey the knows how to reboot unix computers. (Sorry for insulting all the cage-monkeys out there; love yah!)

Re:Perl ? Mmmmm.........

[Jonathan]

Er. the semicolons in odd places like "if; br(T, tree(T), tree(T))" is pretty obfuscated. Yes, you may say there is a good reason for it, but then there is a good reason for Perl's oddities as well.

Re:Perl ? Mmmmm.........

[malkavian]

Urrr.. I tend to use Perl a lot.
Ya know, it's quite easy to pick up (I got up and running in an afternoon on the basics).
The prefixed identifier is pretty useful as a memory aid, so that you are ALWAYS aware of what type you're dealing with (scalar, array, hash, sub, or typeglob).
To learn what these are, you read one page in a book, and all is clear. Now, how difficult is that??
If you're having trouble extracting values out of variables, then I think you have a weird view of 'difficult'. Pulling a value out of a deep struct in C can be difficult, but using $_ being difficult? Bah.
Still, if you don't like it, fine. Your choice. But, please don't keep saying it's so difficult.
I taught my Girlfriend to use Perl in a day (at the basics), and she's never learned a programming language in her life prior to this. She's now sailing away in it happily.

Cheers,

Malk

Re:Perl ? Mmmmm.........

[ethereal]

I just assumed there were some unescaped '<' and '>' characters in there that would make it make sense.

Caution: contents may be quarrelsome and meticulous!

Re:Perl ? Mmmmm.........

[JabberWokky]

Urrr.. I tend to use Perl a lot.

This coming from a Malkavian.

This amuses me tremendously.

--
Evan

Re:Perl ? Mmmmm.........

[Wodin]

hmmm... That looks a hell of a lot like Prolog.

Re:Perl ? Mmmmm.........

[fanatic]

example (this is lifted straight out of the book)...... The 'while' loop..........
while ($tickets_sold ;
chomp($purchase);
$tickets_sold += $purchase;
}
If it was taken from the book, why are there 2 syntax errors in the first line? Try again.

This isn't actually that good an example of what my gripe is, but look at it !!! I mean, what's wrong with a READABLE example like..... my ($blob) = 0; while ($blob 10) { print "$blob\n"; }

--

Re:Perl ? Mmmmm.........

[fanatic]

Ooops, hit submit when I meant preview

example (this is lifted straight out of the book)...... The 'while' loop..........
while ($tickets_sold ;
chomp($purchase);
$tickets_sold += $purchase;
}
If it was taken from the book, why are there 2 syntax errors in the first line? Try again.

This isn't actually that good an example of what my gripe is, but look at it !!! I mean, what's wrong with a READABLE example like.....

Your syntax is wrong, how about this?

my ($blob) = 0;
for $blob1 ($blob..10)
{
&nbsp print "$blob1\n";
}


Your arguments would have much more power if you actually had ANY IDEA what you are talking about.

--

Re:Perl ? Mmmmm.........

[nwetters]

%I was the global variable, holding stuff like $I{dbh} - the database handle.

It's fairly useful having one global variable in a small program, but it becomes cludgy once you modularize.

Re:Perl ? Mmmmm.........

[davidb54]

Oh hey, thanks. I forgot about > et al. I wasn't trying to be rude. I wanted to give an example of "I am a dick" programming style, which you can do really well in Perl. If I ever ran across code like this in a professional setting, I would laugh my ass off, then go yell at the author. Anyway, my real point is that if you can solve that problem in so little space in Perl, that's kind of interesting. To me, at least.

Re:Perl ? Mmmmm.........

[davidb54]

Sorry, I'm a jackass. I thought your post was a response to mine. Ignore that.

Re:Perl ? Mmmmm.........

[davidb54]

Perl can definitely look strange, but you learn over time just how much is possible with the top row of your keyboard, and in how little space it can be done. If you want an example of *readable* Perl code, check http://daveb.net/Code/Perl/phonecode.html. It's not as difficult as it seems. Eventually, you will cackle with glee while you hold down the shift key and bang away at that top row: @#$(&^@)#$&%_. Learn Perl. Love Perl. Be Perl. Then go on and learn something else.

Re:Perl ? Mmmmm.........

[StandardDeviant]

On a funny note, it's probably so people couldn't post derogatory statements about slashcode (pre-bender) that had examples in them (I finally figured out what $S is but wtf is $I?).

On a not-so-funny note, it's not just that "junk" chars are verboten, but the lack of a 'pre' or 'code' tag with which to meaningfully render code is a real bummer. Especially in this section, a priori a code-focused one. I'd propose relaxing the restrictions on 'code' or 'pre' here but I'm sure it would be a pain to implement[1].

[1] yeah, yeah. trolls abusing it for page screwage. cry me a river, and while you're at it just set threshold = [1 .. 3]. ;-)

--
News for geeks in Austin: www.geekaustin.org

Re:Perl ? Mmmmm.........

[Golias]

As I read down through the nested comments, and see yet another compare-and-contrast between Perl and C++, I feel compelled to point something out.

Perl is an interpreted language that lets you quickly hack big jobs with small effort.

C++ is a compiled, object-based language, designed for projects that require the advantages of the OO model and the speed of pre-compiled binary code.

A good all-purpose programmer should learn both. Asking which is better is like asking if a Mack truck is better than a Lotus Esprit Turbo... the answer depends largely on what you want to do with it.

Re:Perl ? Mmmmm.........

[cbr372]

Yes, Perl's compiler could be written in Perl. It would be stupid and slow, but it could be. Why would you want to do that, though? aside from proving that it can be done? Just because Java has a lot of modules for graphics, encryption,etc etc, doesn't make it "more low level" than Perl. If Perl had equivalent packages for doing the stuff in Java, then it could do that stuff too. Let's calm down with the language bigotry, please!

Re:Perl ? Mmmmm.........

[perlyking]

The example looks fine to me, perhaps you're confusing your inability to understand the language with whether or not its a good programming language.
If you like C++ or BASIC then use them instead, I really believe people should choose the language that fits their way of thinking, I enjoy using perl and find it makes sense, you may prefer C++ - that doesnt make either of them better or worse than the other.

Re:Perl ? Mmmmm.........

[Glabrezu]

I dont think that it's a misconception at all. Perl is easy to learn. You dont have many constructs, in fact just three different types of data to do everything, and the C like loop constructs and operands. If you want to program in perl in a similar way than in C you can do it with few modifications. Obviously, you would be using a chainsaw as a scissor....

"Programming Perl" isn't a language reference. I learned perl reading it and IMHO its the best way to grasp the idea of what perl is about. Why? Because it keeps you moving, changing, showing you diferent things at the same time, it helps you to start thinking "perl". A more orderly book would probably produce programmers that wouldn't get the idea of what TMTOWTDI is about.

I know a good number of languages, but i didnt find one that gaves me such an expressive power as perl. I dont always use it anyway, because sometimes i do belive that i need more control on my code. But i can't understand why some people dont like perl. Its the only programming language in wich i can say more things in a sentence that in a full page of natural language...

Santiago
-

Re:Perl ? Mmmmm.........

[ralphbecket]

Hmm, just how much functional programming experience have you had? It most certainly is not hard to tackle real-world problems using FPLs. It is harder to lash-up any old pile of crap that just about gets the job done provided you don't stress it too hard - I'll give you that.

I suspect the ray tracers you're referring to were the ones people wrote for last year's ICFP programming contest. That contest was a free-for-all (imperative entries welcome) that lasted 72 hours from the time the spec. was posted to the time the binaries had to be in. Do you really imagine that a serious performance system is going to be coded in that time? Anyway, this is a straw man since (a) modern FPLs are fast - certainly competitive with C++ and Java - and (b) Perl is not what you use if performance is an issue. By the way, for the three years that the ICFP contests have been going, there have been Perl entries all along, but I don't believe any of them got past the basic correctness tests (I may be wrong about the 1998 entries - anybody know for sure how well they did?)

As for libraries, there I agree with you. Perl does indeed have a very large number of them. Loking at the module list on CPAN there are a large number of modules fixing up holes in the language (which I find astounding given the size of the language.) Surprisingly, I find little there that does not already exist for Mercury other than the systems support libraries (I'm not qualified to report on their quality; my colleagues give them mixed reviews).

But this is all rather beside the point - I don't seriously expect to garner any Mercury converts on this thread. The point is that if you are going to write non-trivial working programs then you should use a language which makes it hard to code bugs in and which is easy to maintain. Perl singularly fails on both these counts.

Re:Perl ? Mmmmm.........

[sumengen]

Your comments might be true Depending on your background!!!
You can write perl programs in C way but that just doesn't make perl easy to learn. That is not why people are trying to learn.
I was a C programmer (not a professional one), and I began reading programming perl (edition 2) and unfortunately it became totally confusing when it began throwing regular expressions around in the first chapter. I stopped looking at perl for about three months then I get a simpler book. Ones I understand ideas such as regexs, split - join,grep, map, push, pop, etc. I began feeling comfortable and I didn't even need to look at books much anymore. If you came from unix background and if you know other scripting languages such as shell, awk, etc. you might not have the same experience. Or if you know python, php or anything along those lines, perl is not difficult to learn. And it is also true vice versa. If you know perl, it isn't much hard to learn other scripting langages. Just learn the syntax of them and go..

Re:Perl ? Mmmmm.........

[sumengen]

A common misconception:"Perl is easy to learn"
No, not really. It is not an easy to learn language for C programmers or new programmers. For C programmers there is a conceptual barrier that they need to pass to get the feel of the scripting languages.

The power of perl comes from that; ones you master perl, it is easy (and fun) to write programs.

I aggree that the perl documentation is not completely newbie friendly, and it probably shouldn't. It is one of the most useful language documentation by the way. It helped me a lot, especially the Perl FAQ's.
There are books like "Learning Perl" for learning perl. If you try to learn perl from the book "Programming Perl", which is a language reference, you obviously hit a stone wall at fifth page or so.

Re:Perl ? Mmmmm.........

[Curien]

I like the $, %, @, etc. They show me the type of a variable at a glance. Look at C variables - most people (should) use hungarian notation, and just look at the horrible result of that.

I most emphatically disagree. Hungarian notation is absolutely and completely evil for a strongly-typed language. The only reason it's at all popular in C is because of Micros~1 API code... and that's because they tried to defeat C's type system by using void*s all over the place (just about everything that starts with H is a void*).

In C and C++ (and any other strongly-typed language for that matter, such as Pascal or Ada), you should be able to determine the type of an object simply by how the object is used.
[An aside... Generic programming takes that notion a step further by saying that it doesn't *matter* what the type of an object is... only the operations that can be applied to an object are important.]

Try doing that in Perl and see how far you get!

I'm not saying that makes C++ and better, per se, than Perl. But C++ is strongly typed while Perl is weakly typed... so from a C++ programmer's perspective, all that @%$ etc crap is unnecessary and horrible.

Of course, in Perl (a weakly typed language), they're necessary. Wondering why they're necessary in Perl is a bit like wondering why you have to mention the datatype in a C++ object declaration.
______

Re:Perl ? Mmmmm.........

[alex_siufy]

All I can say is that not only I use it (extensively), but I like it.

Actually, I like the $, @, % variables a lot! Glance at the code and you know exactly what kind of data a variable holds, and if you name them properly, you'll also realize specifically what the variable is for!

Perl code can be unreadable (aka "obfuscated"), but it can also be plain simple and clean. That's the beauty of it, you (the programmer) make the code as clean as you want. Perl doesn't force you to be "wordy", like other crappy languages (Java!), but if you want to, you can have your share of OO madness.

Larry Wall is right: if you don't like it, you simply don't "see it". Forget Perl, and go play with something "easy".

if const &perl6 (a..Z)

[Anonymous Coward]

Then { if ( why == simple ) then why = not happy elif (why = complex) then why = happy endif elif # perl6 elif # subject

Re:Perl misses the point

[Anonymous Coward]

What I find so difficult (and annoying) is that you can take a variable (@ping) and you can do something 'obvious' with it like @pong = @ping. Except, this ISN'T obvious, is it ? It doesn't do quite what you were expecting, does it ?

Well, actually, it does precisely what I was expecting. This is probably attributable to the fact that I bothered to learn perl before trying to code perl. What's with people confusing "easy to do powerful things" with "if you speak english, you can code"? To my knowledge, the latter has never been a stated goal of perl.

The $,@,%,etc. does not refer to the type of variable that was originally declared (that's why we have UNIQUE NAMES), it's supposed to tell perl what context you mean something in. It's a feature -- NOT a bug. But apparently enough of you have complained to get it changed, and since the change is elegant anyway, I'll do the manly thing and just suck it up.

Re:RFC, like request for comment? for real?

[jandrese]

Wow, looks like a few people forgot turn on their humor detectors this morning. -1 flaimbait and two flames? I guess it's a self fullfilling moderation!

Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.

death of the diamond operator?

[opus]

Damian Conway writes:

The first thing you'll notice is that reports of the diamond operator's death have been greatly exaggerated. Yes, even though the Second Apocalypse foretold its demise, Rule No. 2 has since been applied and the angle brackets live!

I assume this means that Larry has had a change of heart since he wrote Apocalypse 2, but what is this mysterious "Rule No. 2" that has been invoked?

--

Re:death of the diamond operator?

[theMAGE]

Rule 1: The boss is _ALLWAYS_ Right.
Rule 2: When the boss is Wrong, the first rule takes effect.

Re:Not as advertised

[Piers Cawley]

Of course, to really get the advantage from Perl, you'll probably have to start messing with fairly high level conceptual stuff.

People just seem to have a problem getting their heads 'round the likes of pointers. A big difference between Perl and C is that you can get a lot done in Perl before you have to start using pointers/references, so when you do start to need them you are at least comfortable with the rest of the language.

Python,

[Vermifax]

Well, I'd just like to say that I love python. Then again I also love perl.

Vermifax

Re:RFC in Perl 7

[armb]

> I'm surprised Perl doesn't support the GO-FROM-idiom yet

You're thinking of "COME FROM".

See "A Linguistic Contribution to GOTO-less Programming"
http://neil.franklin.ch/Jokes_and_Fun/Goto-less_ Pr ogramming.html

It's been implemented in INTERCAL.
http://www.tuxedo.org/~esr/intercal/

--

Re:RFC, like request for comment? for real?

[_Gus]

Does this guy actually has to audacity to call something an RFC and actually just mean request for comment?

Well DUH! Of course they are RFCs, thats what we english speakers call an "abbreviation" or "acronym". Would you *really* have expected then to type "request for comment 005" where "RFC005" is both correct and perfectly clear?

Re:The real strength of Perl

[khuber]

Perl is indeed its own culture. It's a clique where Larry Wall and Perl are worshipped.

You even sound like Larry.

Perl is "legendary" (notorious) outside the Perl clique for being unreadable and unmaintainable.
Perl programmers tend to use regular expressions
and bizarre syntax far too frequently just because you can. I don't see that as a good thing for
people who will have to maintain that code.

I do not see anything Damian's document to convince me otherwise: Perl has gotten way out of hand from its simple beginnings. Perl 4 had a grammar that mere mortals like me could understand. Perl 5 was okay if you didn't use
its weird hacked on pseudo OO. Smalltalk,
Java, Python, and Ruby are all powerful OO
languages that are much easier to work with
IMNSHO. Perl 6 is just going off the deep end.

Perl has become too clever for its own good. In a company you just can't plan on many people being motivated enough to learn complex nuances like that. I think a simpler, less context-sensitive, and more orthoganal language is better for long-term, large scale development.

-Kevin

Re:Maby just *to* flexible ?

[Zagadka]

Good perl programmers can manage their code in such a way as to make it readable in 6 months and 9 months and 12 months. It's a matter of dicipline.

The vast majority of Perl programmers don't care about readability or maintainability. They care about reducing keystrokes. The few Perl programmers I've met that actually cared about readability and maintainability have since switched to Python. But I guess YMMV...

Re:Maby just *to* flexible ?

[Zagadka]

Programming languages and natural languages are used for different purposes. The expressiveness of english is very handy when writing poetry or interesting prose. If you want to write code, clarity is more important than expressiveness. If that weren't true then we'd be programming in english.

It's for much the same reason that mathematicians, scientists and engineers have precise notation, rather than just using plain english. English is fine for added documentation (ie: comments, etc.) but for the actual code, you want something clear and easy to parse (ie: not Perl).

Maby just *to* flexible ?

[AftanGustur]

How about:
$*ARGS is chomped;

Maby it's just me, but I fear that setting properties to variables that affect how fuctions work on them, will greatly decrease the quality of code, available.

Let's just face it, not everybody has even heard of Dijkstra, let alone know how to write 'proofable' programs.
--
echo '[q]sa[ln0=aln80~Psnlbx]16isb15CB32EF3AF9C0E5D7272 C3AF4F2snlbxq'|dc

Re:Maby just *to* flexible ?

[ianezz]

Taking your reasonement to the extreme, we should all start writing JVM opcodes.

<IRONY>
It is flexible enough so several languages with other paradigms are implemented on it, it is cross platform in the sense that there are decent JVM for the main platforms, and making readable programs only requires disciplined programmers. Maintenance is easily done because everything is well documented with comments and on dead trees.
< /IRONY >

It is worth noting that it requires years for a coder to get the experience needed to be `disciplined'. Expecially, it requires lots of debugging other's code. Even you weren't born as a `disciplined' programmer, but you became disciplined like everyone else, day by day.

In the meanwhile, either the `still not disciplined coder' refrain itself from using languages requiring more discipline (which is a fancy way just to say that some languages are definitively not for beginners), or (s)he use the language anyway, with great headaches for the guy doing maintenance.

It's good for a language to be flexible, but trying to support all coding styles at once just for the sake of it is pure evil. That's why there are multiple languages out there.

Re:Maby just *to* flexible ?

[hillct]

The thing is, it's like those MasterCard Commencials that are currently runnning (in the US) where the slogan is "Credit Management tools for the slightly smarter consumer"

Well, the fact is, the slightly smarter consumer can manage their credit wothout being provided with credit management tools.

Perl is extremely flexible and powerful. Good perl programmers can manage their code in such a way as to make it readable in 6 months and 9 months and 12 months. It's a matter of dicipline. Code management should not have to be built into the language. We're not talking about COBOL here, after all. If you need code and structure management, lay it out nicely, get a good editor, etc. Perl is intended to provide results and fill a need, which it does vary well As Larry says "It makes the easy jobs easy and the hard jobs possible". I fully agree. Without Perl, I'd me doing admin work in awk and sed, cuz C would just be a waste of time in that context.

Program and code management should be on the back of the programmer not the interpreter/compiler, regardless of what language you're using. Flexibility is power and power is good. the trick is to find disciplined programmers who can manage it without special tools provided to them as if they weren't expected to be capable in their own right.

--CTH

--

Re:applescriptish

[chromatic]

If you set $\ (or $OUTPUT_FIELD_SEPARATOR if you use the English pragma), you can use whatever you like, including \n.

My guess is Perl 6 will make this a property of filehandles... seems good to me.

--

Re:PERL: PERL is an Ebonics-Related Language (?)

[banky]

Or functions like
touch (my $bitch) and die;

ode to a small perl of green putty...

[ethereal]

Perl may look confusing, but there's nothing like having to work in VB for a week to make you miss the raw power Perl provides.

Some of these language changes disturb me too, but I trust Larry to ultimately make it fairly simple to transition from perl5-think to perl6-think. The transition will break a few things but it sounds like it will increase the power of the language by about as much as perl4 to perl5 did.

Caution: contents may be quarrelsome and meticulous!

Re:PERL: PERL is an Ebonics-Related Language (?)

[sharkey]

if $bitches = $da_shit, do $nasty_stuff

--

Try This

[sharkey]

10 PRINT "Fuck You!"
20 GOTO 10

Be sure to pipe the output through lpr.

--

Re:Shades of PL/I

[geophile]

Do you really expect to see three variables initialized to 0, 1 and 2 in a tight inner loop? The ridiculous PL/I initialization syntax sought to be concise, and this was achieved at the expense of clarity. This Perl construct seems the same. Just about any syntactic monstrosity can be justified on the grounds of performance, but you have to wonder how much it's really going to help in practice.

Shades of PL/I

[geophile]

25 years ago, I spent many hours debugging a PL/I program to discover that some code I inherited relied on arcane initialization rules and got it wrong. How nice to know that untold generations of programmers will now have the same experience thanks to constructs like "my int ($pre, $in, $post) are constant = (0..2);" I was never a Perl fan and I'm even less of one now. But out of curiosity, what possible justification is there for such a construct?

I was also happy to see Basic's "dim" recycled.

Really guys, haven't we learned anything since oh, I don't know, 1965?

Re:Shades of PL/I

[maraist]

It's the same situation as the x86 line.. It's a language that has proven so useful that it's archeic syntax is sadly being extended to handle classes it was never meant for.

Namely, constants, multi-dimensional arrays, data-typing have no place in a RAD prototype or a 5 line shell-script. But they _are_ useful in large-scale development (in data-type validation or in optimization). The idea of an integer multi-dimensional array, for example, allows the savings of potentially megs of memory. For one-shot operations or an occasional web page, this is an acceptible cost, but performance-minded developers will want to squeeze those 10's 50's of percents of improvement without switching to another language.

So what happens? Bolted on code.. You can't write a compiler that won't work with old code, and you can't require all users to learn entirely new code.. Thus evolution takes place (humans still have an appendix, ya know). I think it gives the language more character.. For example, anybody know why we have "y/x/y/" or $$? Legacy syntaxes that weren't hurting anybody by lingering on.

So Larry is laboring on that trade-off of clearity of new features verses compatibility (both in code and mind-set). The above syntax really involves attribute setting. The syntax may seem bizzar (and we'll probably lose several developers), but the net result will be an extension that is consistent and powerful.

Perl was and is perfect for the task for which it was invented. Additionally, it does a pretty darn good job of web development and small-scale scripted-applications (especially as wrappers). It's been tweaked to the point that it barely looks like a scripting language. It has an incredible freely available module library which furthers the notion of RAD. I can't say that it won't go the same way as COBOL (a la archaic legacy maintanance issues), but it's definately had an interesting life thus far. And at least we won't have lost the source code.

Re:Shades of PL/I

[Bassthang]

But out of curiosity, what possible justification is there for such a construct?

Optimisation?????????????? Typing like this will be an optional feature, but it will speed up certain programs (e.g. numerical routines).

Re:Shades of PL/I

[CharlesDonHall]

25 years ago, I spent many hours debugging a PL/I program to discover that some code I inherited relied on arcane initialization rules and got it wrong. How nice to know that untold generations of programmers will now have the same experience thanks to constructs like "my int ($pre, $in, $post) are constant = (0..2);" I was never a Perl fan and I'm even less of one now. But out of curiosity, what possible justification is there for such a construct

That's for defining an "enumerated type". I like the Pascal syntax best:

type state = {PRE, IN, POST};

That emphasizes the point that we only want to know what state we're in; we don't care which integer is associated with which state.

Re:The real strength of Perl

[Chmarr]

Ah, so instead of programming with a well designed language, well designed libraries, and a community bent on producing a top quality, readable, naturally extensible language, I get to program with.... culture!

I'll go down to the supermarket and get ten tons of yoghurt now, shall I? :)
</flamebait>

Re:the more I learn about C, the more I like perl

[cpeterso]

Being a C++ coder, the more I learn C++, the more I like C.

what a time for my mod points to expire...

[jslag]

oh well, good show anyway.

PERL: PERL is an Ebonics-Related Language (?)

[Jester99]

Now in Perl 6, one can have such syntax as: my int ($pre, $in, $post) is constant = (0..2);
and: $ARGS is prompts("Search? ");

With the advent of this new "is" construction and the use of passive voice in the code, I think that the following should also be added:

• A be operator,
• a being modifier, and
• the gerundative form (-ing) of any keyword should be allowed.

This would allow for such conventions as:

$*ARGS be chomping;
"LibCGI.pl" is being required;
(or if one wants to be smart:)
recognize $foo!;

Just a thought.

the more I learn about C, the more I like perl

[aberoham]

Has anyone else out there sort of grown up with Perl during this dot.compost era and now started to check out C and the real guts behind ''world domination?''

I'm finally getting into C by taking a night class at UCLA, and my god, this stuff only gets cooler and cooler. To see the community RFC type thing go on with Perl6 and to watch/hear/readof the ISO committee floundering with other languages is very interesting too.

Of all the uninspiring things happening with government, the economy, environment, etc these days, I really recommend that any inclined kid such as myself out there get back to basics and check out what their local community college/college extension has to offer. I have, and every time I walk out of class it's like "oh, no shit, that's friggin sweet." Maybe it's just me, but for some of these things, it's just easier to be in an engaging classroom environment rather than to be all by your lonesone with Conway's ''OOP.''

Anywho, back to coding..

Re:the more I learn about C, the more I like perl

[cb0y]

Being a C/C++ coder , the more i learn perl, the more i like C

Re:in its defense...

[bcaulf]

Your comment makes sense as far as it goes. However, that would be a goddamned evil way to design an object! You would be setting yourself up for unnecessary bugs when you call a method and the internal flip-flop happens to be in the wrong state at the time. Just as in Perl 6.

Re:Go take a languages class.

[James Lanfear]

FWIW, people who believe Ada was "the worst, least loved language of all time" invariably have never used it, and often never seen it. The fact of the matter is that Ada has been well-liked and reasonably popular since it was created, and has managed to build up a substantial 'fan-club' among software engineers, especially in embedded systems. Ada really is a good language, perhaps the best of the Algol-Pascal family still in use, and certainly one of the better procedural languages. The type system may not be as sophisticated as ML's, but it's better than Pascal's or C's, and it works well (it even distinguishes between types and classes, putting a step above most OOP).

Anyway, do some research before you deride.

Re:unusual...

[James Lanfear]

Try comp.lang.ada. It's swarming with Ada fans, many of whom would be happy to explain why they love the language so. Ada Home and AdaPower both have quite a bit of information and evangelism (the former is a bit of a 'classic', though).

What I want to know is

[Jailbrekr]

Does Perl still support GOTO?

God, I love that command.

Re:Perl

[Bassthang]

Will it? I thought python was whitespace dependent ... :-)

Re:applescriptish (Can be done...)

[jjn1056]

You can set the line terminator to whatever you want. I do a lot of html and often use the following:

$\="<br />\n"; #Change the terminator from \n
print "Hello World";

Result is:
Hello World<br />\n

You can also define the defaults for input records, for outputting arrays or hashes, etc.

Perl be Yoda

[nwetters]

$*STRONG being the force;

Re:RFC in Perl 7

[Steeltoe]

I think we have a winner here!

LABEL1:
...
LABEL2:
...
LABEL3:
...
GO FROM LABEL1 TO LABEL2
GO FROM LABEL1 TO LABEL3

As you can see, this simple but powerful idiom supports threads too!

(Btw, the idea of "go from" was indeed from Intercal's "come from", a much-recommended language I couldn't remember the name of. Thread-support has been suggested in that area before.)

- Steeltoe

RFC in Perl 7

[Steeltoe]

After reading the page (ouch, my head hurts), I'm surprised Perl doesn't support the GO-FROM-idiom yet. It'd help alot in obfuscating the code more:

LABEL1: /* jumps to all "go from LABEL1"s in the code here */
.....

go from LABEL1

By using multiple GO-FROMs you can even make threads! It's powerful, intuitive and obfuscated. Just the right thing for Perl 7.

If you think "go from" is too elaborate, you could probably use ${LABEL1}-> instead. Unless that's taken of course.

- Steeltoe

Re:RFC in Perl 7

[haystor]

I think the following would be cooler: GO FROM TO Of course that statment itself could be labeled and properly INOREd just to avoid the confusion of GOTO's.

RFC, like request for comment? for real?

[jon_c]

When i first went to this page I saw a shitload of RFC's. all numbers to low to be Real RFC's.

so whats up? Does this guy actually has to audacity to call something an RFC and actually just mean request for comment?

-Jon

Re:RFC, like request for comment? for real?

[nagora]

Does this guy actually has to audacity to call something an RFC and actually just mean request for comment?

Yes.

Contexts...

[sjoperkin]

Context dependent evaluation of variables, could be really interesting to debug...

Re:Contexts...

[sjoperkin]

have not ever, will not ever use it...

Re:Contexts...

[OpCode42]

my head($brain_cells) are hurting = (newSyntax);
butMust -> learntodoit() or die "Knowing I have failed.\n";

Re:Go take a languages class.

[Animats]

I'm familiar with the static/dynamic and weak/strong issues. But it's not the theoretical issues like that which drive language acceptance.

synatical (sic) declaration is not the same as typing - it is only an aid to the compiler.

Syntactic declaration is highly valuable to the maintenance programmer. It makes a believable statement about a data object. Misery is reading a program in a language where there are no type declarations on function parameters, but types do matter. Perl 5 comes to mind. Effectively, parameters have types, but nothing but comments (if any) tells you what they are. This is especially painful for object-oriented Perl. Smalltalk had the same problem. Attempts to deal with this problem via comments usually fail, unless some stringent management regieme is imposed. Such a regieme is usually worse than a declaration system.

Declarations force a nonlinear thinking style on programmers; you're continually jumping back and forth between declarations and executable statements, which are often in physically different places. It's unwieldy in text editing, and distracts from thinking about the executable code. And then there are the "header file" / separate compilation consistency problems. These are the issues that drive programmers to languages with lightweight or no declarations.

On the other hand, dynamic typing tends to defer error detection until the program blows up in operation, instead of detecting it during compilation. Some people think this is good, and some don't. As program size grows, it's more of a problem.

These are the sorts of issues that affect user acceptance. It helps to think of programming as a user interface problem. In fact, user interface testing of programming language constructs, where programmers are videotaped programming and their keystrokes logged, could be quite valuable. I've not heard of that being done.

The language life cycle

[Animats]

There's a life cycle of languages that start out without a serious type system. It goes as follows.

• "We don't need all those declarations. We'll have nice, concise programs"
• "Without any declarations, nobody can keep their variables straight. So we'll have a few declarations, but not like those complicated languages".
• "People are writing big programs in this language, and they need types and objects. So we'll put them in".
• "Now that we have types and objects, people expect all the features that go with them. So we'll add them".
• "The declaration syntax is a mess. It's unreadable, hard to parse, and programmers have a hard time using it right. How did we get into this hole?"
• "This language is too complicated. Let's develop a simpler language."

Wash, rinse, repeat.

C went through this evolution, taking about 25 years to do so. Originally, everything in C was basically a 16-bit int. Structs were just a set of offsets. There was no type-checking; any struct field could be used with any pointer. Then came K&R C, which added a type system but made the syntax context-dependent, because the original language hadn't contemplated user-defined types. ANSI C made the type system consistent. C++ added objects. ISO C++ added templates, collections, and lots of other stuff. Now the language and its manuals are huge.

LISP also went through this cycle, again taking about 20-25 years to go from LISP 1.5 to Common LISP. So did FORTRAN and BASIC. Perl is now well along into this cycle.

If you put in the type system first, as Java, Python, Pascal, Ada, and Smalltalk did, the end result is cleaner, but the language gets an initial reputation of being complicated. Perl, though, has now grown to be more complex than any of those languages, so it's on the downslope of the cycle.

Re:The language life cycle

[smell_the_glove]

Great comment, but... python? smalltalk? These are *dynamically-typed* languages, like lisp and (pre-perl6) perl. Yes, they have a type system, but there are no declarations. Actually there has been a lot of talk in the python community about adding such declarations, and it's also been done in smalltalk (strongtalk). Lisp and Dylan try to have it both ways, but there's no perfect solution that I've seen yet.

Type systems are complex because the notion of "type" can be extended to any level of complexity you want, and knowing where to get off the train is difficult and perhaps even domain-dependent.

Want to go see Damien ?

[jasontheking]

For those of you in Victoria, Australia, You can go see Damien Conway talk about some of the things he is doing for perl at the moment.

More details are at http://programmers.luv.asn.au/

Re:typed languages.

[djberg96]

I second that. It's 5.x forever or Python and Ruby, here I come.

Hitchhiker's guide to Perl

[Siener]

There is a theory that if anyone ever discovers exactly what Perl is for and why it is here, it will immediately disappear and be replaced by something even more bizarrely inexplicable.

There is another theory which states that this has already happened...

There is yet a third theory which states that both the first two theories were concocted by a wily editor of the Camel Book in order to increase the universal level of uncertainty and paranoia, and so boost sales of the book.

Perl 6? But I'm angry now!

[ellem]

--I am just coming to grips with Perl 5. I can msostly write my own stuff without scurrying to the nearest Cookbook or CLPM...

--As for the other threads here about how hard it is to learn Perl. They're all hard. Perl, Python, C, Hell .bat files can be hard.


---

Perl is the crack...

[koolB]

Perl is the crack of programming languages...and I am an addict...with JUST the method of upgrading/installing CPAN modules...it makes it invaluable..to me.... So all you guys thinking about Perl...once you start...you cant stop....and NOTHING compares to the POWER of Perl... I screwed around for a cupla hours yesterday and wrote a complete statics system for my web page...without using 1 module!

Python? (no jihad this time)

[TeknoHog]

Fair enough, not everyone likes Perl. It sounds like you should try out Python, because it was designed to have a more readable syntax without all that $%#{}; confusion.

IMHO the two languages focus on different things. Perl vs. Python is like poetry vs. technical docs: the former has a lot of artistic freedom, and some things can be made more powerful/compact, but it is difficult to use properly, more so in larger projects. Or you could even say they are like Gimp vs. LaTeX as writing tools. Usually I prefer the latter, when I want to focus on content and not worry about formatting, but sometimes you just need that creative freedom.

--

Go take a languages class.

[denshi]

Language design is not Samsara, and all type system do not have the same goal. You seem to fail to see that there are two primary axes, static-dynamic and weak-strong, and further muddle the issue by stirring untyped systems into the mix. You appear confused about objects -- object support is not the same as typing. Finally, synatical declaration is not the same as typing - it is only an aid to the compiler. Smarter systems (LISP, ML, etc) don't need such syntatic sugar. I wager you know nothing about ML's type system, perhaps the most elegant and beautiful strong dynamic type system around; nor Haskell's notion of type classes. I highly recommend you research both topics.

Interesting selection of type-first systems at the end. No one loves Java; you might want to read the early years of Python (and since the semantic underpinnings of Python are similar to Perl, it's not a good example); Pascal - the bane of the 80s; Ada - ha! perhaps the worst, least loved language of all time; Smalltalk - the first system to do objects correctly, this is definitely 'cleaner'. But none of them were inspired type systems, and I can't say typing was 'first' as you said. Only Smalltalk is a wonder of cleanliness. Python is swimming in the same mire as Perl, Pascal - the language that wouldn't die, Ada - the great mistake, Java - the wonders of marketing.

You seem to have a real interest in languages. I urge you to research the background and modern issues, as I would enjoy continuing a real debate here on /.

Re:Go take a languages class.

[denshi]

Is language acceptance what we are talking about here? You started this thread on language cleanliness and power. And if there have been any changes in the IT environment with the web, it was a validation of multiple language use (primarily b/c of the spread of server-side and distributed apps, thus you don't need MFC). So we don't need to strive towards language homogenization like in the good ol' days of DOS.

And yes, theory matters! I'm not going to step into the mire of 'acceptance', which will never be formalized; but theory is not to be ignored. Theory translates directly into language structures and semantics. Any good programmer cares about semantics.

Again, I don't think you've seen what a good implicit typing system (like the MLs) can do for you. I'd argue for a while on this point, but /. is the great time-suck, and I need to catch a plane. More next week.

unusual...

[denshi]

You are certainly the first Ada fan I have encountered. I will take a closer look as soon I have the chance.

hmm....

[denshi]

It looks like a very mature Algol descendant. And by itself that would be cool, but I think I'd rather continue to move on, towards LISP-macros, ML type systems, continuations, Sather iterators, lazy eval, Haskell type classes, etc.

Thanks for the info, though.

Randal Schwartz, are you out there?

[VSarkiss]

Merlyn, HELP!

This is so confusing. Just the sight of @_[0] to mean a scalar, the second argument to a sub, makes me feel dizzy, and the little hairs on the back of my neck stand up. Please, find Damian and Larry and wake them up somehow. Cold water, dope slap, whatever it takes!

...

Whew. I hate those early-morning nightmares. Both Larry Wall and Damian Conway were in this dream, wearing dark suits and Ray-Bans, and, and....

Re:I don't think I'm confused....

[Golias]

...C++ ! It's often critisized for precicely this reason - too many ways of doing the same thing

Perl proudly exists for the benifit of people who like to embrace "too many ways". It allows you to write crappy code that works while you are learning, and grow as a programmer while producing functional software. Speaking for myself, when I first jumped into writing in Perl for actual applications at my job, I found that it was only a matter of two or three weeks that my code got so much better that I cringed every time I looked at the stuff I wrote on day 1 of the project. A couple months later, I could not stand to look at the crap I had written after 3 weeks. But the point is, all of that lousy code from my days of baby-steps still worked. I could go back and clean it up if I needed to, or I could just leave that pile of spaghetti lying there, functioning perfectly, allowing me to move on to more pressing matters.

If you want your choices limited, to force you into mostly good coding habits, use Java or something.

I often think that the only reason anyone uses vi is so that they can point at people who don't use it and giggle.

There are several reasons why some folks like vi:

1. It is everywhere. Pretty much all *n[iu]x OS has it rolled in, so whether you are sitting at a Solaris box, a Linux box, an old SVR4 box, you can count on vi being available. This allows you to learn one text editor, and use it on any (non-MS) server.

2. It is fairly powerful. Once you learn it, you can do some pretty fast editing of multiple files. vi is not the only editor that supports expressions, sed, awk, etc., but it does it fairly well.

3. It feels a lot like the CLI of the more popular shells. Anybody who learns UNIX will already know a lot of what they need to know to use vi.

4. A lot of first-year college kids are taught how to use it, so it is fairly universal

All that said, there are "better" choices out there (the cheering section for emacs continues to swell), and vi is mostly used due to laziness... but then again, laziness is often considered a virtue in the CS world, is it not?

I'll refrain from getting much deeper into it than that, because nothing in the universe is more tedious that a debate about choice of text editor.

Perl is not THAT bad. But why isn't the obvious obvious ?

Because Perl was not written for doing the obvious. It was written for solving challenging problems. If you evaluate all languages according to how hard "Hello, world!" is to write, you are excluding the mort powerful features of all of them. Yes, all the $_ and \@ stuff looks, at a glance, like it is harder than it should be. The same could be said of the way C handles pointers. Some people find it hard to wrap their heads around Java's use of classes.

All I can say is, use Perl for some hard jobs, instead of just trying in out on "obvious" tasks, and check out how much time you can sometimes save, once you embrace the language. You will be a Perl zealot in no time. (After all, the biggest zealots for anything are always the converted critics.)

Perl is very easy to learn

[nagora]

I've interviewed people for jobs and given them Perl in a Nutshell and asked them to do simple programs. C programmers have no real trouble. Perl can be programmed almost as if it was C.

To program Perl as if it was Perl is much harder and I've yet to master it after two years of using it, but I did learn to produce useful programs in it in an afternoon.

TWW

Bloat?

[nagora]

I can't imagine any justification for adding the "prompt" feature to any programming language. Well, can you?

TWW

Re:Bloat?

[fatphil]

It's a 'button' that 1% of people will use in 1% of their code. So I'll not be happy until they've added 10000 such buttons, as then they'll have added something for everyone to use everywhere!

FP.
--

Re:Perl ? Mmmmm......... (ADDITIONAL)

[oingoboingo]

that is a great great thing, unless you make a mistake and cant figure out why your have a varible initialized at zero

which is why we have use strict. it makes a lot of strange "what the hell is my variable doing?!?!" type problems go away instantly. and, as with everything else in perl, you don't have to use it if you don't want to.

Re:if you gonna quota, quota right.

[fatphil]

Bzzzt! Try again!

Read further. 'are' may well be introduced as a synonym for 'is'. The editorial comment was a forward-looking one, was it not?

FP.

--

Re:Am I the only one...

[fatphil]

Fuck, I'm mod, but have posted already.
Moderators - put down the spoon/inner-tube/whatever, and get upmodding!
--

typed languages.

[zoftie]

... fuck typed languages. That means. perl 5.* for
the rest of my life.
p.

perl and quality code

[rpeppe]

Let's just face it, not everybody has even heard of Dijkstra, let alone know how to write 'proofable' programs

come on, this is perl you're talking about! the canonical "write-once, read-nowhere" language... in my experience, the quality of perl code out there currently couldn't be significantly decreased anyway! :-)

Re:I don't think I'm confused....

[perlyking]

(for anyone surfing at a higher number this is in response to an AC post :-)

Why should perl be easy to understand for you? Thats what BASIC is for, no hold on if you want it to be easy and effortless don't program at all!
You can't expect the rest of society to lower themselves down to your level just because you personally can't understand something..

The great thing about open source, the linux community and programming in general is choice - if you like and understand perl you can use it, if you dont look for an alternative (python, ruby,C++,va'raq...), it would be more productive than complaining.

Now the greatest thing about Perl is there is more than one way to do things and that is also (I think) what confuses some people, they expect less flexibility and power from a programming language.

Re:Do we really need it?

[arslanm]

Well, I love perl too, and I think it's powerful, but.. it's pain in the ass, too complicated.. altough i love it i don't use it on simple scripts, i prefer php to perl on web/cmdline scripts.

The beauty of Perl.

[onion2k]

First point I must make, I love Perl. Its far and away my weapon of choice for most programming tasks.

Perl isn't everybody's cup of tea. There are elements of syntax that can be somewhat oblique. There are aspects that are positively obscure compared to C or Java. However, there are some fantastic points about it too. First and foremost, learning Perl is a distinctly easier task than C, Java or any other higher level language. Simple tasks in C are very simple, but anything beyond the basics is extremely taxing for the beginner. Once you're into Perls way of working you're sorted. Perl also has a tendancy to be shown as a block of regexp code too. This doesn't help.

You mention that the example 'won't even bloody compile', inferring you're used to some other compiled langauge. This is another failing of Perl. Its syntacically(sp?) really quite different to everything else. Coming to Perl from another language is difficult, more so than Pascal to C for example.

In the end, live and let live. If you can't get on with Perl then don't. There are many other options open to you.

Re:The beauty of Perl.

[Tyler Eaves]

That's funny, I was able to learn a good bit of Python in an afternoon, but it took me nearly a week to learn the basics of Perl.

applescriptish

[KevinMS]

First of all, I really wish they'd put in a println function, I really hate typing "\n"

but then again

sub println{ print "$_[0]\n";}
print "hello";

in other thoughts, the 'is' in

%node{VALUE} = $val is Found(0);

kinda scares me because it reminds me of applescript. I dont remember applescript, but I've done some sizeable things in it, and its so close to a natural language that you get confused and start programming in english. Its good that spoken language and programming languages look so different, otherwise I'd accidentally start speaking in code.

in its defense...

[Preposterous Coward]

I had a similar initial reaction, but then I get my head around it by thinking of $*ARGS as an object rather than a "plain" variable. Then what you're basically saying is:

$*ARGS->chomped(1);

and any further calls to $*ARGS "accessor methods" behave appropriately.

Of course, I'm no OO guru, so if this mental model has some fundamental flaw I'd appreciate feedback.

TIP (To Insure PROMPTness)

[The Monster]

Damien says:

The only change here is that now you're allowed to have the input handle add a little something to the output before it flushes the buffer. That's done with the prompts property. If an input handle has that property, its value is written to $*OUT just before the input handle reads. So we can replace:

for (print "Search? "; ; print "Search? ";) {
# Perl 5 (or 6)

with

$ARGS prompts("Search? ");
# Perl 6

But there's a huge assumption going on here. When I write a Perl script, and want to prompt the user for, say, a parameter that was left off the command line, I do not use STDOUT for this, because the output of the program may be piped elsewhere. I know for sure that I redirect the output of my scripts to files or other scripts all the time.

In cases like this, I use STDERR for my prompting, because

1. it's not as likely to be redirected
2. even if it is, the user will read this as an error, which it basically is.

This is where someone should tell me it's OK, because there's Another Way To Do It where prompts binds STDERR instead.

Re:Not as advertised

[sumengen]

Well, easy is a relative concept. Learning Perl is at least an order of magnitude easier than learning C, C++, Java, or Assembly. But this doesn't mean that you can become a perl wizard in three days.
And because you can write some small perl scripts that are doing some cool stuff (which would have taken several thousands of lines code in C) doesn't mean that you learned perl (as most people think).

Re:An order of magnitude easier ?

[sumengen]

>I've written far more lines than I care to think about in C, C++, ...

Just guessing; maybe that's the reason why you have a problem with starting up with perl. You just need to learn the Perl way of doing things.

And how long did it take you to learn C or C++?

Re:Perl ? Mmmmm......... (ADDITIONAL)

[ConsumedByTV]

I think he is saying that your while statement uses an undeclared varible.
br. It should declare wha t$ticket_sold is and then do the while loop.


The Lottery:

Re:Perl FAQs

[Art_XIV]

Have you seen the Perl FAQs ? They give a good insight into what is wrong with Perl.

FAQs like...

"how do I pass an array into a function",

"how do I use a reference as a hash key"

"how do I create a 'static' variable"

-- SNIP --

These questions are in the FAQ because they get asked alot in newsgroups. Duh!!!

The answers to these questions should be obvious, and most likely are obvious, to anyone with a CompSci degree or a year or more experience with C-like languages.

These questions are asked because Perl, in spite of the general consensus that it's not a good teaching language, somehow manages to be the first language that many novice developers learn, or at least the second right after VB.

The "obvious" answer to the first two questions involve references.

The interesting thing about Perl is all the functionality that an amateur can squeeze out of it without even know what the h*ll a reference is!

At some point, the eager amateur thinks to him/herself "Wouldn't it save me alot of typing if I could pass a whole array into a function rather than iterating through it?" The aspiring developer then turns to the newsgroups for an answer, where he/she is immediately flamed for not checking the faqs.

Angered and embarrased, the newbie then checks the faqs, and eventually learns what references are and what they are good for.

The fact that these FAQs exist is not a sign that there is something wrong with the language. The fact that these FAQs exist is a sign that Perl is a language that many developers cut their teeth on, and that there is something oh-so-right about the language.

What I'd like

[Dancin_Santa]

Something like Euclid's equation for Perl. Something that elegantly uses all of Perl's special variables in a single statement.

It would likely solve for world peace.

Dancin Santa

Re:Well, yes I do

[hding]

How many lines of C would you have to write for that? How many lines of Java? How many lines of C++? How many lines of some-other-language? How much time would it take you to do so? Can you write it without a second thought?

Well, this isn't exactly the same, since it returns a new collection without mutating the old one, but in Dolphin Smalltalk one could do:

foo collect: [:x | (x beginsWith: 'comment') ifTrue: ['! ' , x] ifFalse: [x]].

so I'd have to answer 1, about 20 seconds, and yes. It's pretty easy in Common Lisp too.

Re:Well, yes I do

[hding]

I don't think Dolphin has a regex class built in, but I'd be surprised if such weren't readily available for Smalltalk - there are some pretty sizeable code archives out there. And perhaps some of the bigger implementations do have them built in.

I was thinking about it some more, and it's not to hard to do in an ML either (and at least some of these do have regexes included - SML does, and OCaml does too):

map (fn x => if String.isPrefix "comment" x then concat ["! ", x] else x) foo;

I'm not so familiar with the ML regexes, but I suspect it's merely a matter (instead of the String.isPrefix "comment" x part) doing something along the lines of (ML pseudocode follows :-) Regex.match (Regex.regex "^[0-9][A-Z][A-Z] etc.") x. I don't know offhand what the exact syntax would be, though. Not as compact as Perl, to be sure, but certainly nothing difficult.

it's getting worse

[janpod66]

Perl4 to Perl5 was a real improvement. I had hopes that Perl6 might fix many of the idiosyncracies in Perl5. But it seems to add more junk to the language without helping much. $*ARGS is chomped? $ARGS prompts("Search?");? That isn't the kind of functionality that is complex enough to warrant new, oddball language constructs, and Perl5 has perfectly good constructs for those cases. And in addition to that, Perl6 also introduces lots of subtle incompatibilities with Perl5. As far as I'm concerned, Perl6 is shaping up to be the worst of both worlds: incompatibility and mess. Thanks for the heads-up: as a long-time Perl user, this really convinces me that it's time to switch.

Re:Perl

[Tyler Eaves]

I've never had any problems with the libraries in python. For example, the following will load SlashDot (just the html code, not parse it), and e-mail me that it has done so. import urllib,smtplib slashdot=urllib.urlopen.read() smtplib.connect('mail.local.com') smtplib.sendmail('sender@send.org','tyler@tylereav es.com','Subject: Slashdot\n\nLoaded')

Weirder syntax for cypherheads

[21mhz]

Get excited to see things like:

all my @base are Belong::To qw/parse error/;

The real strength of Perl

[Dana_D]

The real strength of Perl lay not in its technical construct, or its syntax, or even in the vast set of modules and libraries available to it. The truest strength of Perl is its culture. Larry Wall, from very early on, has tried to foster a real, positive community.

Perl6 is yet another cultural extension to Perl5. The RFC process was very messy, disorganized, and perhaps a little out-of-control. Indeed, as Larry said, he spent several months mentally thrashing as he tried to grok all of the RFC's. But that is the way he wanted it. The RFC process was a picture of a real-life war-room or think-tank.

The end result will be very exciting, I believe. The Perl6 documents, to date, have capitalized on cultural strengths of the Perl community.

Truly, Perl6 is built on the most important resource available to Larry: the huge diversity of Perl programmers all over the world. That diversity has made Perl5 a great, legendary language. I think it will make Perl6 even better. As Perl advocates, I think our best effort is in being inclusive, rather than exclusive, in our thinking.