|XP is just a number|
Re: Migrating from Perl to other language? Why would someone do that?by einhverfr (Friar)
|on Nov 22, 2013 at 14:12 UTC||Need Help??|
We get this question a lot on LedgerSMB as well. We are Perl/PostgreSQL and have no intention of migrating the core implementation to another language or database framework. Well... we are trying to migrate it to sane Perl code (you should have seen it before the fork!) but this takes time and effort, and our design for new code is very post-modern...
But keep in mind we are writing big software. Our codebase has hovered around 200000 lines of code through the last several years and will at some point start to rise significantly. It also depends on software that for a typical install being quite large. ERP and accounting software is not a small thing. But Perl is excellent for this because it lets you move in and out between a heavier software engineering mode and a light-weight scripting mode, and our software leverages both of these. That is an immensely powerful thing.
I think there are actually a few reasons people object to Perl. The first is that there is a lot of bad Perl code out there. The project that we forked from was essentially a textbook on how not to program, especially in Perl. This is something we have to be honest about. Since Perl is good for quick and dirty one-off scripts, these areas don't usually admit to the time and effort in engineering, and are often done by sysadmins who don't have much experience maintaining code. So you get bad code that works but gives people nightmares.
I think the second problem that we face is that people remember "Perl as the language of CGI" and therefore see us as "so last-century." Like the bad code issue these two things give people the impression that we are a premitive precursor to PHP or something and therefore they don't tend to see what we have to offer.
In my experience (having done some programming in PHP, Python, Ruby, and others, and a lot of programming in Perl) are largely without merit. PHP has a mindnumbing number of gotchas, and Python tends to treat things as implicit references in ways that introduce very subtle and hard to find bugs. Ruby is not a bad language, but it suffers from frameworks (Rails, I am talking about you) which cater to those who are phobic of designing software.
None of these offer the multi-paradigm support that Perl offers. With Perl you can write object-oriented code, functional programming code, aspect-oriented code, and more, and you can merge the ideals of the paradigms in a way that makes sense for your project. However, this is also the hardest part of the language to master.
What we decided to do with LedgerSMB was to break off our database access layer into more generally applicable modules (see the PGObject top level namespace for a rough idea of what we have broken off, as the five modules currently there are closely modeled on existing LedgerSMB code), and port those libraries to other languages. We aren't moving away but it is just a recognition that many clients may have Ruby or Python apps that need to interoperate and so the service locators are helpful in this way if ported. For these users, the major issue is just that they know and are more comfortable with other languages. There is nothing wrong with that.