Re: [gentoo-user] New project in perl? {OT}

[Stroller]

On 1/1/2011, at 10:34pm, Grant wrote:
> ...
> I'm starting a new project that is quite straightforward and will
> interface with an old project.  The only point of contact between the
> two projects might be both of them having access to the same database
> table.  The old project is written in a language that is related to
> perl so I can imagine there would be some benefit to using perl for
> the new project.  Am I foolish to start a new project in perl at this
> stage in its lifecycle?  I won't be doing the coding myself and I
> wonder if I would be better off with PHP since more coders seem to be
> familiar with PHP than perl.

I'm not sure if I've mentioned before, but I picked up Perl fairly recently (within the last 12.5 months) although I haven't done *that* much with it.

I *really* like Perl. It feels extremely robust and "right".

I originally picked up Perl in order to parse the output of another program and build an HTML table based on that data. The other program happened to be written in Perl, too, but I figured that Perl was a good choice because it was supposed to be good at parsing (and parsing was the job I was trying to do). I started out parsing this output, and it turned out that the program I was depending on didn't give enough information externally this way. So I had to modify the original program, and add the feature I needed - I was able to do so really fairly quickly, and soon had my first submission (a patch of maybe 200 lines) accepted into an open-source project. Well, I guess vgetty distributes a shell script of mine in its contrib directory, but this felt much more of a grown-up achievement. Doing this in Perl felt really accessible to me, being able to complete this task within hours [1] of picking up the language. 

The "stage of Perl's lifecycle" is not anything to be worried about. Perl may not be a "cool" language, but it isn't going away. Perl 5.x.y will be maintained for a long time; Perl 6 is in development.

On the other hand, you can easily find Perl developers who have been using the language in industry for a decade. You can write bad code in any language - Perl has a reputation for opacity but, y'know, Greek sounds pretty opaque to me, that doesn't mean it's a bad language. To be honest, I think the "problem" is that Perl can be really terse, and that's why newcomers to a codebase have problems understanding it, but I'm inclined to think of Perl's terseness as a *good* thing. From the code I've read on the net, the advice I've received from Perl programmers, I tend to feel the average code quality of Perl developers is higher than that of the average coder in some more fashionable languages, such as PHP or Python. I would think that if you were to contact your local PM group you would find someone who writes pretty good code and who will provide references. http://www.pm.org/groups/

Perl has a big library of modules for interfacing with databases. Your guy should use as many of those as he needs to, and not reimplement things from scratch. Beware of people who "write their own" libraries or who "prefer to do it for themselves" - there are some extremely sophisticated and well-maintained modules in CPAN.

Stroller.



[1] Not the same day, but within only a few hours of actual using the language, for large values of "a few".