Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Exegesis 4 Out 151

Posted by CmdrTaco from the damian-speaks-everyone-listens dept.
BorrisYeltsin writes "perl.com has Exegesis 4 from the Damian, in repsonse to Larry's latest Apocalypse. This installment covers news of the new flow and block control changes, fully integrated exceptions and some other cool stuff!"
This discussion has been archived. No new comments can be posted.

Exegesis 4 Out More

Exegesis 4 Out

Comments Filter:
  • ..."exegesis" means "explanation"
    pronounced exIgisis with vowels having their so-called cardinal (?) values (pat-pot-pet-pit)
    x like in example
    g like the y in yes/year
    exercise for the reader: find the etymology yourself ;)
    • exercise for the reader: find the etymology yourself ;)

      From dictionary.com [dictionary.com]:

      Exegesis comes from Greek, from exegeisthai, "to explain, to interpret," from ex-, "out of" + hegeisthai, "to lead, to guide." Thus an exegesis is, at root, "a leading or guiding out of" a complexity.
      And for the record, I think Mr. Conway might want to re-think the use of the term in trying to explain the new features of Perl. His RPN calculator sample code didn't lead me anywhere except into a headache... :-)

      -B

      • "exegesis" is not an english word derived from the greek word exegeisthai. "exegesis" is an exact greek word which is used as-is in english. It is a feminine noun. As for the etymology, it seems a bit flakey to me... (i'm greek, by the way)

        funny, that word was word-of-the day on my birthday, heh 17th july!
        • According from the dictionary.com page, the word was directly adopted from Greek. It said 'exegesis' (in Greek) was derived from exegeisthai. So, it's not really a Greek word that's used as-is ... check the pronounciation. In English, it's not as you described, as the g has an English sound.

          It's the same thing with many other words. For example, the word tort (as in Law) comes pretty much directly from French, but it's not pronounced the same.

          But this is pretty off topic, now...

  • What?!? (Score:3, Funny)

    by carm$y$ ( 532675 ) on Wednesday April 03, 2002 @04:37PM (#3279204) Homepage
    perl.com has Exegesis 4 from the Damian, in repsonse to Larry's latest Apocalypse[...]

    This sounds [imdb.com] like chinese [dictionary.com] to me. What the hell [hell.org]... maybe I'm reding the wrong [dictionary.com] section... :)
  • I only glanced at the article, and there are some serious changes. Am I going to have re-write my code all over again? (and what about my editors syntax highlighting patterns?) ;P
    • No, you won't. Although I forget what it is at the moment, there is a command-line switch for the interpreter to target a specific release.

      Of course, should you rewrite your code to take advantage of the new improvements? Yes. If nothing else, improved block structure parsing will probably locate errors you didn't even know existed.

      Jouster
      • The way that Larry has planned to separate perl 5 from perl 6 code is that all perl 6 scripts will have a certain keyword that must be the first non-comment line in the file. Lacking that, the script is assumed to be perl 5 and interpretes it this way. Otherwise, the perl 6 interpreter is activated. Note that this doesn't not mean that upgrading to perl 6 may not break some perl 5 code; there's always a few limited cases of broken backwards compatibility, but these are typically few and far between in the case of perl.

        • Where are you getting this? He talks about such an idea in Apocalypse 1 [perl.org], referencing RFC 16: Keep default Perl free of constraints such as warnings and strict. [perl.org] and says specifically that it is not good:

          Now, there are right ways to do this, and wrong ways. I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good.

          Furthermore he goes on:

          A better approach is to modify something that would have to be there anyway. If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a ``package'' declaration. So we break that.

          I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a package declaration does.

          And if you continue to read this section it sounds like the issue has not been completely resolved.

          I've not read much more of the Apocalypses or Exegesises in depth...but what I've skimmed doesn't seem to address this in greater depth. Is there a more definitive answer to this question?

      • You should rewrite as little code as possible (Score:4, Insightful)

        by Wee ( 17189 ) on Wednesday April 03, 2002 @05:41PM (#3279660)
        Of course, should you rewrite your code to take advantage of the new improvements? Yes.

        Respectfully, No. In fact, a resounding "No."

        Existing, running, production code is mature code, by and large. It works, it's had revisions, people have added little bug fixes here and there, and at very worst it has passed the "live QA department's" BFT. Many eyeballs have seen it. And it's harder to read code, even well-commented code than it is to make new code (that old "easier to plant a garden than take care of a garden" analogy fits in here, I think). So translating existing stuff into new code will probably introduce errors.

        I found a good article about Netscape 6 [joelonsoftware.com] which touches on why rewriting code is usually a bad idea. The article says it better than I can. I especially liked the comments [joelonsoftware.com] from Lou Montulli (creator of Lynx) about the rewrite which took place for Netscape 6:

        There was good reason for a large change, but rewriting everything was a bit overboard to say the least. I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.
        If nothing else, improved block structure parsing will probably locate errors you didn't even know existed.

        Of course, there are times a rewrite is needed. But to decide to do rewrite purely because there are new constructs of a new language (which is essentially what Perl 6 is going to be) seems like a real good way to introduce bugs, not find them. Finding bugs is what good design and QA is for...

        -B

        • On the other hand, Joel's in favor of refactoring [joelonsoftware.com], which is certainly an option with Perl 6.

          • Yeah, I noticed that as well. However, I don't think what he describes in that article is really refactoring, per se. He made -- from what I could tell -- semantic changes. For example, he changed his app so that it spits out xhtml instead of plain vanilla html. That's about as far from a programmatic change on you can get. He admits he didn't make "the kinds of changes that introduce bugs". I assume that means that when he made a change to something code-like, he only did stuff like make all occurrences of a variable name more descriptive.

            I still maintain that this is miles away -- idealogically speaking -- from something as drastic as modifying an existing, working perl script(s) to use the new switch statement in Perl (for one example). Now, if he would have rewritten his app in PHP (from ASP) then I would see that as more analogous to "migrating" from Perl 5 to Perl 6. Or maybe PHP3 to PHP4. I'm not sure. Rewriting someone's code (even your own) in the same language is bad enough, IMHO.

            My point is, I'm all for cleaning up code so that it's easier to add features or make it easier for others to maintain (although I'm not a fan of it myself; I'd rather have the luxury of being able to do things The Right Way from the get-go). But I'm not a big fan of throwing incalculable amounts of "genetic memory" in the form of old code just to scratch an itch for newness.

            But I think we're on the same page... :-)

            -B

        • If you properly document all the fixes as you added them to the old code, you should have a nice little guide to exactly what you need when you rewrite it.

          If you didn't properly document it, it'll be hell to deal with either way.

          Now if there's no reason to rewrite the code other than "we didn't use such-and-such fancy language feature" than sure, that would be nuts. Code should be made to fit the problem, not all the shiny edges of the language.
        • Yes your arguments (echoing Joel's) are apt for commercial software, where time is money and lost market share...but perl is more than this. Its a community. Its a group of hackers. Its an open environment for playing around with languages. They aren't in a rush and they aren't losing sales. They're doing what they want, which in this case was a rewrite. Thats the joy of free software- you are not encumbered by the market...or you are encumbered only as much as you want to be.

          As for Joel, his former employer has made itself into the wealthiest software producer in history largely through continuous rewriting of code. Microsoft is famous for releasing an almost entirely new product by time its third revision is out. While I also agree that rewrites can be pointless exercises, it is not prudent to take Joel's argument too far.

          • Ars, I've read some of your posts. I am going to guess that you are the type who knows what 'BFT' stands for. You know when rewrites should happen. And you know when junior guys should get the task of reading hairy code. You know from interns. But you know that rewrites are worse than than re-reads like 99.98% of the time, our great benefactor from Washington notwithstanding. You can draw your own conclusions. We're on the same page.

            Having said that, I wish I had more gumption to respond. I just left my job today at a dot-com startup. I worked there for 18 months and I was recruited there by mutual friends/co-workers from our former Fortune 500 employer (I worked for them for 4 years, alongside many of my dotcomrades). I'm going to work on Monday for a large university system. Before Monday, I'm getting drunk. In fact: I am drunk right now.

            My point is that I wish I had seen your post when I had the wherewithall (and the hand-eye co-ordination) to type out a decent reply. But you caught me at a bad time. I feel like I should buy you a beer and have a chat with you. But I probably shouldn't be drinking right now. What was I saying?

            -B

    • No, you won't have to rewrite your old code - there are so many changes and so much Perl5 code out there - it would be impossible. Likely, there will be a separate Perl5 parser/compiler on top of Parrot (largely separate from the Perl6 parser/compiler).

      If you are a Perl person, or have any interest at all in Perl, I recommend setting aside some time to read the current 4 (and the future) Apocalypses and Exegesises at dev.perl.org [perl.org].

  • Perl 6 will be a painful, but necessary move ahead (Score:4, Interesting)

    by Ars-Fartsica ( 166957 ) on Wednesday April 03, 2002 @04:43PM (#3279261)
    perl6 is a total reset, and most people who claim to be perl experts are going to have to go back and relearn an almost entirely new language. That said, this is a healthy process. perl5 OO is horribly obtuse, and the perl internals are not inviting to modification as they should be.

    Also, the perl6 project is introducing Parrot - a portable, language independent VM. As .Net and Java continue to evolve and prosper, the writing is on the wall - the next platform war will be in frameworks and VMs/JITs. There has to be a competitive open alternative in this market to keep the other players honest. Five years down the road I see Parrot as potentially more important than perl6 itself.

    In any case it'll be nice to see how Larry and the gang put a perl twist on OO in the new language - knowing him there will be some useful enhancements for thinking programmers.

    • Great. So, now, I'll have to learn another Perl, in addition to another VB, J#, and C#, just to keep up with what's going on in the computer science world. Why does everyone think rewriting their languages and pulling new ones out of thin air is so cool, all of a sudden?

      • If you don't care for rapid change... (Score:1, Insightful)

        by Anonymous Coward
        ...you're probably in the wrong field.
      • Well if it makes you feel better, one of the hopes for Perl6 is that it should be able to process Perl5. With Parrot as an abstract backend, Perl6 is just going to be one of several available frontends for the Parrot engine. In principle, there's no reason why a Perl5 frontend can't also be written, just as there is interest in Python frontends, PHP frontends, Scheme, Forth, Tcl, etc.

        This may be painful, yes, but it had to be done because the existing Perl codebase was such a mess that a reimplementation was seen as the only way for the language to keep evolving. In return from starting from scratch like this, the Perl community gets a lot of benefits: there will be lots of tasty new syntactic sugar (which you're welcome to ignore by writing Perl5 style code, but which will make a lot of tasks easier if you get used to the syntax), it should be easier to develop extension libraries (no more evil XS hackery, and PDL becomes much less necessary), it will be easier to port Perl to new platforms (like say Palm Pilots), and you get this great language engine out of Parrot.

        Plus, the only reference implementation of Perl the language has been Perl the interpreter, and this bothers a lot of people for a lot of reasons. With this reworking, the language specification will be fleshed out in much better detail than has ever existed before, and the official reference implementation should be much easier to understand & work with, with actual abstraction of different working layers that should be replaced just as TCP/IP layers can be replaced. Ideally, this will allow others to come in and develop their own implementations of Perl the language, and that competition could stand to benefit us all.

        Still, the funny thing to me is that all this Parrot work was born out of an April Fools Joke [perl.com] last year. Not only was it a funny joke -- unlike say everything that was posted here the other day -- but it has evolved into quite an interesting piece of software architecture. Be careful what you joke about, you just might get it... :)

      • You mentioned both Perl and VB in one sentence with computer science. You lose.
      • why would you want to learn any languages with '#' in the name in it anyways?

        perl is being rewritten because the people that know it best think it's the best way to go. (try reading perl.com if you're actually interested, they tell you more than you want to know about the why's)

    • A lesson learned from Perl5 (Score:5, Insightful)

      by FortKnox ( 169099 ) on Wednesday April 03, 2002 @05:01PM (#3279396) Homepage Journal
      I think you're seeing a lesson learned from perl5.

      Before perl5, Larry was told "people want OO in perl", so Larry slapped OO onto perl, instead of resetting and adding OO elegantly. You've already mentioned the result( *wince* ).

      Now stuff like Parrot and exception handling needs to be added to perl. But Larry says "Woo! Lets do it right this time" and resets the language.

      I think its just a lesson learned (for all language developers, I hope), and hopefully the last reset in perl.
    • OR.....drumroll.....

      Just learn Python and don't worry about how many more times Perl ends up needing to be reset.
    • One of the most interesting things of Parrot is (at least for me), that it is a register based VM, not a stack based one.

      So it seems to be really possible to code in Parrot assembler directly, optimize (Perl-) code etc.

    • Perl 6 will be painful? What about Perls 1-5?
    • perl6 is a total reset, and most people who claim to be perl experts are going to have to go back and relearn an almost entirely new language.

      People keep saying this, but it just isn't true. There will be a few obvious things that change (like using @foo[0] instead of $foo[0]) and a number of less obvious ones, but a lot of the language will be carried over unchanged. It's just that the discussions by Larry and Damian are focusing on the parts that are undergoing the biggest changes.

  • Perl isn't unreadable - some Perl programs are (Score:4, Insightful)

    by CaptainPhong ( 83963 ) on Wednesday April 03, 2002 @04:44PM (#3279272) Homepage
    Though it is true that by default, Perl does nothing to prevent a person from writing an unreadable program, it is unfair to say that Perl is inherently unreadable. It is quite possible to write unreadable C, or Java, or Javascript, or whatever. Nobody complains that "HTML sucks cause it's unreadable" even though the majority of HTML out there is badly written, unreadable, unmaintainable and full of errors.

    It is true that there are lots of unreadable Perl programs out there, but that's the fault of the programmer when they don't make their throw-away script readable when it becomes a mission-critical script.

    I've written lots of maintainable, easy to read Perl, and it's easy to do if you simply follow reasonable coding practices (i.e. documentation). If you aren't doing that, you're asking for trouble no matter what language you use.
    • Or INTERCAL, for that matter. Hail, Eris! Praise INTERCAL!

    • Re:Perl isn't unreadable - some Perl programs are (Score:4, Insightful)

      by tswinzig ( 210999 ) on Wednesday April 03, 2002 @05:03PM (#3279410) Journal
      You're assuming that the people who complain about Perl are talking about the script as a whole. I think they are talking about the language syntax.

      I think the idea that 'Perl Is Hard To Read' comes from the heavy use of symbols to change the meaning of code, especially $variables, %variables, @variables, *variables, \$variables, \%variables, \@variables, \*variables, $$variables, %$variables, @$variables, and *$variables.

      Now add filehandle names and assorted tricks, subroutines and references to subroutines and subroutine references stored in variables, anonymous arrays and hashes, and regular expres/si/on/s.

      But Perl is not UNREADABLE. It's just HARD TO READ. Like learning a language that doesn't use a latin-based alphabet if that's what you're used to.
      • But Perl is not UNREADABLE. It's just HARD TO READ. Like learning a language that doesn't use a latin-based alphabet if that's what you're used to.

        I left out something important -- a complex Perl script is HARD TO READ if you don't know Perl. However, Perl is not hard to LEARN. You can write a perl program without learning all the complex syntax rules very easily. The same cannot really be said for languages like C/C++ and Java, where you have to learn more about the language before you can even get something to compile.
        • That's an interesting argument - by being easy to learn, any joker can start hacking out Perl code after learning almost nothing, and it ends up being unreadable because they haven't learned quite enough...

          And it is also true that the @$%* stuff can make it difficult to read for those unfamiliar with the language. I would argue that Python goes to far in the other extreme - a dearth of punctuation (esp. curlies, semicolons, etc.) makes it difficult to read. overly rigid enforcement of the use of whitespace makes it (IMO) far too inflexible with respect to grouping related statements for readability.

          The complexity of OOP in Perl, strange use of references, writing Perl extensions and weird stuff like typeglobs are admittedly quite bizzare, but most of these things will be fixed up and made all perty in Perl6.

          I suppose Perl gives you enough rope to hang yourself with, whereas Python's rope is full of saftey features that make it very difficult to hang yourself, but it just ends up like childproof lighters and aspirin bottles - rather annoying and only marginally safer.

          To each his own I suppose.
          • I suppose Perl gives you enough rope to hang yourself with, whereas Python's rope is full of saftey features that make it very difficult to hang yourself, but it just ends up like childproof lighters and aspirin bottles - rather annoying and only marginally safer.

            I think that's essentially Larry's point about Perl and programming in general. Forcing programmers to do things the right way seems like a really good idea, but suffers from two problems. One is that many, if not most, problems with programming aren't solvable that way. Nothing can force a programmer to use intelligent variable names, use a proper level of abstraction, write good comments, or do any of the semantic level parts of good programming. That means that the enforced good style can't solve a lot of the bad programming out there.

            The other, and deeper, problem is that forcing programmers to do things the right way assumes that the language designer knows better than the programmer does. This is true far more often than most programmers would probably like to admit, but sometimes the programmer really does know what he's doing. In that case, giving him enough rope to hang himself also gives him enough freedom to come up with better and more elegant solutions.

      • To add a touch to your point: write a "well written" program in perl and a "well written" program in Java, and find a random non-programming person.

        Which can he read easier?

        Probably the one without the freaky symbol thingies.
        • To add a touch to your point: write a "well written" program in perl and a "well written" program in Java, and find a random non-programming person.

          Why would I do that? Since Joe Engineer is off for the day, is Mary from accounting doing my code review? Hell no! Readability by a "random non-programming person" doesn't mean jack about how one should write code, or what language should be used.

          It's a nice goal to have programming languages be readable, and if they were stated in English that seems like it'd be nice. But English is so ambigous it can't make for a good programming language. You'd need a lawyer.

      • Actually, I disagree and think just the opposite. In many cases, I find that perl is easier to read because of all the "symbols" at the begining of variables and such.

        For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

        Also, I think alot the supposed unreadability of perl has to do with regex. Since regex is such a basic part of perl, it gets used alot and when you come across "$_ =~ s/^([^ ]*) *([^ ]*)/$2 $1/;" you may attribute the mess of characters to perl when in fact, most of the mess is regex, which exists in many languages.

        This is not to say that I haven't see lots of ugly code, perl or otherwise but I don't think perl is really any more difficult to read than other languages.

        Just my two cents,
        Geoffeg
        • Agreed. I like to think of the prefix char as a sort of Hungarian notation short hand

          instead of pchFoo you have $foo

          once the $%@ are part of your mental character set then reading Perl is natural and simplified.

          Also helps to efficiently indentify naked strings from variables. This convention makes possible the ability to perform variable interpolation within strings. This feature greatly enhances readablity.

          For example

          $foo = "Good morning $name it is $time $zone";

          instead of something like:

          foo = "Good morning " + name + " it is " + time + " " + zone;

          • 1. As of Perl5, I disagree. The prefix is not very useful because it applies to the expression, not the variable. E.g., you
            write "my @foo = (1,2,3); $foo[3];". I don't see how that's an improvement over "my foo = (1,2,3); foo[3]." In both cases, the type of foo is obvious from the context; the prefix characters don't add anything. In Perl6, the symbols will actually be useful.

            2. Interpolating in strings is not a good reason for forcing every variable to start with a funky character. You could instead simply use "$" in strings to mean "replace the following expression with its value". Python does something like this, if I remember right.
        • For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

          Wrong. In Perl, $foo could be:

          - A scalar string
          - A reference to ANY TYPE OF VARIABLE, subroutine, filehandle, etc.
          - A filehandle
          - etc...

          So the symbols don't really help as much in readability as you claim. All they do is give you three namespaces for three basic variables (scalar, array, hash). So if you want three variables called foo, you don't have to say scalar_foo, array_foo, hash_foo, you just say $foo, @foo, %foo.

          Don't get me wrong, I love Perl and don't have a problem reading it (because I know it already). But these symbols are what make Perl hard to read.

          Also, I think alot the supposed unreadability of perl has to do with regex.

          Yes, that is why I included it in my list of things that make perl hard to read. ;-)

          I don't think perl is really any more difficult to read than other languages.

          That's just not true. You can't see it because you know Perl already. If you know how to read/write only one language, English, you would have a very hard time learning Chinese when compared to learning Spanish.

          Perl has a vastly different alphabet than most common languages (C/C++/Java/Basic/Python/etc).
        • For instance, in Java "String foo;" and in perl "$foo". Now, later in the code, if I see "$foo" in my perl code, I know immediatly that I'm dealing with a scalar, or %foo is a hash, whereas in most other languages I have to either remember the variable declarations or go back and find the variable declaration in the file.

          Let me guess, you are one of those perverse people who thinks that Hungarian notation is a really good idea. Honestly, if you have to work THAT hard to remember what type a particular variable name refers to, you are well on your way to writing impenetrable code anyway.

          Of course real programming languages are strongly typed anyway, so you really don't need to carry the type along encoded in the variable name. Your interpreter/compiler should tell you that you have a poorly typed program.

          • Of course real programming languages are strongly typed anyway, so you really don't need to carry the type along encoded in the variable name.

            So the language that powers the web is not a real language? And the only thing that separates a real language from a fake language is strong typing? Hmmm...

            Your interpreter/compiler should tell you that you have a poorly typed program.

            Was it watching me type it? Oh, you mean my interpreter/compiler should tell me I have loosely-typed language.

            I don't need a compiler to tell me that, I already know it, that's what makes Perl cool.
        • Good naming of variables, software design, and documentation should be what makes it clear what a variable is, not a symbol prefix that can be easily something other than what you think of first. A well named variable will allow you to make a good guess about how to use it. A variable called "userName" should be a string, "User" should be a class that represents users, and "users" should be an array of User objects.

          You mention that you have to go to another file to find the decleration of the variable, no function should span multiple files and strongly typed variable like Java and C++ force you to place the variable type in the function header, decleration, etc. This tells you what the function is (informing/reminding you of paramater and return types as well) and if you haven't read it you really should to prevent altering the intended behavior.

          Pre-6 perl does an excellent job of making it easy to write obfuscated scripts by stuffing so many interpretations into one symbol ($foo can be a scalar, refrence(which is a scalar but is not used the same way), or file handle)and having a list of inconsistencies so long that comprehensive documentation is insanely difficult. The language as it stands at perl 5 does little to help understanding of a script, and more to make the task difficult.
      • I always use curly braces or the -> when dereferencing. It makes things so much clearer. Then you're down to just four variable types (and most people will never use the typeglob variables), a referencing operator ('\') and some dereferencing operators that are pretty clear.

        Compare:
        @$foo[0] vs. $foo->[0]
        %$fark{snark}{mcgark} vs. $fark->{snark}->{mcgark}

        Not only does it make things clearer, but you're much less likely to forget "is fark a hash or a hashref"???
    • Though it is true that by default, Perl does nothing to prevent a person from writing an unreadable program, it is unfair to say that Perl is inherently unreadable.
      Amen, brother. I think Perl's reputation of being unreadable is because in the beginning people were treating it like a scripting language.

      "I'll just hack up a little script to automate these backups"

      "Hm... Need another feature"

      10,000 lines later, you have a horrible mess because the developer never anticipated that the script would be anything that big.

      I've gotten burned on this a few times, so I start with the assumption that it's going to be big, and use good structuring and syntax from the outset. (Down with $_!)

  • Who let the Java dude in? (Score:5, Insightful)

    by Wee ( 17189 ) on Wednesday April 03, 2002 @05:04PM (#3279419)
    Things like this:

    return %var{'$' _ $i} = pop(@stack) but true;

    and

    class Err::BadData is Exception {...}

    Make me weep for the future. Although I kind of like the new switch-ish stuff. And the expanded for functionality looks like it could be very handy. But it's messing up my Perl, you know? It's like your teenage kid coming home with blue hair and five earrings (not all of which are in an ear, and only three of which you can readily see). What you thought once was is not what now is.

    I know, I know...

    • It's going to be painful.
    • But it'll get me cool new stuff.
    • And so I'll have to learn and use it.
    • Then once I do:
      • I won't ever want to go back
        - or -
      • I'll wonder how I ever got along before
    • And Perl will somehow magically become a "real" programming language that "real" programmers won't laugh at anymore.

    OK, I might have been stretching on that last one...

    -B

    • Re:Who let the Java dude in? (Score:1, Interesting)

      by Anonymous Coward
      And Perl will somehow magically become a "real" programming language that "real" programmers won't laugh at anymore.

      Actually, real programmers don't laugh at perl. The last place I worked at the only people who laughed at perl were the ones who had never learned it (and they had a far higher opinion of their java skills (the company was a java shop) than anyone else in the company did as well). These days I tend to associate a bad opinion about perl with ignorance, not that I actually even use perl very much. To that kind of idiot its more of a religious bigotry than anything else. (They also tend to get annoyed when it takes you 10 minutes to write a quick program to dis/prove something which they've spent an hour bickering about)
    • It's like your teenage kid coming home with blue hair and five earrings (not all of which are in an ear, and only three of which you can readily see).
      If I had teenage kids, I think I'd be quite happy if they contented themselves with a weird hairdo and a few piercings. Hair grows out, piercings heal over. More likely, I'd be trying to explain that no matter how cute that tattoo looks now [qth.com], you're gonna be tired of looking at it in a few years -- especially after the ink has faded.

  • New to Perl (Score:5, Interesting)

    by Tadrith ( 557354 ) on Wednesday April 03, 2002 @05:10PM (#3279455) Homepage
    Just thought I'd place a little comment in from a newbie to Perl, seeing as a lot of people are discussing the readability of Perl.

    First off, I've been writing a database application with SQL Server 2000 and Visual Basic for the last year. Recently, I had to do some nasty work with some text documents. I understand the Visual Basic isn't the most popular language, but it has it's place... parsing text documents isn't it.

    Long story short, I decided to try using Perl for it, instead, seeing as Perl is very well suited for the task. It only took me about 4 hours to complete what I needed to do with Perl, and that includes learning the language. So far I've found it very intuitive and it's certainly not any more difficult to read than anything else. If anything, I think Perl simply requires the reader know a bit more about the language, which isn't a bad thing, in my mind.

    Maybe I had a better time with it since I've already done extensive work in C/C++, but I still think it's quite useful, and certainly not unreadable if the programmer takes the time to program it properly.

    • Re:New to Perl (Score:3, Interesting)

      by MisterBlister ( 539957 )
      I think Perl is great for what it is, yet I still claim that it is harder to read in most cases than any other commonly used language.

      Being easy to learn and hard to read aren't mutually exclusive.

      Even if you are familiar with the ins and outs of Perl, it can often take a few seconds or more to parse one of the more complex lines of code contained in your average Perl program, especially if the programmer likes to do 'clever' things with regexps. With C/C++ programs of similar complexity and a programmer as skillful in C/C++ as the Perl programmer is in Perl, on average I find the C/C++ code much easier to do a quick scan and determine what the code is doing even if all the code is uncommented.

      • I can agree with you, in that sense. As far as reading goes, probably the worst part to me is the amount of symbolism involved. C/C++ are certainly fairly far removed from the english language, but it seems to me that Perl takes that one step further. ;)

        Like most things, it falls in between, not necessarily in one extreme or the other...
    • So far I've found it very intuitive and it's certainly not any more difficult to read than anything else.

      Sure, it's certainly possible to write very clear, distinct perl code. It's also incredibly easy to write very obfuscated, near impossible to read perl code. Here [thinkgeek.com]'s a good example of how bad Perl can get. It's a pretty picture though.
  • Don't know if it is me getting old or what, but it seems like there is a gradual convergence of 'mainstream' languages, especially in the core functionality set. (I do not count lisp / scheme / z as mainstream)
    There was a comment somewhere in this months PC Plus (uk edition) on the ease of transferring from VB to their version of c# (or was it j#).
    I think that this is a good thing. You can use a telephone / car / toaster in any country (that has wires / roads / bread), why not have a common core for computer languages?

    • Re:New cars look the same too (Score:5, Informative)

      by babbage ( 61057 ) <cdeversNO@SPAMcis.usouthal.edu> on Wednesday April 03, 2002 @06:01PM (#3279921) Homepage Journal
      You can use a telephone / car / toaster in any country (that has wires / roads / bread), why not have a common core for computer languages?

      It's a mapping problem. At the core of all these common languages are some implicit ideas about what should be possible, what should be easy, and what just can't be done. Any interface/language built on top of this core has to reflect those assumptions. As long as the core assumptions are sufficiently broad, and map well enough onto your way of thinking and solving problems, then there is no problem here. Sooner or later though, the more you use this system, the more you realize that it does have boundaries and that they will come to restrict you.

      The same idea holds in lots of areas. Compare & contrast the tasks you can solve -- and how easily they can be solved -- when using DOS/cmd.exe on one hand and one of the Unix shells on the other. Even plain old /bin/sh is more versatile than modern NT command shells. On the other hand, compare the graphical environments for Windows and X11, and for that matter MacOS. Each of them has different "easy" situations and "hard" situations. I won't get into which of them is better (well ok I will, MacOS9 was best), but suffice to say that they implicitly force a certain mindset.

      And again this holds up with more traditional human cultural situations. The French phrases "il y a" and "je ne c'est quoi" [surely that's spelled wrong] just don't translate fully into English. English cars don't 'translate' well onto European or American roadways, and vice versa. Not every piece of bread fits into every toaster (try putting a nice big slab of foccaccia into one), and that's a good thing. A lot of people feel that these little cultural rough edges are what make culture interesting in the first place.

      And in a general way, that all comes up again in computer languages. VB is highly optimized for writing Windows applications, and I'd suffer if I tried to do the same things in Perl. On the other hand I can do sophisticated text analysis in a Perl one liner that would be almost impossible to do in VB. Likewise, it might be possible to run a wide variety of dynamic scripting languages on top of Parrot, but it looks like they won't necessarily be able to run on Microsoft's CLI (and thus won't necessarily be able to do .NET or Windows GUI stuff); and at the same time code written in relatively static, compile languages for the CLI might not perform so well on top of Parrot and might not run well on Free Software platforms.

      There are good & bad & deep & subtle reasons for all this, but the end lesson is that a certain degree of non-conformity makes the software "ecosystem" richer and healthier. The benefits of a one core engine runs all approach are eventually offset by the restrictions in the types of problems that can be solved by such a system in the long run. Those non-mainstream languages are a valuable source of ideas & direction for the more standard languages to move in. A lot of Perl's best ideas are brazenly stolen from SmallTalk, APL, Scheme, and other obscure but clever languages. I might not use those others -- hell I don't even know how to code in any of them at this point -- but the fact that they're able to demonstrate new ideas in practice propels the development of the languages that I am interested in. I have little doubt that that development would stagnate without this kind of cross-pollination, and I worry that increased language homogenization & core-engine-standardization could strangle this sort of evolution in the future.

    • not true... Very few cellphones and services allow you to use your cellphone around the world (though it is possible), Brits and Americans drive on different sides of the road, Europe and the US use different amperages (or something... i know next to nothing about practical electricity).

  • 'tis like a summer night... (Score:5, Informative)

    by dghcasp ( 459766 ) on Wednesday April 03, 2002 @05:25PM (#3279545)
    The real reason Perl is getting a facelift is because it was getting to be hard to write stories and poetry in Perl 5. Fortunatly, Larry brings us a new language that will compile and execute things like:

    given $beer {
    when 'empty' { next beer; }
    when 'budwiser' { die; }
    when ... err 'drunk' { throw up; }
    }
  • Ahhh, more control keywords! Good thing most perl code I've seen doesn't bother with the trouble of readable variable names, or running out of variable namespace would be an issue! ;)

    (BTW, I like perl. Like a big brother you just can't stop teasing ... :)

  • Dear Editor, (Score:1, Offtopic)

    by jbennetto ( 41159 )
    I am 8 years old. Some of my little friends say there is no Perl 6. Papa says, "If you see it in Slashdot, it's so." Please tell me the truth, is there a Perl 6?

    • jbennetto, your little friends are wrong. They have been affected by the skepticism of a skeptical age. They do not believe except they see. They think that nothing can be which is not comprehensible by their little minds. [slashdot.org] All minds, jbennetto, whether they be men's or children's, are little. In this great universe of ours, man is a mere insect, an ant, in his intellect as compared with the boundless world about him, as measured by the intelligence capable of grasping the whole of truth [develooper.com]and knowledge [beebo.org].
      Whatever, I thought it was funny.
  • ... it just ends up making Lisp look better.

    (jfb)
    • There are very few languages that don't make Lisp look better.

    • Re:Everytime I read one of these things (Score:1, Interesting)

      by Anonymous Coward
      All well and good- but perl is actually very similar to lisp, particularly common lisp. The CL independence of the symbol-variable and symbol-function namespaces is VERY like perl's scalar/array/hash/etc independent namespaces - remember $,%,@ are resolution operators like ' and #' in lisp, and you're away.

      Also, perl has Lambda. It boils down to yet-another-lisp-with-funny-syntax - like Dylan, or TCL.
  • I have a question. How will Perl 6 affect mod_perl? I assume mod_perl will have to be rewritten, considering the Perl internals are completely different.

    Will there be a mod_parrot that makes mod_perl redundant?

  • More informative material here: (Score:1, Informative)

    by Anonymous Coward
    If you are interested in a more enhanced "bleeding edge" version of Perl,
    with much more intelligent design,
    look here [ruby-lang.org].
  • Starts looking more and more like C++.
  • If you happen to be in or near Silicon Valley, you can go bug Larry Wall in person tonight.

    Wednesday, April 3rd., 2002, 7PM-9PM
    Speaker: Larry Wall
    at Cisco Building 9, the land of numbers.
    Topic: An Evening with Larry Wall

    And even if you're not in Silicon Valley, you should take a look at the directions they put up to this building: Cisco 9 [svlug.org]. Truly amazing, anal-geek overkill.

  • We're defining the class, but using the new Perl 6 "yada-yada-yada" operator in a block immediately after the classname.

    Any language that has a "yada-yada-yada" operator has nothing to worry about.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close