I get it -- optimization is a fun game. But isn't one of the rules of Optimization Club to implement the spec first, and optimize once that's been done? One can play all day with unrolling loops, peeling away layers of indirection, and so forth to gain cycles, while piddling away time and energy that could be spent finishing the project within a timeframe that retains relevancy and the respect of potential users.

A reminder: http://perl6.org/compilers/features. Red and yellow boxes indicate that time spent on optimization is premature.

Spending time playing the optimization game without ever finishing the target spec is a strong indication that the project is just a toy for its developer's amusement. Does anyone outside of the project's development club care how fast it runs if it only runs a not-ready-for-production subset of the spec?

I'm sorry, I have long wanted to believe that Perl6 is destined for belated success. But I'm going to have to give up that position, and resign myself to the more realistic view that it's only destined for belatedness. If you want to inspire people to regain hope and enthusiasm, and possibly even to contribute to the project, tell us that after 14 years we have something that is feature complete, and that help is now needed on optimizing performance, improving documentation, or porting extension libraries over.

Update3: I do believe that those participating in the project have good intentions, a genuine interest in the project, and are involved in a thankless pursuit. So I apologize if my comments are unkind to them. I seem to be able to go days and weeks without really caring or thinking about P6. And then a post announcing and congratulating progress in an aspect of the project that seems tangential to its success comes along, and I really believe it does the project a disservice, further turning people off to it.

I get it -- optimization is a fun game. But isn't one of the rules of Optimization Club to implement the spec first, and optimize once that's been done?

That's only if you do waterfall-style development, and if you have well-financed dev team.

But we are volunteer-driven dev team, and so we must also keep those developers happy. And having a dog slow compiler frustrates people, and drives them away. And if volunteer devs have no users and no fun, they stop developing.

Another point is that we're listening to user feedback. When we first released the Rakudo Star distribution, we got lots and lots of feedback. Most of it was "this is very cool, but please make it much, much faster (and less memory hungry)".

Also, while Rakudo isn't feature complete, most user complaints these days concern performance and reliability, not features. Most missing things are very much orthogonal (and on a higher level) than the current optimization, so we don't expect much friction from adding those features later. Quite the opposite; since Rakudo is a partially self-hosting compiler, optimizing it speeds up the development cycle, which makes it easier to add more features.

Finally I'd like to point to other languages and compilers, like C++ with gcc and clang, and C# with mono/roslyn, and java with OracleJVM/OpenJDK + javac. The compiler (and VM) developers spend quite some time optimizing for performance. Yet none of the languages are feature complete, they are all being developed constantly. And not just the languages, the compilers have to catch up on those features too. Do you think they are all wrong too?

Perl 6 - the future is here, just unevenly distributed

TIL that #perl6 believes that comparing perl-6 to C++, C#, or Java doesn't make perl-6 look like a horrible, mismanaged, irrelevant death march.

Mind blown.

Well played. Perhaps those other three languages will eventually have real world users too someday? It will be interesting to see if they also get documentation, libraries, backwards compatibility, stability, tooling, packaging, and project management.

That's only if you do waterfall-style development, and if you have well-financed dev team.

How is that true? Does agile say that you requirements be never frozen?

And having a dog slow compiler frustrates people, and drives them away.

How big is your user base and how many have been driven away? There are slower tools, like Scala. Which many people have no problem in using. Mainly because they can atleast use it, instead of a product that isn't complete but promises to be. I guess you don't realize you have a literally zero user base, apart from a few people who like to write one liners on IRC or write toy programs to implement commonly known algorithms on Forums which no one takes seriously. Which explains why they are happy with a sub set of features. Because for most toy programs you don't need much, but the existing ones to run fine

Also, while Rakudo isn't feature complete, most user complaints these days concern performance and reliability, not features.

Also who are these users? Can you show us at least on serious use of Perl 6 in the wild? A big company, A start up? Anything?

C++ with gcc and clang, and C# with mono/roslyn, and java with OracleJVM/OpenJDK + javac. The compiler (and VM) developers spend quite some time optimizing for performance. Yet none of the languages are feature complete

They are incomplete in the same sense iPhone, or your TV is incomplete. It doesn't mean iPhone's or TV's aren't usable now. It only means they may get a few feature based on the competition they face in the future

