Number of stable Perl 5 releases since the Perl 6 project began in summer 2000: 13.
Number of stable Rakudo (Perl 6 on Parrot) releases since the Perl 6 project began in summer 2000: 17.
Before you tell me how unfair a comparison that is and how you hate my hair and I'm a horrible person, let me add a disclaimer: Perl 5 has several orders of magnitude more users than Rakudo.
Before you get all smug and tell me that I'm correlating meaningless numbers for no good reason, let me revoke part of that disclaimer: in a healthy project, at least some of the users also contribute something back.
The only interesting question to me now is "Why not?"
Oh, and USING Perl
mugwumpjism on 2009-05-29T02:42:09
Also getting on with their day jobs by using Perl.Re:CPAN
chromatic on 2009-05-29T03:45:42
That's because they have no choice.
Re:CPAN
educated_foo on 2009-05-29T04:00:54
Exactly the opposite -- thanks to backwards compatibility, they *do* have a choice, and that's a big part of why they bother to contribute.
Re:CPAN
chromatic on 2009-05-29T04:24:53
If Perl 5 had a better class declaration and management system in the core, there'd be no need for Mouse, Moose, Squirrel, and dozens of other modules in the Class:: namespace.
That has nothing to do with backwards compatibility (at least in a positive way).
Re:CPAN
educated_foo on 2009-05-29T16:00:59
I agree that the profusion of OO support modules is a real waste. While I'm satisfied with blessed hashes and a bit of code generation or autoloading, people who want something more would benefit from having only one (or two or three?) solutions. On the other hand, if some half-baked Java clone had been added to the language 5 years ago (more syntax for pseudohashes?), the OO people probably wouldn't have created Moose at all. A lousy object system seems worse than an incomplete one.Backwards compatibility is relevant because people can write some code to solve a problem, upload it to CPAN as a module, and leave it alone for years, knowing that it will continue to be useful on newer versions of Perl. For example, Pete Ratzlaff released Astro::FITS::CFITSIO in 2006, but if I need to parse a FITS file, I can install it on my 2009 Perl and expect it to work. Mr. Ratzlaff may not be maintaining his module, using Perl, or even living, but his effort is still useful.
Re:CPAN
phaylon on 2009-05-29T16:47:41
What does core here mean? perl itself, or the bundled modules? If bundled, then there'd still be the need for the modules itself. If in perl itself, then we'd be stuck with it for a while. The fact that the common basics of Perl OO are very flexible is why we even got as far as having something as powerful as Moose. We're basically everything Scheme wanted to be. A small core (by which I mean the interpreter, not the distribution) with extensions living in libraries.
Re:CPAN
btilly on 2009-05-29T19:27:05
I feel like I don't have a choice, but not for reasons you'd like. Perl tends to be very important and lots of things need it. As a result sysadmins get touchy about upgrading it because they don't know what will break. Sure, you get distros to include the new Perl, but sysadmins are also touchy about upgrading operating systems on production machines. However it is fairly easy to get those same sysadmins to agree to upgrading one Perl library. Particularly if it isn't being used by a lot of things other than yourself.
The result? The current environment that I am targeting is using Perl 5.8.6. If there is a feature which I want in Perl that I need to develop, there is a real chance that I won't even be in this job by the time we upgrade to a version of Perl that has my change. And this would be true even if Perl 5 released a new version every 24 hours.
By contrast if I scratch that itch by contributing to a CPAN module, I can have the itch scratched, QAed, and rolled out into production within 2 weeks.
Please don't bother arguing that the problem here is stupid sysadmins. I'm not defending their choices, I'm just pointing out that there is pressure on programmers to live with them.
Also I'm sure you're itching to point out that I can install a private version of Perl. That I can. However then I have to install all the libraries that I want for that version of Perl. Worse yet, I'm not allowed to touch the production environment so I have to get sysadmins to do all of that installing. Which is likely to lead to squabbling about the fact that Perl is already on those machines, do we really need to do this? I prefer to avoid arguments, including that one, unless I have a good reason to go there. And generally I simply don't.
The end result? If I've got a problem to solve and it can be done in a module, I'm going to have no motivation to contribute to Perl to solve it. If I have a problem and I have to change core Perl to solve it, I have a lot of barriers to being motivated to try to solve that problem. For reasons that have nothing to do with the Perl development process.
Re:CPAN
chromatic on 2009-05-29T19:48:54
I invite you to consider the history of Lisp and Tcl, which took the same approach. "It's okay that there's no standard, built-in way to do $X. You can just roll your own! The rest of this thread will show you several different approaches before it falls apart in nitpickery."
If 98% of maintainable Perl 5 programs start with the same two lines of code, I can make a good argument that those two lines are boilerplate that a future version of Perl 5 should remove.
Sometimes the right default is useful.
Re:CPAN
btilly on 2009-05-29T20:20:03
If a future version of Perl 5 removes those two lines of code, I guarantee you that a lot of Perl will break. Worse yet, a lot of it is Perl depended on by those same sysadmins who drag their feet on upgrading Perl regularly because "upgrades are risky".
I'd prefer that you not make their point for them. If you want to make a default more intelligent, get rid of the requirement for modules to return a true value. That is low risk. Applying strictures and warnings to everything by default is not.
About the TCL/LISP argument, I'm not in disagreement. However it is irrelevant to my explanation of one of the factors that drives people towards contributing to CPAN instead of core Perl. I'm describing the problem, not suggesting a solution for it.
Re:CPAN
phaylon on 2009-05-30T01:38:59
I would see no problem with that if it was dependent on the user to declare their intended version. For example, couldn't 'use 5.010;' imply strict and warnings? Like it now implies all features in the 5.10.0 bundle?
In November/December, I built an alpha release of "Vanilla Perl 6" (combining Parrot and Rakudo).
I found it to be uninstallable (because it hard-coded all the filesystem paths at compile time which made it almost impossible to make an installer) and it leaked memory so fast that most simple test benchmarks I created consumed more than the 2gig process limit after running for a few minutes.
I concluded that the implementation was not sufficiently stable for me (as a person who doesn't know C) to do anything useful with it yet. That basically put it in my "Interesting, but give it 6 months and then try again".
BUT, at least I could try it out, because there was a Perl 6 binary. Even if I couldn't build an installer, at least I had a simple default "perl6.exe" that I and the other Perl nerds I was hanging out with could poke and see real Perl 6 code running.
And for almost a year before perl6.exe arrived, I was arguing that Perl 6 was too hard for anyone to see as being "real", because there was no executable.
Now Perl 6 is seen as being real, but almost nobody is using it because there's no (as far as I'm aware anyway) easy downstream channels that the majority of people can use.
Every parrot/rakudo release should be accompanied (at the very least) by three to four packages. An
These should be prominently advertised in all the release announcements and be treated as the primary consumption mechanism for users. The tarball should be treated the same as it is for Perl 5, a special case for consumption by distribution packagers, and people with special complex needs.
Contributions by people outside the project is almost always going to be a function of the number of users. If the recommended installation method is for me to learn how to use a version control system I don't know, then checkout from the svn trunk, install a compiler toolchain, then build the product myself, then sorry but I just don't have the time to do that right now.
"I made it, you can use it" is just fine, but not if the use is limited to elites (which I most certainly am not).
Once I've started to use it and invested something in it, then there's an incentive for me to help improve it. But not before.
Re:My experience with Rakudo
mugwumpjism on 2009-05-29T03:16:57
Yeah, I don't know.. I don't think it's the responsibility of the upstream to maintain the distribution packages, too... looks like Allison is maintaining the parrot deb anyway though! Re:My experience with Rakudo
Alias on 2009-05-29T03:34:30
It's the responsibility of the upstream to make it both possible and (ideally) easy for the downstream to package it.
For your new project with no existing downstream channels, it's a fairly basic thing to engage with the people most likely to be your downstream and go out of your way to make life easy for them.
And for channels without an existing community to do any of the work (like Win32) it's probably going to mean doing it yourself, at least for the startup period.
Maintaining the channels are one of the first areas you are going to get contributors for, once the users at the other end start to depend on it.
Re:My experience with Rakudo
Alias on 2009-05-29T03:29:30
I should add that it's a perfectly reasonable point of view to state that because I'm not a contributor, or even a user, of Rakudo I don't really have any right to complain about it.
But unfortunately that still means I end up not using it.
Re:My experience with Rakudo
chromatic on 2009-05-29T03:44:01
You may have taken my comments the opposite way in which I intended them. I find it very interesting that the project with orders of magnitude fewer users has much, much more active development.
(By the way, I just fixed a pile of memory leaks in Rakudo.)
Re:My experience with Rakudo
Alias on 2009-05-29T05:16:35
What do you see the requirements of a "stable" release as, in terms of performance issues like memory leaks?
Re:My experience with Rakudo
chromatic on 2009-05-29T05:24:47
It'd be nice if "stable" releases never had bugs or regressions or memory leaks or misfeatures or incompatibilities, but that's not going to happen. If that's your criteria, you're going to find everything but TeX wildly unsatisfying.
Obviously you have to set your expectations for "stable" in terms of the project's roadmap, intended purpose, and intended audience, but with those caveats in mind, the single most important characteristic I see is "Does it do what the developers intend it to do so far?"
My criteria for a "stable" release is that it passes the test suite on all supported platforms and that it's better than the previous release -- even if "better" means only that "someone fixed a typo in a comment".
Re:My experience with Rakudo
Alias on 2009-05-29T06:19:05
I like to use the the same concepts, definitions and terminology for software bugs, regressions, memory leaks, misfeatures and incompatibilities as the medical profession does for human bugs, regressions, leaks, misfeatures and incompatibilities. The medical profession has a lot of experience with issues that present shades of grey.
For (medically defined) chronic conditions, like memory leaks, you can use assessment criteria similar to those for mental illness.
Many people present degrees of dementia, psychosis, and a plethora of spectrum disorders. The distinguishing factor is not if you present with the disorder, it's whether or not it is Debilitating, whether it is causing a substantive impact on your life.
Disorders that don't have negative effects on your lifestyle may be best left untreated (compared to the risks of side effects).
Likewise, as long as a memory leak isn't debilitating for the "lifestyle" of the user base, they don't necessarily require treatment.
Leaking a few K of circular references over the course of 24 hours is not debilitating for most use cases. Leaking 2gig in an hour will be a debilitating condition for a significant portion of the user base.
I'd suggest that when most people use the word "stable", they refer to a release that is free from debilitating defects for the majority of users and use cases.
Re:My experience with Rakudo
chromatic on 2009-05-29T07:10:37
I find quibbling about the definitions of words very dull, but....
I'd suggest that when most people use the word "stable", they refer to a release that is free from debilitating defects for the majority of users and use cases.
All I can find from you about these "debilitating defects" you found are two comments in IRC -- no bug reports, no messages to the mailing list, no description of steps to reproduce, no context as to what you were doing to trigger them. I started investigating Rakudo memory leaks in detail a few days ago when (I believe) Geoff Broadwell and Jonathan pointed me to a test case.
A defect so long underreported doesn't strike me as "debilitating" to the point of making software unusable.
Re:My experience with Rakudo
Alias on 2009-05-29T09:03:00
Nobody likes quibbling about words. It's just that your definition of stable seems to differ from many people.
I did a fairly simple three line program with a loop in it, and it consumed all my system memory in about a minute.
It possible that it's just me jumping to conclusions.
Because it did it so fast and so blatantly, and we were still at pre-1.0 releases, I just assumed that it was a known problem, and moved on because I lacked the time or skills to investigate it further.
I didn't really take the time to investigate if the Perl 6 test suite is using any leak detection modules.
Re:My experience with Rakudo
chromatic on 2009-05-30T17:45:12
I just assumed
I find it easier to merge duplicate tickets than to fix bugs no one tells me exist. (I have a decent history of fixing Parrot bugs, memory leaks, and performance problems.)
Re:My experience with Rakudo
Alias on 2009-05-30T17:38:57
I should add that this journal entries almost exactly describes my experience and demonstrates why I just assumed that it was something that was known about.
Re:My experience with Rakudo
pmichaud on 2009-05-29T13:14:09
For the record, I totally agree that Rakudo's current installation is very sub-optimal. Part of the reason for this has been that until recently (within the past week), Parrot didn't really provide sufficient hooks for us to be able to build and run Rakudo against anything but Parrot's build tree, short of doing a fair bit of copying things around and specialized linking to make it work.
I just haven't wanted to invest a lot of my time into building (temporary) scaffolding to work around the missing pieces of Parrot installation, especially when I have limited platforms available for me to test what works and what doesn't work.
With the recent improvements to Parrot's support for dynops and dynpmcs, I'm expecting that the next Rakudo release will have a decent "make install" target. Hopefully from that we can start to get people to build pre-packaged binaries for distribution, and scripts to create the pre-packaged binaries as part of our release process.
Pm
Which release is the "stable" release?
After seeing your blog post, I went to rakudo.org, and I see:
On behalf of the Rakudo development team, I'm pleased to announce the May 2009 development release of Rakudo Perl #17 "Stockholm". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1].
If not even the Rakudo announcements say that it's anything more than a developer release, then why would people be expecting Rakudo to be ready for more than fiddling around because they're interested in the future of Perl?
If Perl6 and Rakudo is the "now" of Perl, then it's time to treat it like something every day perl users consume, and not label it for tinkerers checking things out of SVN or building stuff marked as "developer" releases.
You can feel like the code speaks for itself all you want, but if the project as a whole isn't "marketing" itself as ready for the masses (and if it says "developer release," it's not...) then the general Perl-using populace aren't going to try using it in real-world situations yet.
I'm glad it's a healthy project for developers and perl forward-thinkers, but in the end, the project says "we're not ready to reach out to end-users just yet."
You say:
Number of stable Rakudo (Perl 6 on Parrot) releases since the Perl 6 project began in summer 2000: 17.
Patrick's latest release announcement says:
On behalf of the Rakudo development team, I'm pleased to announce the May 2009 development release of Rakudo Perl #17 "Stockholm".
(and the previous 3 announcements are similar - I didn't check further than that.
Re:Releases, yes. But stable?
chromatic on 2009-05-29T04:48:05
If I recall correctly, the intent behind the wording of Rakudo's release announcements -- as well as its version numbers -- is to reduce the possibility of people expecting that any monthly release represents the whole of Perl 6.0.
I hate the linguistic games around "stable" and "maintenance" and "development" almost as much as I hate the magical thinking around version numbers.
With that said, I use the word "stable" to mean "passes tests on supported platforms" and "performs as intended". It's not the final point of development, but it's a well-known collection of working features that represents a measurable improvement over the previous release. We don't randomly slap together a tarball because "it's been a while since the last release and we should get something out there." Similarly, my opinion (I will not put words in Patrick's mouth) is that "development" does not mean "Oh my goodness, someone please download this tarball and tell me if it works!"
Note however that the CPAN site implies strongly that Perl 5.10 is a testing release not intended for stable production environments.
Re:Releases, yes. But stable?
pmichaud on 2009-05-29T14:04:26
Rakudo uses the phrase "development release" primarily as a way of indicating "No, we aren't claiming that it's Christmas yet." More formally, it's an explicit recognition that there are significant portions of the Perl 6 specification that Rakudo doesn't support yet.
We don't (yet?) make any official claims about Rakudo's suitability for given purposes. Do I think Rakudo is ready today for a wide variety of general-purpose applications? No. Can I conceive that Rakudo today could be usable for more than just exploration of Perl 6? Yes. Do I expect to see an increasing population of Rakudo users (as opposed to explorers and developers) in the relatively near future? Definitely.
In general, with each Rakudo release we aim for the following:
1. Anything that is in the current Perl 6 specification and that worked in the previous release continues to work in the new release.
2. At least some new features or capabilities have been added over the previous release.
3. At least some bugs in the previous release have been addressed in the new release.
4. The overall build/install/usage/documentation infrastructure for Rakudo Perl has been improved.
Over the next few months I expect to have discussions and plans about when we'll switch from "development release" to using some other term that indicates that we think Rakudo has progressed beyond the "Innovators and Explorers" stage to being usable by Early Adopters [1]. And I think that switch will likely occur within the next 3-9 months (the imprecision here is due to uncertainty about what we need to achieve before making that switch, the stability of the Perl 6 specification itself, and our overall rate of development progress).
Pm
[1] http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
Was this blog post just a troll against perl5 development? Confused.
Re:Erm
chromatic on 2009-05-29T06:17:50
It's a serious question.
Very few people use Perl 6. Hundreds of thousands of people use Perl 5. Many businesses depend on it. (Yours does. Mine does.)
Why are Perl 6's developers able to make and meet commitments to release software and Perl 5's developers unable to do so?
There are many possible answers. Perhaps no one wants new releases of Perl 5. Perhaps it's impossible or infeasible to release stable versions of Perl 5. Perhaps publishing a ROADMAP or a rough schedule of Perl 5 releases is a bad idea. Perhaps Perl 5 is complete as it is, with nothing left to add or change.
I don't like any of those answers or their implications, and I'd like to figure out if they're fixable. Then again, perhaps I'm completely unreasonable and I should adjust my expectations. This would not be the first time.
Re:Erm
Ovid on 2009-05-29T07:07:29
These are just people's general opinions, from what I can tell. All these things can slow down development.
- Perl 5 has years of cruft built on arcane internals.
- Perl 5 bugs have a greater risk of breaking more people's code.
- Perl 5 has a lot more in the core and thus more to manage.
- Perl 6 can and does make changes to backwards compatibility without impacting their user base significantly. P5P argues long and loud (thank goodness) about risking this.
I could probably come up with several more reasons if I thought about it. At the end of the day, P5P has a huge responsibility and if they get it wrong, they will cause a lot of grief. Reasonable people can come to different conclusions about what the right answer is here.
Re:Erm
chromatic on 2009-05-29T07:14:43
All these things can slow down development.
Be careful not to fall into the trap of thinking that the pace of releases must precisely match the pace of development or vice versa. I have no objection to slow development nor careful development. I object to unsustainable development.
Re:Erm
btilly on 2009-05-29T23:16:27
Taking a look at the OpenBSD Timeline I count 18 stable releases since summer 2000, with the releases usually coming on a regular schedule. Please note that OpenBSD has more code to deal with than Perl, its development is more cautious than Perl, and it has a better reputation for quality than Perl does. Admittedly it is used by fewer people and has to work in fewer environments. But still it shows that a regular release cycle is possible for a project on that scale.
Re:Erm
Matts on 2009-05-29T14:01:38
Well Perl6's development process is new, and thus nimble and agile. Perl5's is slower because it has a lot more history.
Is it changeable? Probably.
Is it totally broken? Not really, though I do wish to see 5.10.1 some time soon!
A regular release is a nice thing to have, but it doesn't always create the most stable platform or the most confidence.
It might interest you to note that SpamAssassin has the same problem right now - it's been forever since the last release.
One thing I did think about with perl5 is that the number of required test platforms for all tests to pass is too high. It made me wonder if we shouldn't rely on vendors to fix issues with their platforms if they want the latest perl there. Such platforms would be: AIX, HPUX, Solaris, OSX, VMS. All of them are low-user platforms (with the possible exception of OSX, but they have a lot more money to throw at it).
Re:Erm
chromatic on 2009-05-29T17:27:06
One thing I did think about with perl5 is that the number of required test platforms for all tests to pass is too high.
I've come to the same conclusion. Platform-specific porters there do great work that I often don't understand, and I mean no disrespect, but sometimes the delay between making a commit and getting sufficient feedback from one of those platforms to have confidence in that commit is exceedingly long. I believe that's a function of a low number of available porters.
This problem seems to affect the standard library (mostly a few culprits) more than anything else.
[Perl 6]'s development process is new, and thus nimble and agile....
Certainly. We have the luxury of saying that we can only support fairly recent releases of the big three platforms (free Unixes and Unix-like OSes, Windows, and Mac OS X) while calling for porters for other platforms. We also don't ship a large core library at attempt to keep it synchronized with the CPAN.
Read between the lines of that paragraph carefully for a handful of proposed parts of a solution. Nothing technical blocks any of them.
