Periodic Table of the Operators

the pdf file by eille-la · 2004-05-30 03:55 · Score: 3, Informative

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?

Re:the pdf file by maswan · 2004-05-30 04:11 · Score: 4, Informative

I put up a mirror of that file here: PeriodicTable.pdf
The current server seems a bit slow to respond, so..
/Mattias Wadenstein
Re:the pdf file by Anonymous Coward · 2004-05-30 05:21 · Score: 2, Funny

Are you sick of having to copy and paste URLs into your address bar, and remove the spaces put there by Slashdot? With amazing new Hyper-Link technology, following URLs is a snap! All you have to do to create one is put this into your post:
<A HREF="your URL here">description of site</A>
Remember to include the http:// in the URL or browsers will think it's a subdirectory of slashdot.org!

Oh my sweet Jesus... by btlzu2 · 2004-05-30 03:56 · 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.

Re:Oh my sweet Jesus... by BokLM · 2004-05-30 04:00 · Score: 4, Insightful

If you don't want more than one way to do it, then Perl is not for you ...

--
wtf.n0x.org
Re:Oh my sweet Jesus... by spectral · 2004-05-30 04:06 · 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.
Re:Oh my sweet Jesus... by Anonymous Coward · 2004-05-30 04:11 · Score: 2, Insightful

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 kinda like using them in C++ or Java, eh? Now try it in Perl where it's built-in (special operators). Seamless, fast, and easy.

The only things I like better about Python are that it has a simple built-in interactive mode, a better object system, and it's easier to integrate into non-Python projects. The language itself sucks though.
Re:Oh my sweet Jesus... by mcc · 2004-05-30 04:19 · Score: 4, Insightful

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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Re:Oh my sweet Jesus... by Ugmo · 2004-05-30 04:49 · 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.
Re:Oh my sweet Jesus... by Waffle+Iron · 2004-05-30 04:59 · 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).
Re:Oh my sweet Jesus... by HeghmoH · 2004-05-30 05:29 · Score: 3, Insightful

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.

--
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
Re:Oh my sweet Jesus... by Vlad_the_Inhaler · 2004-05-30 05:30 · Score: 2, Insightful

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.

--
Mielipiteet omiani - Opinions personal, facts suspect.
Re:Oh my sweet Jesus... by This+Is+Ridiculous · 2004-05-30 05:37 · Score: 2, Insightful

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; Perl has them in the operators. It's a design trade-off.

If you really want a magical equality that Does The Right Thing, the smartmatch operator (~~) does a lot more than the old Perl 5 regex-binding (=~) ever did. You can pretty much hand it two arbitrary objects and it'll do something appropriate with them.

Perl 6 looks like a big language--and really, it is pretty big. The trick to learning it is to recognize the parallels. For example, throughout the language the question mark is used for boolean operations, plus for numeric ops, and tilde for string ops. (The tilde is supposed to remind you of a little piece of string.) This extends to ANDs, ORs, XORs, and NOTs as well--there are the parallel sets of operators ?&, ?|, ?^, ?!, +&, +|, +^, +!, and ~&, ~|, ~^, ~!, along with logical short-circuting &&, ||, ^^, and !, and junctive operators &, |, and &. (Yeah, there's a break in the parallelism there, for hysterical raisins. Junctive operators, btw, allow you to say things like "$foo == 1|2|3", but they're a fair bit more flexible than just that.)

--
Hey, you try to find an open nick these days!
Re:Oh my sweet Jesus... by Jerf · 2004-05-30 05:41 · Score: 4, Insightful

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... by Mr.+Piddle · 2004-05-30 05:48 · Score: 2, Funny

3.0 is identical to 3 or you get your money back

That's unfortunate. Hopefully, Perl programmers can unlearn this habit when they work with just about every other programming language ever. You just can't get around the fact that floating point numbers are constrained to a certain number of bits in RAM, unless special math libraries are used (and those libraries are not used often).

--
Vote in November. You won't regret it.
Re:Oh my sweet Jesus... by Mr.+Piddle · 2004-05-30 05:50 · Score: 2, Informative

You obviously never studied mathematics, 3 and 2.999... are exactly the same.

Programming != what is theoretically true in math. All I got is these 32 or 64 or 80 bits and there isn't any mathemetician of any IQ that can make 2.9999... in IEEE floating point equal 3.0 exactly.

--
Vote in November. You won't regret it.
Re:Oh my sweet Jesus... by imroy · 2004-05-30 06:00 · Score: 4, Informative

You're thinking about strongly typed languages e.g C, C++, Java, C#. In those language variables are only ever of one type. When copying from one type to another, or comparing different types, there are strict rules of "promotion" (i.e we always promote to higher-precision types).

