Slashdot Mirror
Periodic Table of the Operators
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."
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?
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.
The /. operator is the one that causes your system to grind to a halt.
- Thomas;
___ This sig is in boldface to emphasize its importance!
Does anyone have an URL for a cache of this PDF file?
I really think that looks usefull, if only I programmed in perl.
:)
Anyone want to make something similar in PHP?
Congrats to the author.
paul reinheimer
A mirror location for the PDF of the periodic table: http://condor.madoka.be/various/PeriodicTable.pdf
Where is the WTF operator?
Free Firefox news reader.
Code written with them becomes illegible after that.
Perl 6 is going to be the best thing that ever happened to Python.
The sentance reminded me of the Elements song.... No doubt someone has already started rewriting it for Perl !
TONSIL A (1)
The Official INTERCAL Character Set
Tabulated on page XX are all the characters used in INTERCAL, excepting
letters and digits, along with their names and interpretations. Also
included are several characters not used in INTERCAL, which are presented
for completeness and to allow for future expansion.
Character Name Use (if any)
. spot identify 16-bit variable
: two-spot identify 32-bit variable
, tail identify 16-bit array
; hybrid identify 32-bit array
# mesh identify constant
= half-mesh
' spark grouper
` backspark
! wow equivalent to spark-spot
? what unary exlusive OR (ASCII)
" rabbit-ears grouper
". rabbit equivalent to ears-spot
| spike
% double-oh-seven percentage qualifier
- worm used with angles
< angle used with worms
> right angle
( wax precedes line label
) wane follows line label
[ U turn
] U turn back
{ embrace
} bracelet
* splat flags invalid statements
& ampersand[5] unary logical AND
V V unary logical OR
(or book)
V- bookworm unary exclusive OR
(or universal qualifier)
$ big money unary exclusive OR (ASCII)
c| change binary mingle
~ sqiggle binary select
_ flat worm
overline indicates "times 1000"
+ intersection separates list items
/ slat
\ backslat
@ whirlpool
-' hookworm
^ shark
(or simply sharkfin)
#|[] blotch
Table 2 (top view). INTERCAL character set.
(1) Since all other reference manuals have Appendices, it was decided that
the INTERCAL manual should contain some other type of removable organ.
(2) This footnote intentionally unreferenced.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Google cache
I'm also hosting the PDF directly, here:
PeriodicTable.pdf
user@host$ diff
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
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)
appears at http://www.cdbaby.com/tomleher
Mirror mirror on the (Larry) Wall...
.Mac
Bandwidth courtesy of
_______
2B1ASK1
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.
Mirror of the PeriodicTable.pdf here.
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.
-Rob
Marriage doesn't have to suck!
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
In fact, it does the same thing in Acrobat reader 4 through cxoffice. What gives?
Looks like someone made a bad pdf =P
Either that, or they were on a mac.
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.
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?
Then people will learn why Python is the best thing that ever happened to Ruby.
It was when I first saw what they had planned for Perl 6 that I decided to switch.
WTF(($p?(/.{70}\|$/):(/^\|/))||(&{$\[3]}$/[0])?($p =!$ p):&{$\[$p]}||die("$d"));
Free Firefox news reader.
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.
-fragbaitWait 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! It's 100% OO down to the core and it's simply beautiful! It's Perl done right.
My other account has a 3-digit UID.
Intercal is a joke language (though there is a compiler, natch).
See also brainfuck, whitespace, etc.
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.
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 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.
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.
/(.)/g or the first thing that comes to their mind and moves on.
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 =~
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
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..
But most stuff are quite logical and easy to pick up for a Perl 5 programmer like ... (yada yada yada), etc.
boolean operators,
Lots are straight Perl 5, like .. list ..), { }-use, []-use, \, etc.
eq, ne, (
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...:-( )
I imagine it splits 'words' greater than 50 characters. Happens on all kinds of software. (For example, vBulletin does it too.)
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.
...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.
Don't forget fuckfuck!
The rant is about crappy perl programmers. The argument that it supports best is that many perl programmers are crappy, rather than that perl itself is crappy.
The problem, as I see it, is that perl makes quick-and-dirty hacking so quick and easy (for the experienced) that scalable solutions are put off until they're needed much more badly than in other, more restrictive, languages. That's OK. Here's why:
All engineering solutions -- in computer programming, engine design, city layout, or what-have-you -- have multiple tiers of solution for different sizes of problem. A solution that works well for small things (e.g. a simply carbureted air-cooled gasoline engine to drive a scooter) doesn't work well when scaled up to larger operations (like pushing a supertanker around). You have to use more sophisticated solutions that take time to design and implement, but that win in the larger case.
Applied to programming tasks, perl makes it easy enough to hack together sort-of-working solutions that you can really get a long way with quick and dirty stuff. (by analogy: the VW Beetle, the longest running car model in history [RIP] uses a simply carbureted air-cooled engine. It's not the most powerful car around, but more of them were bought new than any other model of car in history.)
Ease of hacking is not a problem, that's a solution. Sure, closed-loop, fuel-injected, water-cooled engines are more powerful and scalable -- but they solve a different class of problem.
A while ago I remember touring the U.S.S. Blowfin in Pearl Harbor -- it's a WW2 era submarine. One of the most interesting parts of the ship was the little machine shop -- rather than shipping spares of every little thing on-board, they carried loads of pipe and metal stock, and a compact milling-machine-and-lathe setup to make stuff. I remember thinking how similar that was to the Perl attitude of just leaving a big box of tools and parts around, to hook up whatever you need.
Like the little machine shop, perl offers you the ability to do a lot of crufty stuff. It's up to you to know when to be crufty and when to be more careful. The problem is that carefulness and insight are much more rare than hackability. You seem to be ranting about perl, but you're actually ranting about people with poor programming judgement. Those people would write crap in any language.
Perl6 is an awful BUGatorian.
Perl6 is a dangerous BUGatorianic.
open4free ©
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.
So long as **= is consistent with +=, -=, *=, and all the others in that vein then frankly it's quite fine.
/don't/ fit an overlying pattern that I see trouble.
/quite/ such a painful experience. Still, as a recovering Perl user currently revelling in the "oh, it all makes sense!" experience of Python, I hope never to have to do that at all.
It's when you get large sets of operators that
As this argument seems to satisfy many, "Python does this too." I happen to think it's the right approach, and possibly less confusing than having some operators availible in <op>= form but not others. It's also worth noting that at least in Python, if I remember correctly the 'x += y" forms are more efficient than the "x = x + y" forms.
When it comes to Perl 6, I'll be glad to see the alleged OOP support in Perl 5 torn out and thrown away. That way, if I ever have to venture back into Perl I won't find it
Informative parent??? It's a joke! Mirror Mirror on the Larry Wall... cmon, moderators! not even a mirror link there! get with it!!!
I used to like perl, I don't anymore, except for extremely transient glue code.
The goodness of perl: it allows you to design and express the success mode of a program in a clean, compact and, if you are any good, also readable form.
The badness of perl: it makes the task of mapping and trapping the potential failure modes of your program, pragmatically impossible. In particular this relates to "coverage": that for the full set of possible erroneous inputs, the program detects and cleanly handles the error. Loosely typed variables and various forms of DWIM cause a re-multiplication of complexity as each input passes through each operator. Bugs can of this sort can typically only be solved by trace logging, and there is no plausible way to be certain that none such remain.
Compare this to something like eg: ocaml, where there is absolutely no ambiguity about types, where the transformations applied to the input are deterministic for a given type, and where incomplete coverage is a syntax error.
PHP > Perl
oh wait, the crack heads at Perl write it as
PHP gt Perl
What I meant to write was "why are they the same? I'm still trying to figure out how to read this table. First I thought precedence went in one direction, then another, and now I doubt it's represented in the table. So never mind.
Am I part of the core demographic for Swedish Fish?
Since the PDF renders at a downright glacial pace, I rendered it with GhostScript at 75 DPI (actually at 300 DPI followed by an interpolated 0.25x scale, since I couldn't figure out how to get GS to do sub-pixel rendering). Anyways, here it is (174 KB). And may God have mercy on my server.
Range Voting: preference intensity matters
Just one nitpick:
That is, as far as I know, true for all but lisp macros. (Perl 6 changes that situation?)Lisp is the only language I'd rather use than Perl -- for most tasks.
Karma: Excellent (My Karma? I wish...:-( )
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?
The periodic table is useful in spotting trends in the elements. This table shows... no trends. It's just a loose grouping in a visual style resembling the periodic table.
For example, going across a row shows that Atomic Radius decreases while the Electron Affinity increases.
-Dizzle
"I most likely AM so interested in myself."
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."
Just to clarifiy, it does split long URLS to avoid page horizontal page scrolling. It isn't an issue if the poster actually posts a linke with the URL.
The only official source for that was an April Fool's Day Press Release.
The Parrot implementors plan for it to be able to run Python, but the current Python implementors have no current plans to switch development from C to Parrot.
If small operators were to be fused or larger operaters were to be split, how much energy would be released?
I couln't help but laugh when looking at the Periodic table of the Operators and thinking of the criticisms of APL that it had too many operators and was a "write-only" language. At least APL had a simple precedence rule (all code to right has higher precedence and code in parentheses is evaluated first).
APL differentiated between functions, which took values as operands, and operators, which take functions as operands to generate new functions. This seems something that Perl could do to help clean up the definitions of much of its syntax.
In Perl5, idioms were under control some how: We had stuff like regexp, match, search, translate. Context grouping keywords like q, qq, qw: for non-interpreter string, interpreted string, list context. The usual @_ $_ @ARGV $` $& $' $| variables, not including the other ones... Usual __END__ __DATA__ and similar. POD stuff =cut =head1 =item Stream operator = ) Some for slurping $a = ; @b = ; The rest was quite straightforward, except 'advanced regexp' syntax with backtracking that most people don't use, at least not without proper comments. The problem with Perl6 is that Perl5 code won't work anymore, everything you knew about Perl5 doesn't exist anymore, you need Ponie for one part and Perl6 for the remaining. It's like comparing Perl5 with Python. [or your favorite language]. It would have been better to introduce new keywords gradually without breaking source code that currently works, so people can use the new keywords as they need it, that would have create a more smooth learning curve. But currently, you have to learn a new language that has nothing to do with Perl5. Without looking further, assuming you are comming from Perl5 and that you have to maintain some Perl6 library, what does the following do: while ($s=$n.accept()) { print $s.gets; } if +(f($s+%hf)) == +$b { print; } $a = "abc"~$b~$c~$d~"def"~getVar($d); @a ^[{ $^a > $^b ?? 1 :: ($^a,$^b) := ($^b,$^a) }] @b;
@b = + @c;
@a = += @b;
@b = + @c;
@a = += @b;
@a ^+= @b;
@a v+= @b;
Assuming you can see the > operator
on your ASCII non-Unicode editor, instead of ?+?.
Have fun!
He used such a pretty script for some of the lettering, I'm surprised he didn't replace all 's's with 'f's like in old documents.
:) .... and can I get mine on parchement, please?
Instead of "Assignegens", we'd have "Affignegenf". If you actually look at the PDF, you can see how cool it would look in the script he chose.
It will happen in one of two ways:
Programmer writes gobs of Perl code and employer is scared to let anyone else touch it, thus ensuring Job Security (much like C++).
*OR*
Programmer writes gobs of Perl code under employer instruction and so, goes rapidly insane trying to maintain his own nightmare.
Either way, both retire to a trailer and a bait shop, the ultimate goal for all geeks when they get tired of constantly retraining, competing with cheaper labor, working too many hours, and avoiding sex through no fault of their own.
Another problem is, how do you order two variables containing, for instance, 9 and 19? Alphabetically, "19" comes before "9", numerically, 19 is bigger than 9.
That's the first PDF it's taken xpdf more than 10 seconds to open.
That means something, I think.
The submitter, mAsterdam, has misspelled the name of the chart's author. It's Lentczner, not Lentcner. That's T as in "Tsar", C as in "Czar", Z as in "Zorro". (Yes, this is a very inside joke.)
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.
The rest should be reasonably clear to a Perl 5 hacker. Note that the weird parts were not the operators--they were new functions, each of which added some new functionality to Perl.
Hey, you try to find an open nick these days!
In (almost) all seriousness, I thought I saw a Perl extension that included the INTERCAL interleave, select, unary and, or, & xor. Basically all of the unique Intercal operators. I think that would have to be a whole new column in this periodic table if they were included. It has been demonstrated that you can perform all normal calculations using these operators, but it does produce some messy code if you want to do "ordinary" bit manipulation. There are time I do wish for a select operator in my favorite compiler.
/. limitation, and not an oversight on your part.
This table doesn't have the overprinted characters (that have two characters symbols printed in the same space, like the cents symbol (aka "change"), or the hookwork (which I though was its own EBDIC symbol on the old IBM 370's, but I might be mistaken). I know this is a
You bury the best piece at the very end of a nice post. This deserved to have a post of its own. :^)
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Truth is stranger than fiction. The equality operators in perl:
This is called the spaceship operator:
The first dog barks. All other dogs bark at the first dog.
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.
Looking at this "periodic table" of operators reinforced my view that perl is not going to last much longer as a real player in computer languages. There is a complexity threshold in computer languages which, once exceeded, makes people not want to use the language any more. Perl 5 was already pushing that threshold pretty hard, and now perl 6 has just got right off the deep end. Most people are just going to switch to python (I did a long time ago, and never looked back). And even python is getting too complicated!
I think what language designers forget is that humans have to learn that massive rule set before they can use the language effectively (not to mention in order to read other peoples' code). What they should do instead of piling on features is to provide ways for users to add their own features if necessary (provide meta-features if you will). So, for instance, in Haskell you can define your own operators, which have to consist of characters from a predefined operator set. If you are reading Haskell code and see an operator which is not familiar, it's probably part of the application and you know where to look for its definition. Also, you can use any binary function as an operator by surrounding it with backticks. Simple, and no periodic table needed. In lisp or scheme this issue doesn't even come up, because there is no difference between functions and operators at all.
I think computer languages should be judged not so much by how many features they have but by how many features they allow users to add for themselves.
The real trade offs are between the portions that are made available as libraries and the portions that are made available as core features of the language.
When choosing a language for a commercial project the out of box ability to solve a large part of the problem is a big factor.
I'm not sure that Java is strongly typed, though. For example, if I didn't know better, I'd expect that Java containers would hold type information. At least C++ generics allow this. (Java generics don't count. If all I wanted were shorter code without any kind of compile time safety, I could write my own preprocessor to cast to and from Object!)
I think that's not the real issue though.
I can find you dozens of Perl programs that use global variables willy-nilly, have no documentation, expose a wide range of security problems, have massive code duplication, reinvent well-known wheels badly, and show no evidence of design, maintenance, or care.
I'm not sure how static typing can fix any of those problems.
I can also find you dozens of Perl programs that have comprehensive test suites, well-factored code, sane and useful documentation, and well-designed APIs which have had code contributions from multiple authors.
Again, I'm not sure that dynamic typing worked against those projects. In fact, I personaly find it much easier to write test code in languages that allow allomorphism!
I agree that there's terrible code in serious systems and that people ought to be more careful and disciplined. I disagree that static typing is the way to enforce that. If you're worried what novices might do with powerful features, I think it's better to teach them how and when to use those features well than to remove those features from the language, where even the experts can't use them.
how to invest, a novice's guide
Should have been:
:)
I think part of the definition of the real number field is that for any x < y there is a value z s.t. x < z < y
29.999... - 2.99... = 10x - x
I don't think you can just sling around decimal fractions like that without treading close to a division-by-zero fallacy. It's been too long since I did serious math for me to be able to prove it.
I think all you have proved is that the limit of 2.9999... is 3, which is obvious.
If you think you have done otherwise, please write it without relying on decimals.
IIRC there is also a relatively simple proof involving Cauchy sequences.
But it won't fit in this margin?
Well, the problem is that the unicode << >> tags
P ort=>20010,Listen=>5);$ n->accept()))
e ($s=$n.accept())
:: ($^a,$^b) := ($^b,$^a) }] @b;
.= scenarios and others like the Yen operator instead of zip...
didn't display correctly, and that will be a problem with Perl6 among all the other Unicode
and other charset being used.
Ok, another:
#!/usr/bin/perl
use IO::Socket::INET;
$n=IO::Socket::INET->new(Local
$n->listen();
while(($s=
{ print <$s>; close $s; }
Perl 6:
#!/usr/bin/perl
use IO::Socket::INET;
my IO::Socket::INET $n = (LocalPort=>20010,Listen=>5);
$n.listen();
whil
{ $stdout.print($s.getlines); $s.close; }
$s is a socket, but the thing is at first sight,
when I read this, I saw string concatenation...
print if f($s+%h<<f>>) == $b;
is what should have been seen if tags worked,
which is print $_ if f( taking the addition of two scalar one from $s the other from the hash %h
key "f" is equal to $b in numerical context.
$a = "abc"~$b~$c~$d~"def"~getVar($d);
is equal to this in Perl5:
$a = "abc".$b.$c.$d."def".getVar($d);
@a ^[{ $^a > $^b ?? 1
This in place comparision thingy can be found
explained on perl.perl6.language
I agree that we have $^a $^b in Perl5.
The others one which didn't print
is all the possible <<+>> >>+<< scenarios.
@b = >>+<< @c;
@a = >>+=<< @b;
@b = <<+>> @c;
@a = <<+=>> @b;
@a ^+= @b;
@a v+= @b;
http://groups.google.com/groups?threadm=200 21101113810.B7568%40rama.comp.pge.com
Not mentioning the abuse of
From Synopsis 3: Summary of Perl 6 Operators: Unfortunately,
Granted, these are still ASCII (>128) and currently just synonyms, but branching to unicode characters seems like a bad omen to me. Then again, IANA Perl programmer, so maybe I'm just blind to the joys of terse hieroglyphic code.
Precedence runs from almost strictly left-to-right as tightest-to-loosest. The op= forms are the only serious exception. The precedence for each operator is given a numeric value in the upper right.
Note: The Perl 6 language is under active design. While these are the current set of operators, the precedence levels have not been set or even been largely discussed. Therefore, the precedence levels are mostly my own guesses. (Oops, I suppose this post outs me as the author!)
Nicely done, sir!
'jfb
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Am I just reading an old copy? I just noticed that there's no "as" operator. I seem to recall Larry recently mentioning "as" for casting. Am I wrong?
aQazaQa
If you have put all the time into it already, a few hours more wouldn't hurt that much... pretty please?
(-: Then it wouldn't be as good an example for the Perl-hating crowd, either. :-)
Karma: Excellent (My Karma? I wish...:-( )
+1 Informative!
C'mon, do it as a joke, and so people make make lame posts complaining about "moderators on crack" and so forth.
For inventing operators that perl might actually have in version 7!
It's called "isotopes".
I manage to use perl just fine. And I either knew the answers to all those offhand, or I could tell you why you shouldn't write code like that in the first place.
Argument trivially refuted by counterexample.
"Many of them should IMHO not be operators;"
I humbly disagree. Perl (and Perl6, by extension) use the concept of Huffman-encoding source (if something is done many times, it should be trivial to write and read, with the least keystrokes possible);
I prefer:
do_something if -r 'file.txt'
To:
if( readable_file("file.txt") ) {
do_something();
}
and having to implement readable_file as some other stuff.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
An even better table: http://web.mit.edu/dryfoo/www/Info/condiments.ht ml
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Then how on earth did I ever manage to use it?
This statement reminded me of the Douglas Adams quote about people who prove black is white and then get run over at the next zebra crossing.
foobie_bletch() if test_file("foobar", "+r");
Seems more orthogonal.
But less compatible with shell programming, of course... hmm. I'm not certain, on closer consideration.
Karma: Excellent (My Karma? I wish...:-( )
It's very pretty. You should be proud.
--Then how on earth did I ever manage to use it?
I'm not asserting that it's impossible to write programs in Perl. That would be silly, of course.
The question I'm talking about is the relative difficulty of writing well-engineered software in some problem space--i.e., relative to the other languages available.
(I programmed in Perl for a number of years, and I think it was a great step forward in its day and that we owe Larry Wall a great debt. But, I also think Perl's day is (and should be) done, unless a great deal of accreted junk can be jettisoned.) My opinion, of course.
Mike
"Not an actor, but he plays one on TV."
It's a darn sight smaller than English, and you seem to manage that reasonably well.
Search 2010 Gen Con events
Mike
"Not an actor, but he plays one on TV."