Which parts of "We release a stable version of Parrot on the third Tuesday of every month
What makes that version "stable"? It changes, as you point out yourself, once a month, passing countless new unit tests. It codes to an evolving spec and is targeted by an evolving compiler.
You can check out the past seven years of the project from our public Subversion repository. Do you live in a bizarro post-existential world where completion precedes existence?
I live outside the military-industrial complex, so in my world, progress reports don't equate completion.
In the case of Perl 6, that would mean [doing exactly what you're doing]...
[...] [Why] are people working on Pugs at the moment?
Why do some people watch football and others lacrosse? Why doesn't everyone do everything exactly the way you say precisely when you say? Why aren't volunteers fungible? De gustibus non est disputandum! It's so unfair!
It seems you still fail to see that you are NOT "doing exactly" what I suggested. Perl 6 is still plodding along as a tangle of vaguely correlated individual agendas.
There is progress, yes, but is there convergence?
You're using the greatest research and publication tool known to mankind to ask a question you could answer for yourself!
That is considerably harder than it might appear to you, as the websphere for Perl 6, like the project itself, is littered with false starts and dead ends.
We publish daily statistics on Rakudo's progress passing the Perl 6 specification tests.
I still have no idea what the canonical source of these statistics would be. What I found was this plot, according to which there is NO convergence, as the number of passed tests grows more slowly than the number of overall tests.
I suspect this shall be my final post in the thread.
Also, as modest as you believe this amount to be, it is, to my knowledge, vastly more cash funding than Perl 5 has received over its existence...
Untrue. O'Reilly funded Larry primarily to work on Perl 5 for several years
... and so did NetLabs. I know. That's why I wrote "cash funding", and discussed the sponsored employment situation in my next sentence, which you chose to omit.
and ActiveState has paid several people to work on Perl 5 as well. I don't have exact dollar figures for any of those, but if my understanding is correct, the total spent primarily to develop Perl 5 exceeds the $200k spent on Perl 6.
I'm sure sponsored employment for Perl 5 exceeded the $200K spent by TPF. However, are you claiming that this practice simply does not exist at all for Perl 6?
I don't see how it addresses my point that Perl 6 consumed substantial resources, a considerable fraction of which could otherwise have gone to Perl 5.
That's RIAA/MPAA/BSA math.
Bah. Only a Nazi would use that line of argument.
Volunteer interest and effort is not fungible. It never has been. It never will be.
My discussion was primarily about MONEY, which by definition IS a fungible resource.
As for volunteer effort, the picture is less clear. Some people, like yourself, have continued to contribute to Perl 5. Others, by refocusing their energies on Perl 6, may have done Perl 5 a favor as well.
Besides, it's not like Perl 5 and CPAN modules used to come without extensive unit tests before the glorious Perl 6 revolution introduced them.
I hate the argument from authority, but you're arguing with the guy who wrote the fundamental testing library that kicked off the pre-Cambrian explosion of testing in Perl 5.
I assume you're talking about Test::MockObject. I have no idea how many CPAN modules are using that (there seems to be no dependency cross reference). Of the subset of 593 modules ported to fink packages, a grand total of 9 (1.5%) seem to use Test::MockObject, of which 8 are Catalyst related. Could it be that you have a somewhat inflated sense of your role in history?
Yes, there were tests -- but they were inconsistent, often of mediocre quality, and poorly understood.
I submit that the world of CPAN was not quite as void and without form before you entered it as you make it out to be, and that you did not cast as much light into it as you believe.
I noticed that you did not choose to reply to my paragraph about the Perl 6 spec still appearing to be far from complete.
I prefer to discuss facts, not subjective impressions.
Does this mean that you're denying the fact that the Perl 6 spec is nowhere near complete?
I'm not all that interested in criticizing individuals.
Individuals create projects.
Or, in the present case, FAIL to create them.
I'm sure if you donate years of volunteer work to a project and some random anonymous Internet crank
It's fascinating how somebody who uses their nom de plume even for their published books gets bent all out of shape over someone else using a chat handle.
whined all over about how awful your project management skills are, how you'll never finish, how you can't communicate, and how you've killed other valuable projects wasting away your time and skills, you might feel a little bit criticized as well.
I've been on the receiving side of that, lived to tell, and eventually figured out which part of the criticism was justified.
However, for a project that needs to ship, a lack of shipping driven people, or failing to put these people in charge at some point, is a fatal flaw.
I welcome your reasoned and researched suggestions for how to ship faster then. [...] Throw away lots of code and rewrite everything on the shiny new VM of the month?
In fact, I believe that the launch of Parrot was the original sin that truly doomed Perl 6. Doubling down on the scope of a complex project by trying to over-generalize a subproject never made sense to me.
Cut back on features?
Naturally, yes. That's how you generally get complex projects to ship: Figure out a reasonable, self contained subset of the totality of things you want to do and stop working on everything not part of that subset until you've shipped that.
In the case of Perl 6, that would mean:
Completing the spec.
Adding only those features to Parrot that are indispensible to support the Perl 6 spec
Finishing Rakudo to implement that spec
Seems self-evident, doesn't it? But if it is, why are people working on Pugs at the moment?
... and quite a bit of it by press release.
Show me a press release from the past three (I believe even four) years which promises a target date or future work that we haven't accomplished.
Yes, that may have been the point at which the sliding 18 month release window was dropped. By then, a good part of the PR damage was done, however (It's not like DNF got a lot of publicity lately either).
Meanwhile, I'll show you over a year and a half of monthly stable Parrot releases, which include the Rakudo implementation -- delivered on the third Tuesday of the month, showing visible, stable, regular progress.
According to the published records, the Perl Foundation awarded at least $200K in grants for Perl 6 development during 2000-2006.
That could buy two years of a modestly-paid software developer's time (figure in self-employment tax, health care, et cetera). TPF crammed two funded developer years into six calendar years for Perl 6, and it's still not done. (We might be up to four funded developer years for the specification, the test suite, a virtual machine, and the language implementation.)
Nothing here that I disagree with, but I don't see how it addresses my point that Perl 6 consumed substantial resources, a considerable fraction of which could otherwise have gone to Perl 5.
Also, as modest as you believe this amount to be, it is, to my knowledge, vastly more cash funding than Perl 5 has received over its existence (total funding is hard to estimate, because prior to Perl 6, a lot of the funding consisted of companies allowing developers to spend part - sometimes the majority - of their time on Perl development; I don't know to what extent this practice has persisted).
No one has claimed that Parrot or Perl 6 is a "stable, shipping product" right now. If you really want to claim that this makes the entire project "vaporware", please feel free to apply that moniker to Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1, and a few hundred thousand other projects in progress -- at least, if you're at all interested in applying words fairly.
The reason I used that word is that Parrot was (a) announced with great clamor and (b) seven years later, still is not shipping. I don't think these criteria apply to any of the projects you cite.
While the Perl 6 project may have attracted some of this funding, and some of the Perl 6 work was backported to Perl 5, I very much doubt that this adds up to being a net benefit for Perl 5.
You may find it interesting to hear that the reason Perl 5 (for one example) has orders of magnitude more core tests than Ruby or Python (and let's not mention how much the culture of testing has permeated the CPAN) is a direct result of the Perl 6 project.
Again, I'm not denying that SOME of the Perl 6 work has benefited Perl 5. My question is whether Perl 5 got $120K worth of benefits (or whatever you consider a fair estimate of funding siphoned off by Perl 6). Besides, it's not like Perl 5 and CPAN modules used to come without extensive unit tests before the glorious Perl 6 revolution introduced them.
Also, I'd love to see your list of widely-available, cross-platform C99-conforming compilers -- as someone who writes a fair amount of C code to run across several operating system and compiler combinations, I can think of several vendors who can't seem to support a decade-old C standard.
Fair enough. "abound" was not my choice of words. At least C compiler vendors have a published standard to be held to - I noticed that you did not choose to reply to my paragraph about the Perl 6 spec still appearing to be far from complete.
I know too few of the current core contributors to decide whether they lack focus on shipping, or the authority to make the others focus.
That would have made an interesting disclaimer to your previous post, though I suspect it's much easier to criticize several anonymous strangers in bulk for their perceived shortcomings.
I'm not all that interested in criticizing individuals. What is evident is that the PROJECT these individuals have pursued has been a massive failure.
I also don't think that lack of a focus on shipping is necessarily a "shortcoming" in an individual. There are plenty of people who are successful and productive, despite not being particularly shipping driven (and in many cases, probably BECAUSE of it). However, for a project that needs to ship, a lack of shipping driven people, or failing to put these people in charge at some point, is a fatal flaw.
We do nearly all of our work in public,
... and quite a bit of it by press release.
We've made plenty of mistakes worth criticizing, yet most of the criticism we get is from people who've never looked at any of our work (and certainly none of our recent work).
Ship it, and maybe you'll get the better class of critics you feel you deserve.
Perl 6 has made huge strides since 2000. The question is whether progress of the project will ever catch up with the goal posts.
Umm... the goalposts are set. The language spec is done.
So did it get completed between the time you last posted and it was "largely" done, and now? Congratulations!
The test suite is being built. All that's left is to implement it, and that's being done as we speak. What else do you want?
I don't want "being done". I want "done".
After eight years, the best you can say about the language specification is that it's "largely" complete?
Last I checked, the C language spec was still being worked on.
The THIRD iteration, after the first two iterations were DONE, FINAL, and widely implemented.
There's a difference between regular iterations and continuous tinkering.
And yet, C compilers abound.
C compilers implementing C89 or C99, the COMPLETED iterations.
As I understand it, there are a few places where work is still being done, but implementations can, and are, building on the existing spec, because it's *finished*.
You keep contradicting yourself. Are you sure you know what "finished" means? To the best of my knowledge, there isn't even a complete DRAFT available to the public. In what appears to be the most authoritative list, about half the chapters have not even been published as a draft, and about half of the rest are still marked as "DRAFT", so presumably not final.
Besides, you took one small quote and asked "is that best best you can say?".
I'm quite serious. Ada, which was a huge effort and must have been bogged down in enormous amounts of red tape (with both the DoD and a standards organization involved), went from CFP to published standard in 6 years. Perl 6 does not have a complete draft after 8 years.
Funny how you completely ignored the rest, such as the test suite,
I'll grant that this is a good thing to have.
and the two ongoing implementations.
I'd gladly settle for ONE, FINISHED, USABLE implementation.
As interesting as having Perl 6 implementation in Haskell is from an academic point of view, it's about the least likely practical deployment platoform I can think of.
Perl 6 keeps siphoning off mindshare and developers.
Uhh... okay. I can't say I've seen that, but if you say it's true, I guess it must be...
One of the concrete ways this manifests is in the funding of Perl 5 and Perl 6. According to the published records, the Perl Foundation awarded at least $200K in grants for Perl 6 development during 2000-2006. While the Perl 6 project may have attracted some of this funding, and some of the Perl 6 work was backported to Perl 5, I very much doubt that this adds up to being a net benefit for Perl 5.
despite the fact that you contradict yourself in the very same sentence, pointing out, as I already have, that Perl 5 continues to move forward.
Yes, the Perl 6 effort has not killed Perl 5 progress entirely. That does not mean it hasn't hindered it.
Parrot threatened to throw other scripting languages into a similar state of confusion
Because it'll provide a new platform to target, much like the.NET CLR or the JVM?
It's not the "new platform" that is the problem, but the vaporware existence of a platform that after more than 7 years still isn't shipping in stable form. Again, the distinction between stable, shipping products and endlessly evolving projects seems to elude you.
For all the "progress" and "huge strides", Perl 6 still seems to lack an authoritative voice (whether that of a single person or a small group) with a single minded focus on convergence and shipping, and until that voice emerges, I'm pessimistic about Perl 6 ever shipping.
Would you care to give a list of name of people that group isn't? I can give you a list of names that group is. I'm curious if you've paid enough attention to cross off every name on my list.
I'm afraid I'm unable to parse your request with sufficient confidence to know what exactly you'd like me to list. Also, I fear you're asking me to discuss which people I don't consider focused on convergence and shipping, and I will not do that. I know too few of the current core contributors to decide whether they lack focus on shipping, or the authority to make the others focus.
Instead, let me give you a counterexample: For a while, Chip Salzenberg was the Parrot pumpking, which raised my hopes for Perl 6. As the Perl 5.004 pumpking, Chip had exactly the focus that I feel is missing from Perl 6 today.
I explicitly said there *wasn't* an imminent release.
Which is the Perl 6 problem in a nutshell.
What I said was that Perl 6 is making huge strides,
Perl 6 has made huge strides since 2000. The question is whether progress of the project will ever catch up with the goal posts.
For all the "progress" and "huge strides", Perl 6 still seems to lack an authoritative voice (whether that of a single person or a small group) with a single minded focus on convergence and shipping, and until that voice emerges, I'm pessimistic about Perl 6 ever shipping.
In fact, the longer development drags on, the more likely the developers are to self select for those who are perfectly content to live in a permanent state of daily development snapshots.
Until I see a schedule, the comparison to DNF sticks.
Only if you don't understand the two projects. DNF has an ever-changing target of requirements and specifications... hell, it's changed engines, what, three times? Perl 6 has a largely complete language specification,
After eight years, the best you can say about the language specification is that it's "largely" complete?
Is there still a ton of work to do? Absolutely! But it's *far* from being the clusterf*ck that is DNF,
Given that there is a substantial community of people depending on Perl for their work, and the same can hopefully not be said for DNF, Perl 6 is a much bigger disaster than DNF.
While Perl 5 actually has made substantial progress over the last few years (and seems to be as stable as ever), Perl 6 keeps siphoning off mindshare and developers.
Parrot threatened to throw other scripting languages into a similar state of confusion, but it appears that no other front end has reached the critical mass yet to be taken serious as a language implementation, so in this case, it seems that the debacle has been somewhat self limiting.
The US is building a fighting force of extraordinary magnitude. George W. Bush is forging our tradition in the spirit of our ancestors. He has our gratitude.
Microsoft has enough cash reserves to operate for at least a year without selling a single product. If they focused everything on developing Windows 7, then they might, just, have something in a year.
That's about as likely as getting 9 women to have a baby in one month.
Freeman Dyson said this in 2005. If Slashdot is going to post a daily piece of anti-global warming propaganda each day, couldn't they at least pick a current piece?
Since Aperture relies on Core Image and a fast video card to do its adjustments (RAW decoding is done by the CPU), it's limited to what the single 3-D card can do. Lightroom does everything with the CPU and so it is likely to gain more speed as multicore systems get faster.
That's exactly backwards. GPUs are designed with much more parallelism than CPU, and their performance is improving at much higher rate than CPU performance, so if an algorithm is well suited for GPU execution, it will outperform a CPU implementation by ever greater margins.
The author of that sentence doesn't seem to know what he's talking about.
An interesting point, theoretically, but if you write a compiler for a language that has an eval() function (basically any dynamic interpreted language) you would have to include a complete compiler for the language in the language's runtime environment. This also applies to any language that does call- or pass-by-name (since this is just an application of eval() ).
Correct regarding eval(), but call-by-name can easily be implemented by thunks.
Depends on your definition of "large". VA Linux spread their friends & family IPO stock quite generously through the open source community, and as a result, lots of people made a nice windfall (in the lower 5 figures).
It's hardly a surprise that a Napster insider would have a somewhat self serving perspective on what went wrong.
Other observers might very well conclude, e.g. from books like All The Rave that Napster was not a trustworthy (or even a competent) partner for a deal.
Furthermore, today there are all sorts of legal models for online music (subscription, per-song, whatever), and it hasn't exactly stopped piracy networks.
Slashdot Mirror
Which parts of "We release a stable version of Parrot on the third Tuesday of every month
What makes that version "stable"? It changes, as you point out yourself, once a month, passing countless new unit tests. It codes to an evolving spec and is targeted by an evolving compiler.
You can check out the past seven years of the project from our public Subversion repository. Do you live in a bizarro post-existential world where completion precedes existence?
I live outside the military-industrial complex, so in my world, progress reports don't equate completion.
Why do some people watch football and others lacrosse? Why doesn't everyone do everything exactly the way you say precisely when you say? Why aren't volunteers fungible? De gustibus non est disputandum! It's so unfair!
It seems you still fail to see that you are NOT "doing exactly" what I suggested. Perl 6 is still plodding along as a tangle of vaguely correlated individual agendas.
You're using the greatest research and publication tool known to mankind to ask a question you could answer for yourself!
That is considerably harder than it might appear to you, as the websphere for Perl 6, like the project itself, is littered with false starts and dead ends.
We publish daily statistics on Rakudo's progress passing the Perl 6 specification tests.
I still have no idea what the canonical source of these statistics would be. What I found was this plot, according to which there is NO convergence, as the number of passed tests grows more slowly than the number of overall tests.
I suspect this shall be my final post in the thread.
Suit yourself
Untrue. O'Reilly funded Larry primarily to work on Perl 5 for several years
... and so did NetLabs. I know. That's why I wrote "cash funding", and discussed the sponsored employment situation in my next sentence, which you chose to omit.
and ActiveState has paid several people to work on Perl 5 as well. I don't have exact dollar figures for any of those, but if my understanding is correct, the total spent primarily to develop Perl 5 exceeds the $200k spent on Perl 6.
I'm sure sponsored employment for Perl 5 exceeded the $200K spent by TPF. However, are you claiming that this practice simply does not exist at all for Perl 6?
That's RIAA/MPAA/BSA math.
Bah. Only a Nazi would use that line of argument.
Volunteer interest and effort is not fungible. It never has been. It never will be.
My discussion was primarily about MONEY, which by definition IS a fungible resource.
As for volunteer effort, the picture is less clear. Some people, like yourself, have continued to contribute to Perl 5. Others, by refocusing their energies on Perl 6, may have done Perl 5 a favor as well.
I hate the argument from authority, but you're arguing with the guy who wrote the fundamental testing library that kicked off the pre-Cambrian explosion of testing in Perl 5.
I assume you're talking about Test::MockObject. I have no idea how many CPAN modules are using that (there seems to be no dependency cross reference). Of the subset of 593 modules ported to fink packages, a grand total of 9 (1.5%) seem to use Test::MockObject, of which 8 are Catalyst related. Could it be that you have a somewhat inflated sense of your role in history?
Yes, there were tests -- but they were inconsistent, often of mediocre quality, and poorly understood.
I submit that the world of CPAN was not quite as void and without form before you entered it as you make it out to be, and that you did not cast as much light into it as you believe.
I prefer to discuss facts, not subjective impressions.
Does this mean that you're denying the fact that the Perl 6 spec is nowhere near complete?
Individuals create projects.
Or, in the present case, FAIL to create them.
I'm sure if you donate years of volunteer work to a project and some random anonymous Internet crank
It's fascinating how somebody who uses their nom de plume even for their published books gets bent all out of shape over someone else using a chat handle.
whined all over about how awful your project management skills are, how you'll never finish, how you can't communicate, and how you've killed other valuable projects wasting away your time and skills, you might feel a little bit criticized as well.
I've been on the receiving side of that, lived to tell, and eventually figured out which part of the criticism was justified.
I welcome your reasoned and researched suggestions for how to ship faster then. [...] Throw away lots of code and rewrite everything on the shiny new VM of the month?
In fact, I believe that the launch of Parrot was the original sin that truly doomed Perl 6. Doubling down on the scope of a complex project by trying to over-generalize a subproject never made sense to me.
Cut back on features?
Naturally, yes. That's how you generally get complex projects to ship: Figure out a reasonable, self contained subset of the totality of things you want to do and stop working on everything not part of that subset until you've shipped that.
In the case of Perl 6, that would mean:
Seems self-evident, doesn't it? But if it is, why are people working on Pugs at the moment?
Show me a press release from the past three (I believe even four) years which promises a target date or future work that we haven't accomplished.
Yes, that may have been the point at which the sliding 18 month release window was dropped. By then, a good part of the PR damage was done, however (It's not like DNF got a lot of publicity lately either).
Meanwhile, I'll show you over a year and a half of monthly stable Parrot releases, which include the Rakudo implementation -- delivered on the third Tuesday of the month, showing visible, stable, regular progress.
There is progress, yes, but is there convergence?
That could buy two years of a modestly-paid software developer's time (figure in self-employment tax, health care, et cetera). TPF crammed two funded developer years into six calendar years for Perl 6, and it's still not done. (We might be up to four funded developer years for the specification, the test suite, a virtual machine, and the language implementation.)
Nothing here that I disagree with, but I don't see how it addresses my point that Perl 6 consumed substantial resources, a considerable fraction of which could otherwise have gone to Perl 5.
Also, as modest as you believe this amount to be, it is, to my knowledge, vastly more cash funding than Perl 5 has received over its existence (total funding is hard to estimate, because prior to Perl 6, a lot of the funding consisted of companies allowing developers to spend part - sometimes the majority - of their time on Perl development; I don't know to what extent this practice has persisted).
No one has claimed that Parrot or Perl 6 is a "stable, shipping product" right now. If you really want to claim that this makes the entire project "vaporware", please feel free to apply that moniker to Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1, and a few hundred thousand other projects in progress -- at least, if you're at all interested in applying words fairly.
The reason I used that word is that Parrot was (a) announced with great clamor and (b) seven years later, still is not shipping. I don't think these criteria apply to any of the projects you cite.
You may find it interesting to hear that the reason Perl 5 (for one example) has orders of magnitude more core tests than Ruby or Python (and let's not mention how much the culture of testing has permeated the CPAN) is a direct result of the Perl 6 project.
Again, I'm not denying that SOME of the Perl 6 work has benefited Perl 5. My question is whether Perl 5 got $120K worth of benefits (or whatever you consider a fair estimate of funding siphoned off by Perl 6). Besides, it's not like Perl 5 and CPAN modules used to come without extensive unit tests before the glorious Perl 6 revolution introduced them.
Also, I'd love to see your list of widely-available, cross-platform C99-conforming compilers -- as someone who writes a fair amount of C code to run across several operating system and compiler combinations, I can think of several vendors who can't seem to support a decade-old C standard.
Fair enough. "abound" was not my choice of words. At least C compiler vendors have a published standard to be held to - I noticed that you did not choose to reply to my paragraph about the Perl 6 spec still appearing to be far from complete.
That would have made an interesting disclaimer to your previous post, though I suspect it's much easier to criticize several anonymous strangers in bulk for their perceived shortcomings.
I'm not all that interested in criticizing individuals. What is evident is that the PROJECT these individuals have pursued has been a massive failure.
I also don't think that lack of a focus on shipping is necessarily a "shortcoming" in an individual. There are plenty of people who are successful and productive, despite not being particularly shipping driven (and in many cases, probably BECAUSE of it). However, for a project that needs to ship, a lack of shipping driven people, or failing to put these people in charge at some point, is a fatal flaw.
We do nearly all of our work in public,
... and quite a bit of it by press release.
We've made plenty of mistakes worth criticizing, yet most of the criticism we get is from people who've never looked at any of our work (and certainly none of our recent work).
Ship it, and maybe you'll get the better class of critics you feel you deserve.
Perl 6 has made huge strides since 2000. The question is whether progress of the project will ever catch up with the goal posts.
Umm... the goalposts are set. The language spec is done.
So did it get completed between the time you last posted and it was "largely" done, and now? Congratulations!
The test suite is being built. All that's left is to implement it, and that's being done as we speak. What else do you want?
I don't want "being done". I want "done".
After eight years, the best you can say about the language specification is that it's "largely" complete?
Last I checked, the C language spec was still being worked on.
The THIRD iteration, after the first two iterations were DONE, FINAL, and widely implemented.
There's a difference between regular iterations and continuous tinkering.
And yet, C compilers abound.
C compilers implementing C89 or C99, the COMPLETED iterations.
As I understand it, there are a few places where work is still being done, but implementations can, and are, building on the existing spec, because it's *finished*.
You keep contradicting yourself. Are you sure you know what "finished" means? To the best of my knowledge, there isn't even a complete DRAFT available to the public. In what appears to be the most authoritative list, about half the chapters have not even been published as a draft, and about half of the rest are still marked as "DRAFT", so presumably not final.
Besides, you took one small quote and asked "is that best best you can say?".
I'm quite serious. Ada, which was a huge effort and must have been bogged down in enormous amounts of red tape (with both the DoD and a standards organization involved), went from CFP to published standard in 6 years. Perl 6 does not have a complete draft after 8 years.
Funny how you completely ignored the rest, such as the test suite,
I'll grant that this is a good thing to have.
and the two ongoing implementations.
I'd gladly settle for ONE, FINISHED, USABLE implementation.
As interesting as having Perl 6 implementation in Haskell is from an academic point of view, it's about the least likely practical deployment platoform I can think of.
Perl 6 keeps siphoning off mindshare and developers.
Uhh... okay. I can't say I've seen that, but if you say it's true, I guess it must be...
One of the concrete ways this manifests is in the funding of Perl 5 and Perl 6. According to the published records, the Perl Foundation awarded at least $200K in grants for Perl 6 development during 2000-2006. While the Perl 6 project may have attracted some of this funding, and some of the Perl 6 work was backported to Perl 5, I very much doubt that this adds up to being a net benefit for Perl 5.
despite the fact that you contradict yourself in the very same sentence, pointing out, as I already have, that Perl 5 continues to move forward.
Yes, the Perl 6 effort has not killed Perl 5 progress entirely. That does not mean it hasn't hindered it.
Parrot threatened to throw other scripting languages into a similar state of confusion
Because it'll provide a new platform to target, much like the .NET CLR or the JVM?
It's not the "new platform" that is the problem, but the vaporware existence of a platform that after more than 7 years still isn't shipping in stable form. Again, the distinction between stable, shipping products and endlessly evolving projects seems to elude you.
None of this would matter much if Perl 6 and
Would you care to give a list of name of people that group isn't? I can give you a list of names that group is. I'm curious if you've paid enough attention to cross off every name on my list.
I'm afraid I'm unable to parse your request with sufficient confidence to know what exactly you'd like me to list. Also, I fear you're asking me to discuss which people I don't consider focused on convergence and shipping, and I will not do that. I know too few of the current core contributors to decide whether they lack focus on shipping, or the authority to make the others focus.
Instead, let me give you a counterexample: For a while, Chip Salzenberg was the Parrot pumpking, which raised my hopes for Perl 6. As the Perl 5.004 pumpking, Chip had exactly the focus that I feel is missing from Perl 6 today.
I explicitly said there *wasn't* an imminent release.
Which is the Perl 6 problem in a nutshell.
What I said was that Perl 6 is making huge strides,
Perl 6 has made huge strides since 2000. The question is whether progress of the project will ever catch up with the goal posts.
For all the "progress" and "huge strides", Perl 6 still seems to lack an authoritative voice (whether that of a single person or a small group) with a single minded focus on convergence and shipping, and until that voice emerges, I'm pessimistic about Perl 6 ever shipping.
In fact, the longer development drags on, the more likely the developers are to self select for those who are perfectly content to live in a permanent state of daily development snapshots.
Until I see a schedule, the comparison to DNF sticks.
Only if you don't understand the two projects. DNF has an ever-changing target of requirements and specifications... hell, it's changed engines, what, three times? Perl 6 has a largely complete language specification,
After eight years, the best you can say about the language specification is that it's "largely" complete?
Is there still a ton of work to do? Absolutely! But it's *far* from being the clusterf*ck that is DNF,
Given that there is a substantial community of people depending on Perl for their work, and the same can hopefully not be said for DNF, Perl 6 is a much bigger disaster than DNF.
While Perl 5 actually has made substantial progress over the last few years (and seems to be as stable as ever), Perl 6 keeps siphoning off mindshare and developers.
Parrot threatened to throw other scripting languages into a similar state of confusion, but it appears that no other front end has reached the critical mass yet to be taken serious as a language implementation, so in this case, it seems that the debacle has been somewhat self limiting.
I never quite understood the appeal of e-gold.
"When civilization breaks down, I'll have a handy supply of GOLD... in an offshore vault, guaranteed by electronic certificates".
Does not compute, to me.
Guess what? Intel sold its XScale divission to Marvell two years ago.
Did they really have to buy a processor manufacturing division just to make a bunch of fancy Spider-Man action figures?
... but only in this particular universe.
Not true. Southern Indians tend to have darker skin than many, if not most African-Americans.
The US is building a fighting force of extraordinary magnitude. George W. Bush is forging our tradition in the spirit of our ancestors. He has our gratitude.
Microsoft has enough cash reserves to operate for at least a year without selling a single product. If they focused everything on developing Windows 7, then they might, just, have something in a year.
That's about as likely as getting 9 women to have a baby in one month.
... is this called a Beotollah cluster?
Freeman Dyson said this in 2005. If Slashdot is going to post a daily piece of anti-global warming propaganda each day, couldn't they at least pick a current piece?
That's exactly backwards. GPUs are designed with much more parallelism than CPU, and their performance is improving at much higher rate than CPU performance, so if an algorithm is well suited for GPU execution, it will outperform a CPU implementation by ever greater margins.
The author of that sentence doesn't seem to know what he's talking about.
Correct regarding eval(), but call-by-name can easily be implemented by thunks.
"We're in ur cr3dit cardz... checking out ur iT00ns purchasez"
an a blind person install and configure windows, iis, SQL server, exchange, and active directory?
I don't know about that, but MacOS X (starting with 10.4) is designed to be installable by a blind person.
Depends on your definition of "large". VA Linux spread their friends & family IPO stock quite generously through the open source community, and as a result, lots of people made a nice windfall (in the lower 5 figures).
If Sony made prosthetics would they restrict how I used my limbs?
Not only that, but they'd probably restrict how you used your non-prosthetic limb, too.
Furthermore, they would of course cost an arm and a leg...
I live in North Pole, Alaska. I STILL can't buy videos
Have you tried threatening to put Steve Jobs on your "naughty" list, Mr. Claus?
It's hardly a surprise that a Napster insider would have a somewhat self serving perspective on what went wrong.
Other observers might very well conclude, e.g. from books like All The Rave that Napster was not a trustworthy (or even a competent) partner for a deal.
Furthermore, today there are all sorts of legal models for online music (subscription, per-song, whatever), and it hasn't exactly stopped piracy networks.