You're a great one for setting up straw men so you can knock them down, aren't you?
Until Parrot can run at least one of the two original target languages, I consider its stated goal of aiming to support all dynamic languages an embarrassment. At the current point it runs neither, and there are no plans in place that I can see to change that. (Though you recently started a project to try to run the designated successor of one of the two original target languages.)
Getting from the point of embarrassment to actual success is a different question.
I've told you what looks like embarrassment in my eyes, what looks like success in my eyes, and what I think looks like success according to your stated goal. Three different goalposts. As always you are free to pay attention or disregard my opinion as you wish.
I'm aware of that fact and consider it a generally good thing. But I'll need to see actual success before my opinions about the project change substantially.
I would recognize success for the platform as a whole if Parrot is the default platform for a widely used language. A relatively objective definition of "widely used" could be that it shows on the TIOBE top 20 list. (Yes, I know all of the problems with that index. Still it is better than nothing.)
My definition of success for the goals the platform has set for itself is that Parrot becomes a popular platform for running at least one widely used language that was not originally associated with the Perl or Parrot communities.
Note that both the JVM and
My current belief is that the odds are against success by my first definition, and are strongly against success by the second definition.
I take it you weren't at Sam Ruby's OSCON talk a few years back where he gave a post mortem on why the Pirate effort failed.
The fact of failure is one thing. The reasons for that failure are quite another. The historical importance of that failure adds even more weight.
The fact that a port has been started does not mean it is useful.
Pynie looks like a recent attempt to start porting a version of Python that is not in widespread use. Pirate would be the attempt to port the version of Python that is actually used widely, and its current status is pretty useless.
I have respect for Allison, but she isn't done. Therefore I reiterate. Until there are actual, useful ports of the most popular, widely used, and widely ported dynamic languages out there, I think that claiming that Parrot supports all dynamic languages is false advertising.
A decade ago it was reasonable to insert the claim in the hope that you'd make it true. A decade in the claim is an embarrassment.
I think that claim should be eliminated from Parrot's description until it is able to run Python.
You know, the widely used dynamic language that was one of Parrot's two original target languages, which happens to have been ported and runs well on several other platforms, including the JVM and
You know, the one which lead to Dan Sugalski getting pie in the face when he couldn't even get the benchmark to run correctly, let alone run faster than the native C platform as promised.
The inability of the UK to cope with snow is directly connected to the overall climate and is hardly unique.
I guarantee that large parts of the USA (eg the Pacific Northwest and Virginia) are similarly incapable of handling even small amounts of snow. By contrast there is only one place in Canada which is unable to handle snow. (That would be Victoria, BC. It has a combination of rare snow due to warm, wet climate, with a tendency towards wet snow combined with steep geography with many residents who moved from locations with dry snow and flat geography. The result can be..amusing.)
I am in the USA. What is this "meter" business.
More seriously didn't you mean to tell people to convert "couple inches" into "several centimeters"? Because, unless we Americans have really mangled English units, an inch is nowhere near a meter.
The 1999 standard added common table expressions, and the 2003 standard added window functions. Those made it Turing complete.
It is more common than I'd like to see END and DESTROY blocks do something that clears the exit status of a Perl program on its way out the door.
In fact it is common enough that I'd prefer not to rely on it to detect abnormal ending of a test suite. Particularly since many test suites like to do cleanup when they are done.
In response to the criticism that it is a source filter, it filters for content within pod sections, which avoids almost all of the ambiguities that otherwise make parsing Perl so fun.
The number one thing to realize is that an average team of 5-7 people has a throughput that matches a team of 20 people. So there is a big productivity drop chasm that you don't want to stumble into by accident.
If you need a cite, read Software Estimation by Steve McConnell. (I forget where in the book the tidbit is, but the whole book is good so you should read it anyways.)
I have enough entries now at Random Observations that I'm fairly sure I'll post at least sporadically. Be warned that little of what I've felt motivated to write about so far is Perl related. Though I'm sure I'll write some Perl stuff eventually.
If you tell weightlifters that they should be able to lift a weight, they are able to lift less weight than they can if you tell them that they can do it.
Hearing the word "should" makes you weaker. Literally!
I'm sorry for not getting back. Here is the reason for the speed up.
With MySQL here is the fastest access path to data in memory given a unique identifier. You take the value, do a binary search on an index to find the rows you want and what pages of memory they are in. You then parse through that page of memory to pull out the row, grab the fields you want and put it in a temporary table. All of this is done by an interpreter following micro-code.
Here is the equivalent access path for the C++ code. Access an array by index.
That is a several order of magnitude difference in how much work to access a piece of data. That is the bulk of the performance difference right there.