Perl is a weakly typed language. There's three main variable types: scalar, list (array), and hash (associative array). Scalars can be both numerical and text strings at the same time. This is the reason that Perl has different equality tests for numbers and strings. The run-time has to to be explicitly told which comparison to use. For an example of how not to handle this situation, just look at the way PHP does it. When a language is weakly typed, the interpreter/run-time loses information about how certain things are to be done with variables. That information loss must be made up somwhere. In this case, it's the operators.
Re:Oh my sweet Jesus... by mcc · 2004-05-30 06:06 · Score: 5, Insightful

"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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Re:Oh my sweet Jesus... by friedo · 2004-05-30 07:56 · Score: 2

Oh, come now. If you were a real perl programmer you would have written
perl -le 'print "true" if 2.9999999999999999 == 3.0'

:)
Re:Oh my sweet Jesus... by hazem · 2004-05-30 07:59 · Score: 2, Funny

You obviously never studied mathematics, 3 and 2.999... are exactly the same.

I thought that was engineering:

pi =3
g=10m/s^2

or at least close enough for government work.
Re:Oh my sweet Jesus... by Finuvir · 2004-05-30 08:09 · Score: 2, Funny

I was able to gauge my progress through school and college based on the number of significant digits in g. "g is 10", "g is 9.8m/s", "g is 9.81ms^-1", "screw g; you want G!", "G? This is General Relativity!"

--
Why is anything anything?
Re:Oh my sweet Jesus... by Waffle+Iron · 2004-05-30 08:22 · Score: 2, Insightful

Hello? We're talking Perl 6 here. It hasn't even been released yet.
No, OP was expounding on the virtues of Perl 5 vs. other existing languages: "Part of the reason why Perl is so good is that it makes development fast and easy.". Note that it did not say: "will make it fast and easy if and when it is ever released".
Re:Oh my sweet Jesus... by btlzu2 · 2004-05-30 10:24 · Score: 2, Insightful

It's not like having many colors of paint prevents you from making a nice painting, is it?
I'm afraid coding and painting are not even CLOSE to being analogous. Having unnecessary operators and sloppy constructs does NOT make you more expressive in a coding sense. If that were the case, why can I do everything Perl can, and most likely more, in Java than in Perl when Perl has over 140 operators and Java has only 48? Expressiveness is in the algorithms and the approach to a problem, not how many or what type of operators I can have.

The problem a LOT of us have with Perl is that it is a very sloppy, unmaintainable language. You've got tons of people whipping up utter crap in Perl and then when they leave, programmers who use better languages are stuck wading through that garbage to re-write or maintain it. It's happened to me numerous times. I'm quite sick of Perl and the 5,000 ways people write the same scripts.

A couple million of us DO and will continue to.
Great. More work for me when your code falls apart and you can't add simple functionality because of fragile spaghetti code. ;)

--
Zed's dead baby. Zed's dead.
Re:Oh my sweet Jesus... by btlzu2 · 2004-05-30 13:23 · 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.
Re:Oh my sweet Jesus... by devphil · 2004-05-31 06:42 · Score: 2, Insightful

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 ways of doing the same damn thing, and all the minor ways in which they differ. Just to read and maintain it, not to write anything new.

"More than one way" is fine. Anarchy is not.

--
You cannot apply a technological solution to a sociological problem. (Edwards' Law)

Undiscovered: the /. operator by thomasdelbert · 2004-05-30 03:56 · Score: 4, Funny

The /. operator is the one that causes your system to grind to a halt.

- Thomas;

--
___ This sig is in boldface to emphasize its importance!

Re:Cache? by technix4beos · 2004-05-30 04:05 · Score: 4, Informative

Courtesy of Google:

http://www.google.nl/search?hl=nl&ie=UTF-8&q=cache %3Ahttp%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fblog%2 Fcode%2FPeriodicTable.pdf&btnG=Zoeken

--
user@host$ diff /dev/urandom /dev/uspto

PDF mirror by Cond0r · 2004-05-30 04:06 · Score: 5, Informative

A mirror location for the PDF of the periodic table: http://condor.madoka.be/various/PeriodicTable.pdf

I looked all over. by Phidoux · 2004-05-30 04:07 · Score: 5, Funny

Where is the WTF operator?

--
Free Firefox news reader.

Re:I looked all over. by thomasdelbert · 2004-05-30 04:27 · Score: 3, Funny

Where is the WTF operator?
Here:

($p?(/.{70}\|$/):(/^\|/))||(&{$\[3]}<$/[0])?($p=!$ p):&{$\[$p]}||die("$d");

- Thomas;

--
___ This sig is in boldface to emphasize its importance!
Re:I looked all over. by Temporal · 2004-05-30 10:04 · Score: 3, Funny

Man... someday someone is going to write an obfusicated perl version of "rm -rf *" and post it on slashdot, and everyone is going to fall for it.

Some of these have a halflife of a few nanoseconds by JCCyC · 2004-05-30 04:07 · Score: 5, Funny

Code written with them becomes illegible after that.

Perl 6 by Anonymous Coward · 2004-05-30 04:08 · Score: 5, Funny

Perl 6 is going to be the best thing that ever happened to Python.

Re:Perl 6 by aurelien · 2004-05-30 05:15 · Score: 3, Insightful

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 that one. this is
true even if you know perl very well. life is too long to be an expert
at harmful things, including such evilness as C++ and perl.

I once studied perl enough to read perl code and spot bugs in other
people's programs (but later gained the wisdom that this was not an
accomplishment -- spotting a bug in a perl program is like spotting the
dog that brought the fleas), but I don't write in it and I don't ever
plan to use it for anything (part of my new position is quality assurance
for the systems I'm inheriting responsibility for, and part of any
serious QA is removing perl code the same way you go over a dilapidated
building you inherit to remove chewing gum and duct tape and fix whatever
was kept together for real). also, very much unlike any other language I
have ever studied, perl has failed to stick to memory, a phenomenon that
has actually puzzled me, but I guess there are some things that are so
gross you just have to forget, or it'll destroy something with you. perl
is the first such thing I have known.