Perl 6 is just incomplete. Its a bit like shipping an iPhone without a feature to store phone numbers. That's a very different kind of incompleteness than the former.

Spending time playing the optimization game without ever finishing the target spec is a strong indication that the project is just a toy for its developer's amusement. Does anyone outside of the project's development club care how fast it runs if it only runs a not-ready-for-production subset of the spec?

I am happy that Perl6 is a toy-project and that it can explore all the highways and by-ways, dead-ends and royal roads and takes all the time (and more) than needed.

Otherwise we will end up with another Java or PHP.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Hi davido,

If what I write below is not helpful (or worse), please accept my apologies.

I have long wanted to believe that Perl6 is destined for belated success. But I'm going to have to give up that position, and resign myself to the more realistic view that it's only destined for belatedness.

It does indeed sound like it might be time for you to let your P6 hopes go. Believing something about the future of P6 is faith really, and if you're in the dark about what's actually going on right now then it's blind faith, which I think you'll agree is ultimately unhealthy.

If you want to inspire people to regain hope and enthusiasm

I'm not trying to inspire people to regain hope and enthusiasm. I'm occasionally (about once a month) informing monks about what's going on in the P6 world and encouraging readers to consider exploring P6 -- especially the friendly and productive #perl6 vibe that Audrey bequeathed us (and which bares no recognizable relationship to the dumb drunks caricature one monk in particular would have the world believe).

And then a post announcing and congratulating progress in an aspect of the project that seems tangential to its success comes along, and I really believe it does the project a disservice, further turning people off to it.

I've reread my OP and I don't see how I was congratulating anyone. That certainly wasn't my intent. I'd appreciate clarification of what you saw as congratulatory.

I can see how my posts have put you off, and seem to you like a disservice to everyone, given that you were worried that P6 might not succeed and believed that what I have focused on was tangential. So, while I respectfully disagree, at least about my OP of this thread, I do get that my posts can leave you feeling discouraged or worse.

However, you can hopefully see things from my perspective too: I see what's actually going on with P6 because I follow the project; I want to occasionally (once a month or so) share P6 tidbits at the monastery; I post in this section because it says "if you want to share or discuss ... Perl 6 development, this is the place"; and my posts usually get positive votes with no significant downvotes, as is the case for this one at the time I write this.

---

As I said at the start, I think it might be healthy for you to let go of your hopes for P6. Then, the moment you notice a P6 post, and you don't like it, you'll be able to just ignore it because it won't matter to you. And if a post is interesting, well, you can read it without pain because you won't be getting your hopes up based on blind faith.

---

»ö« ^{. o O ( "the celebrity tell-all of the Perl-6 cult?" )}

I see nothing wrong with continuing to post updates. I just regret that the updates don't seem to reflect the approach of Christmas.




Dave

I never said "dumb drunks." That's just your paranoia talking, Ralphie boy. I think the people who are actually programming are very smart, just irresponsible and not interested in ever releasing anything "useful and usable".

But for fun, search the logs for "beer" and "tutorial":

#perl6 beer

#perl6 tutorial

I also searched for "book" and "documentation" but those results were too noisy to suggest anything interesting. But you can see from skimming the results that #perl6 spends far more time talking about consuming beer than it does talking about writing a useful tutorial. Unless Moritz edited the logs again to remove Jonathan cursing people out.

Which probably explains why the Rakudo has approximately zero users and keeps getting rewritten. Ballmer Peak anyone?

I understand why people have the "working now, optimized later" attitude. However, this blog post isn't just about making the compiler run faster. It's about getting it to produce faster compiled code. I for one do consider that a feature. It's also something that would likely be harder to rough in later in the project. A working spec-complete compiler that does basic optimization from the start is more likely, I think, to be used than one that is spec complete and produces very slow programs.

This isn't least bit interesting, as others have pointed out in this thread

Show us something that is spec complete. That's the only thing that will ever make others feel you are serious about this whole thing. For now most of us, don't really care what your toy experiments are.

But we all already know what we are going to get an year from now. We are likely to see the same spec being tried to be ported to a few more VM's. Another few sub projects related to that started. And you telling us, that we are able to run them at the same speed the same feature we had 6 months back on the new VM. Or worse, Rakudo is being re written again! And we should expect some thing fully ready by 2020 and that anybody doubting that is a troll.