There's no rule that patches applied on bugzilla are to be reported upstream!... Upstream devs can register to receive any and all buzilla tickets for their products, if they chose to do so.
Wow, how generous. They distribute software that I write to their users under the same name as my version while potentially applying patches that I may never see unless I go looking for them. Can you see how a bad patch like this might give users the wrong impression about the software I wrote, or how having to check every potential distributor of my software might not be the most enjoyable use of my time?
And, lo and behold the bug will be fixed:
A bug which was never present in a stable release of Perl -- the only reason it was present in the Red Hat version of Perl is because Red Hat took a patch from a development version of Perl and kept applying it even to stable releases of Perl when it was no longer appropriate.
Fast and correct always wins, and the real Perl hackers are working on that.
No released version of Perl ever had this bug. Red Hat pulled a patch from a development version of Perl and maintained it over released versions of Perl which did not need it. That's the source of this bug. The Perl developers fixed this bug before releasing the next stable version of Perl.
There's nothing to counter. When you provide actual evidence (if it's so "well known", you shouldn't be having this much trouble citing actual facts, such as the number of unique operators or precedence levels or grammatical categories in Perl 6 from 2004 and in Perl 6 in 2008 -- the design documents are available in a public Subversion repository, so the source material is absolutely trivial to find in excruciating detail), then there might be something to counter.
Onus probandi is, as usual, on the original claimant.
Feel free to have the last word in this discussion, however.
Languages with straight forward syntaxes that are easy ARE NOT for everyone. There are people who like complex languages like APL and PERL. It gives them a certain satisfaction of being able to "CODE" cryptic programs that others can't do. They are for people who like recursive acronyms; the uber geeks who never get dates and still wear pocket protectors even if you can't see them doing so, or those who like slide rules. If that's you then fine.
...
Now that is a respectful posting as my others have been.
Are you sure "respectful" is the correct word there?
Also:
The chart likely got worse in the last four years.
"Likely" means "I didn't bother to look." You'd rather wave your hands and rant and rave than find out? That's worse than lazy. That's deliberate and malicious ignorance.
Strawman much? How do you expect anyone to take your argument seriously when you can't represent my position with a modicum of accuracy or respect? Why bother wasting your time typing the rest of your post, when you lead off with "Nyah nyah, boo boo! You're a dumb dumb!"
Let's take one other example chosen at random:
The Perl Chart of the Elements is proof enough that perl is overly complex...
First, that chart is four years old. Second, you're taking it out of context if you don't compare it to syntax charts for other languages (and not Lisp, unless you include Lisp's special quoting forms). Third, and this flows from the first objection, Larry has simplified the syntax based on feedback from implementors (including his own grammar parser).
While your premise that simple syntax is always better than "complex" syntax (whatever that means) may be valid, your argument here is worthless.
All I said was that given 5 hours with a decent book, a person learning PHP will be able to accomplish a lot more than the person learning Perl at the end of the day.
Perhaps in the domain of the web, which is PHP's only successful ecological niche. Not all Perl programmers are web programmers.
Rakudo (Perl 6 on Parrot) is part of the monthly Parrot release cycle. We've released a new stable version of Rakudo with Parrot every month since November 2006 -- including a new version yesterday.
Is [Ruby] not a much cleaner and more powerful object oriented language than just about anything else?
No, not really. It's a nice combination of Perl and Smalltalk (and in some ways, a very immature descendant of both), but it's only somewhat syntactically cleaner than Perl (implicit variables magically springing into existence, boo, but the lack of dereferencing syntax and better metaprogramming syntax yay) and no more powerful than Smalltalk (block/Proc distinction, boo).
Oh, you're one of those people. How does Python force people to choose meaningful identifiers, or to factor their code into loosely-coupled units, or to remove extraneous code, or to reduce duplication, or to model the problem domain accurately, or to write effective tests, or to avoid overlong compilation units or... well, there are a lot of things more important to maintainability than indentation.
Perl is a write-only language. Larry Wall knows this, and that's why he's spent so many years trying to make [Perl 6] a clone of Ruby.
I don't believe you know a thing about Larry Wall, Perl 6, or Ruby -- not after a statement like that.
Would you care to make a list of features that Perl 6 has "borrowed" from Ruby? (Would you care to make a list of language features first seen in Ruby? I can. It's awfully short.)
I'd say that closed source, proprietary technologies cause the internet to thrive and progress, and when the open standards people catch up to what most people have been doing for 5 years, it's usually a good thing.
I take it you're unfamiliar with the development of Internet Explorer since approximately 1999.
Slashdot Mirror
How about Firefox? Thunderbird?
I have; Microsoft had something which did this several years ago.
Wow, how generous. They distribute software that I write to their users under the same name as my version while potentially applying patches that I may never see unless I go looking for them. Can you see how a bad patch like this might give users the wrong impression about the software I wrote, or how having to check every potential distributor of my software might not be the most enjoyable use of my time?
A bug which was never present in a stable release of Perl -- the only reason it was present in the Red Hat version of Perl is because Red Hat took a patch from a development version of Perl and kept applying it even to stable releases of Perl when it was no longer appropriate.
That's your prerogative, but I think you may have learned the wrong lesson here.
p5p uses a tool called perlbench to check performance periodically. It doesn't cover every combination of language features, but it's a good baseline.
No released version of Perl ever had this bug. Red Hat pulled a patch from a development version of Perl and maintained it over released versions of Perl which did not need it. That's the source of this bug. The Perl developers fixed this bug before releasing the next stable version of Perl.
They already do. Hiding your email address in the fervent misbelief that spammers care if they have a thousand misses to one hit is security theater.
The proper response is "Do you want to put ads on everything for the rest of your life, or do you want to change the world?"
There's nothing to counter. When you provide actual evidence (if it's so "well known", you shouldn't be having this much trouble citing actual facts, such as the number of unique operators or precedence levels or grammatical categories in Perl 6 from 2004 and in Perl 6 in 2008 -- the design documents are available in a public Subversion repository, so the source material is absolutely trivial to find in excruciating detail), then there might be something to counter.
Onus probandi is, as usual, on the original claimant.
Feel free to have the last word in this discussion, however.
Are you sure "respectful" is the correct word there?
Also:
"Likely" means "I didn't bother to look." You'd rather wave your hands and rant and rave than find out? That's worse than lazy. That's deliberate and malicious ignorance.
... Haydn might have written more symphonies.
Strawman much? How do you expect anyone to take your argument seriously when you can't represent my position with a modicum of accuracy or respect? Why bother wasting your time typing the rest of your post, when you lead off with "Nyah nyah, boo boo! You're a dumb dumb!"
Let's take one other example chosen at random:
First, that chart is four years old. Second, you're taking it out of context if you don't compare it to syntax charts for other languages (and not Lisp, unless you include Lisp's special quoting forms). Third, and this flows from the first objection, Larry has simplified the syntax based on feedback from implementors (including his own grammar parser).
While your premise that simple syntax is always better than "complex" syntax (whatever that means) may be valid, your argument here is worthless.
You can avoid those costs if you can prove that specific compilation units don't need those features.
Prove that a minimal syntax lets you get everything done more easily.
You might be interested in The Sims: Sit Around and Whine For Six Books.
Perhaps in the domain of the web, which is PHP's only successful ecological niche. Not all Perl programmers are web programmers.
Rakudo (Perl 6 on Parrot) is part of the monthly Parrot release cycle. We've released a new stable version of Rakudo with Parrot every month since November 2006 -- including a new version yesterday.
We released a new version of Rakudo (Perl 6 on Parrot) only yesterday, just as we do on the third Tuesday of every month.
Statistics please, not handwaving.
No, not really. It's a nice combination of Perl and Smalltalk (and in some ways, a very immature descendant of both), but it's only somewhat syntactically cleaner than Perl (implicit variables magically springing into existence, boo, but the lack of dereferencing syntax and better metaprogramming syntax yay) and no more powerful than Smalltalk (block/Proc distinction, boo).
You might not be aware that Larry borrowed Python's object model for Perl 5.
Because you know Python and not Perl. Why is that surprising?
Oh, you're one of those people. How does Python force people to choose meaningful identifiers, or to factor their code into loosely-coupled units, or to remove extraneous code, or to reduce duplication, or to model the problem domain accurately, or to write effective tests, or to avoid overlong compilation units or... well, there are a lot of things more important to maintainability than indentation.
I don't believe you know a thing about Larry Wall, Perl 6, or Ruby -- not after a statement like that.
Would you care to make a list of features that Perl 6 has "borrowed" from Ruby? (Would you care to make a list of language features first seen in Ruby? I can. It's awfully short.)
I take it you're unfamiliar with the development of Internet Explorer since approximately 1999.
I believe you mean "distribute", not "use".