this is your brain. this is perl. this is your brain on perl. any
questions?

| If I learn lisp well will I be able to do what people do with perl[?]

no, you won't. however, there is a very important clue to be had from
this: what people do with perl is wrong. perl makes a whole lot of tasks
easy to do, but if you look closely, you will see that those tasks are
fundamentally braindamaged, and should never have been initiated. perl
is perhaps the best example I can think of for a theory I have on the
ills of optimization and the design choices people make. most people,
when faced with a problem, will not investigate the cause of the problem,
but will instead want to solve it because the problem is actually in the
way of something more important than figuring out why something suddenly
got in their way out of nowhere. if you are a programmer, you may reach
for perl at this point, and perl can remove your problem. happy, you go
on, but find another problem blocking your way, requiring more perl --
the perl programmer who veers off the road into the forest will get out
of his car and cut down each and every tree that blocks his progress,
then drive a few meters and repeat the whole process. whether he gets
where he wanted to go or not is immaterial -- a perl programmer will
happily keep moving forward and look busy. getting a perl programmer
back on the road is a managerial responsibility, and it can be very hard:
the perl programmer is very good at solving his own problems and assure
you that he's on the right track -- he looks like any other programmer
who is stuck, and this happens to all of us, but the perl programmer is
very different in one crucial capacity: the tool is causing the problems,
and unlike other programmers who discover the cause of the problem sooner
or later and try something else, perl is rewarding the programmer with a
very strong sense of control and accomplishment that a perl programmer
does _not_ try something else.

it's not that perl programmers are idiots, it's that the language rewards
idiotic behavior in a way that no other language or tool has ever done,
and on top of it, it punishes conscientiousness and quality

--
aurelien

The Elements - Tom Lehrer by Richard_L_James · 2004-05-30 04:09 · Score: 3, Funny

which operators are yet to be discovered.

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

Relevant excerpt from the INTERCAL language manual by mcc · 2004-05-30 04:09 · Score: 4, Funny

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.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

PDF Mirror by technix4beos · 2004-05-30 04:12 · Score: 3, Informative

I'm also hosting the PDF directly, here:

PeriodicTable.pdf

--
user@host$ diff /dev/urandom /dev/uspto

Awful! XD by Apage43 · 2004-05-30 04:14 · Score: 4, Insightful

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 by eyeball · 2004-05-30 04:16 · Score: 2, Informative

Mirror mirror on the (Larry) Wall...

Bandwidth courtesy of .Mac

--

_______
2B1ASK1

huh by INeededALogin · 2004-05-30 04:16 · Score: 2, Funny

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 by Anonymous Coward · 2004-05-30 04:26 · Score: 2, Funny

O, a sarcasm detector, thats a real useful operator.

Can't seem to find it... by mcc · 2004-05-30 04:24 · Score: 4, Funny

We may have to wait for Perl 7 for that one. However, if you look under "Quasi Variables/Templars", you will find there is a "yadda, yadda, yadda" operator.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

Really, it's not too bad. by Anonymous Coward · 2004-05-30 04:33 · Score: 2, Insightful

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 list for almost any other language, and it would appear pretty large.

Perl has more operators than other languages, but if you include some of the things this individual is including, I'm not sure it's that much more.

My reaction, too, was something like "whoa! what are all those!" But then when I saw what they were, it didn't seem so overwhelming.

Brace yourself... by pedantic+bore · 2004-05-30 04:36 · 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?

Re:Brace yourself... by Hanji · 2004-05-30 05:02 · Score: 2, Informative

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 low precedence, it's (practically?) guaranteed that you can safely use them for that, and they will be evaluated only after the entire first operand.

