chromatic

Several reasons, in no particular order.

One, because of the deliberate driving off of Parrot developers and their knowledge about what works and what doesn't work for building a VM for a Perl. (Sure, you can believe that I feel a little personal betrayal there, but there's also a concern that the Rakudo developers were taking on yet another project for which the bus number is, as usual, abysmally low.)

Two, because the resulting design (when I looked at it) was adequate, at best. I believe it won't compete with fast VMs without a serious change in its architecture, and no amount of magical thinking about how a GSoC student will build a JIT in 10 weeks will fix that.

Three, because it represents yet another example of NIH thinking and throwing out working code in favor of spending even more time building something new from scratch.

Four, because it set back the P6 release date by at least 18 months, if not years.

Five, because all it represented when I looked at it was the kind of code shuffling that Parrot could easily have done in the past three years, without doing anything much else (such as make the architecture improvements we'd begun to design and prototype).

One fact often forgotten in all of the nonsense about how "Parrot lost its focus and thus its purpose" is that Parrot was, from the start, intended to run at least both Perl and P6 simultaneously in the same process without embedding libperl.so.

Why would they? Rakudo's position was "Parrot is fundamentally broken and Rakudo is actively moving away from it." You can see how Parrot's development all but stopped within a few weeks of that discussion from the Ohloh link I posted earlier. More than that, Moar's development began in secret around that time, so how would Parrot developers know that they should have been working on that instead?

(Rakudo developers often claim that Parrot had no singular focus on Rakudo, but that graph argues differently to me. Then again, Rakudo developers also claim that they decided against using Parrot because Parrot development ceased, but that's an obvious post hoc ergo propter hoc argument to anyone who looks at the chronology.)

Personally, I've always viewed MoarVM as a spiritual successor to Parrot.

I looked at the code briefly after its announcement. It seems to repeat most of the long-standing architectural flaws of Parrot and it ignored much of the design work that we had been doing to make a Parrot which could compete favorably with fast VMs such as LuaJIT or v8. (My impression then was that, if Rakudo hadn't chased away Parrot developers and Parrot were free to ignore pesky things like backwards compatibility, deprecation, and users who wanted it to continue to work, Moar looked a lot like Parrot would have after the same time period. It was pretty disappointing.)

The deprecation policy was a point of contention, sure. It was poorly implemented in practice--but it was as much to help Rakudo as it was to reduce the amount of churn in Parrot. Rakudo probably would have had less trouble with it if Rakudo had less code which poked into the internals of Parrot. That's half the fault of Parrot, which had poor design of certain pieces, as well as Rakudo, which rejected a lot of offers to pull some or most of that code into Parrot. (That's a theme.)

I personally spent most of my time on Parrot doing things to improve it for Rakudo--fixing a lot of unpleasant bugs, both in Parrot and Rakudo, for example as well as improving performance. I and other Parrot developers asked multiple times for a list of issues Rakudo wanted Parrot to address. Occasionally we'd get a list and work on them--but I also volunteered to focus on specific improvements for Rakudo and was told "No" or "Not yet" multiple times. You can see that too, if you look in the IRC logs--and not just for things I wanted to do. Andrew Whitworth, in particular, spent months or years on tenterhooks, volunteering to implement the object system called "sixmodel" in Parrot, but he was always told that it wasn't fully designed yet or it wasn't mature enough. Eventually he left the project too.

On one side, I took a lot of criticism from Rakudo developers for not pushing Parrot harder to be what they wanted and on the other side, I took a lot of criticism from Rakudo developers for trying to change Parrot to be what they wanted. In the face of that seeming contradiction, it seemed obvious to me that they'd already decided to write and maintain a new backend VM from scratch.

My priority--getting a usable P6 release out and stable for general purposes--was clearly incompatible with that decision. Rakudo Star was supposed to come out as a "useful and usable" distribution for early adopters over four years ago, and to my knowledge, it's still only nominally useful and usable for very few purposes.

That is one of my most substantive criticisms of the whole process. Rakudo and P6 have a long history of claiming to be about eighteen months away from general usability, but the project's history is littered with rewrites, questionable technical decisions, and many, many good people leaving in frustration--sometimes quiet and sometimes not.

I begrudge no one working on it, but I believe it's on a path to ever less relevance without a dramatic change in project management. I'll reluctantly take the blame for mistakes I made as a member of the P6 design team and as a leader in Parrot, but I object to rewriting history to suggest that Parrot was solely at fault for Rakudo's current state.

It's possible to close more of the speed gap, but these JITs have to be able to:

* identify and use native primitives (avoid overflow and so forth)

* prefer stack allocation over heap (improved escape analysis)

* inline memory allocation and freeing and remove unused codepaths

* optimize across the boundary between implementation language and hosted language (which I believe requires self-hosting)

It's worse than that. Rakudo developers declared Parrot deprecated (in favor of a new VM which had yet to be written). That, of course, drove off all of the Parrot developers--see the decline in commits in March 2011:

https://www.ohloh.net/p/parrot/commits/summary

If Rakudo ever reaches a point of stable equilibrium where it's reasonable to think about creating libraries for it, P6 still faces an adoption cycle that's more difficult than that of Python 3. There's no plan for P6 to replace Perl (partly to avoid that adoption pain, for one, and partly because P6 has taken so long, there wouldn't be any Perl users remaining unless P6 had publicly changed its strategy).

Python's transition hasn't been quick or easy, but it's gone much, much better than the P6 fiasco.

Multiple Parrot developers volunteered to do this. Rakudo developers said "No", or in some cases "Not yet." Said developers tired of being called out for not supporting Rakudo on one hand and being told not to improve Parrot on the other hand and stopped working on Parrot altogether. You can easily verify this by looking at mailing list archives from that period.

You're spreading misinformation, and you've been told this enough times that it seems deliberate.

The P6 design team had been having weekly phone calls for years. Patrick (Rakudo pumpking) and Allison (Parrot architect) were both regularly on the calls. As you might expect from any kind of regular meeting, there were occasional disagreements, but the purpose of those conferences was to guide the convergent development of both projects.

I used those calls to figure out what I should work on within Parrot to help Rakudo.

Technically, moving the projects into separate repositories and onto different change schedules seemed to have worked out badly.

From the outside, that probably looks like the point at which the projects really started to diverge, but I think it was a symptom. Near the start of Parrot, a lot of people thought P6 was an ambitious project that'd never amount to anything and they wanted Parrot to succeed with or without P6. At some point, enough people within Rakudo decided that they didn't want to be tied to Parrot forever that they wanted an alternate backend.

Aren't you assuming that TDD requires pervasive unit isolation?

I practice TDD often and prefer not to isolate units at least at the level of filesystem artifact.

I believe that one of the reasons test-first became TDD and gave up on the distinction between unit tests and acceptance tests is because the Smalltalk sUnit style of testing units as units didn't work so well in languages which aren't Smalltalk.

Best wishes for your interviews.

This, and my CV says system administrator exactly once, and that ended in 2000. Everything since then has been not system administration. To be pigeonholed into system administration because the mighty algorithm had decreed that the intersection of "Perl" and "system administration" on a CV meant "system administration" did not sit well with me.

No, he wasn't. The article isn't about Perl. The article is about the excessive attachment to novelty and reinvention as practiced in much of the programming world today.

You may be responding to something that isn't in the article at all.

I first learned Ruby in 2000, mostly because Dave and Andy sent me a copy of the just-published Pickaxe book. There were few reasons to use Ruby in the English-speaking world back then, unless you were a language magpie or had very simple needs and didn't already have a scripting language in your toolkit.

I didn't do much with it until 2004, when Dave told me to check out the nascent Rails. (I'd already failed to convince my employer to cover Ruby in more detail even though many of the clever and insightful people I knew had started to pay attention.) We published the first Rails article anyway, and it was a good thing we did.

