The farce that is Perl 6 continues to be little but vapour-ware and really does nothing good for Perlââ¬â¢s image.
— admin, Why I'm Writing This Blog
Maybe if I keep saying "We release a new stable version of Parrot on the third Tuesday of every month, and we've done so twenty times now, and every release includes a new stable version of Rakudo, an implementation of Perl 6 on Parrot," people will start getting the message. Perl 6 and Parrot exist and they get better every day. We do all of our development in public. You can see our progress every day.
Goodness gracious, you can even look at Rakudo spectest graphs, updated daily, to see the velocity of progress on Rakudo. I particularly like the sharp uptick in the past week, where we added some 18% more passing tests. The second graph shows this more dramatically.
What the graph doesn't show is that the Google Summer of Code funding ended for Adrian Kreher, that Patrick Michaud has completed the Mozilla Foundation grant, and that Jonathan Worthington (funded for one or two days a week -- I believe it's back to one -- to work on Rakudo) has been on vacation.
Using "vaporware" to describe a project that consistently hits monthly stable releases and increases velocity despite a lack of funding and the vacation of project leaders stretches the definition past the point of belief.
Then again, how many people who "comment" on Perl 6 and Parrot actually bother to look up and quote relevant statistics? (That in itself suggests something about their level of information.)
You can say you're working on perl6 all you want, and put out stable parrot releases, but they're not stable releases of "perl 6" until you can go to perl.com and when you click "download" it gives you something other than 5.10.
*I* know perl6 is progressing, and *you* know perl6 is progressing, and other folks around here know it's progressing, and perhaps it's even usable day-to-day right now, but it's not perceived as "there, we're ready to have regular users use this, and we declare it perl 6.0" until it's really released. Release-early-release-often is good for development, but it's not the same as "we've put out a non-development release and we stand by it."
Until that 6.0 comes out, with a big announcement, no one will believe it's anything more than Enlightenment eternal snapshot mode.
Re:All About Perception
chromatic on 2008-09-30T22:16:49
... they're not stable releases of "perl 6" until you can go to perl.com and when you click "download" it gives you something other than 5.10. Fun fact: I edited the Perl.com Downloads page sometime around December 2007 to include information on how to download and build monthly Rakudo releases with the perl6 binary that Jerry and I made work.
Release-early-release-often is good for development....
Silly me. I thought it was also good for demonstrating that the software does actually exist -- you know, because hundreds of millions of people can actually try it for themselves. No one claims that it's finished. Plenty of people claim that it doesn't exist and never will exist. I believe that the facts are not on their side.
Re:All About Perception
Ranger Rick on 2008-10-01T00:44:01
include information on how to download and build monthly Rakudo release
Sure, and right now, it says it's an "in-development" version for "experimentation and testing." Not exactly saying "we're want testers!"
I'm not saying there isn't progress, I'm saying that people won't treat it as "real" until, as Alias said, people say "here's perl 6.0 alpha 1" and many folks won't really start evaluating it for their own uses until it at least says "beta 1" on the announcements.
Until then, it just looks like a development in-progress that isn't ready for a wider audience yet.
I know you spend a lot of time on parrot, and to you, it seems like it's hard to miss perl6's progress, but from the outside, the only reminder I have that it even exists is the occasional post from you showing up in my RSS feeds. Until it's on Slashdot/digg/whatever "PERL 6 ALPHA AVAILABLE!" many folks will assume no major announcements for a long time means it's in incubation, or dead, and don't have the time to seek out proof to the contrary.
Silly me. I thought it was also good for demonstrating that the software does actually exist
Right, I think everyone believes it exists, but IMHO, their "little but vapour-ware" comment meant: not yet ready for anyone but developers who are knee-deep in perl to look at. The casual perl-using crowd who have grown perl5 to the huge user-base it enjoys use it to get things done, not to play with the new hot perl6 stuff.
I think we're in violent agreement, for the most part. I just don't think the vapour-ware comment meant "nonexistant", rather I think it meant "not yet blessed by the perl6 community as ready for a wider audience beyond hardcore perl geeks." You're just not going to stop getting such comments until something that indicates the project is winding down the "language design" phase and working into the "stabilizing and getting user feedback" phase by releasing an alpha/beta.
It looks like it may be moving forward now, unilke 2001 to around 2005 or so. However, Perl 5 has also adopted Perl 6's useful bits -- "say," "//," named subpatterns, OO stuff (via Moose) -- and via Devel::Declare, may soon get named parameters as well. My wild guess is that Perl 6 will be officially done in 3-5 years. When it's done, Perl 6 will have to compete with a mature Perl 5 that has been consistently cloning many of its best features. Unless Perl 6 has some kind of killer app, that's a very, very hard sell.
Re:Skeptical.
chromatic on 2008-09-30T22:42:08
However, Perl 5 has also adopted Perl 6's useful bits.... Unless Perl 6 has some kind of killer app....
Better internals? Pervasive OO? Mutable lexical grammars? Working exceptions? NCI? Macros? JIT? Bytecode? Grammars? Serializable continuations? Multidispatch? STM? Hyperoperators? Pervasive laziness? Immutable sigils? True reference context? Aliasing and binding? Few globals? A robust parser?
I can think of two reasons why Perl 5 will never get many of the interesting and useful features of Perl 6 (some of which already exist in one or more implementations).
Re:Skeptical.
educated_foo on 2008-09-30T23:23:19
Here's my perspective on these things, as someone who uses Perl regularly, and contributes to CPAN but not to the Perl core:
- Better internals? Not directly relevant to me as a Perl programmer.
- Pervasive OO? I'm not pervasively OO either, so it doesn't matter.
- Mutable lexical grammars? Nice.
- Working exceptions? Perl 5's exceptions work well enough for me.
- NCI? If it is better than Inline::C.
- Macros? Nice.
- JIT? Bytecode? If they reduce the number of times I have to drop down to C for speed.
- Grammars? Nice.
- Serializable continuations? Possibly useful.
- Multidispatch? Nice.
- STM? WTF
;). Maybe useful. - Hyperoperators? Convenient.
- Pervasive laziness? Not that useful (and I've used Haskell for real programs).
- Immutable sigils? I understand how sigils work now, so I don't care.
- True reference context? Not sure what you mean.
- Aliasing and binding? Between glob assignment and "alias", Perl 5 seems to have this covered.
- Few globals? Don't care.
- A robust parser? I spend much more time on logic bugs than parsing bugs, so I'm not sure how this helps.
It would be great if you were less coy about your two reasons.
Re:Skeptical.
chromatic on 2008-10-01T00:04:45
It would be great if you were less coy about your two reasons.
Perl 5's internals are almost unmaintainable. Its internal API has leaked out through XS into the CPAN and the DarkPAN. That's problem one.
Problem two is that backwards compatibility overrides all other concerns, including problem one. P5P is almost entirely unwilling to consider potentially breaking the DarkPAN, so refactoring poorly designed or badly implemented APIs doesn't happen.
Most of the features in the list I quoted are impossible without either a superhero-sized shoehorn to wedge feature after features into the internals without destroying the whole thing (because refactoring is nearly impossible), or magic candy-flavored unicorns (and the Ruby and Python communities have prior art there).
Re:Skeptical.
educated_foo on 2008-10-02T01:35:45
I agree that Perl 5 does move slowly, for the reasons you mention among others, but 5.10 was a big step forward from 5.8, so Perl 5 certainly hasn't ground to a halt. Perl 6 (whichever version) also moves slowly (or at least unevenly), and has much more ground to cover than Perl 5, which has been a mature language for many years. It will be interesting to see whether or not Perl 6 becomes mature before Perl 5 adopts most of its interesting features.
Re:Skeptical.
chromatic on 2008-10-02T03:14:56
Perl 5 certainly hasn't ground to a halt.
Given multiple years between major releases -- and I'll be charitable and say three and a half years, there's your deprecation cycle length. If you want to remove a misfeature of Perl 5 or its API, you're going to have to wait until April 2012 before you can start using the replacement in production.
Usually you have to give Oracle, SAP, BEA, or IBM millions of dollars to move software that slowly.
Don't forget to account for the fact that the "stable" release of Perl is still 5.8.8 nine and a half months after the release of Perl 5.10.0.
It will be interesting to see whether or not Perl 6 becomes mature before Perl 5 adopts most of its interesting features.
This would make a very boring graph. Plot time on the X axis and the interestingness of the feature adopted on the Y axis and you'll see a flat line that suddenly asymptotes right at the "Heat Death of the Universe" tick.
Re:Skeptical.
educated_foo on 2008-10-02T03:57:11
Given multiple years between major releases -- and I'll be charitable and say three and a half years, there's your deprecation cycle length.
Deprecation doesn't matter. If something is deprecated and removed, then if I am using it, some of my code will break (wasting my time), and if I am not, it doesn't matter to me.
This would make a very boring graph. Plot time on the X axis and the interestingness of the feature adopted on the Y axis and you'll see a flat line that suddenly asymptotes right at the "Heat Death of the Universe" tick.
I have no idea where you're getting this. Are you saying (with a straight face) that none of the new features in 5.10 (wait another few months and re-read this if you insist) were borrowed from 6? Or that no future release of Perl 5 can possibly borrow more features of Perl 6? Or are you just trying to browbeat me into dropping the subject? I have nothing against Perl 6, but it has to prove itself just like any other language (Python, Ruby, Lua, Haskell,
...) as a replacement for Perl 5 as my main scripting language. Re:Skeptical.
chromatic on 2008-10-02T04:43:45
I'm saying that it's impossible to shoehorn new and changed features into Perl 5 without modifying the internals substantially. Given the strictness of backwards compatibility, that's impossible... at least without deprecating the changes through one stable major release cycle.
Even a feature as simple as the one I backported (
!!!
) potentially broke old code. I disbelieve that adding anything more complex would be free in terms of backwards compatibility, especially if it touches the parser.Re:Skeptical.
educated_foo on 2008-10-02T05:17:01
I'm saying that somehow these substantial internals changes keep happening fast enough to adopt Perl 6 features at a decent rate. It's an empirical question whether or not this continues. Also, "potentially broke" is not the same as "broke" -- has anyone reported your feature having broken actual code?
Re:Skeptical.
chromatic on 2008-10-02T06:26:25
I really don't mean this to sound like an argument from authority, but do you read p5p? If you do, then I really don't understand how you reach these conclusions. (If you don't, I wonder where you get your information.)
I'm saying that somehow these substantial internals changes keep happening fast enough to adopt Perl 6 features at a decent rate.
Smart match still isn't finished. That's why 5.10.1 isn't out, nine and a half months after 5.10.0.
[Has] anyone reported your feature having broken actual code?
That would require someone testing DarkPAN code with bleadperl, which also doesn't happen. Admittedly it's unlikely that someone would use the affected construct in anything other than golf or obfuscation, but it's a previously syntactically valid construct which now parses differently.
Re:Skeptical.
educated_foo on 2008-10-02T16:34:57
Where I get my perl 6 information? I skim p5p sometimes (e.g. I read some of the posts on the regex work), but since I'm not a core developer, there's no sense in reading it religiously. However, I have read perl5100delta, maybe a few blog posts or articles, and some journals here, so I know about the new features. Heck, anyone visiting the front page of use.perl will see that poll that's been up forever. If you think I'm ignorant in particular ways, you'll have to be more specific.Admittedly it's unlikely that someone would use the affected construct in anything other than golf or obfuscation
Bingo. I don't lose any sleep over changes that will break my golf shots.
Re:Skeptical.
Aristotle on 2008-10-02T18:32:35
I don’t know about the decent rate. Most of the adopted features were either utterly trivial (
say
) or only half-adopted as a significantly semantically poorer version (~~
). But there is a lot more in Perl 6 than those. And the rate of adoption is only going to slow down as easily adopted Perl 6 features start running out and the remnants get more and more intertwined with the richer, less ambiguous semantics of Perl 6.As for the new regex constructs in 5.10, there isn’t a single person who would call their syntax anything but frighteningly ugly.
Re:Skeptical.
educated_foo on 2008-10-04T02:39:35
Define "significantly semantically poorer." AFAICT Perl 5's smart match is a good adaptation of Perl 6's. Perl 6 has a richer type system, so its smart match has to do more things, which I would call "semantically more appropriate."
Of what does your "a lot more" consist? (God, proper English grammar is awkward...) And before you say "pervasive OO," remember that I'm not an OO dogmatist, so I don't care about that.
Like I said before, this is an empirical question. So far, the evidence is that Perl 5 can keep up with Perl 6 well enough. Perl 6 is cool in theory -- enough so that I sunk many hours into it in 2001-2002 -- but it has much 'splaining to do in 2008.
Re:Skeptical.
chromatic on 2008-10-04T02:51:17
Like I said before, this is an empirical question.
I've already listed a subset of advantages Perl 6 has over Perl 5. You don't care about any of them. Bully for you. If your "empiricism" (or the fact that Perl 5 can't support them to the extent that Perl 6 supports them, which you right now admitted) suggests that they therefore don't exist, it's no empericism with which I'm familiar.
The point of this journal entry is ontological, not whether you care about any specific feature.
Re:Skeptical.
educated_foo on 2008-10-04T03:02:07
Screw it. Consider me browbeaten.
Re:Skeptical.
Aristotle on 2008-10-02T17:52:09
Perl 5 certainly hasn’t ground to a halt.
No, it’s just very, very stable.
Re:Skeptical.
brian_d_foy on 2008-10-01T19:19:47
You only think better internals aren't relevant for you. IF you want bug fixes to perl, you want people to be able to fix bugs without jury rigging.
You'd probably want bytecode too. I don't hear any Perl programmers seriously saying that they want to recompile everything on every invocation of their script. Want a faster Perl program? Get rid of the compilation step.
You get the benefit of a lot of things you don't care about.
Re:Skeptical.
educated_foo on 2008-10-02T01:52:46
I'm aware of the benefits of these things, but none is a killer feature. Maybe "don't care about" is the wrong phrase -- I just mean that none of them would be a significant factor for me in choosing a language.
Yes, the complicated internals make bug fixing more difficult. On the other hand, the core code is mature and battle-tested, so it has few bugs, and most of those are in weird corner cases.
And ahead-of-time compilation, whether to bytecode or native code, has some advantages. But the time only I have been annoyed by startup time was when using a large Parse::RecDescent grammar. Usually compilation time is swamped by the time to either load my data or process it. A working dump/undump would probably be most useful to me, but I gather that's hard to do.
Re:Skeptical.
Aristotle on 2008-10-02T18:09:46
All of the things you casually dismiss as “doesn’t matter to me directly” certainly do matter to you because they translate directly into how far and how easily the platform reaches. How about being able to do number crunching with code much closer to raw Perl 6 than PDL-using code is to raw Perl 5, with much less effort than PDL took to write? That would most certainly be directly relevant to a whole lot of people in the trenches, even though they won’t personally get dirty in the guts.
Re:Skeptical.
educated_foo on 2008-10-02T20:55:43
This is why I distinguished between "doesn't matter directly" and "doesn't matter." I'm not saying the indirect effects aren't there, I'm saying it's hard to predict them.
Maybe if I keep saying "Nobody is going to try this until you build some easily-downloadable binary packages, stamp it with 'Perl 6 Alpha 1' and release it "officially" someone will eventually release it.
Christmas would be fairly appropriate though...
In the same way that adding a "perl6" binary launcher wasn't a big deal technically but had a large effect, unless you specifically build an "outreach" release that DOESN'T rely on people compiling it yourself, nobody is really going to pay attention.
Practically nobody is going to hand-compile development snapshots, due to previous pain.
Re:Monthly releases creates the wrong perception..
chromatic on 2008-09-30T23:25:24
Maybe if I keep saying "Nobody is going to try this until you build some easily-downloadable binary packages, stamp it with 'Perl 6 Alpha 1' and release it "officially" someone will eventually release it.
Are you referring to our Debian packages? Our RPMs? Our Cygwin packages? There are even Windows installers, courtesy of François and Parrot Win32 (generally uploaded the day after a release).
(As for the Alpha tag, I'd like to think we're sober and practical minded adults who don't succumb to the Street Fighter II Naming Squee Kawaii Fest of version numbers.)
Maybe he should have used Perl?
Re:What the developers of Perl6 really need ...
sjn on 2008-10-01T11:51:10
A reality check?
If you (or perladmin or anyone else) want to give the Perl6 devs such a thing, then there are lots of better ways of doing this than commenting the bikeshed colour.
1) Fix your pet peeve in the source code. Don't like the lack of an install-base on Debian? Make some
.deb's and work to get them included in the official Debian repositories. Don't like the lack of contributors? Start recruiting - make people excited about the language. 2) Start playing with Perl 6 to see if it's really as good as the devs say. Want to do it in a directed manner? Write tests. Just in for the fun? Publish your experimental code on your blog or on perlmonks to get feedback.
3) Are you thinking there's too much hype? Then help the people who are making some substance. Find out if there are any Perl 6 application projects, and offer your help. If you don't find any you like, then start your own and make it public.
Perl 6, Parrot and all the related projects are Open Source. This means patches are welcome, but pundits less so. Perladmin seems to offer punditry. What do you offer?
Re:What the developers of Perl6 really need ...
soulchild on 2008-10-01T12:22:35
What if I just want to create apps without having to dive into the guts of my favourite language's next version? Not every developer loves poking around at such a low level and I'd like to leave this to the ones who know and love this stuff. I don't think many PHP/Python/Ruby (and Perl) programmers developing popular high-volume web sites participate in developing the next version of their language, do you? What do you think how many construction workers build their own jack hammer?;-) I didn't mean to diss anyone and have high respect for every perl6 developer. But just ignoring (or bashing against) all this "perl5 is dying and perl6 is vapourware" stuff is dangerous IMHO because it shows what perl is missing the most: a face and a positive image. Not solely some super awesome stuff going on deep in the guts that sends chills down every comp-sci's spine. Re:What the developers of Perl6 really need ...
Khrt on 2008-10-01T16:54:41
What souldchild said. I have been trying to follow the development of Perl 6 and, not having a comp-sci background (I'm an engineer), most of it was gobbly gook to me. For instance I have not idea what any of this means:Better internals? Pervasive OO? Mutable lexical grammars? Working exceptions? NCI? Macros? JIT? Bytecode? Grammars? Serializable continuations? Multidispatch? STM? Hyperoperators? Pervasive laziness? Immutable sigils? True reference context? Aliasing and binding? Few globals? A robust parser?
I just wish I could understand how all that gobbly gook benefits my work or why I should be excited about it.
Re:What the developers of Perl6 really need ...
pjm on 2008-10-02T02:30:48
But of course the real question is: if you are not willing to spend the few hours to research what these things are, and how they would benefit your work, why --pray-tell-us-- should anyone be even slightly interested in what you have to say on the matter of Perl6 development?
[[Side question: do you really not know what "Better internals" means? "A robust parser"? "Macros"? "Working Exceptions"? Hmm...]]
There's a lot of pushme-pullyou going on in this comment thread: on the one side chromatic wants to push the progress made in making perl6 a reality, including the availability of rakudo, but on the other side there's the "gimme binary and get out of my way, and stop whining about how it's complicated to make: everyone knows it can't take more than a year or two to design a language and implement it. Wake up to yourselves..." folk who want the shiny new package and want it *now*. Unfortunately it looks like there's still quite a gap between what's being offered on one side and expected on the other (though maybe a nice neat platform-dependent blob would placate some of the angst, even if it wasn't the fully laden camel?)
Re:What the developers of Perl6 really need ...
slanning on 2008-10-02T08:47:48
the real question is: if you are not willing to spend the few hours to research what these things are, and how they would benefit your work, why --pray-tell-us-- should anyone be even slightly interested in what you have to say on the matter of Perl6 development?
Ah, is that the real question? I was wondering.
Maybe you should be slightly interested because he's a human being, and it might be beneficial not to marginalize and trivialize him? Or because you can't predict where the black swans might come from? Or because it might not be in your own self-interest to appear self-centered?
Re:What the developers of Perl 6 really need ...
chromatic on 2008-10-02T18:27:13
Once in a while a disinterested, uninformed (not meant pejoratively) observer makes a brilliant observation which transforms a field of study. For every one of those, you have to put up with most of a million Time Cubes. (I can think of a few people in this discussion who've written about why those features matter and why anyone should care, not that some people have bothered to look -- nor apparently even ask.)
That's a nice segue to let me be unequivocably clear about the singular thesis of this journal entry. Anyone who says "Perl 6 does not exist" has done no research, and should admit that.
Re:What the developers of Perl6 really need ...
educated_foo on 2008-10-04T02:45:29
do you really not know what "Better internals" means?
LOL! Could this be any more vague?
Re:What the developers of Perl6 really need ...
chromatic on 2008-10-04T06:45:06
Fine, let me spell it out for you.
Perl 5's internals are a mess of poorly documented and often intrinsically contradictory features implemented as mazes of macros calling macros calling macros and pseudo-OO C code implemented as semi-isomorphic structs. There's little distinction between an internal and an external API, and it's almost completely unknowable if changing any part of the API will break the guarantees of backwards source compatibility that p5p tries to maintain even between stable major releases. There is almost no encapsulation.
Adding new features is extremely difficult. Cleaning up the existing code within the system as it exists now is nearly impossible. Deprecating awful features takes years. Refactoring the API may take decades, if it ever happens. Adding new features -- especially if they include syntax -- means shoehorning yet more code into crevices between the lexer and the parser, and Larry help you if you need to modify existing code there.
I don't know how much more clearly I can put this. Perl 5's internals are a mess. Almost anything else is better, including most of Parrot. I've hacked on both of them. I've explained how to hack on both of them to other people. People who have hacked on Perl 5 have done things very differently in Parrot due to the experience.
Is that concrete enough for you?
Re:What the developers of Perl6 really need ...
Aristotle on 2008-10-04T07:34:42
As an example of that, I proposed that “
length undef
” should silently return undef rather than returning 0 after warning about undef. Rafaël took a first short at implementing this, but it broke thousands of tests, which puzzled him. Nicholas spotted the problem quickly, but it took him an extended tracing session to figure out where all he needed to stick flags in order to make disparate parts of the guts work together so that this would work as specified. When it takes Nicholas and half a day for such a trivial feature to be implemented, you know the code base is convoluted…Re:What the developers of Perl6 really need ...
chromatic on 2008-10-04T17:40:29
In Perl 6, if
length
were written in Perl 6, we'd add another multi variant for the undef case. It's two SLOC. Iflength
were written in PIR, it's four or five SLOC. Either way, it's trivial code.Re:What the developers of Perl6 really need ...
educated_foo on 2008-10-11T01:13:37
Yes -- sorry to have raised the temperature of this discussion.
I agree that they're painfully complex. I have the git clone of the blead repository sitting on my disk as we type. But I think one of the things Perl 5 teaches is the value of staring complexity in the face and beating it to death with the available blunt instruments. Starting over always feels great -- I love doing so with my own code -- but there are reasons that perl5, like many other mature pieces of software, is so ugly. And it will take perl6 time to rediscover these reasons.
So I agree that perl6 is cleaner, because younger software is always cleaner than older software. But I reserve judgement about whether it's better enough to make up for perl5's maturity. I hope perl6 will still be cleaner than perl5 when it is as fast, portable, and stable, but I'll wait and see.
Re:What the developers of Perl6 really need ...
chromatic on 2008-10-11T04:52:17
there are reasons that perl5, like many other mature pieces of software, is so ugly.
Many of those reasons, in the case of Perl 5, are very bad reasons though. The biggest problems are the lack of a specification beyond "What someone discovers that the implementation has been doing for several years" and a lack of encapsulation.
I reserve judgement about whether it's better enough to make up for perl5's maturity.
That's fair. I believe it will be, but that doesn't happen overnight, and it doesn't happen because I hope or wish it to be true. Right now Rakudo doesn't run Perl 5 modules, and that's a big drawback. Perl 6 without some sort of standardish library won't be nearly as useful as Perl 5 even if Perl 6 is multiple orders of magnitude better as a language. There are several axes along which to measure goodness.
Re:What the developers of Perl6 really need ...
educated_foo on 2008-10-13T05:51:33
The two main reasons for ugliness I'm talking about are weird platform issues and non-obvious cases where some language behavior makes more sense. It's almost impossible to anticipate these things, so you just have to spend years tripping on and fixing them.
I think Perl 6 has an advantage in uncovering these things because of its heritage, but it's far from automatic.
Re:What the developers of Perl6 really need ...
Aristotle on 2008-10-14T07:27:44
But those are not the reasons why the Perl 5 interpreter codebase is so convoluted.
Re:What the developers of Perl6 really need ...
educated_foo on 2008-10-15T21:42:32
*Sigh*
My point is that being cross-platform is necessarily ugly, and that it takes time to acquire the warts.
Re:What the developers of Perl6 really need ...
chromatic on 2008-10-01T17:54:55
Please stop bashing people for criticizing the [Perl 6] development, chromatic!
What do you suggest I do with people who haven't done their research and feel the need to bloviate their uninformed opinions all over the Internet on subjects I work on and care about, besides responding with verifiable facts?
If any of the statistics I posted are wrong, I welcome corrections. If any of the conclusions I've suggested from those statistics are wrong, let's talk about them.
For anyone to say "Perl 6 does not exist!" requires a strong anti-reality bias against tremendous amounts of public information.
Has Ian Hague's $200,000 already been used up?
Re:$200,000
chromatic on 2008-10-01T17:58:40
Nearly all of it is still available. Several grant applications are in progress. I don't mean to imply that funding is or isn't a constraint at the moment -- only that visible progress has accelerated despite all indications that it should have stalled for a few weeks.
There's a simple explanation for the disconnect in user perception of Perl6's status: All of the relevant websites that SHOULD be posting a big giant "DOWNLOAD PERL6 HERE" links are failing to provide such things.
Going to Rakudo.org gives me... the latest meeting minutes and some links to "other sites", but NOWHERE on the page is a "Here's how you get Rakudo" or even so much as a "What the hell is Rakudo, and why didn't we bother just calling it Perl6?"
Going to perlfoundation.org/perl6, the download links are miniscule and buried halfway down the page. Not only that, but I end up clicking through three more pages before getting anything remotely resembling download instructions.
Going to dev.perl.org/perl6, I find no mention at all about rakudo, and no explanation of what Parrot or Pugs are until I actually click a couple of links in.
I disagree with the previous poster that said you need "alpha" or "beta" releases. You don't. You simply need a clear way to download the code that isn't buried in the murky depths of some wiki.
Ultimately, the reason nobody is using perl6 is because the perl6 guys have done a terrible job of making perl6 easy to obtain.
Give people a single link to click on the front page of perl.org for the latest release in tar.bz2 format. It needs to be that simple.
Re:Why user adoption fails.
chromatic on 2008-10-01T17:51:20
Ultimately, the reason nobody is using perl6 is because the perl6 guys have done a terrible job of making perl6 easy to obtain.
That's concrete feedback and fixable. We can work on that. Thank you.
Re:Why user adoption fails.
Aristotle on 2008-10-02T18:19:32
It would be worthwhile to make some noise about November in close vicinity to the Perl 6 download link as a “look! that’s what real-world Perl 6 code looks like, and it runs today” demonstration, to impart the idea that what’s there is tangible and not a mere declaration of intent that’s of interest mainly to language lawyers – even if it’s not complete and nowhere near fast enough for real work.
Re:Why user adoption fails.
masak on 2008-10-14T12:50:38
It would be worthwhile to make some noise about November in close vicinity to the Perl 6 download link as a “look! that’s what real-world Perl 6 code looks like, and it runs today” demonstration, to impart the idea that what’s there is tangible and not a mere declaration of intent that’s of interest mainly to language lawyers –
Thanks for the confidence. As far as I'm concerned, the more noise about November, the better.
even if it’s not complete and nowhere near fast enough for real work.
Actually, it's fast enough nowadays, even though some caveats apply. But we are still working on the basic wiki features, and despite the progress we're making and the fun we're having on the way, these are early days still.