Slashdot Mirror

← Back to Stories (view on slashdot.org)

Periodic Table of the Operators

Posted by CmdrTaco on 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."

10 of 323 comments (clear)

  1. Oh my sweet Jesus... by btlzu2 · · Score: 5, Interesting

    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.

    --
    Zed's dead baby. Zed's dead.
    1. Re:Oh my sweet Jesus... by spectral · · Score: 2, Interesting

      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 doesn't do that, then you can make it?

      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?

      Even if you use only 5% of this language, reading the code of someone else who uses even just a different 1% of the language is going to be a maintenance nightmare, imho.

    2. Re:Oh my sweet Jesus... by Ugmo · · Score: 2, Interesting

      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. You can do the same thing with Pascal but it takes more code and sometimes more complicated code.

      I had similiar feelings about short-circuit operators and I tend not to use them. My code is longer because of that.

      Have you ever tried using regular expressions in Java or Visual Basic? The Perl operators and syntax make using regexes and matching 1000 times simpler and easier to understand in Perl than those other languages if you ask me.

      I think if you learned Perl and understood all the freaky operators you would actually learn techniques and distinctions that would probably help you in using other languages once you tanslated the ideas into their syntax. (Foreach in Perl is similiar to iterators in C++, at least I use them that way)

      That being said I have been screwed over by the distinction betweeen the string and numeric comparison operators before.

    3. Re:Oh my sweet Jesus... by Waffle+Iron · · Score: 2, Interesting
      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 much easier to comprehend at a glance than the equivalent Perl code would be (for example, no subtle differences between "list context" or "scalar context" depending on exact placement of @s and $s).

    4. Re:Oh my sweet Jesus... by btlzu2 · · Score: 2, Interesting
      Does Perl encourage sloppy programming or does it allow people who aren't concerned about so-called software-engineering to do productive things?"

      You have a good point there and perhaps it's true as far as doing productive things. It breaks when you have to do productive things along with other people and maintain it for future expansion.

      I do think, and this is down to opinion I suppose, that it *does* encourage sloppy programming because fundamental typing is nowhere to be seen. Use this variable over here for one thing, clobber it over there to use it for another. I read on that article you referenced and pretty much got confused by the differing opinions and corrections. Wiki is a pain in the butt to read! :) Here's my view, which I stole from the Java Language Overview on Sun's site:
      One of the advantages of a strongly typed language (like C++) is that it allows extensive compile-time checking so bugs can be found early. Unfortunately, C++ inherits a number of loopholes in compile-time checking from C, which is relatively lax (particularly method/procedure declarations). In Java, we require declarations and do not support C-style implicit declarations.
      Sure, you can write horrible code in Java too--I've done it--but at least it supports a more reasonable structure (interfaces, strong typing). There is no silver bullet language, I realize that, but to me Perl is pretty scary to rely on for nearly any task as I've found going back to maintain old Perl code from various sources.

      I think it boils down to opinion, but mine is very strongly opposed to using Perl as a serious language for anything. If they redesigned Perl completely, cut back 50% on the cruft and structured it more reasonably, I'd not have as much of a problem; however, they're adding more operators and it's remaining weakly typed, so I have no hope.
      --
      Zed's dead baby. Zed's dead.
  2. Brace yourself... by pedantic+bore · · Score: 2, Interesting
    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 "="?

    --
    Am I part of the core demographic for Swedish Fish?
  3. Hear hear! by BerntB · · Score: 2, Interesting
    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.

    --
    Karma: Excellent (My Karma? I wish...:-( )
  4. This is a beautiful diagram by dozer · · Score: 4, Interesting

    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?

    1. Re:This is a beautiful diagram by toby · · Score: 3, Interesting
      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.

      --
      you had me at #!
  5. In support of large languages by smishra · · Score: 2, Interesting
    English (or your native language) is a large language. Very few of us can claim to know it all. However we all use it and are comfortable with it.

    The problem with large languages is not that they are large but that it is very difficult to arrive at a consistent useful description. Our modern languages have evolved over a very long time. A modern theory is that the capacity for language is hardwired into our genes and is the primary differentiator of humans from animals.

    Programming lanaguages on the other hand are small. While Turing completeness may imply that all languages are equivalent, it is easier to interface with languages that most closely match the domain being modelled and are closer to the way we humans think.

    For all this the large number of operators in Perl are not bad as long as they are internally consistent and consistent with the way we think.