Comment Re:SQL Ledger (Score 1) 399
OK, the point that you're replying to wasn't expressed very well. There is a substantial difference between a language being used to write software in using weak data types, and a language being used to "software engineer" a product that has weak data types.
I think the point was, Perl is difficult to engineer and do all the maths with around pre- and post-conditions as opposed to something like C, because there are lots of things going on that might not be immediately obvious and so it's hard to write the formal specification for.
The question is, does an accounting package need to be software engineered - if you look at the Changelog for SQL-Ledger (I've never heard of it before, but just took a look), you'll notice some interesting changes - e.g. "added code for debit and credit balance check to get rid of out of balance error where there is none. Apparently computers don't always know that 14.05 plus 1.96 is 16.01 and not 16.0000000000997" - now that sort of thing should just plain not happen in any accounting system.
Perl is a beautiful language, but if you need to be certain without any doubt that it will behave 'correctly' and 'completely' with any input data that might be put in, then Perl might not be the best language to get that kind of proof for. C however (ignore OO for this discussion, or we'll be going all over the place), does allow you to be a little bit more mathematical about the whole process though.
I think the point was, Perl is difficult to engineer and do all the maths with around pre- and post-conditions as opposed to something like C, because there are lots of things going on that might not be immediately obvious and so it's hard to write the formal specification for.
The question is, does an accounting package need to be software engineered - if you look at the Changelog for SQL-Ledger (I've never heard of it before, but just took a look), you'll notice some interesting changes - e.g. "added code for debit and credit balance check to get rid of out of balance error where there is none. Apparently computers don't always know that 14.05 plus 1.96 is 16.01 and not 16.0000000000997" - now that sort of thing should just plain not happen in any accounting system.
Perl is a beautiful language, but if you need to be certain without any doubt that it will behave 'correctly' and 'completely' with any input data that might be put in, then Perl might not be the best language to get that kind of proof for. C however (ignore OO for this discussion, or we'll be going all over the place), does allow you to be a little bit more mathematical about the whole process though.