--
A Minesweeper clone that doesn't suck
Re:Brace yourself... by Dr.+Zowie · 2004-05-30 05:10 · Score: 4, Informative

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 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.
Re:Brace yourself... by This+Is+Ridiculous · 2004-05-30 06:14 · Score: 3, Insightful

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. The tilde wasn't being used for anything terribly important (1's complement), so he stole it and made something else do 1's complement; it's supposed to remind you of a little piece of string.
Charwise operators?
Allow you to treat a string as a bit vector and perform bitwise operations on it. You can already do this in Perl 5 with the normal bitwise ops--Larry just split them out into separate operators for Perl 6.
And just to be pedantic, shouldn't all the "op=" operators be described as molecules formed from "op" and "="?
Yes, as should the bool/int/bitstring ops, and a lot of other things. That, IMHO, is the main flaw of this table, although I don't really know how to do it better.

--
Hey, you try to find an open nick these days!

THAT'S A LOT OF NUTS!!!! by fragbait · 2004-05-30 04:46 · Score: 2, Insightful

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 everything look like chemistry. Or for the programmers, a C programmer can program C in any language.

-fragbait

Re:Looks great by SHEENmaster · 2004-05-30 04:52 · Score: 2, Informative

Here it is.

--
You can't judge a book by the way it wears its hair.

Operators considered optional. by mcc · 2004-05-30 04:52 · Score: 5, Insightful

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

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

Re:Operators considered optional. by alw53 · 2004-05-30 07:17 · Score: 2, Insightful

>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.

Re:Some of these have a halflife of a few nanoseco by BerntB · 2004-05-30 05:01 · Score: 3, Insightful

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?

--
Karma: Excellent (My Karma? I wish...:-( )

If you think this is scary... by dexter+riley · 2004-05-30 05:20 · Score: 3, Funny

...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.

Re:If you think this is scary... by pjt33 · 2004-05-30 06:10 · Score: 3, Funny

Dexter used to drink a lot, but now he drinks no more:
For what he thought was H2O was H2SO4.

huh? by gumbi+west · 2004-05-30 06:19 · Score: 3, Insightful

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.

Re:huh? by This+Is+Ridiculous · 2004-05-30 07:35 · Score: 2, Insightful

There's no exact pattern, but in general similar operators are grouped together. For an example take a look at the bitwise/charwise/boolean and/or/xor, and the fact that xx (list repetition), x (string repetition), and * (multiplication--like number repetition) are in the same column. Additionally, True Operators below about the midline of the table tend to be lvalues (able to be assigned to), although that isn't quite consistent.

By the way, there is at least one operator that this table predicts should exist: list concatenation. Well, except that you can just push the elements on to the end of the array, or use an idiom like @c=(@a, @b).

(Hmm...could comma be considered the list concatenation operator?)

--
Hey, you try to find an open nick these days!

Hear hear! by BerntB · 2004-05-30 07:15 · 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...:-( )

This is a beautiful diagram by dozer · 2004-05-30 07:22 · 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?

Re:This is a beautiful diagram by MtnViewMark · 2004-05-30 18:00 · Score: 3, Informative

Thank you for the kind comments.

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

- Mark
Re:This is a beautiful diagram by toby · 2004-05-30 21:25 · 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 #!

unfortunately, you still have to READ others' Perl by mkcmkc · 2004-05-30 07:38 · Score: 5, Insightful

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. Perl 6 just takes things completely over the top.

Mike

--
"Not an actor, but he plays one on TV."

Re:Hmm.. by ChrisDolan · 2004-05-30 08:18 · Score: 2, Insightful

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.

In support of large languages by smishra · 2004-05-30 11:08 · 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.

English IS as write-only as Perl can be. by Roman_(ajvvs) · 2004-05-30 13:22 · Score: 2, Insightful

When it comes to people who were never taught set theory (which subsets is part of) or the common use of the term 'programs' in computing, then yes; English is a write-only language. People who use english as a second language come to mind as an immediate example.

Using a relatively obscure subset of Perl is akin to using jargon in a paper. Noone but those "in the know" would fully understand what on earth you're on about. When you want to make yourself understandable to a wider audience it is at times (unfortunately) necessary to lower your vocabulary to the lowest common denominator. But with most programmers being less than adept at social interaction, this concept doesn't get applied to writing code very often.

Which brings us back to this periodic table. It's use is to create a common vocabulary. Chemists use the periodic table as a common framework, so people can understand eachother when they're talking about materials. Sodium (English) = Natrium(dutch) = Na. Most chemistry specialists would identify Na. Not many dutch chemists would easily identify "Sodium". If you had to make sure someone understood you, what would you use? I hope that this table gets wider recognition.

--
click-clack, front and back. I'm not moving this car otherwise.

Slashdot Mirror

Periodic Table of the Operators

64 of 323 comments (clear)