Periodic Table of the Operators 323
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."
Oh my sweet Jesus... (Score:5, Interesting)
All the more reason for me (IMO) to avoid Perl like the plague.
Re:Oh my sweet Jesus... (Score:2, Interesting)
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.
Brace yourself... (Score:3, Interesting)
And just to be pedantic, shouldn't all the "op=" operators be described as molecules formed from "op" and "="?
Re:Oh my sweet Jesus... (Score:3, Interesting)
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.
Re:Oh my sweet Jesus... (Score:2, Interesting)
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).
Hear hear! (Score:3, Interesting)
Just one nitpick:
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.
This is a beautiful diagram (Score:5, Interesting)
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?
In support of large languages (Score:2, Interesting)
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.
Re:Oh my sweet Jesus... (Score:3, Interesting)
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!
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.
Re:This is a beautiful diagram (Score:3, Interesting)