On Mon, Oct 6, 2008 at 5:49 AM, Elyse M. Grasso <[EMAIL PROTECTED]> wrote: > My company sells an application that links a bugtracking tool with an SCM tool > so that, for example, the files changed for each bug are recorded in the > bugtracking tool. It is currently written in (mostly) non-object-oriented > perl5. > > We are re-architecting the application so that it can work with different > bugtracking tools and SCM tools, and do things like sync data from specific > fields between a help desk tool and the bugtracking tool. This would be a good > time for us to transition to perl6. > yes, it seems perfectly reasonable to consider language choices when re-designing your product's architecture. certainly, the perl 6 specification makes it an attractive choice.
> As far as I can tell from the various faqs and wikis, the existing > functionality in rakudo should support most of our needs for the initial > release. I may need to assist with the porting of some database access and > other modules from CPAN to C6PAN in the longer term. > the core functionality of rakudo may support what you need, but at this point i have some concerns with chosing rakudo as the runtime for a client-facing production product. mainly, there are un- and under-tested portions of the language implementation, which to me suggests that there are bugs lurking as it hasn't been proven otherwise by passing tests. this isn't to suggest that rakudo is not ready for use, but it is a risk--until we (rakudo project team) have higher test coverage and more passing tests. anybody can help, by adding tests which cover the official perl 6 specification (http://spec.pugscode.org/) to the pugs repository (http://svn.pugscode.org/). anyone who is interested can get commit priviliges to the repository; the procedure is simple, and approval is always granted. feel free to contact this list with a commit bit request. also, there are a number of us with experience writing tests that cover the spec, and we're happy to share our knowledge on the subject. porting modules to perl 6 definitely needs some help. currently there is no c6pan, there is only the pugs repository, where some previously ported modules live. i haven't seen much visible work on c6pan lately, and i'm sure there's no solution nearing production. this means it's best to package any required modules with your product rather than relying on an external resource to provide perl 6 modules at build/configure/install-time. > However, I am concerned about deployment of a perl6 based product to > customers. Perl5 can be reasonably specified as a prerequisite for loading our > application, since it is generally available (and shipped with some of the > products we integrate). That is not the case with Perl6. > this is another case for concern, for sure. parrot's installation code is not extremely robust, but is improving quickly. as of last month's release (0.7.1), parrot is released as a source distribution from the source repository (http://svn.perl.org/parrot/tags/RELEASE_0_7_1), a CPAN module (http://search.cpan.org/~pmic/parrot-0.7.1/), a windows installation package (http://parrotwin32.wiki.sourceforge.net/), a cygwin package (libparrot0 and libparrot-devel), and a debian package (http://packages.qa.debian.org/p/parrot.html). these installation methods are in varying states of maturity, and all are being actively improved. depending on your user system requirements, these methods may work well for you. i suggest investigating further. > Is it practical now to deploy a Perl6/Parrot runtime with a (possibly > precompiled) version of our product? Will it be practical any time soon? I can > probably get away with occasionally requiring Linux and Solaris users to > rebuild Parrot to fit their local configuration, but Windows is another > matter. > (Shipping a known version of the runtime with our product will also allow us > to tune our application to a known set of available perl6 functions.) > possible? yes, definitely. practical? that's hard to say. if parrot and rakudo meet your functionality needs, and the packages are available, then yes. however, i can't call it practical until i've tried it successfully at least three times in simulated user environments. > The mechanism for generating the packages I ship to my customers does not need > to be pretty, it just needs to exist. If there are instructions already online > about how to generate such packages (now or in the near future), I would > appreciate a pointer to them. > parrot has a guide for creating the monthly release package, and there is a guide for debian packaging as well, found at http://svn.perl.org/parrot/trunk/docs/project/). questions here or on other related mailing lists are most welcome. if, during the course of your further examination of parrot and rakudo, you develop concerns on stability, portability, packaging, completeness or other topics, there are multiple ways to address those concerns. firstly, the mailing lists are an excellent resource, as well as parrot's and rakudo's bug tracking systems (http://rt.perl.org/rt3/). however, if you want targeted development/design/training to address your company's needs, donations to the perl foundation (http://www.perlfoundation.org/) and parrot foundation (http://www.parrot.org) can produce wonderful results. for an example, see patrick michaud's perl 6 development grant final report (http://www.pmichaud.com/perl6/mfp6grant.pdf). as president of parrot foundation, i'd be happy to discuss this topic more. additionally, there are for-profit companies (like mine, http://www.rakudoconsulting.com) that offer services including targeted development on rakudo/parrot features and maintenance plans that give you the confidence you need to adopt a new technology and succeed, without the constraints under which a non-profit foundation operates. i'd be happy to discuss the specifics of what rakudo consulting group has to offer your business in an off-list discussion. ~jerry
