On Mon, Oct 6, 2008 at 5:49 AM, Elyse M. Grasso
> 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

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

> 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

> 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

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.


Reply via email to