Actually, I still hate what they did to the Finder. In OS X I tend to wind up using Bash for many basic tasks, which is basically my judge of how I can tell that a GUI has failed me.
And I never stopped hating that God-awful "Aqua" prison-stripes-interference-pattern-headache scheme. I used third party themes until the day 10.3 got into my hands and I found Apple had finally toned it down.
We're talking about pseudomilitiant extremist Christians in America today, aka the "Christian Right", which is more of a cultural group than a religious bloc. And while there's probably some militant Catholics out there somewhere, they probably don't get to be counted as part of the "Christian Right" club. In fact, that particular movement sometimes seems to hate Catholics evenalmostasmuch as they hate us homosexuals.
No, clearly not all Christians are in with this crowd. And not all Christians are "turning a blind eye" to things like abortion clinic bombings. But within the Christian community a violent minority does exist. And the number of "Christians" that are turning a blind eye, or even to some degree tacitly approving, to the extremists among them is large enough to be rather scary. And the number of Christians who practice their personal religion in a totally healthy, positive and loving way, yet seem to be totally unconcerned that a nontrivial number of people out there are applying the name "Christian" to a religion based essentially around hate, is much larger.
Basically, if you're trying to protest the painting of all Christians with a wide brush, then yes, you're right, good point. But other than that, I don't see how one Christian minority group disapproving of violent tactics makes the actions of another Christian minority group which does approve of violent tactics any less of a "lynching".
SCO is a corporation, which means its officers are protected from legal action stemming from the behavior of the company, unless the behavior becomes SO visible that it becomes an embarrassment to the current presidential administration at a moment that said administration desperately needs to perform lip service to corporate accountability in order to deflect public attention from the fact that their past and planned future behavior is basically to largely ignore any corporate crime that occurs.
That assumes SCO survives the IBM case, the IBM countercase (for damages against SCO), the Redhat Lanham act case (for damages against SCO), and the Autozone and Chrysler cases (which, if those two companies do really well, may end with demanding SCO pay their lawyers fees) and still has anything left to turn on Sun.
Whether or not you believe Sun purposefully tried to prop up SCO in hopes it would damage Linux, that's not a very reasonable assumption to make.
In the absence of the requested discovery items, SCO has had to rely upon some alternative sources for proof.
With repeated statements like this, SCO has shown themselves to be not only in a different conception of reality from IBM, but in a different conception of reality from the case judge.
In this case, the "discovery items" they referred to were basically every single code change, no matter how minor, in the entire history of AIX/Dynix, when IBM has already provided straight-up source to both of these. SCO repeatedly said it "needed" this. The judge flat-out told SCO that this is not relevant to the case, that it's an undue imposition on IBM, and that there's no reason to need that material unless SCO is going on a fishing expedition.
SCO has continued to say, even in court, that IBM has "not provided" its needed discovery-- when they're referring to materials that the judge has specifically ruled IBM doesn't have to provide. In short, SCO is acting as if the judge doesn't exist, sometimes directly to the judge's face.
I keep wondering exactly what impact this sort of behavior-- and repeated failures by SCO to do what is ordered of them-- is having on the judge.
I then wonder if this is going to make the judge less likely to grant SCO things that they want if there's a grounds to reject them.. like the requested delay of trial until next year...
Where does "allowing SCO to delay the inevitable" come in? Despite the fact that public statements on Sun+OSS and SCO's motion to reschedule trial are indeed both mentioned in this Slashdot headline, they don't appear to be related in any way other than that.
And how does Sun publicly contradicting SCO help SCO, exactly?...Okay, yeah, giving SCO something to disagree with does indeed give them something to speak to the press about, but that would imply that every single open-source related news item that occurs would be equally likely to be a covert attempt to give SCO a platform to stay in the news, potentially implicating IBM, ESR, and Andy Tanenbaum. Also, it seems like SCO would have gotten in the news today anyway since they are moving to reschedule their trial with IBM.
By promptly removing all traces of the violating code from their codebase, producing documentation showing that the code was presented to them as an original work, and then sending the lawyers after the person or persons who contributed the code in violation of its copyright to the open source project in the first place-- since, after all, they did consiously commit an illegal act.
If you're asking how the open source project will deal with the fact that merely being accused of something in today's legal system is a significant cost, I believe the SCO case neatly demonstrates that this is not a real problem. The community seems more than happy to support those who are deserving of support, and the SCO case has resulted in the creation of at least one general open source legal defense fund.
Cells have been evolving against this possibility, however, the possibility has been evolving by the same mechanism. Lifeform immune systems are constrained in their ability to adapt by the evolutionary process. But so are viruses, so this isn't much of a problem. HOWEVER, nanotech works outside the evolutionary process. A nanotech virus developed in a lab could rise to a form such that no lifeform immune system has ever seen anything like it in a countable number of years, and from the perspective of "the wild" it would if released appear instantly. It might take lifeform immune systems thousands of years to adapt to the point where they could deal with this totally alien nanotech "thing". That might be in a worst-case scenario enough time for the nanotech to kill many of the lifeforms.
Life is constrained to working with certain sorts of molecules; it needs carbon, oxygen, nitrogen, etc, because those are the elements it knows how to use as fundamental building blocks. It doesn't really need a whole lot of anything else. It needs certain amounts of certain metals and nutrients, but there's no lifeform on earth for whom it makes sense to just, for example, suck up as much iron as possible. A lifeform that attempts to go "gray goo" is mostly going to only be operating on the materials of life, and really is pretty much just going to be attacking lifeforms themselves (which, as you note, the world's current "gray goo" nanomachines-- i.e. infectious diseases-- have been doing). Nanotech doesn't have this constraint. It's possible to imagine, for example, some sort of self-replicating nanobots designed to mine iron ore, which isn't contained very well, gets picked up by the wind and carried to somewhere else, and starts ravaging the countryside.
I don't think these are serious enough concerns at the moment to give us any pause in nanotech research whatsoever, but they're nonzero. Interesting to think about, anyway.
3. Thousands and thousands and thousands of pissed-off Linux zealots buy said book, in order to debunk it, burn it, sit it on the shelf and laugh at it, whatever... 4. Profit!!!
An ingenious plan, but the flaw in it is that slashdot readers can't be bothered to click on the link at the top of the slashdot article so that they can know what they're talking about before they comment. You really think that they're going to actually get up out of the house to buy a book??
Well, the Reuters article says this study came from a company called Hitwise. So, let's see what they have to say.
Hmm, it looks like they've got a FAQ that gives a decent amount of information on their tracking methodology and seems to answer most of your questions. They seem to use a variety of sites and ISPs for tracking, though they're very vague as to what. The link also says that they are, in fact, using standardized definitions for the terms you mention, and they're the definitions given in "the industry standard definitions published by the US Internet Advertising Bureau's Media Measurement Task Force on 'Metrics and Methodology'". I'm not sure where to get these definitions, they aren't immediately turning up on a google search.
Still, that should be enough to give you a good start.
I'm sorry, but that should be "GNU/X". If X is a part of "The GNU System", then we have to give credit to GNU by calling it "GNU/X".
We can do whatever we want. And if the GNU project didn't want their code to be used without that sort of titular attribution, then they shouldn't have released it under the GPL.
Minux was a model operating system included with a textbook on operating system design.
Linus, since he was trying to make a "UNIX-like" operating system and definitely owned a copy of that textbook (since he owned a copy of Minux and used it to compile the early Linux versions on), almost certainly took ideas from this textbook; and, thus, from Minux (since that's what the textbook was about). Assuming he read it.
But that doesn't mean that anything illegal, bad, or "case" worthy came in. I mean... if this is true, it means.. that Linus took ideas from a college textbook. Oh gee, people taking IDEAS from TEXTBOOKS?? WHAT'S NEXT??
The problem isn't the code itself, which will remain GPLed. But the problem is the code by itself isn't as useful since this is the kind of project that requires constant maintenance. Who's going to host the code? More crucially, who's going to maintain it and ensure it remains compatible with new kernel versions and modules? You? Didn't think so.
The fact anyone could host the project doesn't help unless someone actually does...
"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.
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.
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
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.
Slashdot Mirror
Personally, I use KDE because I can get things done.
I use GNOME for the same reason. Of course, the difference here is largely that my definition of "gets things done" is not "acts like Windows".
Actually, I still hate what they did to the Finder. In OS X I tend to wind up using Bash for many basic tasks, which is basically my judge of how I can tell that a GUI has failed me.
And I never stopped hating that God-awful "Aqua" prison-stripes-interference-pattern-headache scheme. I used third party themes until the day 10.3 got into my hands and I found Apple had finally toned it down.
We're talking about pseudomilitiant extremist Christians in America today, aka the "Christian Right", which is more of a cultural group than a religious bloc. And while there's probably some militant Catholics out there somewhere, they probably don't get to be counted as part of the "Christian Right" club. In fact, that particular movement sometimes seems to hate Catholics even almost as much as they hate us homosexuals.
No, clearly not all Christians are in with this crowd. And not all Christians are "turning a blind eye" to things like abortion clinic bombings. But within the Christian community a violent minority does exist. And the number of "Christians" that are turning a blind eye, or even to some degree tacitly approving, to the extremists among them is large enough to be rather scary. And the number of Christians who practice their personal religion in a totally healthy, positive and loving way, yet seem to be totally unconcerned that a nontrivial number of people out there are applying the name "Christian" to a religion based essentially around hate, is much larger.
Basically, if you're trying to protest the painting of all Christians with a wide brush, then yes, you're right, good point. But other than that, I don't see how one Christian minority group disapproving of violent tactics makes the actions of another Christian minority group which does approve of violent tactics any less of a "lynching".
SCO is a corporation, which means its officers are protected from legal action stemming from the behavior of the company, unless the behavior becomes SO visible that it becomes an embarrassment to the current presidential administration at a moment that said administration desperately needs to perform lip service to corporate accountability in order to deflect public attention from the fact that their past and planned future behavior is basically to largely ignore any corporate crime that occurs.
But wouldn't it seem like the rights would most likely be seized by SCO's creditors at that point?
Which, it seems, after the lawsuits settle and damages are assigned, would probably wind up being IBM and Redhat?
That assumes SCO survives the IBM case, the IBM countercase (for damages against SCO), the Redhat Lanham act case (for damages against SCO), and the Autozone and Chrysler cases (which, if those two companies do really well, may end with demanding SCO pay their lawyers fees) and still has anything left to turn on Sun.
Whether or not you believe Sun purposefully tried to prop up SCO in hopes it would damage Linux, that's not a very reasonable assumption to make.
In the absence of the requested discovery items, SCO has had to rely upon some alternative sources for proof.
With repeated statements like this, SCO has shown themselves to be not only in a different conception of reality from IBM, but in a different conception of reality from the case judge.
In this case, the "discovery items" they referred to were basically every single code change, no matter how minor, in the entire history of AIX/Dynix, when IBM has already provided straight-up source to both of these. SCO repeatedly said it "needed" this. The judge flat-out told SCO that this is not relevant to the case, that it's an undue imposition on IBM, and that there's no reason to need that material unless SCO is going on a fishing expedition.
SCO has continued to say, even in court, that IBM has "not provided" its needed discovery-- when they're referring to materials that the judge has specifically ruled IBM doesn't have to provide. In short, SCO is acting as if the judge doesn't exist, sometimes directly to the judge's face.
I keep wondering exactly what impact this sort of behavior-- and repeated failures by SCO to do what is ordered of them-- is having on the judge.
I then wonder if this is going to make the judge less likely to grant SCO things that they want if there's a grounds to reject them.. like the requested delay of trial until next year...
Where does "allowing SCO to delay the inevitable" come in? Despite the fact that public statements on Sun+OSS and SCO's motion to reschedule trial are indeed both mentioned in this Slashdot headline, they don't appear to be related in any way other than that.
...Okay, yeah, giving SCO something to disagree with does indeed give them something to speak to the press about, but that would imply that every single open-source related news item that occurs would be equally likely to be a covert attempt to give SCO a platform to stay in the news, potentially implicating IBM, ESR, and Andy Tanenbaum. Also, it seems like SCO would have gotten in the news today anyway since they are moving to reschedule their trial with IBM.
And how does Sun publicly contradicting SCO help SCO, exactly?
For the VH1 special.
[[Camera slowly zooming in on photo of Linus Tourvalds]]
NARRATOR: BUT BEHIND THE SCENES, THINGS WERE STARTING TO FALL APART.
How will open source negate an actual violation?
By promptly removing all traces of the violating code from their codebase, producing documentation showing that the code was presented to them as an original work, and then sending the lawyers after the person or persons who contributed the code in violation of its copyright to the open source project in the first place-- since, after all, they did consiously commit an illegal act.
If you're asking how the open source project will deal with the fact that merely being accused of something in today's legal system is a significant cost, I believe the SCO case neatly demonstrates that this is not a real problem. The community seems more than happy to support those who are deserving of support, and the SCO case has resulted in the creation of at least one general open source legal defense fund.
- Cells have been evolving against this possibility, however, the possibility has been evolving by the same mechanism. Lifeform immune systems are constrained in their ability to adapt by the evolutionary process. But so are viruses, so this isn't much of a problem. HOWEVER, nanotech works outside the evolutionary process. A nanotech virus developed in a lab could rise to a form such that no lifeform immune system has ever seen anything like it in a countable number of years, and from the perspective of "the wild" it would if released appear instantly. It might take lifeform immune systems thousands of years to adapt to the point where they could deal with this totally alien nanotech "thing". That might be in a worst-case scenario enough time for the nanotech to kill many of the lifeforms.
- Life is constrained to working with certain sorts of molecules; it needs carbon, oxygen, nitrogen, etc, because those are the elements it knows how to use as fundamental building blocks. It doesn't really need a whole lot of anything else. It needs certain amounts of certain metals and nutrients, but there's no lifeform on earth for whom it makes sense to just, for example, suck up as much iron as possible. A lifeform that attempts to go "gray goo" is mostly going to only be operating on the materials of life, and really is pretty much just going to be attacking lifeforms themselves (which, as you note, the world's current "gray goo" nanomachines-- i.e. infectious diseases-- have been doing). Nanotech doesn't have this constraint. It's possible to imagine, for example, some sort of self-replicating nanobots designed to mine iron ore, which isn't contained very well, gets picked up by the wind and carried to somewhere else, and starts ravaging the countryside.
I don't think these are serious enough concerns at the moment to give us any pause in nanotech research whatsoever, but they're nonzero. Interesting to think about, anyway.3. Thousands and thousands and thousands of pissed-off Linux zealots buy said book, in order to debunk it, burn it, sit it on the shelf and laugh at it, whatever... 4. Profit!!!
An ingenious plan, but the flaw in it is that slashdot readers can't be bothered to click on the link at the top of the slashdot article so that they can know what they're talking about before they comment. You really think that they're going to actually get up out of the house to buy a book??
Well, the Reuters article says this study came from a company called Hitwise. So, let's see what they have to say.
Hmm, it looks like they've got a FAQ that gives a decent amount of information on their tracking methodology and seems to answer most of your questions. They seem to use a variety of sites and ISPs for tracking, though they're very vague as to what. The link also says that they are, in fact, using standardized definitions for the terms you mention, and they're the definitions given in "the industry standard definitions published by the US Internet Advertising Bureau's Media Measurement Task Force on 'Metrics and Methodology'". I'm not sure where to get these definitions, they aren't immediately turning up on a google search.
Still, that should be enough to give you a good start.
I'm sorry, but that should be "GNU/X". If X is a part of "The GNU System", then we have to give credit to GNU by calling it "GNU/X".
We can do whatever we want. And if the GNU project didn't want their code to be used without that sort of titular attribution, then they shouldn't have released it under the GPL.
BA-DUM CHING!
Minux was a model operating system included with a textbook on operating system design.
Linus, since he was trying to make a "UNIX-like" operating system and definitely owned a copy of that textbook (since he owned a copy of Minux and used it to compile the early Linux versions on), almost certainly took ideas from this textbook; and, thus, from Minux (since that's what the textbook was about). Assuming he read it.
But that doesn't mean that anything illegal, bad, or "case" worthy came in. I mean... if this is true, it means.. that Linus took ideas from a college textbook. Oh gee, people taking IDEAS from TEXTBOOKS?? WHAT'S NEXT??
I was getting tired of accidentally setting my clothes on fire myself, now I can get a robot to accidentally set my clothes on fire for me
That wierd sort of rattling? Yeah. That's the sound of the open source development process functioning properly... ^_^
"A verbal contract isn't worth the paper it's printed on."
The problem isn't the code itself, which will remain GPLed. But the problem is the code by itself isn't as useful since this is the kind of project that requires constant maintenance. Who's going to host the code? More crucially, who's going to maintain it and ensure it remains compatible with new kernel versions and modules? You? Didn't think so.
The fact anyone could host the project doesn't help unless someone actually does...
== compares the two pointers correctly.
And pointers are represented as ints. Which is what I said, which is that all == can do is compare numbers.
Hopefully, Perl programmers can unlearn this habit when they work with just about every other programming language ever.
Rejecting convenience because someday you may have to work without said convenience does not seem to me to be a logical behavior.
"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.
A quote from the relevant docs. In short, Larry Wall really, really wanted to use the colon for something else.
"." 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.
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
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.