×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Periodic Table of the Operators

CmdrTaco posted more than 9 years ago | from the whats-the-atomic-weight-of-a-regex dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

323 comments

Shazzam! (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9289718)

Pyle!

the pdf file (3, Informative)

eille-la (600064) | more than 9 years ago | (#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?

Re:the pdf file (1)

brokencomputer (695672) | more than 9 years ago | (#9289803)

Gnome PDF viewer .131 had no problem loading this in firefox. Also, it renders correctly as long as the background is supposed to be black. :-/

what is up with SPACES in the urls at slashdot? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#9290012)

I have been noticing this lately ... people post a comment with a URL in it, and a space some how ends up in the URL, breaking it. Obviously it's easy to fix the URL and surf to the site, but why is this happening on slashdot.

It happened in a comment I posted yesterday, and now I see it happening all over the place in other people's comments.

Here is a test URL just to see if it breaks it. I will not put any spaces in it at all when I type it.

http://www.nospaces.com/inthisurl/please.html

I bet it will break it. Let's see:

Re:what is up with SPACES in the urls at slashdot? (0, Offtopic)

lvdrproject (626577) | more than 9 years ago | (#9290101)

I imagine it splits 'words' greater than 50 characters. Happens on all kinds of software. (For example, vBulletin does it too.)

Re:the pdf file (2, Funny)

Anonymous Coward | more than 9 years ago | (#9290208)

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... (5, Interesting)

btlzu2 (99039) | more than 9 years ago | (#9289730)

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... (4, Insightful)

BokLM (550487) | more than 9 years ago | (#9289745)

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

Re:Oh my sweet Jesus... (0)

Anonymous Coward | more than 9 years ago | (#9289856)

I love that excuse: it's like saying you'd rather buy assembly-required kits where all parts can fit together "because there should be more than one way to do it". Wake up, programming isn't about getting fancy with coding style, is about consistency, readability and re-use. Unless you only write one-off hacks, of course.

Re:Oh my sweet Jesus... (0)

Fweeky (41046) | more than 9 years ago | (#9290011)

I prefer having more than one way to do it in terms of choosing different algorithms and code styles; whether I want to do it like a script, a procedural or OO app, custom datatypes and objects or native types, language defined loops or methods with control over passed code blocks.. there's *plenty* of ways to do things without giving the language itself huge levels of redundancy; that's a naive and frankly silly way towards having MTOWTDI. But, hey, TMTOWTDI, that's why we have multiple languages :)

Re:Oh my sweet Jesus... (1, Funny)

Roland Piquepaille (780675) | more than 9 years ago | (#9289746)

That code is gonna be NASTY.

That code already is nasty. Ever looked at Perl scripts in the last few years?

Re:Oh my sweet Jesus... (0)

Halfbaked Plan (769830) | more than 9 years ago | (#9290025)

And unlike the camel, perl didn't evolve in a desert. It was invented in a rarified atmosphere.

So it's a hothouse plant, essentially.

That's okay. There's also a following of people who raise African Violets. They have enthusiast magazines, clubs and associations, too.

Re:Oh my sweet Jesus... (2, Interesting)

spectral (158121) | more than 9 years ago | (#9289773)

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... (4, Insightful)

mcc (14761) | more than 9 years ago | (#9289835)

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.

Re:Oh my sweet Jesus... (1)

lightknight (213164) | more than 9 years ago | (#9289902)

Well, maybe.

(Excuse my ignorance in such matters{Perl}), but I think it's the compiler's job (with other languages) to check for conditions likes this (comparing two unlike objects). It catches the mistake, you cast one of the objects one way or another, and use their methods.

Re:Oh my sweet Jesus... (1)

Mr. Piddle (567882) | more than 9 years ago | (#9290035)

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

Re:Oh my sweet Jesus... (0)

Anonymous Coward | more than 9 years ago | (#9290184)

Perl is not C, so 3.0 is identical to 3 or you get your money back

Re:Oh my sweet Jesus... (1)

gorre (519164) | more than 9 years ago | (#9290199)

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

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

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

Vlad_the_Inhaler (32958) | more than 9 years ago | (#9290251)

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... (0)

Anonymous Coward | more than 9 years ago | (#9290220)

That's the whole point of casting -- to tell the compiler/interpretter how to interpret the data. You have this problem with overloaded operators in C++ too. And in PHP and Python.

You could obviate the whole thing with sensible promotion of variables. Though that gets into an interesting case of what the default promotion should be -- to numbers or to strings?

Re:Oh my sweet Jesus... (0)

Anonymous Coward | more than 9 years ago | (#9289840)

It's really no different than the way Perl currently works.

== versus "eq"? I never even think about it. It works because it lets you force both sides to strings, or you can force both sides to be numerical. So you can do things like "1" == "20" and it will convert them to integers before comparing. Or 1 eq 20 will convert them to strings before comparing. This gives the programmer a lot of power.

Re:Oh my sweet Jesus... (1)

bcrowell (177657) | more than 9 years ago | (#9289880)

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 different operators, and require an explicit cast if you want to do a numerical comparison of two strings, for instance.
Option 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. It makes an opportunity for a lot of subtle bugs, e.g., you don't realize that your code is really doing a string comparison rather than a numerical comparison.

Option 3 just sounds like a pain, although I guess some languages do it that way, e.g., I think in OCaml there are separate operators for multiplying integers and multiplying floating point numbers.

Some of the operators might seem needlessly baroque, but they're actually really nice. For instance, the logical operators && and || have synonyms 'and' and 'or', which have lower precedence. That means you can often write complex logical expressions in a very readable way, without lots of parentheses:

a
and
b || c
(Slashcode ate my indentation there -- the two operands of the 'and' are meant to be pushed to the right for readability.)

Re:Oh my sweet Jesus... (1)

SatanicPuppy (611928) | more than 9 years ago | (#9290032)

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.

Re:Oh my sweet Jesus... (0)

Anonymous Coward | more than 9 years ago | (#9289778)

Stick to your Visual Basic then....

Re:Oh my sweet Jesus... (1)

ipjohnson (580042) | more than 9 years ago | (#9289783)

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.

You can write nasty code in any language (1, Insightful)

Anonymous Coward | more than 9 years ago | (#9290017)

As I said in my last interview. You can write nasty code in any language some just lend themselves more to it.
Why do people think that simple language equates to easier programming/comprehension? Hey, maybe we should reduce the number of words in English or the number of letters in the alphabet!

Oops. I said "comprehension". That's a complicated word. It requires understanding a large vocabulary. Perhaps I should have circumlocuted instead by saying "easy to understand"? We wouldn't want to have parsimony and nuance in our expressions...

At some point you have to pay for complexity. If you don't do it at the language level, you'll do it at the phrase, block, unit, or organizational level. How long to learn Brainfuck [thefreedictionary.com] and how long to build a useful program in it?

So apart from some windy griping, only one coherent argument has been presented here to counteract Perl's dada/inclusiveness bent. That was the astute observation that the families of operators are bigger because the types are not explicit and therefore the operation must be explicit instead of relying on context to understand what "a op b" actually really means. However all is not necessarily ideal because now the type of operation disappears from the local context, hence the reason for such reviled ideas as Hungarianization ("aByteP op bByteP").

I find the most unsettling part of Perl is that I always thought scripting languages should be easy to learn: a limitation that makes them poorly suited to large or complex projects. And on the other end of the spectrum, an industrial-strength language should take years to learn properly but once mastered you can build the universe.

Re:Oh my sweet Jesus... (1)

RuneB (170521) | more than 9 years ago | (#9289792)

Possibly worse are languages that let you define your own syntax. Imagine something similar to #define in C, except you could specify what symbols you wanted to use to separate each argument.

The TADS3 language uses this extensively to allow you to define shortcuts when defining an object. You can look at some examples here [ox.ac.uk].

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

Anonymous Coward | more than 9 years ago | (#9289802)

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... (2, Interesting)

Waffle Iron (339739) | more than 9 years ago | (#9290070)

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... (0)

Anonymous Coward | more than 9 years ago | (#9290147)

Yes, I know about the crap that has been shoehorned in. Kinda like the stuff they have been forcing into Java because the designers were too dumb to make a decent language in the first place.

Your example does not make Python worthwhile. You can do the same thing in C++. In Perl it's even easier.

Re:Oh my sweet Jesus... (1)

Waffle Iron (339739) | more than 9 years ago | (#9290206)

Yes, I know about the crap that has been shoehorned in.

And Perl doesn't have any crap shoehorned in? LOL.

Re:Oh my sweet Jesus... (0)

Anonymous Coward | more than 9 years ago | (#9289825)

Hello just testing pls ingore thx

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

Anonymous Coward | more than 9 years ago | (#9289900)

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.

Re:Oh my sweet Jesus... (1)

Kegster (685608) | more than 9 years ago | (#9289908)

At least half of these are already in Perl at the moment, its not that hard to read, better than trying to figure out if someone really wants to test, ie numeric or string equality from context if the operators are the same.

If you can remember what the operators do then it makes it explicit, which is good, you just have top memorise the operators, which could be a pain in the arse.

Sure, you can use it to write nasty code that is impossible to read, but you can do that in practically any language that isn't completely tedious to use.

I use perl because I like the flexibility, and it makes sense to me, if you don't like the way Perl works, use something else, like Python or Ruby, its not as if anyone is pointing a gun at your head forcing you to use Perl.

Re:Oh my sweet Jesus... (2, Interesting)

Ugmo (36922) | more than 9 years ago | (#9289996)

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.

Operators considered optional. (5, Insightful)

mcc (14761) | more than 9 years ago | (#9290018)

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" operator, ^+, is actually just the normal + operator altered by the ^ ("hyper"/"iterate over a list") adverb. So there is at least logic to all of this, and it may be unfair to list every single one of these potential adverbial combinations as a separate operator. Alas, this does not help readability any. Also, a few days ago while reading slashdot, the little "fortune" quip at the bottom of a pageload was "'So far, we've managed to avoid turning perl into APL' -- Larry Wall". Maybe that one should be expunged from the database... ;)

Re:Oh my sweet Jesus... (1)

eyeye (653962) | more than 9 years ago | (#9290134)

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... (3, Insightful)

HeghmoH (13204) | more than 9 years ago | (#9290245)

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.

Undiscovered: the /. operator (4, Funny)

thomasdelbert (44463) | more than 9 years ago | (#9289731)

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

- Thomas;

Re:Undiscovered: the /. operator (1, Funny)

Anonymous Coward | more than 9 years ago | (#9289785)

So the equivalent of Unobtainium in periodic terms then.

Cache? (1)

anonieuweling (536832) | more than 9 years ago | (#9289752)

Does anyone have an URL for a cache of this PDF file?

Re:Cache? (0)

Anonymous Coward | more than 9 years ago | (#9289810)

Is it just me and my Firefox or does the Google pdf-to-cache conversion need some work..?

Re:Cache? (1)

technix4beos (471838) | more than 9 years ago | (#9289817)

Definately needs some work. I think a better approach is to just strip any and all tags from the pdf and present it as plaintext as much as possible.

Wouldn't have formatting issues with text screaming off to the right, like it is now.

Re:Cache? (1)

FLEB (312391) | more than 9 years ago | (#9289995)

Short answer:

Easier said than done.

Long answer:

The only problem with that, though, is that it would need to make educated guesses as to where things like columns are. If not, a two-column layout would get messy, with c1-c2-c1-c2 alternating in the same paragraph.

Most PDFs don't just have "paragraphs" of text. The text is broken up, line-by-line, with positioning information for each (AFAIK). With the positioning info, the lines don't even need to be in the file in the order they're originally shown.

I looked all over. (5, Funny)

Phidoux (705500) | more than 9 years ago | (#9289775)

Where is the WTF operator?

Can't seem to find it... (4, Funny)

mcc (14761) | more than 9 years ago | (#9289855)

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.

Re:I looked all over. (3, Funny)

thomasdelbert (44463) | more than 9 years ago | (#9289874)

Where is the WTF operator?
Here:

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

- Thomas;

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

JCCyC (179760) | more than 9 years ago | (#9289776)

Code written with them becomes illegible after that.

Re:Some of these have a halflife of a few nanoseco (3, Insightful)

BerntB (584621) | more than 9 years ago | (#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 (5, Funny)

Anonymous Coward | more than 9 years ago | (#9289782)

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

Python (1, Funny)

Anonymous Coward | more than 9 years ago | (#9289925)

Then people will learn why Python is the best thing that ever happened to Ruby.

Re:Python (0)

Anonymous Coward | more than 9 years ago | (#9289981)

please exemplify.

To tell the truth (1)

grouse (89280) | more than 9 years ago | (#9289929)

It was when I first saw what they had planned for Perl 6 that I decided to switch.

It sure is... (1)

Dr. Zowie (109983) | more than 9 years ago | (#9290152)

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 (3, Insightful)

aurelien (115604) | more than 9 years ago | (#9290167)

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 craftsmanship
-- put simply: you can commit any dirty hack in a few minutes in perl,
but you can't write an elegant, maintainabale program that becomes an
asset to both you and your employer; you can make something work, but you
can't really figure out its complete set of failure modes and conditions
of failure. (how do you tell when a regexp has a false positive match?)

a person's behavior is shaped by the rewards and the punishment he has
received while not thinking about his own actions. few people habitually
engage in the introspection necessary to break out of this "social
programming" or decide to ignore the signals that other people send them,
so this is a powerful mechanism for programming the unthinking masses.
rewarding idiotic behavior and punishing smart behavior effectively
brainwashes people, destroying their value systems and their trust in
their own understanding and appreciation of the world they live in, but
if you're very good at it, you can create a new world for them in which
all of this makes sense.

to really destroy any useful concepts of how software is supposed to work
together, for instance, the best possible way is to ridicule the simple
and straightforward concepts inherent in Lisp's read and print syntax,
then ridicule the overly complex and entangled concepts in stuff like IDL
and CORBA, which does basically the same thing as Lisp's simple syntax,
and then hail the randomness of various programs that output junk data,
because you can easily massage the data into the randomness that some
other program accepts as input. instead of having syntax-driven data
sharing between programs, you have code-driven glue between programs, and
because you are brainwashed perl idiot, this is an improvement, mostly to
your job security. and once you start down this path, every move forward
is a lot cheaper than any actual improvements to the system that would
_obviate_ the need for more glue code. however, if you never start down
this path, you have a chance of making relevant and important changes.

that's why, if you learn Lisp and become a good programmer, you will
never want to do what people do with perl. as such a good programmer,
one in five managers will notice that you solve problems differently and
will want to hire you to clean up after the perl programmers he used to
be mortally afraid of firing, and you can push any language you want at
this point -- just make sure you can find more programmers he can hire
who know it and always keep your code well-documented and readable -- you
do _not_ want to make any other programming language appear as random as
perl to any manager. perl is already a "necessary evil", but still evil,
while other languages don't have the "necessary" label, so if you screw
up, it will hurt other programmers, too. this problem can always be
minimized by simply being good at what you do. few perl programmers are
actually good at anything but getting perl to solve their _immediate_
problems, so you have an incredible advantage if you're a good Lisper.

I'll concede, however, that it is very important to be able to understand
what perl programmers do. if you don't understand what they are talking
about, you won't understand what they are actually trying to accomplish
with all the incredibly braindamaged uses of hash tables and syntactic
sadomasochism, and you won't be able to see through their charades and
"just one more hack, and I'll be there" lies.

here's a simple rule to use on perl programmers. if a solution is clean
and complete, it will immediately look like a tremendous amount of work
to a perl programmer, which it will: writing code that does the right
thing in perl is incredibly arduous. this is the only positive use for
perl programmers. like a really bad horror movie, where the evil guys
have no redeeming qualities whatsoever and will hate anything beautiful
or good, a true perl programmer will have a strong emotional reaction to
any really good solution: there's no way he can improve on it with his
perl hackery, and the very existence of his expertise is threatened.

then there are good programmers who know and use perl for some tasks, but
more than anything else know when _not_ to use it. they are _very_ rare.

#:Erik

The Elements - Tom Lehrer (3, Funny)

Richard_L_James (714854) | more than 9 years ago | (#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 !

music video, too (Re:The Elements - Tom Lehrer) (1)

retiarius (72746) | more than 9 years ago | (#9289818)

appears at http://www.cdbaby.com/tomleher

Re:music video, too (Re:The Elements - Tom Lehrer) (1)

retiarius (72746) | more than 9 years ago | (#9289865)

"This may prove useful to you someday
perhaps, in a somewhat bizarre set of circumstances."

--Tom Lehrer

corrected to:

http://www.cdbaby.com/cd/tomlehrer

Relevant excerpt from the INTERCAL language manual (4, Funny)

mcc (14761) | more than 9 years ago | (#9289789)

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.

Re:Relevant excerpt from the INTERCAL language man (0)

Anonymous Coward | more than 9 years ago | (#9289987)

Intercal is a joke language (though there is a compiler, natch).

See also brainfuck [muppetlabs.com], whitespace [dur.ac.uk], etc.

Re:Relevant excerpt from the INTERCAL language man (0)

Anonymous Coward | more than 9 years ago | (#9290261)

Don't forget fuckfuck! [chilliwilli.co.uk]

Awful! XD (4, Insightful)

Apage43 (708800) | more than 9 years ago | (#9289813)

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

OMG (1)

vijaya_chandra (618284) | more than 9 years ago | (#9289814)

If this periodic table somehow gets into school textbooks

the number of those who would pick chemistry as their career would definitely exceed those who take up computers
(atleast in our CS-crazy country
you guessed it right. India)

huh (2, Funny)

INeededALogin (771371) | more than 9 years ago | (#9289821)

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 (2, Funny)

Anonymous Coward | more than 9 years ago | (#9289872)

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

There's one of these for Oracle too... (1)

lpangelrob2 (721920) | more than 9 years ago | (#9289844)

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.

Re:There's one of these for Oracle too... (1)

The Unabageler (669502) | more than 9 years ago | (#9289899)

As a perl programmer for the past 5 years, the only ones that don't stick in my head (along with their relative precedence to whatever else I'm doing) are the -x operators.

Hmm.. (1)

Azureflare (645778) | more than 9 years ago | (#9289861)

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 (1)

Azureflare (645778) | more than 9 years ago | (#9289882)

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.

Re:Not just linux (1)

1u3hr (530656) | more than 9 years ago | (#9290181)

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.. (1)

uss_valiant (760602) | more than 9 years ago | (#9289978)

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?

Works with Adobe Acrobat Reader 6.0 (no black areas).
Jaws PDF Editor Version 2.1 is readable, but the rectangle around the periodic table is black instead of white.
I thought the newest version of Jaws PDF Editor was Acrobat 6.0 compatible, strange.
(all on WinXP)

Brace yourself... (2, Interesting)

pedantic bore (740196) | more than 9 years ago | (#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... (1, Informative)

Anonymous Coward | more than 9 years ago | (#9289990)

> Why is "&&" different from "and"? Ditto for "||" and "or", etc. Operator precedence. Look at perldoc perlop

Re:Brace yourself... (2, Informative)

Hanji (626246) | more than 9 years ago | (#9290092)

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.

Re:Brace yourself... (4, Informative)

Dr. Zowie (109983) | more than 9 years ago | (#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.

Re:Brace yourself... (1)

mcc (14761) | more than 9 years ago | (#9290178)

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 an operator that is not used often enough to justify the waste of two characters. It's bad Huffman coding, in other words. Every proposed use of colon in the RFCs conflicted with the ?: operator. I think that says something.
"." is now "~"?

Huh? Well, I hope so-- last I heard "." was becoming "_", leading to the horrific situation where "$a _" and "$a_" have totally different meanings. ~ makes much more sense.

At any rate, they're coopting the "." operator as a dereference operator, the way it's used in java, so it couldn't be stringcat anymore.

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

They should be, but a big chunk of the things on this chart ought to be as well, not the least of which are the charwise operators. The vast bulk of usable perl "operators" are formed from molecules of this sort.

Re:Brace yourself... (1)

WWWWolf (2428) | more than 9 years ago | (#9290217)

The Perl 5 string concatenation operator (full stop) has changed into an underscore in Perl 6. The reason was given ages ago - The full stop is now for a method call, like in many other programming languages. Yeah, I thought it looked ugly the first time I saw that. I don't really care.

I suspect (in other words, guess) the difference with "&&" and "and" will be the same as it is currently: They have different precedence. ("and" being tighter than "&&".) I don't really know.

You may find the Exegesis on the operator issues [perl.com] helpful.

THAT'S A LOT OF NUTS!!!! (2, Insightful)

fragbait (209346) | more than 9 years ago | (#9289969)

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

And those are just the operators... (1)

Per Wigren (5315) | more than 9 years ago | (#9289983)

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.

Perl6 Kitchen Sink: **= as an operator?! (1, Insightful)

Anonymous Coward | more than 9 years ago | (#9290000)

Yes, how often does one have to perform "x = pow(x,y)" - or God forbid - "x = x ** y" - that you would need to shorten it to "x **= y"? This is what is wrong with Perl6 - it has the kitchen sink/second system syndrome. You all know what happens to such projects.

There is more than one way.. (0)

rijrunner (263757) | more than 9 years ago | (#9290047)



If you want to live up to the whole "There is more than one way to do it" slogan, you have to give someone a swiss army chainsaw..

If you think this is scary... (3, Funny)

dexter riley (556126) | more than 9 years ago | (#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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...