Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Perl Programming

Exegesis 2: Damian Conway On Perl6 125

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);"
This discussion has been archived. No new comments can be posted.

Exegesis 2: Damian Conway On Perl6

Comments Filter:
  • by 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.

  • by 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.

  • by 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 ;
    $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.
  • by Anonymous Coward
    Then { if ( why == simple ) then why = not happy elif (why = complex) then why = happy endif elif # perl6 elif # subject
  • by 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.
  • by 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.
  • 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.
  • 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?

  • 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.
  • 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.
  • by jCaT ( 1320 ) on Wednesday May 16, 2001 @01:44AM (#220214)
    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. :)
  • Well, I'd just like to say that I love python. Then again I also love perl.

  • 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.

  • 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!)

  • 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.
  • > 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.

  • 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?
  • 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.

  • 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...
  • 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).
  • by AftanGustur ( 7715 ) on Tuesday May 15, 2001 @11:29PM (#220224) Homepage

    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 [utexas.edu], let alone know how to write 'proofable' programs.
    echo '[q]sa[ln0=aln80~Psnlbx]16isb15CB32EF3AF9C0E5D7272 C3AF4F2snlbxq'|dc

  • 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.


  • by malkavian ( 9512 ) on Wednesday May 16, 2001 @01:24AM (#220226)
    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.


  • Or functions like
    touch (my $bitch) and die;
  • I just assumed there were some unescaped '<' and '>' characters in there that would make it make sense.

    Caution: contents may be quarrelsome and meticulous!

  • by ethereal ( 13958 ) on Wednesday May 16, 2001 @07:43AM (#220229) Journal

    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!

  • if $bitches = $da_shit, do $nasty_stuff

  • 10 PRINT "Fuck You!"
    20 GOTO 10

    Be sure to pipe the output through lpr.

  • 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.
  • by geophile ( 16995 ) <jao&geophile,com> on Wednesday May 16, 2001 @03:41AM (#220233) Homepage
    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?

  • <flamebait type="humourous">
    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? :)

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

  • Urrr.. I tend to use Perl a lot.

    This coming from a Malkavian.

    This amuses me tremendously.


  • oh well, good show anyway.
  • by Jester99 ( 23135 ) on Wednesday May 16, 2001 @05:40AM (#220238) Homepage

    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.

  • 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 [cuj.com] 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 [fatbrain.com].''

    Anywho, back to coding [dajoba.com]..

  • 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.
  • 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).

  • 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.

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

    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.

  • hmmm... That looks a hell of a lot like Prolog.
  • 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.

  • 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 [oreilly.com]

    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.
  • by James Lanfear ( 34124 ) on Thursday May 17, 2001 @12:59AM (#220247)
    Try comp.lang.ada [google.com]. It's swarming with Ada fans, many of whom would be happy to explain why they love the language so. Ada Home [adahome.com] and AdaPower [adapower.com] both have quite a bit of information and evangelism (the former is a bit of a 'classic', though).
  • Rule 1: The boss is _ALLWAYS_ Right.
    Rule 2: When the boss is Wrong, the first rule takes effect.
  • 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.
  • Does Perl still support GOTO?

    God, I love that command.
  • 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).

  • Will it? I thought python was whitespace dependent ... :-)
  • 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.

  • example (this is lifted straight out of the book)...... The 'while' loop..........
    while ($tickets_sold ;
    $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"; }

  • Ooops, hit submit when I meant preview

    example (this is lifted straight out of the book)...... The 'while' loop..........
    while ($tickets_sold ;
    $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.

  • %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.

  • $*STRONG being the force;
  • I think we have a winner here!


    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
  • 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
  • When i first went to this page [perl.com] I saw a shitload of RFC's. all numbers to low to be Real RFC's [rfc-editor.org].

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

  • 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.
  • Context dependent evaluation of variables, could be really interesting to debug...
  • have not ever, will not ever use it...
  • 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.
  • Sorry, I'm a jackass. I thought your post was a response to mine. Ignore that.
  • 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 [daveb.net]. 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.
  • 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.

  • by Animats ( 122034 ) on Wednesday May 16, 2001 @10:36AM (#220268) Homepage
    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.

  • 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 [geekaustin.org]
  • by jasontheking ( 124650 ) on Wednesday May 16, 2001 @02:40AM (#220270)
    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/

  • I second that. It's 5.x forever or Python and Ruby, here I come.
  • by Siener ( 139990 ) on Wednesday May 16, 2001 @01:57AM (#220272) Homepage
    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.
  • --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 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!
  • 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...
  • Fair enough, not everyone likes Perl. It sounds like you should try out Python [python.org], 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.


  • 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 /.

  • You are certainly the first Ada fan I have encountered. I will take a closer look as soon I have the chance.
  • 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.

  • 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.

  • by VSarkiss ( 173815 ) on Wednesday May 16, 2001 @06:54AM (#220281)
    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....

  • ...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.)

  • by Golias ( 176380 ) on Wednesday May 16, 2001 @09:42AM (#220283)
    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.

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


  • 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.


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


  • 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.

  • 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!

  • 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?


  • Fuck, I'm mod, but have posted already.
    Moderators - put down the spoon/inner-tube/whatever, and get upmodding!
  • by perlyking ( 198166 ) on Wednesday May 16, 2001 @01:51AM (#220295) Homepage
    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.

  • 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.
  • by KevinMS ( 209602 ) on Wednesday May 16, 2001 @02:01AM (#220301)

    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.
  • 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)
    $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.

  • by hillct ( 230132 ) on Wednesday May 16, 2001 @05:08AM (#220307) Homepage Journal
    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.


  • 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.
  • 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:
  • by OpCode42 ( 253084 ) on Wednesday May 16, 2001 @12:40AM (#220316) Homepage
    my head($brain_cells) are hurting = (newSyntax);
    butMust -> learntodoit() or die "Knowing I have failed.\n";
  • 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.

  • 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.

  • 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.
  • 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."

  • by Dana_D ( 452538 ) on Wednesday May 16, 2001 @05:51AM (#220328) Homepage

    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.

The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford