Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Apocalypse 3 151

Posted by michael from the book-of-revelations dept.
rob_99 writes: "The third installment of the Apocalypse is out!" You may have missed the first or second Apocalypses. This one is roughly "all about operators".
This discussion has been archived. No new comments can be posted.

Apocalypse 3 More

Apocalypse 3

Comments Filter:
  • It's a bout time.

    Thanks, Larry Wall. Now for some fun reading...

  • Breaking out of your own culture (Score:4, Interesting)

    by Water Paradox ( 231902 ) on Wednesday October 03, 2001 @05:07PM (#2385910) Homepage
    "Breaking out of your culture is also important, because that is how we understand other cultures. As an explicitly multicultural language, Perl has generally done OK in this area, though we can always do better. Examples of cross-cultural exchange among computer cultures include XML and Unicode. (Not surprisingly, these features also enable better cross-cultural exchange among human cultures -- we sincerely hope.)"

    It is for statements like this, that I am drawn into studying and using Perl. Many designers try to design a langauge which develops its own internal culture; it becomes static and internally consistent, but not very adventurous. Larry Wall seeks to develop a language which has built-in the fact that we like to explore, making his task more difficult, but a language which moves and flows with the evolution of our culture readily.

    Keep up the great work!
    • Larry Wall seeks to develop a language which has built-in the fact that we like to explore, making his task more difficult, but a language which moves and flows with the evolution of our culture readily.
      On the contrary... what I think is the greatest advantage of Perl's flexibility is the fact that I can programm like I want. I don't want a language for exploring new ways of coding, I want it for creating code in the very particular way that satisfies me.

  • Whew... (Score:1, Troll)

    by shr3k ( 451065 )
    You had me for a minute there... I thought we had another attack on our country. It's just another (weirdly-titled?) article about PERL.
    • You had me for a minute there... I thought we had another attack on our country. It's just another (weirdly-titled?) article about PERL.

      It was the camel that fooled you?
      • Well, gee... in what part of the world do we find camels? Makes perfect sense to me. OK, that's silly, but it almost had me too, because you tend to notice the title before the icon.
  • Perl gets around some of these problems by keeping track of whether it is expecting an operator or a term. As it happens, a unary operator is simply one that occurs when Perl is expecting a term. So Perl could keep track of a unary = operator, even if the human programmer might be confused.

    This seems to be a seriously smart way to do sytax checking. Is this drawn from an existing implementation in a different language or is it a new development that he thought up?

    Speaking from my own experience as a non-developer coder, I'd love to see more of this kind of "artificial" intelligence in programming languages. I really love the power of languages such as c/c++ but keeping track of every possible way I can fsk stuff up is just impossible. I definately think having more checks in place (within reasonable limits) would certainly make for better code all around.
    • Well, there's not really anything novel in what he's talking about. Almost all languages do the same thing. Consider these two expressions:

      5 - 3
      5 + - 3

      The first "-" relates to subtraction. The second one relates to negating a number. Those are two different kinds of operations, and those are considered two different operators. You can tell the two apart, because in the first one when you encounter "-" you are looking to extend the expression; while in the second when you encounter "-" you are looking for a second term to go after "+".

      You could do the same thing with "=", but that sort of thing can get confusing. Imagine an expression $x = =$y (quite different from $x == $y !)

    • ...I'd love to see more of this kind of "artificial" intelligence in programming languages.

      If you're interested in how computers can help bring languages together, check out BlueBox [dloo.org] -- they're writing "words" which define behavior, and are working on writing syntaxes/grammars for most common languages.

      The cool part about this? You can write a program in Perl, feed it into BlueBox, and have it output your program in C++. Or Python. Or Shell script. Or ASM.

      Even better is the reverse: feed EXPLORER.EXE in and have it spit out Perl! 'Course it won't be commented, but -- humans know how to comment, perhaps humans can teach computers how to comment?

      To be topical: BlueBox could also help convert from Perl 5 to Perl 6 (and vice versa!), once both grammars have been written.

  • Concatenating strings (Score:4, Insightful)

    by seanadams.com ( 463190 ) on Wednesday October 03, 2001 @05:20PM (#2385960) Homepage
    He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "

    ...instead of:

    $a . $b . $c

    you'll say:

    $a _ $b _ $c


    String concatenation is such a commonly used perl feature that it deserves a single character operator. Discriminating between operators by the existence of white space before/after the character is an incredibly ugly kludge. Larry seems to admit it, too: This is to be construed as a feature

    At least we don't have to use "+", like in JavaScript!
    • one of the nice things about the dot is that it's a single keystroke. the underscore may be a single character, but (at least on English) keyboards it requires two keystrokes.

      of course perl has such extensive string interpolation and other capabilities that this doesn't strike me as a humongous problem.

      I, too, hate the whitespace kludge, but then i've always put whitespace around my dots too because print $this . $that just seems more readable to me than print $this.$that, which looks disturbingly like some kind of slightly funky method call.

    • No, in Perl this is written:

      $d = "$a$b$c";

    • Re:Concatenating strings (Score:2, Informative)

      by motb ( 526357 )
      'He stresses the importance of good huffman coding, then goes on to change the string concatenation operator "." to a three character sequence " _ "'

      Actually, I'd be surprised to see that stick around once Unicode support is rock-solid on the popular platforms. Larry mentions using non-ASCII operators, and I'm almost sure string concatenation will use one of these.

      For my part, though, I actually like spaces around most binary operators, and wouldn't be upset to see it enforced in the language. That way, people would write unreadable code in my style of unreadable coding. ;)

      I'm looking forward to non-ASCII operators. I understand they were much loved on the Lisp machines, and much hated in APL. Different ways of handling things in the two languages, though, so it might be a contextual thing. It will be interesting to see how they are received after twenty years or so of disuse.

  • As I sheepishly back away... (Score:4, Interesting)

    by hillct ( 230132 ) on Wednesday October 03, 2001 @05:28PM (#2386001) Homepage Journal
    I never really thought about how valuable perl really is. I use it constantly. I use it based on the syntactic rules set fourth in the cammel book. I never considered evaluating changes to the language (well, not to any great degree anyway. While I find Larry Wall's series of articles interesting, I just can't get excited about changing the language in it's next incarnation. It works. It's an effective tool. That's good enough to me. I'm not saying don't change it, so much as in it's role as a tool I find it valuable, but when given the opportunity to provide feedback on how to change it I'm at a loss.

    Now, I consider my job to be 'Intranet Systems Arhitect' as distinct from 'Programmer'. Perhaps that's why I can't get excited about changing a tool I've come to depend on in it's current form. Perhaps true programmers might find the prospect fascinating. perhaps you could liken it to the difference between an army officer and a gunsmith. While both make use of guns at various times, only the gunsmith is inclined to take the gun apart, examine it and make a better one.

    Or perhaps I'm just not showing the proper community spirit, and I should dive in and offer my two cents on how to make the language better. Maybe I'm just lazy (then again, isn't that why perl is such a great language...)

    --CTH

  • Larry is always interesting (Score:3, Interesting)

    by Ars-Fartsica ( 166957 ) on Wednesday October 03, 2001 @05:29PM (#2386004)
    Regardless of your opinion of perl, I find Larry's writings to be consistently insightful and although the humor os a bit corny, somewhat amusing.

    How perl 6 will fare is another issue. The language is going to change radically - will developers follow Larry into perl 6, just use perl 5 compatibility mode, or move on altogether?

  • Does anyone see the irony in having a third Apocalypse, let alone a second :)

  • Perl trying to outgrow its niche (Score:3, Interesting)

    by Starship Trooper ( 523907 ) on Wednesday October 03, 2001 @05:38PM (#2386042) Homepage Journal
    Let's face it, perl is absolutely great for its original intention - fast, easy, write-and-forget scripting. But as I see the plans for Perl 6 [perl.org] unfold, one thought comes to my mind - Yuck. The language they propose is bloated and convoluted beyond words; it's clearly evident that Wall and his fellow "designers" are struggling vainly to make Perl "grow up" -- something that it has absolutely no need to do. There [sun.com] are [ioccc.org] other [python.org] languages [microsoft.com] out there to fill the other niches; languages which try to do everything [att.com] doom themselves to failure. Ambition kills.

    • Let's face it, perl is absolutely great for its original intention - fast, easy, write-and-forget scripting. .... Wall and his fellow "designers" are struggling vainly to make Perl "grow up" -- something that it has absolutely no need to do.


      Perl is already used by many people not just as fast, easy, write-and-forget scripting lanuguage. Java, Python are good languages but they don't have something that is missing in Perl. Perl have everything anyone needs to build complex web application for example(mod_perl, AxKit, HTML::Mason, etc).

  • operators (Score:1, Interesting)

    by Anonymous Coward
    larry proposed an operator that does "defined($a) ? $a : $b"... he's probably going to get permanently banned from p5p for that
    • Hey, I was just thinking yesterday that there really oughtta be something like ?= - though I was working with php at the time (which is slowly getting replaced with eperl).

  • Limerick (Score:2, Funny)

    by 575 ( 195442 )
    There once was a hacker named Wall
    To maintain his own scripts, his downfall
    He released to the world
    A wonder named Perl
    You can write code, but never recall!
  • I've never heard of "The Apocalypse" before, and I'm sure it was a pretty good title for an article a month ago...

    But today, when I see "Apocalypse 3" in a link from a previous story... I wasn't sure whether to click to read the story, or get up to check for mushroom clouds outside the window.

    I'm such a nerd... I didn't get up.

    • Re:Not a good title (Score:3, Informative)

      by Matchstick ( 94940 )
      See the definition:
      Apocalypse \A*poc"a*lypse\, n. [L. apocalypsis, Gr. ?, fr. ? to uncover, to disclose; ? from + ? to cover, conceal: cf. F. apocalypse.] 1. The revelation delivered to St. John, in the isle of Patmos, near the close of the first century, forming the last book of the New Testament. 2. Anything viewed as a revelation; a disclosure.
      Or read the first paragraph of the first apocalypse [perl.com]:
      People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.)
  • I guess that bum I saw downtown the other day was right... The Apocalypse was coming...

  • Sweet! Hyperoperators! (Score:2, Interesting)

    by Fixer ( 35500 )
    I like the way Perl6 is going, I have to say. Though I kind of agree with others, changing
    $a.$b.$c
    to
    $a _ $b _ $c
    kind of bites. Then again, this could also be looked at as readability enforcement. Common cases:

    $a = $b.$c;
    print "Hello: ".$you."\n";

    becomes

    $a = $b _ $c;
    print "Hello: " _ $you _ "\n";

    It is definitely more readable, but I dislike significant whitespace. shrug
    But as to the rest of the proposed changes, I can't wait.

    • > $a = $b.$c;
      > print "Hello: ".$you."\n";
      >
      > becomes
      >
      > $a = $b _ $c;
      > print "Hello: " _ $you _ "\n";

      Or just

      $a = "$b$c";
      print "Hello: $you\n";

      like you can do right now.

      I can't tell yet whether "$a:b" will change, but presumably the Perl5 clarification "${a}:b" would still work.
    • I think it sounds annoying as heck, because I tend to use a lot of _ in my variable names. Things like $foo_bar are a lot more readable than $fooBar, imho-- and allows me to save caps for other purposes like constants and the occasional global.
    • I really dislike having a concatenation operator that's a valid identifier character. There's just no reason for it.

      And I don't completely buy the excuse that we're running out of punctuation characters. If you're going to jumble some of them up and talk about the "Huffman" reason for picking multi-character operators for some and not for others: let's do a little more housecleaning. Get rid of the bit operators as punctuation characters and make them named operators. That frees up some punctuaction for something that's not used very often anyway.

      BTW, if you're under the impression that they're used frequently try:
      for i in `find /usr/local/lib/perl5 -name *.pm`; do if perl -wc $i >/dev/null 2> then perl -MO=Terse $i | grep 'bit_'; fi done >> bitops
      Sure it doesn't pick up everyhing (late compilation), but in the 1056 files I have there I had exactly 7 occurances of bit operators. This does not impress me enough to use valuable punctuation.

  • More eclectic, less practical... (Score:3, Interesting)

    by forehead ( 1874 ) on Wednesday October 03, 2001 @06:51PM (#2386310)
    Before I begin, I know that Perl is Larry's baby and he can do with it what he likes. But I wouldn't be so vocal about this if I didn't care. ;-) That said...

    Maybe it is just me, but the more and more I see what is going on in the perl world, the less and less I want to have anything do with it. The whole
    hyper-operator conecpt is a good example. My thoughs? Just use a fscking for loop. That is what they were designed to do. Larry seems to be going through *great* pains to include as many bizzare syntactic short cuts as you can reasonably string characters on the keyboard to represent. This is not terribly innovative.

    It's starting to diverge from "Practical extraction and report(ing) language"
    and towards "pathetically Eclectic rubbish lister". Personally, I aim a little more towards practical. That was what made it so popular to begin with. Make difficult things easy and hard thing possible was a nice concept. Perl 5 did that well. IMNSHO, Perl 6 seems to be making 100 ways to do the same simple thing all so the developer can opt to use the method with the verbosity level he/she desire, and not making the hard things any easier.

    </rant>
    • Okay. All languages that are Turing complete are equivalent, as you well know. So why do we need more than one language?
      • Convenience. Certain problems are easier to express with a different paradigm (oo vs imperative vs functional, etc). Even concepts within a language class have benefit (e.g. polymorphisim and overloading in oo languages). What I see Larry spending a lot of his time on does nothing to change this. It just gives programmers multiple ways to say (a > 10 && a 20). I say BFD to that. Pick a reasonable syntax and go with it, unless there is a compelling reason to change (so far I haven't seen any reasons more compelling than I'm lazy, let me type it this way instead).
        • Well, hyperoperators seem to be a very convenient way to deal with operations on matrices and tables, no? Makes vector math much more succinct.

          I will agree, alot of the proposed changes don't seem to have alot of immediate application to what I do personally, but I admit their utility.

          But here's an idea in which we can both be happy: Don't use Perl 6. Continue on with 5. Considering the immense amount of v5 code, I doubt highly that it will all suddenly disappear. In fact, I recall from a previous Apocalypse that Larry mentioned the idea of allowing all existing Perl5 syntax, until you use a piece of new syntax.

          Yeah, it's not the greatest of solutions. Perhaps what will happen will resemble C/C++, with many continuing to use the old for quite a while yet.

    • Why, then, does Perl include a 'foreach' operator when a 'for' loop will do just fine? Efficiency. By giving the language a hint as to what you are going to do, it can iterate through the list faster and with fewer resources. I expect that when the implementation arrives, we will find the hyper operators offer a not-insignificant efficiency gain over a simple for loop.


      The point of Perl is not necessarily to provide more than one way to do things, but to make certain types of programming much easier than with other languages. There are things I do in Perl in an hour that would be a week undertaking in C or C++. If enough users are calling for these seemingly esoteric features, add them. The more expressive the language, the more useful.

      • Your FOREACH and FOR example is without merit.

        ripped from perlsyn (man perlsyn):

        The `foreach' keyword is actually a synonym for the `for' keyword, so you can use `foreach' for readability or `for' for brevity.

        I do agree on your point though, you just choose a bad example and topic, since 'Efficiency' for perl *normally* means coding better and faster, not running faster.

        • Yes, I know you can use for as an abbreviation of foreach, but I was not referring such syntactic sugar. I was referring to the difference between the statement for(;;) and the foreach scalar, array.

          For example:

          for (my $j = 0; $j != @ary2; $j++) {
          #do something with $ary2[$j]
          }

          and a foreach loop:

          for my $jet (@ary2) {
          #do something with $jet
          }

          The Perl Manual [perldoc.com] has this to say on the matter.


          It's [foreach] cleaner, safer, and faster. It's cleaner because it's less noisy. It's safer because if code gets added between the inner and outer loops later on, the new code won't be accidentally executed. The next explicitly iterates the other loop rather than merely terminating the inner one. And it's faster because Perl executes a foreach statement more rapidly than it would the equivalent for loop.


          The example has merit and is quite pertinent to the discussion. The foreach construction allows Perl to better understand your intention. It takes advantage of that knowledge to increase its efficiency. Hence my original point.
          • The foreach construction allows Perl to better understand your intention. It takes advantage of that knowledge to increase its efficiency.

            Although if your're _that_ pressed for run-time efficiency, then you shouldn't be programming in an interpreted language in the first place. Sure, "for" is slower than "foreach" but replace all occurrences of the latter with the former is any application and what do you get? Certainly not a perceptible difference.

            What matters in this case is that foreach style loops are easier for humans to parse.
            • Yes, you can get a very perceptible difference in performance with well-coded Perl. And yes, Perl is used for quite a few large scale applications where such efficiency is needed (Slashcode itself comes to mind). Run time efficiency is quite important and you should not dismiss a tool out-of-hand for a minor drawback such as its compilation system.

  • don't jump to conclusions: (Score:4, Insightful)

    by Anonymous Coward on Wednesday October 03, 2001 @09:03PM (#2386673)
    For all of those people who want to jump ship from perl6, all I can say is I'd give it some time. I've been playing around with the syntax in perl6, and I think people are giving it way too much short shrift, without thinking no less. Here, for example, are a couple of equivalent programs in perl6 and perl5:

    Concatenating two arrays together:

    perl5

    my $biggest_index = (@array1 > @array2)? @array1:
    @array2;

    for ($index = 0; $index $biggest_index; $index++)
    {
    $array1[$index] += $array2[$index];
    }

    perl6:

    @array1 ^+= @array2;

    Comparing all of the elements in an array to one another for equality:

    perl5:

    for ($xx = 0; $xx @array1; $xx++)
    {
    ($notequal = 1, last) if ($array1[$xx] ne $array2[$xx]);
    }
    if (@array1 != @array2)
    {
    $notequal = 1;
    }
    else
    {
    $notequal = 0;
    }

    Perl6:

    $notequal = (@array1 ^!= @array2);

    Perl5: setting an element to the first defined item:

    my $element = (defined($a))? $a : (defined($b))? $b: 'default';

    perl6:

    my $element = $a // $b // 'default';

    etc, etc. I could go on, but I'll leave it to damien && his exegesis...

    Now, you could argue that things like the above don't belong in the language proper, and that it would be better to write functions to do them, but believe me, there are a hell of a lot of different low level functions that you can write, all with a little wrinkle here or there that makes them *slightly* different from the functions that you've written before - like doing cmp instead of ==, and so on.

    So don't bolt before you see the final result.. I think its going to be really cool, especially being built on top of parrot....

    Ed

    (ps - as for the OO, I'd *also* hold my tongue if I were you. I've used the OO features of perl5 extensively, and its exceedingly flexible. There are aspects that I don't like (like no type checking of attributes as they are in a hash) but even this can be used to your advantage in programming.

    so its definitely *not* worthless, and definitely something worth checking into. 50,000 line APIs don't just spring up overnight...
    • Alternate perl 5 solutions below:

      Concatenating two arrays together:
      @array1 = (@array1, @array2);

      Setting an element to the first defined item:
      $element = (grep defined, ($a, $b))[0] || 'default';

      note that this last example is also generalizable to lists of arbitrary length...

  • Unicode operators? (Score:3, Funny)

    by iabervon ( 1971 ) on Wednesday October 03, 2001 @11:07PM (#2387000) Homepage Journal
    It'll be so great to be able to use expressions like "x y". Of course, you'll have to define for yourself what an eight teardrop-spoked propeller asterisk does...

    Hmm... slashdot doesn't seem to like my character. Gonna make it hard to ask about my programs...

Slashdot Top Deals

Programmers do it bit by bit.

Close