Even then, I didn't use Rails seriously myself because it and Ruby offered no benefits and only drawbacks. It was slower and had fewer libraries and worse tools than what I was already using. (Unlike a lot of Rails adopters, I wasn't primarily working in either J2EE or PHP.)

In 2014, even with Ruby and Rails off of their 2007 peaks, the metrics have changed a little bit. Ruby and Rails have better job prospects, in my experience, while the tooling and ecosystem and languages themselves are roughly equivalent. (One's better in some aspects and the other is better in others.)

Funny thing, though. It seems like around here Rails or Django are the old guard--the conservative technologies no one will lift an eyebrow at you using--and things like single-page client applications served by Node.js are the exciting technologies with new libraries and frameworks announced every week.

Some of those will succeed. Some will fail. Given that I'm not 14 or 19 or 22 anymore, that I spend my days working hard to deliver value for clients and/or employers, and that I have other things to do on nights and weekends than sit in front of a computer, where do I focus my time and energy and resources so that I can both get things done well now and continue to be employable for the next fifteen or twenty or thirty years?

That is what the article was about, not calling everything but Perl a fad.

"Just pack up and move somewhere cheaper" is easy advice to give, but it doesn't apply to every situation. Not everyone has that luxury. By the time you reach the mid-point of your career, you may have one or more of a partner, a partner with a professional career, personal obligations in your area, a mortgage, a mortgage you can't get out of without losing a lot of money/credit rating, aging parents, children, ailing family members who live with you, medical conditions which limit where you can live, ex partner with children not willing to move, et cetera. Alternately you may already live very frugally.

When I was fresh out of college, I couldn't have imagined any of those circumstances applying to me or anyone I know. Now I've seen them happen to many of my peers and colleagues.

After I'd spent a couple of weeks going through phone screens which alternated between "Rah rah! Google! We solve interesting problems! We're changing the world! Work on whatever you want!" and "How do you sort a million phone numbers using the least amount of memory possible?" and that silly ping pong ball question, the recruiters started asking things like "How do you feel about getting handed code without documentation and being responsible for deploying it?" and "Is it a problem for you to be maintaining code but not writing it?"

Then again, I'd accuse myself of making this up if I hadn't experienced it more than once.

http://trendshare.org/how-to-invest/

It amuses me that most of the revenue comes from warning people about the risks of penny stocks.

You should have started your comment with this. Then I could have stopped reading there. Are you here to participate in an informed and enlightened discussion or to show everyone how brilliant you are for not liking something?

I wish this claim wouldn't come up in every Perl article because that's a big part of Perl's perception problem. P6 is entering its 15th year of advocates claiming that it'll be ready in "about a year and a half".

If that claim is true this time, then it puts off people doing interesting things with Perl now as they figure they'll wait for a successor to look at it.

If that claim isn't true, then it puts off people doing interesting things with Perl now as the claim will change to be "about a year and a half from now" in another 18 months.

Your experience is so very different from mine (and that of everyone I know) that I'm not sure we're on the same planet. CPAN Testers provide near real time feedback on the patches made to Perl itself. That's the combined test suites of almost 130,000 modules for every commit to the Perl language and core libraries.

Sure, but you don't have to worry about reformatting making code that was correct suddenly and subtly incorrect.