Hi, Anonymous Monk. SQL Ledger was actually the very first package that we evaluated. We were very impressed with its long list of features. However, "features" are only part of the package. This is a short list from my initial review of the code.

• Poorly written
• Doesn't use strict
• Extensive use of global variables
• Has security concerns
• Is non-portable
• Hand-rolled template system
• Difficult to test
• Will be difficult to extend
• And guess how it handles CGI data ...

You are absolutely correct that OSS doesn't appear to have been terribly successful with accounting software. In the defense of the people responsible for SQL Ledger, the above list is not unique to their product.

Now, if only I could find an accounting package with a test suite ... any test suite.

Cheers,
Ovid

Update: Just to let people know that I am not being too picky, here's a sample of code from admin.pl in SQL Ledger.

# customization
if (-f "$form->{path}/custom_$form->{script}") {
  eval { require "$form->{path}/custom_$form->{script}"; };
  $form->error($@) if ($@);
}
[download]

You'll notice that we are using eval on data from a hashref named $form. As one can imagine, this data has been pulled (incorrectly) straight from a Web form. It is also tainted (or would be if taint checking were used). Due to how feature-rich this code is, working to track down all of the security holes (such as unvalidated and improperly quoted data being used in SQL statements) would take so much time that I'd rather start with a better written, but less feature-rich package.

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

I just had a little look through the SQL Ledger source, I think you're review was too nice. Excuse me while I go find the people who recommended it to me =D.

With regards to the lack of strict, it does slow down execution time right? So, as long as it's included during development is it that big of a deal if it's removed (or preferably commented out) and just switched back on when changes are being made/tested?

The relative importance of strict is a tricky thing to assess. For example, every once in a while, I see people using a scalar reference ($$x). However, if $x is actually a string in that example, Perl will treat it as a symbolic reference. Results can be very unpredictable.

Of course, I'm taking a very unusual scenario there, so that's not fair :)

If the code was developed under strict, I would argue it should be left in. If performance is an issue, Devel::Dprof, Devel::SmallProf and Benchmark will likely do far more for improving performance than removing strict. However, there is no need to worry about performance unless it has demonstrably become a problem. Too much Bad Stuff has made its way into the programming world because of false optimizations made in the name of performance.

Some people routine write such weird stuff that repeatedly turning strict off and on would be a hindrance for them, so they leave it off. Mere mortals such as myself should not consider that route.

Of course, since I can't seem to shut up about testing, I'll add that if variables are properly declared and good scoping rules are enforced, I wouldn't mind strict being absent if a decent test suite was present. I've yet to see any OSS accounting package with such a suite.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

The effect of use strict occurs only at compile time, when Perl parses the source code and creates its internal representation. It does not change the execution speed of that code at run time. If the slowdown caused by strict is really a problem, the application can be designed in such a way that the code is only compiled once for a large number of operations. Depending on the application requirements and architecture, there are a number of ways to do this including turning the application into a long-running daemon or running it under mod_perl if it is a web application.

The big deal if use strict is removed is that it is only a matter of time before somebody decides to try to "fix" a bug in production code without bothering to re-enable strict. When that happens, and it probably will in most deployment environments, the risks of not using strict will far outweigh any potential slowdown from using it.

Besides, in what situation is the speed of an accounting application ever going to be more important that its correctness. I'd much rather have the code dealing with my money protected by the safety afforded by strict than have the code run a little faster.

Update: changed "executions" to "operations" in the first paragraph.

Anyone with (or without) accounting knowledge up for creating an Open Source Perl alternative if nothing suitable is found?

I'd say that without accounting knowledge you're going to be pretty hard pressed to do a whole hell of a lot for an accounting package.

I've had to play accountant a few times here at work and "the books" made less sense to me than some of the Perl obfu's here. : )

Seriously though, it's not something I think I'd trust if the person didn't have some accounting background behind them that was doing the work. Just my opine.

There is no emoticon for what I'm feeling now.

No kidding. I'm still having trouble figuring out how somebody just notices that they don't really have $7-10 billion that they said they had, or that other people thought they had. I mean, When my bank account goes under by $5, I get charged $30 and that's that. I tried the "no really, I've got $18 million in there!" angle, but no dice. So I'm clueless.. how do you botch so much money?

Perhaps Corporate America needs a real accounting package. Perhaps they need perl.
-=rev=-