That does suggest that Ubuntu included a bad version without testing, no?
If no one using Flash on SuSE had problems and if everyone using Flash on Ubuntu had problems, that would suggest that Ubuntu included a bad version without testing. Your anecdote suggests that Flash works with your hardware and software combination.
Again, it's relatively trivial to fix the issue for you and I as well as most/.ers....
Does Ubuntu really install Adobe's Flash player by default? I certainly don't remember seeing it in any Ubuntu I've installed.
Even so, it's not relatively trivial for me to fix the problem, and I have some experience writing C code on Linux. (I did it most recently not more than ten minutes ago.) Adobe's binary blob crashes. Unless you have magic powers, you can't reliably "fix" that without the source code.
[Similarly], it is Ubuntu's fault that it isn't trivial for some people to fix the issue.
There are, what, a few thousand programmers who understand Linux systems programming well enough to debug GUI programs and post patches? It's not trivial for those programmers to fix Flash because Adobe won't let them see the source code. How is that Ubuntu's fault?
This is, in fact, the second time today I've responded to someone calling for the spectacular failure of a major company, in the middle of a major economic downturn.
How would GOOG losing a significant portion of its value due to automated trading cause the spectacular failure of the company?
... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....
Unless you change the Perl 6 grammar, $my_thing gets parsed as a variable name, not string concatenation. (You'd have to override the grammar to change allowed characters in identifiers, whitespace sensitivity, the concatenation operator, and filehandles.) You can do it, but that's not how the Perl 6 grammar works.
Could it be that you have a somewhat inflated sense of your role in history?
... and you keep jumping to faulty conclusions.
The module to which I alluded still has my copyright and credit prominently in its documentation, and it's a dependency of probably 95% of distributions uploaded to the CPAN in the past three -- and perhaps five -- years (including Test::MockObject), and there are ports to at least four other languages. That seems a fairly tangible side benefit of Perl 6.
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.
Maybe someone would have written it if I hadn't, but history doesn't support these kinds of experiments. (Though nice Biblical strawman, by the way. If you're going to put words in my mouth, poetic license helps.)
Which parts of "We release a stable version of Parrot on the third Tuesday of every month, as we have done for the past two years -- and this includes Rakudo, an implementation of Perl 6 on Parrot" are difficult to understand? 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?
In the case of Perl 6, that would mean [doing exactly what you're doing]...
If we're doing that wrong, please feel free to suggest what we should do instead. I'm sure our volunteer project managers would love nothing more than to hand off their lazy, slipshod, ignorant work to someone so obviously wiser, more talented, taller, more virile, and (hey, why not?) better looking.
[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!
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! We publish daily statistics on Rakudo's progress passing the Perl 6 specification tests. (That is, you could find that information if you're not somehow stuck in a parallel universe where software magically springs into existence perfectly-finished only after weeks, months, or years of work from volunteers when the software doesn't exist at all, which despite protestations to the contrary, I suspect is not actually the case.)
Hm. Open mockery, with Latin, the many-worlds theory, and late 20th century philosophy. 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 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 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. Volunteer interest and effort is not fungible. It never has been. It never will be.
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. Yes, there were tests -- but they were inconsistent, often of mediocre quality, and poorly understood.
Parrot... seven years later, still is not shipping.
We release a stable release on the third Tuesday of every month, as we have done every month since the end of 2006. Again, if you're at all interested in using words fairly, please call Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1 vaporware, as they release stable not-yet-final versions as well but somehow aren't "shipping" either.
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.
I'm not all that interested in criticizing individuals.
Individuals create projects. I'm sure if you donate years of volunteer work to a project and some random anonymous Internet crank 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.
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. Shall we berate volunteers for not working hard enough? Convince them to quit their jobs and pay them in shiny TPF scrip? Throw away lots of code and rewrite everything on the shiny new VM of the month? Cut back on features?
The appropriate mailing lists and IRC channels are public. Please note that no one will take you seriously unless you demonstrate a passing familiarity with the project's goals, its recent history, and the milestones. Likewise, handwaving and saying "You should really ship something" isn't useful.
... 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. (For every press release which says "TPF funds developer $x for $foo", I'll point you to another public status report for that developer.) 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.)
Again, the distinction between stable, shipping products and endlessly evolving projects seems to elude you.
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.
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. See slide 43 in Tim Bunce's Perl Myths 200802. (If you don't believe him, believe me, because I was there, I wrote a significant amount of them, and I did the research to which Tim alludes.)
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.
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. We do nearly all of our work in public, as we have done for many years. 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).
[When] a language like Perl stagnates, people extend it with modules. Not necessarily bad, just strange.
I'm not sure "stagnates" is fair; one of the design goals of Perl 5 was to enable language experimentation and extension in modules. 14 years (and some 14,000 distributions on the CPAN) later, there are some successes.
Also, comparing it to English doesn't exactly make the case for simplicity.
Everything depends on whether you want a simple language or simple programs. I said earlier that the SKI combinator calculus is a simple language -- but good luck writing simple programs with it. Complexity always goes somewhere.
You seem to want others to redistribute only your pristine sources.
No, I want distributors to talk to upstream. If Red Hat had asked "Hey, do you know about this bug? Is there a fix? Can we backport a patch to the old version of Perl we distribute?" they could have avoided this problem.
That is just plain ludicrous, as [Perl 5] variable names such as $my_thing = 1 now means something completely different under [Perl 6].
The concatenation operator is now ~ (which is a further improvement because now the tilde signals stringy behavior in all sorts of contexts) -- but what you said was untrue even when the underscore was the string concatenation operator. As there are no (undeclared) barewords in Perl 6, there's no way to parse $my_thing as anything other than a variable name.
If you have trouble with $_ in Perl, avoid pronouns and implied subjects in imperative sentences in English. (You seem to use the word "it" correctly, so you should be able to use $_ correctly in Perl.)
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.
Is it just me or does Perl 6 feel an awful lot like VB.NET?
I can't answer that directly, having never written VB.NET, but I've written Perl 5 code, Perl 6 code, and VB code, and Perl 6 is a tremendous improvement over Perl 5 in many ways. I say that admitting that I've written a lot of Perl 5 code and I like Perl 5. You should try Perl 6; it's very nice.
Taking a language that's good enough for what it was used for, making just enough arbitrary syntax changes that you need to re-learn it, and requiring a VM to run it.
I don't believe any of the syntax changes are arbitrary; they're all documented with their motivations. Besides that, if Perl 6 is only as good as Perl 5 was, there's no reason to work on Perl 6. Again, having written code in both languages, I believe Perl 6 is much better than Perl 5 is, and will be more appropriate for many new types of problems. As well, Perl 5 has a VM too.
Of course, why you'd need Perl 6 to run Perl 5 code seeing as Perl 5 runs Perl 5 code perfectly well...
When one of the features of Perl 6 is grammar mutability (such that you can parse Perl 5 code) and one of the main implementations of Perl 6 is a VM that can run Perl 5 code as well as Perl 6 code, it seems silly to require people to rewrite all of their existing Perl 5 code at once before they can use any Perl 6 code.
I suppose if you want a minimal language with a few things you have to remember (whether operators, standard library functions, core objects, monads, or whatever), you want the SKI combinator calculus. The problem with that is you have to reinvent the universe just to make an apple pie.
Slashdot Mirror
If no one using Flash on SuSE had problems and if everyone using Flash on Ubuntu had problems, that would suggest that Ubuntu included a bad version without testing. Your anecdote suggests that Flash works with your hardware and software combination.
Does Ubuntu really install Adobe's Flash player by default? I certainly don't remember seeing it in any Ubuntu I've installed.
Even so, it's not relatively trivial for me to fix the problem, and I have some experience writing C code on Linux. (I did it most recently not more than ten minutes ago.) Adobe's binary blob crashes. Unless you have magic powers, you can't reliably "fix" that without the source code.
There are, what, a few thousand programmers who understand Linux systems programming well enough to debug GUI programs and post patches? It's not trivial for those programmers to fix Flash because Adobe won't let them see the source code. How is that Ubuntu's fault?
How would GOOG losing a significant portion of its value due to automated trading cause the spectacular failure of the company?
... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....
Subtraction?
Unless you change the Perl 6 grammar, $my_thing gets parsed as a variable name, not string concatenation. (You'd have to override the grammar to change allowed characters in identifiers, whitespace sensitivity, the concatenation operator, and filehandles.) You can do it, but that's not how the Perl 6 grammar works.
You keep making faulty assumptions...
... and you keep jumping to faulty conclusions.
The module to which I alluded still has my copyright and credit prominently in its documentation, and it's a dependency of probably 95% of distributions uploaded to the CPAN in the past three -- and perhaps five -- years (including Test::MockObject), and there are ports to at least four other languages. That seems a fairly tangible side benefit of Perl 6.
Maybe someone would have written it if I hadn't, but history doesn't support these kinds of experiments. (Though nice Biblical strawman, by the way. If you're going to put words in my mouth, poetic license helps.)
Which parts of "We release a stable version of Parrot on the third Tuesday of every month, as we have done for the past two years -- and this includes Rakudo, an implementation of Perl 6 on Parrot" are difficult to understand? 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?
If we're doing that wrong, please feel free to suggest what we should do instead. I'm sure our volunteer project managers would love nothing more than to hand off their lazy, slipshod, ignorant work to someone so obviously wiser, more talented, taller, more virile, and (hey, why not?) better looking.
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!
You're using the greatest research and publication tool known to mankind to ask a question you could answer for yourself! We publish daily statistics on Rakudo's progress passing the Perl 6 specification tests. (That is, you could find that information if you're not somehow stuck in a parallel universe where software magically springs into existence perfectly-finished only after weeks, months, or years of work from volunteers when the software doesn't exist at all, which despite protestations to the contrary, I suspect is not actually the case.)
Hm. Open mockery, with Latin, the many-worlds theory, and late 20th century philosophy. I suspect this shall be my final post in the thread.
Untrue. O'Reilly funded Larry primarily to work on Perl 5 for several years, 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.
That's RIAA/MPAA/BSA math. Volunteer interest and effort is not fungible. It never has been. It never will be.
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. Yes, there were tests -- but they were inconsistent, often of mediocre quality, and poorly understood.
We release a stable release on the third Tuesday of every month, as we have done every month since the end of 2006. Again, if you're at all interested in using words fairly, please call Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1 vaporware, as they release stable not-yet-final versions as well but somehow aren't "shipping" either.
I prefer to discuss facts, not subjective impressions.
Individuals create projects. I'm sure if you donate years of volunteer work to a project and some random anonymous Internet crank 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 welcome your reasoned and researched suggestions for how to ship faster then. Shall we berate volunteers for not working hard enough? Convince them to quit their jobs and pay them in shiny TPF scrip? Throw away lots of code and rewrite everything on the shiny new VM of the month? Cut back on features?
The appropriate mailing lists and IRC channels are public. Please note that no one will take you seriously unless you demonstrate a passing familiarity with the project's goals, its recent history, and the milestones. Likewise, handwaving and saying "You should really ship something" isn't useful.
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. (For every press release which says "TPF funds developer $x for $foo", I'll point you to another public status report for that developer.) 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.
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.)
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.
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. See slide 43 in Tim Bunce's Perl Myths 200802. (If you don't believe him, believe me, because I was there, I wrote a significant amount of them, and I did the research to which Tim alludes.)
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.
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. We do nearly all of our work in public, as we have done for many years. 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).
Distrust vendors who don't work with upstream.
I'm not sure "stagnates" is fair; one of the design goals of Perl 5 was to enable language experimentation and extension in modules. 14 years (and some 14,000 distributions on the CPAN) later, there are some successes.
Everything depends on whether you want a simple language or simple programs. I said earlier that the SKI combinator calculus is a simple language -- but good luck writing simple programs with it. Complexity always goes somewhere.
No, I want distributors to talk to upstream. If Red Hat had asked "Hey, do you know about this bug? Is there a fix? Can we backport a patch to the old version of Perl we distribute?" they could have avoided this problem.
Is that really too much to ask?
The concatenation operator is now ~ (which is a further improvement because now the tilde signals stringy behavior in all sorts of contexts) -- but what you said was untrue even when the underscore was the string concatenation operator. As there are no (undeclared) barewords in Perl 6, there's no way to parse $my_thing as anything other than a variable name.
If you have trouble with $_ in Perl, avoid pronouns and implied subjects in imperative sentences in English. (You seem to use the word "it" correctly, so you should be able to use $_ correctly in Perl.)
Facts, for one. No one who's tried to reproduce TIOBE's data has succeeded. Unreproducible statistics are suspect.
That statement is wrong (or if it's right, then Ruby 2 and Python 3000 and PHP 6 and Java 7 and GHC 6.10 and so on are all vaporware too.)
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 can't answer that directly, having never written VB.NET, but I've written Perl 5 code, Perl 6 code, and VB code, and Perl 6 is a tremendous improvement over Perl 5 in many ways. I say that admitting that I've written a lot of Perl 5 code and I like Perl 5. You should try Perl 6; it's very nice.
I don't believe any of the syntax changes are arbitrary; they're all documented with their motivations. Besides that, if Perl 6 is only as good as Perl 5 was, there's no reason to work on Perl 6. Again, having written code in both languages, I believe Perl 6 is much better than Perl 5 is, and will be more appropriate for many new types of problems. As well, Perl 5 has a VM too.
When one of the features of Perl 6 is grammar mutability (such that you can parse Perl 5 code) and one of the main implementations of Perl 6 is a VM that can run Perl 5 code as well as Perl 6 code, it seems silly to require people to rewrite all of their existing Perl 5 code at once before they can use any Perl 6 code.
I suppose if you want a minimal language with a few things you have to remember (whether operators, standard library functions, core objects, monads, or whatever), you want the SKI combinator calculus. The problem with that is you have to reinvent the universe just to make an apple pie.
We also release a new version of Rakudo with the monthly stable release of Parrot, as we've done every month for the past 20 months.