Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Re: (OT) Perl Open Source accounting packages?

by Ovid (Cardinal)
on Oct 10, 2002 at 21:29 UTC ( #204342=note: print w/replies, xml ) Need Help??

in reply to Re: (OT) Perl Open Source accounting packages?
in thread (OT) Perl Open Source accounting packages?

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.


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

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

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.

Replies are listed 'Best First'.
Re: Re: Re: (OT) Perl Open Source accounting packages?
by Anonymous Monk on Oct 10, 2002 at 22:24 UTC

    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.


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

        Thanks for the reply, I'll check out those modules and keep strict around for the time being :).

      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.

        strict 'vars' and strict 'subs' are compile time directives. However, strict 'refs' has runtime implications. See strict.


        Excellent explanation, thanks :).

    A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://204342]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (2)
As of 2021-03-07 10:18 GMT
Find Nodes?
    Voting Booth?
    My favorite kind of desktop background is:

    Results (120 votes). Check out past polls.