My little application (10 Years Later, Only 250 SLOC) has grown to almost 500 SLOC, and it'll grow some more as I add user accounts and login. I'm happy to use Catalyst for the dynamic portions, as the abstractions and plugins are useful and reduce the amount of code I have to write.
Using modern Perl for one portion of the project does not necessarily require the use of Perl for all of the project.
I used to be an advocate of Perl 6, the language. Was it worth using Perl 6 for the other part of the project? The big contender was obviously Rakudo, because it is the most active project and runs on a free software stack I can debug myself. (The other possible candidate implementation, Niecza, runs on Mono, which disqualifies it from my considerations. Your personal technology choices may not be mine. I have no interest in discussing Mono here.)
I posted the other day my list of requirements to use Rakudo for practical purposes. What do I need technically?
This little app must:
- Communicate with a database. I don't necessarily need DBIx::Class for a project of this size, but I do need the ability to work with SQLite now and PostgreSQL later. Without DBIC, I'd have to do more work mapping tables and rows to objects, but the schema is simple enough it's not too onerous.
- Communicate with websites. I do need the equivalent of LWP. While I do use at least one specialty web service consumer module from the CPAN, I could as easily perform HTML scraping.
- Manage regular expressions, not grammars. Part of the project requires HTML scraping. If I were prone to overengineering, I'd write a full grammar for this. As it is, some quick and dirty data munging is more than sufficient right now for this proof of concept.
- Work with a decent templating system. I know there's no Template Toolkit system for Rakudo, but I don't use all of TT's power. I need only a few features: variable interpolation, loops, conditionals, and subtemplates. If I had to reinvent a template system or work around it I could, but why would I want to? (I am in no mood to reinvent HTML escaping or to correct UTF-8 encoding either.)
- Work with dates and times. I use Perl's DateTime. Never again will I reinvent date or time handling. Never.
- Deploy easily. I use Dist::Zilla to manage bundling and testing. The simpler the work to deploy new versions and corrections, the more frequently I will do it. Again, Dzil does far more than I need, but what it needs I hate to give up.
Speed doesn't really matter for this application. It's a batch process which runs once a day and takes 10 seconds in Perl, mostly because I haven't done any work to exploit the embarrassingly parallel nature of the processing. If Rakudo ran it in ten minutes, that would be fine. (With that said, the data set will probably eventually scale by two orders of magnitude, so improving the Perl version's parallelism is useful but would likely help a Rakudo version less.)
Memory use does matter, because I've deployed this application to a shared server and want to be a good citizen.
The stability of Rakudo as a target platform also matters, because I've set up this program to run without manual intervention for days, weeks, and even months. I understand that one of Rakudo's goals is to produce new and better versions every month or so, and I understand that me babysitting a Perl 6 version of this little app would provide valuable feedback to Rakudo developers...
... but I can't justify turning a fire-and-forget tiny side project into the tip of a spear intended to open the tent for further, larger projects.
I could work around the lack of most of the few modules I need. (Database access is the only real sticking point.) Yet even for a small side project—a toy project, even—with minimal needs, I find myself not wanting to use Rakudo because I'd rather spend my small side project time working on the small side project and not trying to get the technology stack beneath that small side project to stay put.
The conventional wisdom in #perl6 has long been that P6 needs more people playing with it to find bugs and more people building its equivalent of CPAN to attract more people to play with it. In my experience, that misses the point. After over a decade of development, P6 hasn't even produced anything which provides what Rakudo Star was supposed to be. Even years after the first Rakudo Star release, it isn't that.
Maybe your project is different, and maybe your needs are different from mine. Maybe you won't find Rakudo buggy, incomplete, unstable, and slow. Maybe you don't mind babysitting code which won't run in a month because the specifications are still changing after a decade and a half.
All I know is that P6 is still looking for people who don't mind that level of pain. I think they'll be looking for a long time.
Don't be disappointed, please! :-)
We're currently having courses with Damian in Zürich, Switzerland - excellent courses, by the way - and quite often it comes to the question if Perl6 does xyz better than Perl5. Or if an issue is fixed. And the answer keeps being "yes, it does, yes it is."
I come to the conclusion that if you try to get something really really right, then it will take a whole lot of time. If you look at it this way, the time it has taken to develop Perl6 means that really many things will be done right.
I sincerely hope that Perl6 will have its moment of breakthrough really soon. Until that happens I'm happy to make the best out of Perl5 which is already a lot!
What I am personally disappointed (with myself) is that I don't find time to help out with development..
:m)
Perl 6 is a better language than Perl 5, but I still feel disappointment in that a year after the first release of Rakudo Star, I can't justify using Rakudo even for a small project which would otherwise seem like a great fit.
So after about twenty years of Perl 5 development and its respective ecosystem, you were honestly expecting the same level of ecosystem after one year of Rakudo Star?
You overstate things I explicitly disclaimed.
After one year of Rakudo Star, I expected to be able to deploy it for small, simple projects. I understand the risks and requirements of early adoption, but I can't justify using Rakudo right now. After eleven years of waiting for Perl 6, eight years of working on Parrot and Perl 6, and a year after the first release of Rakudo Star, that's very disappointing.
I'm wondering to what extent your objections apply to the following I found through the Perl 6 Modules directory at http://modules.perl6.org/. Do you mind commenting on what makes the following candidate modules fail your criteria? I'll freely admit I haven't used a single one (which says something in itself), but your opinion is useful (as explained below).
Database:
* DBDI (is SQLite the only blocker here?)
HTTP Client:
* LWP::Simple
Regular Expressions:
Not really sure what you are looking for here.
Templating:
* HTML::Template: Simple port of P5 equivalent
Date Parsing/Manipulation:
* DateTime::Utils
* DateTime-Parse
Deployment:
None jump out from a simple find in the modules page. I think this is the easiest to hand-roll a simple solution specific to your needs though.
I'm not trying to imply that these necessarily fit all your needs, but I assume you've seen them at some point, and may have had a chance to assess them in some respect. When I read your post, my first impression was that simplistic versions of those aren't necessarily hard to provide, and that's a good list of core modules to provide a good minimal environment for a simple web app. I would like to help address that need, but knowing where others have failed (or succeeded!) should be the first step on that journey.
I can't trust the Panda ecosystem given the abandonment of Rakudo master and the instability of Rakudo nom.