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

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Periodic Table of the Operators 323

Posted by CmdrTaco from the whats-the-atomic-weight-of-a-regex dept.
mAsterdam writes "At his code blog Mark Lentcner writes: "A while back, I saw Larry Wall give a short talk about the current design of Perl 6. At some point he put up a list of all the operators - well over a hundred of them! I had a sudden inspiration, but it took a few months to get around to drawing it..." You might want to take a look at this and think about which operators are yet to be discovered."
This discussion has been archived. No new comments can be posted.

Periodic Table of the Operators More

Periodic Table of the Operators

Comments Filter:

  • the pdf file (Score:3, Informative)

    by eille-la ( 600064 ) on Sunday May 30, 2004 @11:55AM (#9289726)
    http://www.ozonehouse.com/mark/blog/code/PeriodicT able.pdf

    I the only one who saw the adobe acrobat plugin for firefox on his knees loading this?

  • Oh my sweet Jesus... (Score:5, Interesting)

    by btlzu2 ( 99039 ) * on Sunday May 30, 2004 @11:56AM (#9289730) Homepage Journal
    This cannot mean good things for Perl. Look at all of those operators!!!! Correct me if I'm wrong, but isn't that pretty onerous to have a huge chart of possible operators for a language? I'd quite prefer simplifying over adding multiple combinations of ways to doing things. That code is gonna be NASTY.

    All the more reason for me (IMO) to avoid Perl like the plague.

    • Re:Oh my sweet Jesus... (Score:4, Insightful)

      by BokLM ( 550487 ) * <boklm@mars-attacks.org> on Sunday May 30, 2004 @12:00PM (#9289745) Homepage Journal
      If you don't want more than one way to do it, then Perl is not for you ...

      • While that sounds all nice and freedom-loving, that's exactly why any group larger than about 5 people usually gives up on Perl.

        So there's 10 ways to do something. Okay, great, you only need to use one of them to write the code. But it's not the same way I used, and neither of those are the same way as the guy over here used, and the sourceforge[t].net code we just downloaded uses a fourth way, and the new hire wants to use a fifth because "it's the Perl Way."

        So now all of use have to know all 10 way

    • I was going to disagree, but then I looked at it. Apparently orthogonality wasn't much of a concern when creating this language. I realize it's loosely/dynamically typed (the distinction between the two has always been difficult for me), but come on.. different types of compare operators that work on regular variables (one for numbers, one for strings)? Can't the interpreter just say "Oh, one of these is a string, internally. Do it like that. Or, have a special cast or somethign so in the rare cases it

      • Re:Oh my sweet Jesus... (Score:5, Insightful)

        by mcc ( 14761 ) <amcclure@purdue.edu> on Sunday May 30, 2004 @12:19PM (#9289835) Homepage
        come on.. different types of compare operators that work on regular variables (one for numbers, one for strings)? Can't the interpreter just say "Oh, one of these is a string, internally.

        This duality is already a feature of Perl and it actually is a necessity. The reason is that string compare and numeric compare are different desired operations.

        Let us say that perl used == for both string and numeric compare. Now let us say that someone wrote the following statement in a perl program: "3.0" == "3". Does this return true or not? If we perform a numeric compare, then yes. If we perform a string compare, then no. Now, you can point at my example and say that since 3 and 3.0 were both quoted here, clearly the programmer intended for 3 and 3.0 to be treated as strings. However, if rather than literals those had been variables-- maybe taken from user input-- that would have been no such indicators. The language has no way to tell what to do.

        This really so much isn't about types as it is about the fact perl will autobox numbers in and out of strings for you. I'll give you Perl has many features that just make one's head hurt, but this isn't one of them.
        • "3.0" == "3". Does this return true or not?

          Even numerically, good programmers assume this to be always false. Why? Because it isn't deterministic whether "3.0" is actually 2.999999... or 3.0000...0001. Also, "==" does not imply "almost"; it is exact.

          • 40 odd years ago, Algol60 was defined. The 'equality' operator ('=', I think!) was defined as being 'roughly equal' for floating-point numbers.
            This turned out to be a bad thing(tm) so no-one has repeated that particular mistake since.

        • Re:Oh my sweet Jesus... (Score:5, Insightful)

          by Jerf ( 17166 ) on Sunday May 30, 2004 @01:41PM (#9290308) Journal
          However, if rather than literals those had been variables-- maybe taken from user input-- that would have been no such indicators.

          Here is where your argument falls down. Proof by construction: There are a large number of languages of every variety that still manage to have types for that input.

          Your argument is more accurately described as:

          "Perl actively tries to avoid giving types to strings and numbers, and as a result of this desire to not distinguish between the two, the onus is on the programmer to do so. That's how the language solves this problem that other languages solve through stronger typing."

          At this point, one can then go on and debate whether or not this is a good thing, but don't pretend that Perl has no choice. It had all kinds of choice and deliberately chose this system, most likely for backwards programmer compatibility with awk and its other predecessors.

          Perl isn't "autoboxing"; that's a technical term that means that you take simple C++ or Java style scalars and automatically wrap them in an object. Perl is dynamically "looking at" the object as either a number or a string, depending on context; thus, to the programmer, every string is also a number (albiet usually 0) and every number is also a string.

          • Re:Oh my sweet Jesus... (Score:5, Insightful)

            by mcc ( 14761 ) <amcclure@purdue.edu> on Sunday May 30, 2004 @02:06PM (#9290452) Homepage
            "Perl actively tries to avoid giving types to strings and numbers, and as a result of this desire to not distinguish between the two, the onus is on the programmer to do so. That's how the language solves this problem that other languages solve through stronger typing."

            Stronger typing does not automatically solve this particular issue. Look at, for example, C. It uses == for numeric compare and strcmp() for string compare. Strong typing does not help here; ==, as in perl, means only one thing, and that one thing is "compare two numbers".

            Now, you *can* in C++ overload the == operator on a string class you create-- or in Java the equals() method-- to do custom comparisons on specific types. However this then brings up the question of what happens if for some reason you want to do a numeric compare between two string objects. You have to somehow do a conversion to a different object type. Perhaps this is a bit clumsy. So yes, certain applications of strong typing lead to a potential way to trick the language into allowing you to perform the two different operations of string and numeric comparison with only a single operator. However you have unfortunately in doing so introduced ambiguity into your definition of equality. This does not necessarily seem like a win to me.

            It is worth noting that Perl 6 offers the opportunity to strongly type your variables, and this includes numeric types. However it still uses the separate == and eq operators for numeric and string compare even when this strong typing is effect, simply as a design choice. I think this is a good one: there are already far too many situations where an operator or function in Perl behaves in different ways depending on minor details of the context, we do not need another. Again, I assure you, you are better off going to find some other grounds on which to attack Perl. You will not have to look long.

            Incidentally, I used the term "autoboxing" in the sense that Perl is automatically converting data entities from string to numeric types (yes, the variables may not be "typed", but the data certainly can be said to be). I was not aware the term "autobox" referred only to conversions between object and non-object types. Oops.

            • Now, you *can* in C++ overload the == operator on a string class you create-- or in Java the equals() method-- to do custom comparisons on specific types. However this then brings up the question of what happens if for some reason you want to do a numeric compare between two string objects.

              This is a nonissue (unless you like poor design). Operator overloading is a great feature as long as you maintain it consistent and intuitive -therefore, the semantics for operator== should dictate that it always compar

            • Re:Oh my sweet Jesus... (Score:2, Informative)

              by Jerf ( 17166 )
              Stronger typing does not automatically solve this particular issue. Look at, for example, C.

              C is not strongly typed. It pretends it is but it isn't.

              So yes, certain applications of strong typing lead to a potential way to trick the language into allowing you to perform the two different operations of string and numeric comparison with only a single operator.

              This, almost by defition, is bypassing the type system. Here there be dragons....

              However you have unfortunately in doing so introduced ambiguity
      • I guess it's better for there to be operators for each, so there's no ambiguity. But if you didn't want type ambiguity, why not just make variables statically typed?
        I can see three options for how to design the language:
        1. Design it the way it's actually designed: b<c and b lt c are both valid, and mean different things.
        2. Design it with static typing. You declare b and c as either strings or numbers, and b<c means something different in the two cases.
        3. Design it with static typing, have two differen
        • >2. Design it with static typing. You declare b and c as either strings or numbers, and bOption 2 sucks, IMO, because it means when you read the code, you can't tell what it's doing without knowing the types of b and c.

          If the code is properly designed, you either A) do know the types or B(etter)) don't need to. The semantics for x == y should always be the same -do the values compare if assumed both are same type.

          >That means you can often write complex logical expressions in a very readable way, wit
      • Aside from the math issues vis a vis string/int comparing, I'm always leery of letting a program decide for itself the data type that it is recieving. Every time VB does that, its an open door to a buffer overflow.

        Agree completely about reading other peoples perl code, though.

      • but come on.. different types of compare operators that work on regular variables (one for numbers, one for strings)?

        Perl has always had this. All Perl 6 values have a type like Int or Str, but this isn't necessarily useful--I/O in Perl is done exclusively with strings, so without casting (which already exists--the ~, + and ? unary ops, along with the 'as' binary op) all the comparisons would be with strings too.

        Basically, you have to have the typing somewhere. Some languages have them in the values;

    • As I said in my last interview. You can write nasty code in any language some just lend themselves more to it.

      I write perl routinely to help do everything from produce C++ code to parsing log files. Its all in how you use it.

    • Re:Oh my sweet Jesus... (Score:2, Insightful)

      by Anonymous Coward
      Part of the reason why Perl is so good is that it makes development fast and easy. That's what a scripting language should do. It should be high-level and easy to develop in. The extreme flexibility of Perl is a good thing.

      Contrast this to something like Python which I find barely acceptable as a high-level language. The syntax is just as tedious and verbose as something like C++ or Java. Which raises the question, why use the slower Python at all? Try using regular expressions in Python. It is kin
      • Contrast this to something like Python which I find barely acceptable as a high-level language. The syntax is just as tedious and verbose as something like C++ or Java.

        Have you bothered learning the latest feature additions to the Python language? Some of these can make Python just as terse as Perl, especially list comprehension; for example:

        print '\n'.join(dict.fromkeys([ x.lower() for x in file('foo.txt').read().split() if x not in ignore_words ]).keys())

        That's nothing like C++ or Java. And it's

      • One of the distinctions between high-level and low-level languages is understandability. Perl looks like Assembler without indentation.

    • Really, it's not too bad. (Score:2, Insightful)

      by Anonymous Coward
      I'll be the first to admit that Perl can be ugly--it's driven me to an interest in Ruby--but when you really think about it, it's not that many operators.

      Alot of them, for example, are numeric operators that should be familar to most programmers: !=,==,=,&,&&,, and so forth. About a third of them are regex operators. And among those that are left, many are either common Perl operators, or are not that difficult to figure out if you don't know what they are--e.g., "eq".

      I could make up a similar

    • Re:Oh my sweet Jesus... (Score:3, Interesting)

      by Ugmo ( 36922 )
      These constructs exist (or can exist with some work) in all languages even if there are no symbols for them.

      I originally learned programming (formally) with Pascal. We were taught to increment a loop variable with a:=a+1;

      When I learned C I thought the post increment operator was stupid and a waste, invented just so lazy programmers could save typing a few characters (a++ instead of the above). But anyone who uses pre and post increment operators knows it enables you to do some things in a nice compact way

    • Operators considered optional. (Score:5, Insightful)

      by mcc ( 14761 ) <amcclure@purdue.edu> on Sunday May 30, 2004 @12:52PM (#9290018) Homepage
      One of the underlying philosophies about perl is to give the user as many options for doing things as is concievably possible. However, there's certainly no reason you have to take these options or, generally, to know those options are there. I repeat: you do not have to know these operators to use perl 6. There is almost nothing on this entire graph for which you could not get the same functionality in a more clean and readable manner by just doing it a different way.

      There is no doubt that a cleaner and more consistent language would arise from putting all the language functionality into clear and well-organized paths that everyone would use and recognize in exactly the same way. However the thing is, that is not what many people want. And I would posit that the popularity of perl proves that that is not what people want. While this chart may horrify many programmers, the simple fact is that one of the main reasons for the popularity of perl is the freedom offered by all of its shortcuts and bizarre little unnecessary operatorss. Someone programming in, say, Java, will find themselves often having to stop, scratch their heads, and try to remember or look up the method or class in the standard library used to do some trivial thing, or write a trivial function to do it themselves. While the perl programmer just scribbles out &$g =~ /(.)/g or the first thing that comes to their mind and moves on.

      Perl 6's one big problem, from my perspective, is that the language is *so* big that it's unlikely or impossible any one person will be familiar with all of its features. However one of these features-- which is either horrible or very attractive depending on how you look at it-- is that it offers you the opportunity to redefine the syntax. My personal theory is that many organizations which decide to adopt perl 6 internally will use this to just cut out large swaths of the language, cutting perl 6 down to something more streamlined and manageable. That is, in order to ensure everyone can read each other's code, they will be able to just set certain coding standards-- for example, "don't use hyper operators" or "don't alter the perl grammar"-- and then enforce this by requiring everyone to include a lib that simply removes these features from the language. Do something like this, and you're left with a language which is readable yet still perfectly functional and still more attractive in many ways than many other languages.

      This doesn't help though with the reason this is a big problem, though: code reuse. Perl 6 offers so many options that code written by another person or another organization, when it falls in your hands may sometimes appear to have been written in a different language than the one you are used to. And if people have been taking advantage of the syntax-redefinition features, it will literally be in a different language. However, I suspect this will not be an intractable problem for one reason. Perl 6 offers a very robust object system; it is likely that most of the code reuse in perl 6 will be done through modularity and incorporation of objects, rather than simple cut and paste code reuse. This is in fact generally the way that things work in perl 5; people just modularize everything, and learn not to poke too closely at the internals of any class they're given to work with, looking only at the perldocs. Weirdly, despite the illegible code (or perhaps because of it), the perl culture, or at least the perl module community, seems to have developed a tendency to write very exhaustive documentation. Anyhow, we shall see what happens.

      One last thing. This chart is not as bad as it seems. Most of the size of this chart stems from the explosion of "operators" caused by the addition into perl 6 of APL-style "adverbial operators". (I believe the user may define their own adverbs, but I am not sure.) This means that many of the operators on this list are actually compound operators-- for example, the "add the contents of two lists" oper
      • >One of the underlying philosophies about perl is to >give the user as many options for doing things as >is concievably possible. However, there's certainly >no reason you have to take these options or, >generally, to know those options are there. I >repeat: you do not have to know these operators to >use perl 6.

        You can write programs in whatever subset you want;
        but if you want to read someone else's programs you had better know it all. Which is why Perl is a write-only language.

      • unfortunately, you still have to READ others' Perl (Score:5, Insightful)

        by mkcmkc ( 197982 ) * on Sunday May 30, 2004 @03:38PM (#9291077)
        you do not have to know these operators to use perl 6

        Unfortunately, you still have know these operators in order to READ Perl code written by other programmers.

        Perl 5 is already conceptually too large to use [mathdogs.com]. Perl 6 just takes things completely over the top.

        Mike

    • here, have a free clue.

      THEY AREN'T COMPULSORY!
      You don't have to use them, feel free to do things the long way round and pretend you are using another language.

      I'm guessing you don't know anything about perl.

      • Re:Oh my sweet Jesus... (Score:4, Insightful)

        by HeghmoH ( 13204 ) on Sunday May 30, 2004 @01:29PM (#9290245) Homepage Journal
        That's all fine and good until you have to read or modify somebody else's code. Then you're in for a world of trouble, because the operators you like to use and the operators he likes to use will not be the same, and you'll have to look them up.

        If you never get beyond hobby programming, of course, then this is almost never an issue.
        • There is the problem with Perl, lots of people start to learn it and as soon as they can get something to run they think they have mastered it.

          Then they look at someone elses code and realise they actually know bugger all.

          The "problem" is that perl is very forgiving and caters to newbies by having easily accessible features while also catering to experts. Then when the clueless look at decent code their little minds boggle and they start despise perl because it makes them feel stupid.
      • here, have a free clue.
        Do you *have* to be an ass about expressing a different opinion? I don't care if they aren't compulsory. Having too many unnecessary options makes a language sloppy and furthermore, promotes sloppy programming.

        That said, did you enjoy your little "I am superior" posting? Hope so.

  • Undiscovered: the /. operator (Score:5, Funny)

    by thomasdelbert ( 44463 ) <thomasdelbert@yahoo.com> on Sunday May 30, 2004 @11:56AM (#9289731)
    The /. operator is the one that causes your system to grind to a halt.

    - Thomas;
  • I really think that looks usefull, if only I programmed in perl.

    Anyone want to make something similar in PHP? :)

    Congrats to the author.

  • PDF mirror (Score:5, Informative)

    by Cond0r ( 569916 ) on Sunday May 30, 2004 @12:06PM (#9289772)
    A mirror location for the PDF of the periodic table: http://condor.madoka.be/various/PeriodicTable.pdf [madoka.be]

  • I looked all over. (Score:5, Funny)

    by Phidoux ( 705500 ) on Sunday May 30, 2004 @12:07PM (#9289775) Homepage
    Where is the WTF operator?

  • Some of these have a halflife of a few nanoseconds (Score:5, Funny)

    by JCCyC ( 179760 ) on Sunday May 30, 2004 @12:07PM (#9289776) Journal
    Code written with them becomes illegible after that.

    • Re:Some of these have a halflife of a few nanoseco (Score:4, Insightful)

      by BerntB ( 584621 ) on Sunday May 30, 2004 @01:01PM (#9290090)
      Oh, get real. Many of them should IMHO not be operators; the file tests ('-r', etc) are probably there because of compatibility w Perl 5.

      But most stuff are quite logical and easy to pick up for a Perl 5 programmer like
      boolean operators, ... (yada yada yada), etc.

      Lots are straight Perl 5, like
      eq, ne, ( .. list ..), { }-use, []-use, \, etc.

      quite a few are pure C (and Perl 5), like
      --, ++, +=, ==, !=, &&, ||, |=, [array access], etc.

      In short, it's not that different from Perl 5. An indication on the periodic table for what is different from Perl 5 would have been very useful.

      Author, please?

  • Perl 6 (Score:5, Funny)

    by Anonymous Coward on Sunday May 30, 2004 @12:08PM (#9289782)
    Perl 6 is going to be the best thing that ever happened to Python.
    • It sure is, since it means you'll be able to import bits of perl code to do the stuff that's awkward in Python.

    • Re:Perl 6 (Score:3, Insightful)

      by aurelien ( 115604 )
      http://www.underlevel.net/jordan/erik-perl.txt

      it stands for itself...

      * ; ; ; h e l m e r . . .
      | I have been slowly learning lisp over the past year and have had someone
      | mention to me that I should learn perl, for jobs etc.

      the unemployed programmer had a problem. "I know", said the programmer,
      "I'll just learn perl." the unemployed programmer now had two problems.

      having a job is not unimportant, but if knowing perl is a requirement for
      a particular job, consider another one before taking th
      • I love a good rant as much as the next guy, but that one doesn't hold enough water. It's true that perl allows you to do really despicable things in the name of a dirty hack, and it's true that many programmers succumb to the temptation -- but all of the fundamental mechanisms in lisp are present in perl as a strict subset of the language.

        The rant is about crappy perl programmers. The argument that it supports best is that many perl programmers are crappy, rather than that perl itself is crappy.

        The pr

        • I used to like perl, I don't anymore, except for extremely transient glue code.

          The goodness of perl: it allows you to design and express the success mode of a program in a clean, compact and, if you are any good, also readable form.

          The badness of perl: it makes the task of mapping and trapping the potential failure modes of your program, pragmatically impossible. In particular this relates to "coverage": that for the full set of possible erroneous inputs, the program detects and cleanly handles the error.

        • Hear hear! (Score:3, Interesting)

          by BerntB ( 584621 )
          I couldn't have written that better.

          Just one nitpick:

          but all of the fundamental mechanisms in lisp are present in perl as a strict subset of the language.
          That is, as far as I know, true for all but lisp macros. (Perl 6 changes that situation?)

          Lisp is the only language I'd rather use than Perl -- for most tasks.

    • Well, considering that the Perl 6 effort is what kicked off the Parrot bytecode engine, which both Python and Perl plan to use, you're probably right.

  • The Elements - Tom Lehrer (Score:3, Funny)

    by Richard_L_James ( 714854 ) on Sunday May 30, 2004 @12:09PM (#9289787)
    which operators are yet to be discovered.

    The sentance reminded me of the Elements song [songsforteaching.com].... No doubt someone has already started rewriting it for Perl !

  • TONSIL A (1)

    The Official INTERCAL Character Set

    Tabulated on page XX are all the characters used in INTERCAL, excepting
    letters and digits, along with their names and interpretations. Also
    included are several characters not used in INTERCAL, which are presented
    for completeness and to allow for future expansion.

    Character Name Use (if any)

    . spot identify 16-bit variable
    : two-spot identify 32-bit variable
    , tail identify 16-bit array
    ; hybrid identify 32-bit array
    # mesh identify constant
    = half-mesh
    ' spark grouper
    ` backspark
    ! wow equivalent to spark-spot
    ? what unary exlusive OR (ASCII)
    " rabbit-ears grouper
    ". rabbit equivalent to ears-spot
    | spike
    % double-oh-seven percentage qualifier
    - worm used with angles
    < angle used with worms
    > right angle
    ( wax precedes line label
    ) wane follows line label
    [ U turn
    ] U turn back
    { embrace
    } bracelet
    * splat flags invalid statements
    & ampersand[5] unary logical AND
    V V unary logical OR
    (or book)
    V- bookworm unary exclusive OR
    (or universal qualifier)
    $ big money unary exclusive OR (ASCII)
    c| change binary mingle
    ~ sqiggle binary select
    _ flat worm
    overline indicates "times 1000"
    + intersection separates list items
    / slat
    \ backslat
    @ whirlpool
    -' hookworm
    ^ shark
    (or simply sharkfin)
    #|[] blotch

    Table 2 (top view). INTERCAL character set.

    (1) Since all other reference manuals have Appendices, it was decided that
    the INTERCAL manual should contain some other type of removable organ.

    (2) This footnote intentionally unreferenced.

  • Awful! XD (Score:4, Insightful)

    by Apage43 ( 708800 ) on Sunday May 30, 2004 @12:14PM (#9289813) Homepage
    Take a look at this, then take a look at a real periodic table. Yup, that's right, a list of the operators of perl are more complicated than a list of all the atoms that make up everything around you. Mirror (Bittorrent so I wont get myself /. ed) http://www.raiden.se/download/1541/PeriodicTable.p df.torrent

  • Mirror (Score:3, Informative)

    by eyeball ( 17206 ) on Sunday May 30, 2004 @12:16PM (#9289820) Journal
    Mirror mirror on the (Larry) Wall...

    Bandwidth courtesy of .Mac [mac.com]

  • huh (Score:2, Funny)

    by INeededALogin ( 771371 )
    You might want to take a look at this and think about which operators are yet to be discovered

    Yet to be discovered? means... Yet to be thought of... or yet to be documented. I am sure that I could find all of them by spending a few minutes looking through the code.

    Sorry, I am just puzzled by what I am discovering.

    • Re:huh (Score:2, Funny)

      by Anonymous Coward
      O, a sarcasm detector, thats a real useful operator.
  • Admittedly, not nearly as complex as the Oracle one (nothing like a poster of reserved words to keep you company at work). And yet, has Oracle gone away? Not really. I won't get into the orthogonality of the language debate, though. :-p

    This could be pretty helpful for people that can't remember what all those symbols do and yet have to code on a regular basis. Heck, if I were a Perl developer I'd blow this up and print it.

  • Anyone else having problems viewing this pdf in linux? A large part of the pdf is completely black in Xpdf and kghostview.

    In fact, it does the same thing in Acrobat reader 4 through cxoffice. What gives?

    • Not just linux, I just tried it in Acrobat reader on my windows box, and it's also got the black background...

      Looks like someone made a bad pdf =P

      Either that, or they were on a mac.

      • Not just linux, I just tried it in Acrobat reader on my windows box, and it's also got the black background... Looks like someone made a bad pdf =P Either that, or they were on a mac.

        The file info says it was made by Quartz in OS X. Anyway, I was viewing it in Acrobat 4 on Windows, which showed parts obscured by black boxes. But I could delete them with the Touch-up object tool and it looks fine now.

    • Re:Hmm.. (Score:3, Insightful)

      by ChrisDolan ( 24101 )
      It's a PDF v1.4 document. You need Acrobat 5 or higher (or the equivalent) to view it properly. It looks black because the transparent images are not supported in PDF v1.3 and earlier. It could be considered a flaw that Acrobat 4 does not recognize that it's a newer PDF than the application knows how to render.

      The author probably built the chart in Illustrator, which outputs its PDF documents as v1.4 by default.

  • Brace yourself... (Score:3, Interesting)

    by pedantic bore ( 740196 ) on Sunday May 30, 2004 @12:36PM (#9289914)
    I hope there are typos in this table, or else I'm not looking forward to Perl 6 any more... It's going to break my brain to go back and forth:
    • Why is "?:" spelled "??::"?
    • Why is "&&" different from "and"? Ditto for "||" and "or", etc.
    • "." is now "~"?
    • Charwise operators?

    And just to be pedantic, shouldn't all the "op=" operators be described as molecules formed from "op" and "="?

    • Re:Brace yourself... (Score:3, Informative)

      by Hanji ( 626246 )
      Can't answer all of those, but as for
      Why is "&&" different from "and"? Ditto for "||" and "or", etc.
      It's always been that way, at least for perl 5 (I have no earlier perl knowledge)

      and and or have much lower precedence than && and ||, the idea being that the latter should be used for logical expression ($a || $b), and the former for a sort of concise control structure (using short circuit evaluation), i.e.

      open(FIN,$file,"<") or die("Unable to to open $file: $!");

      Since they have such

    • Re:Brace yourself... (Score:5, Informative)

      by Dr. Zowie ( 109983 ) <slashdot@defores t . org> on Sunday May 30, 2004 @01:10PM (#9290137)
      Why is "?:" spelled "??::" ?
      Because "?:" is a logical (short-circuit; control flow) operator. The newer spelling makes it look more like "&&" and "||".
      Why is "&&" different from "and"? Ditto for "||" and "or", etc.
      Precedence, my friend, precedence. That already exists in perl 5. The spelled-out operators have much lower precedence than && and friends -- so you can say
      if( $a = shift and $a=~m/foo/ ) { ... }
      conveniently. ($a gets the shifted value, not the boolean AND of the shifted value and the match).
      "." is now "~"?
      Well, three good ones out of four ain't bad... IMHO this is dumb. The reason is that "->" is now "." (saving some keystrokes, I suppose) -- but I'd rather leave both operators as-is.
      Charwise operators?
      Yes, excellent stuff! I believe that this is actually driven by the PDL [perl.org] application -- there, you have large arrays (e.g. several million entries) and want to do vast vectorized operations on them. Currently PDL uses the perl 5 bitwise operators for vectorized ops -- but that's not a perfect fit, since sometimes you do actually want bitwise operations.
    • Why is "?:" spelled "??::"?

      A quote from the relevant docs. In short, Larry Wall really, really wanted to use the colon for something else.

      The old ?: operator is now spelled ??::. That is to say, since it's really a kind of short-circuit operator, we just double both characters like the && and || operator. This makes it easy to remember for C programmers. Just change:

      $a ? $b : $c

      to

      $a ?? $b :: $c

      The basic problem is that the old ?: operator wastes two very useful single characters for

    • Why is "?:" spelled "??::"?

      Larry Wall felt that inline if wasn't a common enough operation to lose both question mark and colon to. He also likes to point out that, like || and &&, ??:: is a short-circuiting logical operator.

      Why is "&&" different from "and"? Ditto for "||" and "or", etc.

      Different precedence levels. This already exists in Perl 5.

      "." is now "~"?

      Yes. Larry wanted dot to be used for method calls, since objects are becoming much more prevalent in Perl 6. Th

    • Why is "&&" different from "and"? Ditto for "||" and "or", etc.

      What I meant to write was "why are they the same? I'm still trying to figure out how to read this table. First I thought precedence went in one direction, then another, and now I doubt it's represented in the table. So never mind.

  • To people who don't deal with the Periodic Table of Elements on a regular basis (i.e. it isn't part of the job or hobbies), this is overwhelming. I find this interesting because I can see how the brain of a fellow human works.

    Why go this trouble if they will be presented in the index of a book or an order of operations table? He's forced the information into his way of understanding. He's taken the operators and organized them in a manner that he feels they are easy to deal with.

    A chemist can make ever

  • Wait until they add the special variables like $_ and $^ ...
    I'd like to have a chart over how to do simple stuff like accessing a string in an array in a hash.. I always forget where to put that cryptic $\@%-stuff..

    If you like the concept of Perl but hate the cryptic syntax and feel that Python isn't flexible enough without being too verbose, have a look at Ruby [rubycentral.com]! It's 100% OO down to the core and it's simply beautiful! It's Perl done right.

  • If you think this is scary... (Score:4, Funny)

    by dexter riley ( 556126 ) on Sunday May 30, 2004 @01:20PM (#9290205)
    ...remember that unlike Perl operators, you can't overload the chemical elements. Imagine if He meant helium, unless some chemist changed its definition to mean Mercury, or Ununtrium, or anything else!

    Mmm, a bottle of good old H2O! Glug glug. What's this small print? "The oxygen in this molecule has been overloaded to be radioactive, caustic, and-" ack!
    Thud.

  • huh? (Score:4, Insightful)

    by gumbi west ( 610122 ) on Sunday May 30, 2004 @02:19PM (#9290555) Journal
    Okay, can someone explain to me what it means to be to the right or left of another opperator? What is periodic about this table?

    The amazing properties of the periodic table was that you could predict properties of elements that had not yet been discovered, and this amazing property is of use today. For example, we can predict that, chemically, strontium makes a good calcium analog because they are in the same column, and we are right! Strontium is often found in bones where calcium normally is. (this was important when there was a lot of radioactive strontium in fallout and when it decayed it didn't hold the bone together as well.)

    Anyway way, for other properties, next-to relationships are importantand also allows for predictions to be made.

  • Since the PDF renders at a downright glacial pace, I rendered it with GhostScript at 75 DPI (actually at 300 DPI followed by an interpolated 0.25x scale, since I couldn't figure out how to get GS to do sub-pixel rendering). Anyways, here it is [dyndns.org] (174 KB). And may God have mercy on my server.

  • This is a beautiful diagram (Score:5, Interesting)

    by dozer ( 30790 ) on Sunday May 30, 2004 @03:22PM (#9290980)
    Excellent antialiasing, excellent fonts with good kerning, great drop shadows, lots of repititive work assembled pretty much flawlessly... This chart gets an A+ for style (which is pretty rare in the non-Mac Unix world).

    Does anybody know the tool Mark Lentcner used to make it? Illustrator? Could I be so bold as to hope that Sodipodi or Inkscape are now capable of something like this?
    • Thank you for the kind comments.

      I used Omnigraffle 3 (standard edition) running on Mac OS X (10.3).

      - Mark

    • lots of repititive work assembled pretty much flawlessly

      Except for the odd typo (e.g. in junctive elements) - not to disparage a neat, humorously executed piece of work and a clever idea.

      Could I be so bold as to hope that Sodipodi or Inkscape are now capable of something like this

      Hand-coded PostScript is quite capable of this :-) Certainly the PS greybeards pulled off even fancier things that way - 3D with hidden surface removal, etc.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close