The FreeBSD team does not have any full time people either, yet they somehow managed to get things out the door.
I'm not privy to the details of FreeBSD funding, but the FreeBSD Donations page shows that the FreeBSD Foundation set a funding goal of $250,000 for 2007. That yearly goal is higher than all of the money put into Perl 6 over the past eight years, and the FreeBSD Foundation raised over $400k in 2007. That's not counting funded development work from companies such as Yahoo, NetApp, and PC-BSD.
At this point Parrot relies almost entirely on unfunded volunteer work. So does Perl 6. Criticize the schedule all you want, but do it fairly.
Parrot is considerably slower than the Lua VM despite being much larger.
The Parrot used for those benchmarks was also a development version never released as a stable 1.0 version for production, and we haven't done much optimization on it (or the Lua language written on it). Of course it's slower.
Sweetie, I'm one of those "tens of people". No one has been working on Perl 6 or Parrot full time since 2003 or 2004. There have been no full-time developers working on Perl 6 or Parrot for years.
If you want to compare the schedule and progress of either project to another project, one with actual funding and resources, that's fine -- but scale down the resources and funding of that project to match the resources and funding of Perl 6 or Parrot before you draw any conclusions.
Changed it to a character that's free in other grammatical constructs such that all stringy operations use the same character. Consistency is an important goal.
Bad move Larry, I'll be sticking with 5.005 which has served me well for 7 years.
Closures and lambdas can be faked using objects and named functions.
How do you fake anonymous lambdas? Of course our models of computation are all equivalent if you throw out any abstractions, but beware the Turing Tarpit.
Perl5 OO is dog food, yet Perl 5 library authors consistently use it to define their library interfaces.
Actually, the idea is that you can know enough about Python to work competently with Python code and still have enough brainspace left over to be an expert in something besides programming.
I prefer to hire people who are good at programming to write and maintain code I care about. I find that they tend to write better, more maintainable code. Novices tend not to write good code.
That should take about five minutes to do right?:-)
If it weren't for trying to get symbol exports working properly on Mac OS X and static builds happy on Solaris with Sun Studio, maybe! (Don't even ask about the joys of MSVC's support of C99.)
Python's lambda is limited to a single expression, which sucks, but you can always do def _(...) just before use.
No anonymous lambdas, hmm? That does seem like an advantage to Perl.
As for closures, Python implements closures properly (properly = as described in SICP, the environment model of evaluation)...
I have SICP right here; can you give me a reference that says you cannot write to lexicals in proper closures? You can in Perl. (Admittedly you can in Python as well; close over an aggregate and modify an element of that aggregate.)
Python's parsing of vertical whitespace is not ambiguous.
Whatever other reason Guido may give for not including multi-line lambdas, he has said:
Since I find alternative syntax for statement grouping (e.g. braces or begin/end keywords) equally unacceptable, this pretty much makes a multi-line lambda an unsolvable puzzle.
Name one thing that's not insanely unmaintainable and therefore useless that you can do on Perl and cannot on Python.
Working lambdas (especially closures), for one.
Python is not dumbed down, it's simplified.
How ironic that you praise Scheme's design in this context. The ambiguous parsing of vertical whitespace leads directly to the broken lambda problem. Now that's probably fine for a teaching language, but plenty of people seem to think that Python is a language that scales up for experts. If that's the case, perhaps it's appropriate to judge the design of Python in terms of how it supports important features on which to build larger and more elegant abstractions.
Parrot probably could but I'm not sure if it does. Does anyone know the answer to that?
That's definitely a goal. I think we'll need to make at least one change to the garbage collector such that we don't trigger copy-on-write for shared memory pages of internal data structures and dirty pages unnecessarily, but I think it's possible to fix that without too much trouble.
The content for sites like Slashdot and Fark is written almost entirely by volunteers, yet it's that discussion content that brings readers to the sites to click on the ads or pay for subscriptions.
I'm not sure that's true. The most recent statistics I've seen on Slashdot show that 80% of visitors have never read a single discussion.
Because you were cunning enough to use the GPL, you can hold them to ransom, and charge them $1M for a limited license that lets them use your shiny widget in their new project. And whats more, you can sell it all over again the next time someone needs your shiny widget in a non-GPL setting.
My goodness, it's almost as if you had some way to make companies who don't want to participate in the development of free software participate by funding it! That's so... evil?
Because it might want to acknowledge one of the roots of Western civilization and an institution that has provided intellectual and moral leadership for over 2,000 years?
If, as you initially claimed, the only way to write bug-free code is to use formal methods, why don't you use them all of the time? Don't you want to write bug-free code?
Which is it then, "bug-free" or merely "more bug-free"? "Formal methods" or "informal proofs"? "Bug-free" or "90% works perfectly on the first run"?
Slashdot Mirror
I assumed you meant the Lua on Parrot versus Lua on the Lua VM benchmarks. My mistake.
That's an... interesting perspective. By what magic fairy dust are you able to profile code you haven't written yet?
I'm not privy to the details of FreeBSD funding, but the FreeBSD Donations page shows that the FreeBSD Foundation set a funding goal of $250,000 for 2007. That yearly goal is higher than all of the money put into Perl 6 over the past eight years, and the FreeBSD Foundation raised over $400k in 2007. That's not counting funded development work from companies such as Yahoo, NetApp, and PC-BSD.
At this point Parrot relies almost entirely on unfunded volunteer work. So does Perl 6. Criticize the schedule all you want, but do it fairly.
The Parrot used for those benchmarks was also a development version never released as a stable 1.0 version for production, and we haven't done much optimization on it (or the Lua language written on it). Of course it's slower.
Wow. Don't know much about Perl 6 or Ruby, do you? See The Long Perl 6 Super-Feature List for enlightenment.
Sweetie, I'm one of those "tens of people". No one has been working on Perl 6 or Parrot full time since 2003 or 2004. There have been no full-time developers working on Perl 6 or Parrot for years.
If you want to compare the schedule and progress of either project to another project, one with actual funding and resources, that's fine -- but scale down the resources and funding of that project to match the resources and funding of Perl 6 or Parrot before you draw any conclusions.
Changed it to a character that's free in other grammatical constructs such that all stringy operations use the same character. Consistency is an important goal.
Passive-aggressive threats much?
Who are the business and academic backers of Perl? You have ActiveState and maybe O'Reilly.
How do you fake anonymous lambdas? Of course our models of computation are all equivalent if you throw out any abstractions, but beware the Turing Tarpit.
"I don't really know much about Python. I only stole its object system for Perl 5. I have since repented." Larry Wall, Programming is Hard, Let's Go Scripting...
I prefer to hire people who are good at programming to write and maintain code I care about. I find that they tend to write better, more maintainable code. Novices tend not to write good code.
If it weren't for trying to get symbol exports working properly on Mac OS X and static builds happy on Solaris with Sun Studio, maybe! (Don't even ask about the joys of MSVC's support of C99.)
No anonymous lambdas, hmm? That does seem like an advantage to Perl.
I have SICP right here; can you give me a reference that says you cannot write to lexicals in proper closures? You can in Perl. (Admittedly you can in Python as well; close over an aggregate and modify an element of that aggregate.)
Whatever other reason Guido may give for not including multi-line lambdas, he has said:
Language Design Is Not Just Solving Puzzles
Working lambdas (especially closures), for one.
How ironic that you praise Scheme's design in this context. The ambiguous parsing of vertical whitespace leads directly to the broken lambda problem. Now that's probably fine for a teaching language, but plenty of people seem to think that Python is a language that scales up for experts. If that's the case, perhaps it's appropriate to judge the design of Python in terms of how it supports important features on which to build larger and more elegant abstractions.
A shoestring budget with one full-time developer is still more than Perl 6 and Parrot have had.
That's definitely a goal. I think we'll need to make at least one change to the garbage collector such that we don't trigger copy-on-write for shared memory pages of internal data structures and dirty pages unnecessarily, but I think it's possible to fix that without too much trouble.
That's good; that name will likely be "Perl 6".
I'm not sure that's true. The most recent statistics I've seen on Slashdot show that 80% of visitors have never read a single discussion.
My goodness, it's almost as if you had some way to make companies who don't want to participate in the development of free software participate by funding it! That's so... evil?
You might find the definition and use of the Latin word fides enlightening, as well as the entire field of epistemology.
Did I say it wasn't a logical conclusion? I merely said that you believed in something you haven't seen or done yet.
Believing that you could create artificial intelligence without having done it before is faith.
Because of your faith?
Nit: 1500 years, maybe.
I take it you're not a Latin scholar. Explore the word fides sometime.
$800M can also buy a lot of customers. That's what Sun did.
Some of the bugs I've fixed could have been crashers in certain circumstances. They were unlikely cases, but they had potential unpleasantness.
If, as you initially claimed, the only way to write bug-free code is to use formal methods, why don't you use them all of the time? Don't you want to write bug-free code?
Which is it then, "bug-free" or merely "more bug-free"? "Formal methods" or "informal proofs"? "Bug-free" or "90% works perfectly on the first run"?